Cloud Foundry UAA CVE-2026-22734: SAML 2.0 Bearer Assertion Signature Bypass Allows Token Forgery — Brief Summary and Patch Analysis - ZeroPath Blog

Introduction

A missing else clause in Cloud Foundry's UAA server allowed any remote attacker to forge an OAuth token for any user by submitting a SAML 2.0 bearer assertion with no signature and no encryption. For organizations running Cloud Foundry as their application platform, this vulnerability (CVE-2026-22734, CVSS 3.1: 8.6) effectively dissolved the authentication boundary protecting every downstream application that relies on UAA for identity.

Cloud Foundry UAA (User Account and Authentication) is the central identity management and OAuth2 authorization server for the Cloud Foundry ecosystem. It handles user authentication, token issuance, and client authorization across multi cloud deployments on AWS, Azure, GCP, and on premises infrastructure. As the single identity provider for the platform, a bypass in UAA has cascading consequences for every application and service in the deployment.

Technical Information

Root Cause: Missing Validation Branch in SAML Assertion Processing

The vulnerability lived in Saml2BearerGrantAuthenticationConverter.java, the class responsible for processing SAML 2.0 bearer grant assertions during OAuth token exchange. Before the patch, the process() method had a single conditional branch: it checked only whether the assertion was signed via assertion.isSigned() and, if so, proceeded to decrypt any encrypted elements. Critically, no else clause existed. If an assertion arrived that was neither signed nor encrypted, the code simply fell through, silently treating it as valid.

This is classified under CWE-290 (Authentication Bypass by Spoofing). The CVSS 3.1 vector string is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N, which breaks down as follows:

Metric	Value	Meaning
Attack Vector	Network	Exploitable remotely
Attack Complexity	Low	No special conditions required
Privileges Required	None	No authentication needed
User Interaction	None	No victim action required
Scope	Changed	Downstream systems are impacted
Confidentiality	High	Full token forgery for any user
Integrity	None	Scored as none in the vector
Availability	None	Scored as none in the vector

The "Changed" scope is significant here. While the vulnerability exists in UAA, the impact extends to every application and service that trusts UAA issued tokens for access control decisions.

Attack Flow

The exploitation path is direct and requires no special tooling or prior access:

Identify a target UAA instance with a client configured to accept SAML 2.0 bearer assertions. This is a specific client configuration, so not all UAA deployments are vulnerable by default; the SAML 2.0 bearer grant type must be enabled for at least one client.
Craft a bare SAML 2.0 assertion naming the target user as the subject. The assertion needs no cryptographic signature and no encrypted elements. It is, in essence, a plaintext XML document claiming to be a particular user.
Submit the assertion to the UAA token endpoint using the SAML 2.0 bearer grant flow. Because the process() method lacks an else branch, the unsigned, unencrypted assertion passes through validation without triggering any error.
Receive a valid OAuth token for the named user. The attacker can now use this token to access any UAA protected system as that user.

The low attack complexity and absence of any authentication requirement make this vulnerability particularly concerning for internet facing UAA instances.

Patch Information

The Cloud Foundry Foundation published a fix for CVE-2026-22734 on April 6, 2026. The core patch landed in UAA v78.9.0 (released March 10, 2026) via PR #3762 ("fix saml and invitations beans"), authored by @fhanik and merged with commit 26389733e0b3d5fc5a2e5ba4915c6f612f5d9cd5. The fix was then rolled up into cf-deployment v55.0.0 (released March 23, 2026), which bundles UAA release v78.10.0.

What Changed

The patch introduces a new private helper method, hasEncryptedElements(), that inspects the assertion for any encrypted NameID or encrypted attributes within attribute statements:

private static boolean hasEncryptedElements(Assertion assertion) {
    if (assertion.getSubject() != null && assertion.getSubject().getEncryptedID() != null) {
        return true;
    }
    for (AttributeStatement statement : assertion.getAttributeStatements()) {
        if (!statement.getEncryptedAttributes().isEmpty()) {
            return true;
        }
    }
    return false;
}

