spring-projects/spring-security · error · IOException
SAML payload exceeded maximum size of
Error message
SAML payload exceeded maximum size of
What it means
Saml2Utils wraps its output stream in a CappedOutputStream that counts written bytes and aborts once they exceed MAX_SIZE, protecting against decompression-bomb attacks when inflating SAML payloads. When the inflated data would exceed the cap, write() throws IOException('SAML payload exceeded maximum size of ' + MAX_SIZE), which callers wrap into 'Unable to inflate string'.
Source
Thrown at saml2/saml2-service-provider/src/main/java/org/springframework/security/saml2/provider/service/web/Saml2Utils.java:212
}
static class CappedOutputStream extends OutputStream {
private static final long MAX_SIZE = 1024 * 1024;
private final OutputStream delegate;
private int size;
CappedOutputStream(OutputStream delegate) {
this.delegate = delegate;
}
@Override
public void write(int b) throws IOException {
if (this.size >= MAX_SIZE) {
throw new IOException("SAML payload exceeded maximum size of " + MAX_SIZE);
}
this.delegate.write(b);
this.size++;
}
}
}
View on GitHub (pinned to 96852e8860)
Solutions
- Treat this as suspicious input: log the source IP and reject the request with HTTP 400 rather than retrying.
- If legitimate payloads genuinely exceed the cap, upgrade Spring Security — MAX_SIZE has been raised in newer versions — or use a version whose limit fits your largest real payload.
- Do not remove or enlarge the cap blindly; instead validate/trust the sender (signature verification happens after decode) before accepting larger payloads.
- Catch Saml2Exception/IOException around inflate and return a generic 400 to avoid leaking internals.
Example fix
// before (default cap too small for legit large responses)
String xml = Saml2Utils.samlInflate(decoded); // IOException: exceeded maximum size
// after
// upgrade dependency so MAX_SIZE accommodates legit payloads
// implementation 'org.springframework.security:spring-security-saml2-service-provider:5.8.x/6.x'
// and add handling:
try { xml = Saml2Utils.samlInflate(decoded); }
catch (Saml2Exception e) { response.sendError(HttpServletResponse.SC_BAD_REQUEST); return; } Defensive patterns
Strategy: try-catch
Validate before calling
if (b64 != null && b64.length() > EXPECTED_MAX_B64_LENGTH) { response.sendError(400); return; } Try / catch
try {
String xml = Saml2Utils.samlInflate(decoded);
} catch (Saml2Exception | IOException ex) {
securityLog.warn("Possible decompression bomb from " + request.getRemoteAddr());
response.sendError(HttpServletResponse.SC_BAD_REQUEST);
} Prevention
- Keep the size cap enabled; never remove it for production endpoints
- Log and alert on repeated oversized payloads per source IP
- Keep Spring Security updated so the cap reflects current upstream limits
- Perform signature verification before trusting large payloads
When it happens
Trigger: Inflating (samlInflate / withDecoded(...).inflate()) a compressed SAML payload whose decompressed size exceeds MAX_SIZE — either a legitimately huge payload or a malicious decompression bomb submitted to a redirect-binding endpoint.
Common situations: An attacker sends a small highly-compressible SAMLRequest to exhaust memory (the attack this cap exists for); an unusually large signed response (big metadata/embedded certs) legitimately exceeds the limit in an older Spring Security version; repeated retries with the same oversized malicious payload from a vulnerability scanner.
Understand the failure class
Background: payload too large / request exceeds maximum size: why libraries cap bytes and how to fix oversize payloads — this error's family across 50 libraries.
Related errors
- SAML payload exceeded maximum size of
- SAML payload exceeded maximum size of
- internal_validation_error
- malformed_response_data
- decryption_error
AI-assisted analysis of spring-projects/spring-security@96852e8860 (2026-09-10).
Data as JSON: /api/errors/70636c7e46639564.
Report an issue: GitHub.