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

  1. Treat this as suspicious input: log the source IP and reject the request with HTTP 400 rather than retrying.
  2. 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.
  3. Do not remove or enlarge the cap blindly; instead validate/trust the sender (signature verification happens after decode) before accepting larger payloads.
  4. 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

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


AI-assisted analysis of spring-projects/spring-security@96852e8860 (2026-09-10). Data as JSON: /api/errors/70636c7e46639564. Report an issue: GitHub.