SAML assertion bypass lets attackers mint Cloud Foundry UAA tokens
TL;DR — A SAML 2.0 bearer assertion validation flaw in Cloud Foundry UAA can let remote attackers mint access tokens for arbitrary users when bearer assertions are enabled.
What happened
Cloud Foundry UAA (User Account and Authentication) is the identity and token service used by Cloud Foundry to issue and validate credentials for UAA-protected components and applications.
CVE-2026-22734 describes an authentication bypass / token spoofing issue triggered when SAML 2.0 bearer assertions are enabled for a client. In this configuration, UAA can accept SAML 2.0 bearer assertions that are neither signed nor encrypted, allowing an attacker to obtain a token for any user and use it to access UAA-protected systems.
This is a high-impact appsec problem because it targets the platform’s authorization boundary: once an attacker can mint tokens, downstream services may treat requests as legitimately authenticated, turning a single config-dependent weakness into broad lateral access.
Who is impacted
- Cloud Foundry environments where a UAA client has SAML 2.0 bearer assertions enabled.
- Impacted version ranges vary by component and how deployments track UAA releases.
| Component | Affected versions (per public records) | Notes |
|---|---|---|
UUA | v77.21.0 through v78.8.0 | CVE record scope for the UUA product line. |
uaa_release | v77.30.0 through v78.7.0 (inclusive) | Cloud Foundry advisory’s affected uaa_release range. |
cf-deployment | v48.7.0 through v54.14.0 (inclusive) | Cloud Foundry advisory’s affected deployment range. |
What to do now
- Follow vendor remediation guidance and apply the recommended upgrades for your packaging/deployment line.
"Upgrade uaa_release versions to v78.9.0 or greater" "Upgrade cf-deployment version to v55.0.0 or greater"
- Inventory UAA clients and configurations to determine where SAML 2.0 bearer assertions are enabled, and prioritize patching those environments first.
- Treat this as potential credential/token compromise if exposure is suspected: review UAA token issuance/authentication logs and rotate credentials (and invalidate tokens where feasible) according to your incident response playbooks.
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.