CVE-2026-97791: Apache CXF: STSTokenValidator can accept untrusted SAML assertions because it shares validation state between requests
In Apache CXF, STSTokenValidator checks whether a SAML assertion is signed by a trusted certificate before deciding to send it to the STS. That result was stored in one object shared by all requests, so one request could read another's result. A remote, unauthenticated attacker could send a forged assertion signed with an untrusted certificate while legitimate requests were being processed, and it could be accepted as trusted without ever reaching the STS. Only services that use STSTokenValidator to validate SAML tokens without alwaysValidateToSts set are affected. Users are recommended to upgrade to versions 4.2.4 or 4.1.9 or 3.6.13, which fix this issue.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Apache CXFto a version that resolves this vulnerability.Fixed in 4.2.4 - Upgrade
Upgrade
Apache CXFto a version that resolves this vulnerability.Fixed in 4.1.9 - Upgrade
Upgrade
Apache CXFto a version that resolves this vulnerability.Fixed in 3.6.13
Event History
Frequently Asked Questions
Which deployments are affected?
Only services that use STSTokenValidator to validate SAML tokens and do not have alwaysValidateToSts enabled are affected. The issue is tied to validation state shared across requests.
What does an attacker need to exploit this?
A remote attacker does not need authentication. They need to submit a forged SAML assertion signed with an untrusted certificate while legitimate requests are being processed, so that another request's trust-validation result can be reused.
Does enabling alwaysValidateToSts mitigate the issue?
Yes. The affected condition is specifically use of STSTokenValidator without alwaysValidateToSts set; enabling it avoids the described affected configuration.
Which versions contain the fix?
Upgrade to Apache CXF 4.2.4, 4.1.9, or 3.6.13.