OpenSAML Security Advisory [13 May 2026]

[Scott Cantor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

OpenSAML Security Advisory [13 May 2026]

An updated version of the OpenSAML Java library is available
which includes explicit features and updated defaults to correct
a denial of service vulnerability that can cause unconstrained
resource consumption using XML that exceeds typical limits on
certain kinds of content.

Maliciously crafted XML causes excessive resource consumption
=============================================================
While the XML parser in newer versions of Java includes default
settings that limit certain kinds of malicious content, older
versions did not and so can be vulnerable to specially crafted
XML. These default settings are in any case not set low enough
to be safe in this usage context.

The OpenSAML library's decoding of SAML and SOAP messages is
unprotected in its default configuration from such content and
parsing some messages can result in memory and/or CPU exhaustion,
causing a denial of service in applications using it.

Most/all applications using OpenSAML to parse SAML messages may
be vulnerable to this issue.

Since most XML message types are parsed either without the
protection of a signature or in advance of evaluating one, the
exploit does not require an authenticated attacker and so is
serious, though as a denial of service issue it remains in a
lower tier of vulnerabilities.

An updated versions of the OpenSAML Java library (V5.2.2) is
available which establish new defaults for these two parser
settings when using the OpenSAML internal ParserPool instance:

* jdk.xml.elementAttributeLimit (default 30)
* jdk.xml.maxElementDepth (default 25)

These properties are supported by Java 17 and later, the minimum
Java version supported by the library. We believe the parser
properties alone are sufficient at present to mitigate this issue.

However, note that *only* the ParserPool object installed into
the OpenSAML library configuration is configured with these settings.
If your application does its own XML parsing, then you are *not*
protected and are vulnerable to this and many other security risks
that you are solely responsible for mitigating. This is something
we strongly advise against doing.

In addition, the library has been enhanced with several new options
that can be set to control the size limits on various types of SAML
and SOAP messages being decoded. Those options are not enabled by
default, but are present in case they are needed in the future.

Recommendations
===============
Update to V5.2.2 of the library. The updated default settings on the
internally configured ParserPool are deemed sufficiently safe at this
time, but *only* under the assumption that the library's ParserPool
instance is always used.

Another mitigation if our ParserPool is not used is to directly configure
size limits on the MessageDecoder classes in use, but we have not explored
the efficacy of this approach.

In the event that upgrading is not possible, for this immediate issue
one can set the two properties noted above as system properties on the
command line (typically via a -D<option>=value addition to the
relevant process' startup command).

Note that this will impact all uses of JAXP in the process globally,
which can of course create problems when parsing other content that
might be expected to exceed limits.

Note also that we do not know the specific older versions of Java that
support these parser attributes, and they are known to have gone by
different names in some older versions prior to Java 17. If you are
on an unsupported, older version, refer to the relevant JAXP parser
documentation in that Java version for details.

Credits
=======
Jens Friess and Haya Schulmann, Goethe University Frankfurt.


URL for this Security Advisory:
https://shibboleth.net/community/advisories/secadv_20260513a.txt

-----BEGIN PGP SIGNATURE-----

iQJPBAEBCgA5FiEE3KoVAHvtneaQzZUjN4uEVAIneWIFAmoEvOQbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMCwzAAoJEDeLhFQCJ3lid0IP+QHX1w1VoGnaUNNNBfS/
8cw8H43YwWv98dBaKGOd0BJLxCu0uY1yr/5+xMfLI4e11Ya7JnK50QFY2Gc/sIQi
EGv6/ad6tqyJwYbQyN93R0v2KVleqvOhkW/BCDEkYa8LVN22z001NRc55leFasm6
NqeJ27zJICMa/8Cq+efr8AT2Bzj29gYGw9XToKVDouFh5sm4ErpQl6n0rHA2EbRe
P32HkoEFVFcwgHrZ8z1G1fcCbiM8dIdB4XqkebdkKEPUiR1j5b8GLeMdv6MehDLS
97sLYJiB+RrwfUZDhJY2JC98GSFnQlifWeiw0cmObYz9lsc5lL7KqHK43vc3ZwXT
sXaoWvYguKCyHi8IuvdAM78H71L4qm1WdlBPobpqeSWNw0aJI/sjGmO43snDcni2
kgLFfXaXRZeQof22mGiQA0kbjkD28couvjjucVEd/tl/uQoiZ4JNvzFInb6z5udZ
p1i7mZQDe4fbSlTIwl2Eoalhj3hsZsHLLHCPzdC7cpLbDTlCzDMKzMLKofbOG70z
xLZj0Nco3OJXlWaA6ceMvjE5YrD3JX8PHPr+c0hrS9Qxch0nuzUt6hHhGST+RA7L
3Wk1nEbalduDfcLchDxfkNXEDSxo1oFbVOi00cnvaQb2s3GZKm4bBjUvsZ4xel/B
3CbNRJh14PMohwnHDx/lf4YC
=tHXg
-----END PGP SIGNATURE-----