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

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. Because UAA is 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 that processes 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, went on to decrypt any encrypted elements. There was no else clause. An assertion that arrived neither signed nor encrypted simply fell through without an error and was treated 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:

The vulnerability exists in UAA, but the "Changed" scope reflects that its 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:

1. Identify a target UAA instance with a client configured to accept SAML 2.0 bearer assertions. This requires a specific client configuration. The SAML 2.0 bearer grant type must be enabled for at least one client, so not all UAA deployments are vulnerable by default.

2. 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 a plaintext XML document that claims to be a particular user.

3. 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.

4. 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 the 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 adds a private helper method, hasEncryptedElements(), that checks the assertion for an encrypted NameID or for 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 then changed 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 layering is deliberate. 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). An assertion that is neither signed nor encrypted now immediately throws a Saml2AuthenticationException with the INVALID_SIGNATURE error code (branch 3). That final else block is the 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 confirms that an unsigned assertion with encrypted attributes is still accepted and processed.

Over a dozen existing tests were also updated to pass their assertions through a signed() helper before creating tokens. The pre-patch test suite had been inadvertently sending unsigned assertions down the happy path, which masked the vulnerability.

Additional Fix in the Same PR

The same PR also fixed a Spring bean injection ambiguity in InvitationsEndpoint.java. It adds an explicit @Qualifier("identityProviderProvisioning") annotation so that the wrong IdentityProviderProvisioning bean is not injected when ExternalOAuthProviderConfigurator (which implements the same interface) is present.

Upgrade Paths

Administrators using the cf-deployment repository should note that v55.0.0 contains breaking routing changes. It 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 affects multiple Cloud Foundry packaging formats. Administrators must verify their exposure across standalone UAA deployments, BOSH releases, and canonical Cloud Foundry deployments.

The vulnerability is exploitable only when SAML 2.0 bearer assertions are enabled for a client. Deployments that do not use this grant type are not affected, though checking client configurations on every UAA instance is still strongly recommended.

Vendor Security History

The Cloud Foundry Foundation has a dedicated Security Team that acts as the single point of contact for reporting vulnerabilities in open-source Cloud Foundry codebases. The Foundation keeps a public security advisory archive and publishes PGP keys for secure vulnerability reporting, both signs of a mature disclosure process. Patches for this issue shipped promptly in both the standalone uaa_release and the broader cf-deployment manifest, which indicates strong coordination in how the Foundation manages vulnerabilities. The same cf-deployment v55.0.0 release that addresses this CVE also fixes CVE-2026-22726, a separate routing security issue.

References

• NVD: CVE-2026-22734
• Cloud Foundry Advisory: CVE-2026-22734 UAA SAML 2.0 Signature Bypass
• UAA Release v78.9.0
• cf-deployment Release v55.0.0
• UAA PR #3762: fix saml and invitations beans
• UAA Commit 26389733e0b3d5fc5a2e5ba4915c6f612f5d9cd5
• Cloud Foundry UAA GitHub Repository
• Cloud Foundry Security
• Cloud Foundry Security Advisory Archives