CVE-2026-50627 is a missing audience check (CWE-303) in the Apache CXF JwtAccessTokenValidator, scored 9.1 critical. A token issued for one resource server can be replayed against another. Upgrade to CXF 4.2.2, 4.1.7 or 3.6.12, then confirm that your servers check the aud claim.
What's affected
Apache CXF, in the cxf-rt-rs-security-oauth2 module. The project announcement lists 4.2.0 before 4.2.2 and anything before 4.1.7. The CVE record adds the 3.6 line and names 3.6.12 as the fixed version.
Fixed versions: 4.2.2, 4.1.7 and 3.6.12. The project rates it important, while NVD scores it 9.1 with a high privilege requirement, so the score depends on the attacker already holding a valid token for some service.
Only applications that use CXF as an OAuth2 resource server and validate JWT access tokens through this class are involved.
How to check if you're exposed
Find out which CXF version your build resolves. For Maven:
mvn dependency:tree -Dincludes=org.apache.cxf
For Gradle:
gradle dependencies --configuration runtimeClasspath | grep cxf
If the cxf-rt-rs-security-oauth2 module appears at a version below the fixed ones, you are on an affected release. Then search your code and configuration for JwtAccessTokenValidator to see whether the class is in use.
You can also run the free in-browser dependency scan or browse the Gold directory to see where this component shows up in your stack.
What to do now
- List every service that uses CXF OAuth2 and read the resolved version of
cxf-rt-rs-security-oauth2. - Upgrade to 4.2.2, 4.1.7 or 3.6.12, depending on your line, and rebuild.
- Run your tests with a token issued for a different service and confirm it is now rejected.
- Where you cannot upgrade yet, add your own check of the aud claim against the expected audience before trusting the token.
- Review how your authorization server sets audience values, since a validator can only check what the issuer puts in the token.
Why it matters
Tokens carry an audience claim so each resource server knows a token was meant for it. If a validator skips that check, a token from one service can be presented to another that trusts the same issuer. This is a case of CWE-303, an incorrect implementation of an authentication algorithm, and CWE-289, an authentication bypass by alternate name.
The damage depends on how many services share an issuer. In a flat environment with many APIs behind one identity provider, one stolen or over-scoped token can reach much further than intended. The record does not flag the CVE as exploited in the wild, and it is not in the CISA Known Exploited Vulnerabilities catalog.
The companion CVE-2026-50628 in the same module is a separate bug, so patch both with one upgrade.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does upgrading fix tokens already issued?
The upgrade changes how tokens are checked, not how they were issued. Make sure your issuer sets sensible audience values.
Is CVE-2026-50628 fixed in the same versions?
Yes, the project lists the same fixed versions for both.
Sources
Last reviewed: 19 October 2026.