The process() method was then updated from a single if to a three branch structure:

if (assertion.isSigned()) {
    this.assertionElementsDecrypter.accept(...);
} else if (hasEncryptedElements(assertion)) {
    this.assertionElementsDecrypter.accept(...);
} else {
    throw OpenSaml4AuthenticationProvider.createAuthenticationException(
            Saml2ErrorCodes.INVALID_SIGNATURE,
            "Assertion is missing a signature.",
            null
    );
}

The logic is deliberately layered: a signed assertion is processed normally (branch 1); an unsigned but encrypted assertion is still considered trustworthy, since the encryption binding provides integrity and confidentiality (branch 2); but an assertion that is neither signed nor encrypted now immediately throws a Saml2AuthenticationException with the INVALID_SIGNATURE error code (branch 3). This final else block is the critical addition that closes the bypass.

Test Coverage

Two new test cases were added to Saml2BearerGrantAuthenticationConverterTest.java:

authenticateWhenUnsignedAssertionThenThrowInvalidSignature confirms that a bare, unsigned assertion now triggers an INVALID_SIGNATURE error.
authenticateWhenUnsignedButEncryptedAssertionThenSucceeds validates that an unsigned assertion with encrypted attributes is still correctly accepted and processed.

Additionally, over a dozen existing tests were updated to pass their assertions through a signed() helper before creating tokens. This is a telling detail: the pre-patch test suite was inadvertently passing unsigned assertions through the happy path, masking the vulnerability.

Additional Fix in the Same PR

Beyond the core SAML fix, the same PR also addressed a Spring bean injection ambiguity in InvitationsEndpoint.java by adding an explicit @Qualifier("identityProviderProvisioning") annotation, preventing the wrong IdentityProviderProvisioning bean from being injected when ExternalOAuthProviderConfigurator (which implements the same interface) is present.

Upgrade Paths

Component	Target Fixed Version	Notes
uaa_release	v78.9.0 or later	Direct upgrade for standalone BOSH deployments of UAA
CF Deployment	v55.0.0 or later	Automatically includes the patched uaa_release v78.10.0

Administrators utilizing the cf-deployment repository should note that version v55.0.0 contains breaking changes related to routing, which blocks route service access to internal network ranges to fix a separate issue (CVE-2026-22726). Teams must review the release notes carefully before applying the v55.0.0 update.

Affected Systems and Versions

The vulnerability impacts multiple packaging formats of the Cloud Foundry ecosystem. Administrators must verify their exposure across standalone UAA deployments, BOSH releases, and canonical Cloud Foundry deployments.

Component Type	Vulnerable Version Range	Notes
UAA Server	v77.21.0 through v78.8.0	Core application versions affected by the bypass
uaa_release (BOSH)	v77.30.0 to v78.7.0 (inclusive)	BOSH release packaging of the UAA server
CF Deployment	v48.7.0 to v54.14.0 (inclusive)	Canonical deployment manifests containing vulnerable UAA versions

The vulnerability is only exploitable when SAML 2.0 bearer assertions are enabled for a client. Deployments that do not use this specific grant type are not affected, though verifying client configurations across all UAA instances is strongly recommended.

Vendor Security History

The Cloud Foundry Foundation maintains a dedicated Security Team that provides a single point of contact for reporting vulnerabilities in open source Cloud Foundry codebases. The vendor demonstrates a mature security disclosure process, utilizing a public security advisory archive and providing PGP keys for secure vulnerability reporting. The prompt release of patches across both the standalone uaa_release and the broader cf-deployment manifest indicates strong coordination in their vulnerability management lifecycle. Notably, the same cf-deployment v55.0.0 release that addresses this CVE also includes a fix for CVE-2026-22726, a separate routing security issue.

Cloud Foundry UAA CVE-2026-22734: SAML 2.0 Bearer Assertion Signature Bypass Allows Token Forgery — Brief Summary and Patch Analysis

CVE Analysis

Experimental AI-Generated Content

Introduction

Technical Information