Cloud Foundry UAA CVE-2026-40965: EC Private Key Disclosure via Public Endpoint — Brief Summary and Patch Analysis

Introduction

A single unauthenticated HTTP GET request to a Cloud Foundry UAA server can return the Elliptic Curve private key used to sign every JWT the platform issues. With that key in hand, an attacker can forge tokens granting arbitrary permissions across the entire Cloud Foundry deployment.

Cloud Foundry UAA (User Account and Authentication) is the OAuth2 authorization server and identity management layer for Cloud Foundry, an open source Platform as a Service originally developed by VMware and now maintained under the Linux Foundation. While Cloud Foundry holds a modest share of the broader PaaS market, it has significant adoption in enterprise and government environments where it serves as the backbone for cloud native application deployment. UAA is the component responsible for issuing and validating JWTs that authenticate users and services across the platform.

CVE-2026-40965 carries a CVSS v4.0 score of 10.0, the maximum possible, reflecting the combination of unauthenticated network access, zero complexity, and complete compromise of the cryptographic trust model. The vulnerability is classified under CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor).

Technical Information

The /token_keys Endpoint

In UAA's architecture, the /token_keys endpoint is a publicly accessible API that returns JSON Web Key (JWK) representations of the keys used to sign JWTs. External services and platform components query this endpoint to retrieve the public keys they need to validate token signatures. The endpoint supports key rotation by listing all currently valid keys. The security model relies on a fundamental assumption: only public key components are exposed, enabling signature verification without compromising signing capability.

Root Cause: EC Key Serialization Flaw

The vulnerability exists in the KeyInfo.java class, specifically in the getJwkMap() method that constructs the JSON map serialized into the /token_keys API response. For RSA keys, the code had always carefully extracted only the public modulus and exponent. For EC keys, however, the code serialized the entire JWK object, including the private d parameter (the secret scalar that constitutes the private key):

 } else if (type == EC) {
-    result.putAll(jwk.toJSONObject());
+    result.putAll(jwk.toPublicJWK().toJSONObject());
 }

The jwk.toJSONObject() call on the original code path returned all JWK fields, including the d parameter for EC keys. This meant that any HTTP client querying /token_keys received the complete EC private key alongside the public components (crv, x, y).

Secondary Issue: Asymmetric Key Classification

A related problem existed in TokenKeyEndpoint.java, which controls access to the key endpoints. The original code only recognized RSA keys as "asymmetric" and therefore safe to serve to unauthenticated callers. EC keys were not in this allow list, which could cause inconsistent behavior:

-if (!includeSymmetricalKeys(principal) && !RSA.name().equals(key.type())) {
+if (!includeSymmetricalKeys(principal) && !isAsymmetricKey(key.type())) {

Attack Flow

Exploitation of this vulnerability follows a straightforward sequence:

1. An unauthenticated attacker sends an HTTP GET request to the /token_keys endpoint of the UAA server. This endpoint is publicly documented and intended to be accessible without authentication.

2. The JSON response includes EC private key components (specifically the d parameter) alongside the intended public key material (crv, x, y).

3. The attacker extracts the private key from the response. No parsing complexity is involved; the d parameter is a standard JWK field.

4. Using the compromised private key, the attacker generates JWTs with arbitrary claims, scopes, and user identities. Standard JWT libraries in any language can produce these tokens.

5. Forged tokens are accepted by all services that trust the UAA as the token issuer, because the signatures verify correctly against the public keys published at the same endpoint.

This represents a complete collapse of the asymmetric cryptographic trust model. The entire purpose of using asymmetric key pairs for JWT signing is that the private key remains secret while the public key can be freely distributed. When the private key is exposed through the same endpoint that distributes the public key, the distinction between legitimate and forged tokens disappears entirely.

Why RSA Configurations Are Unaffected

The vulnerability is specific to the serialization logic for EC keys. RSA key configurations are not impacted because the UAA server correctly filters RSA private key components before publishing them through the /token_keys endpoint. The asymmetry in handling between RSA and EC keys is the core of the bug: RSA keys received careful public component extraction, while EC keys were serialized wholesale.

Scope of Impact

The CVSS v4.0 vector reflects the severity: network accessible (AV:N), low complexity (AC:L), no prerequisites (AT:N), no privileges required (PR:N), no user interaction (UI:N), and high confidentiality impact (VC:H). The /token_keys endpoint is designed to be publicly accessible, so requests to it do not inherently appear anomalous, making exploitation difficult to detect through standard monitoring.

Patch Information

The fix for CVE-2026-40965 was delivered through PR #3861 ("Ensure EC keys work as expected"), authored by Duane May (@duanemay), merged into the develop branch of cloudfoundry/uaa on April 22, 2026 (commit aa6fdddb). It shipped in UAA v78.13.0 (released April 23, 2026) and was rolled into CF Deployment v56.1.0.

The patch is compact: 148 additions and 4 deletions across 5 files, addressing the vulnerability with surgical precision across two production source files, supported by thorough new test coverage.

Fix 1: KeyInfo.java — Stripping the private key material

This is the heart of the fix. The one line change chains .toPublicJWK() before .toJSONObject(), leveraging the Nimbus JOSE library's built in method to derive the public only representation of the EC key:

 } else if (type == EC) {
-    result.putAll(jwk.toJSONObject());
+    result.putAll(jwk.toPublicJWK().toJSONObject());
 }

This ensures only the safe public components (crv, x, y) are emitted and the secret scalar d is never included in the response. The corresponding test was updated to assert the map now has 7 entries (4 base JWK parameters: alg, use, kid, kty plus 3 EC public parameters: crv, x, y) instead of the previous 8, and explicitly asserts .doesNotContainKey("d").

Fix 2: TokenKeyEndpoint.java — Treating EC keys as asymmetric

The endpoint's access control logic was updated to properly classify both RSA and EC keys as asymmetric:

-if (!includeSymmetricalKeys(principal) && !RSA.name().equals(key.type())) {
+if (!includeSymmetricalKeys(principal) && !isAsymmetricKey(key.type())) {

A new private helper method was introduced:

private boolean isAsymmetricKey(String keyType) {
    return RSA.name().equals(keyType) || EC.name().equals(keyType);
}

This change was applied to both the single key endpoint (getKey) and the multi key listing endpoint (getKeys), ensuring EC public keys are served to unauthenticated clients on equal footing with RSA, but now only their public components.

Test coverage

The remaining 3 files in the commit are tests that serve as regression guards. Unit tests in KeyInfoBuilderTest and TokenKeyEndpointTests validate that the d parameter is absent and that EC keys are served to unauthenticated users alongside RSA keys (while symmetric keys remain gated behind authentication). Integration tests in TokenKeyEndpointMockMvcTests exercise the actual /token_keys and /token_key HTTP endpoints end to end, parsing the JSON response and asserting that exactly 7 JWK fields are present with no d parameter.

Post Patch Actions

Upgrading alone is not sufficient. Because the vulnerability exposes EC private key material through a publicly accessible endpoint, any EC keys that were in use during the vulnerable period must be considered compromised. Operators must:

1. Rotate all EC signing keys by generating entirely new key pairs and decommissioning old keys. UAA supports key rotation natively through its configuration.
2. Audit access logs for requests to /token_keys from unexpected sources during the vulnerable period.
3. Review active OAuth tokens if compromise is suspected, as forged tokens would pass all standard validation checks.

As a temporary workaround for deployments that cannot immediately upgrade, switching the JWT signing key configuration from EC to RSA eliminates the disclosure path, since the vulnerability does not affect RSA key configurations.

Affected Systems and Versions

CF Deployment v56.1.0 bundles the fixed uaa_release v78.13.0, providing a single upgrade path for operators using the CF Deployment pipeline.

Important configuration qualifier: Only deployments using Elliptic Curve (EC) keys for JWT token signing are vulnerable. Deployments configured with RSA keys for JWT signing are not affected by this specific CVE. Organizations should verify their UAA key configuration to determine exposure.

The affected version range spans approximately 26 major CF Deployment versions, meaning a large number of deployments may be running vulnerable configurations.

Vendor Security History

The Cloud Foundry UAA component has exhibited a notable concentration of security vulnerabilities in the 2025 and 2026 timeframe, particularly around authentication and cryptographic key handling:

The recurrence of key handling vulnerabilities is particularly notable. CVE-2025-22246 also involved private key exposure in UAA, though through a different mechanism (logging). CVE-2026-22734 allowed SAML 2.0 signature bypass, enabling an attacker to obtain tokens for any user. When considered together, these vulnerabilities suggest a systemic pattern in UAA's handling of cryptographic material and authentication flows.

The Cloud Foundry Foundation Security Team has demonstrated timely disclosure and patching; the advisory and fix for CVE-2026-40965 were released simultaneously on May 14, 2026. However, the cumulative record raises questions about the depth of security review applied to this critical authentication component. Organizations relying on Cloud Foundry should consider implementing additional layers of defense beyond UAA, such as network segmentation, downstream token validation, and monitoring for anomalous token usage patterns.

References

• Cloud Foundry Advisory: CVE-2026-40965 UAA EC Private Key Disclosure
• NVD: CVE-2026-40965
• GitHub: UAA v78.13.0 Release
• GitHub: PR #3861 "Ensure EC keys work as expected"
• GitHub: Commit aa6fdddb
• GitHub: PR #3861 Diff
• Feedly: CVE-2026-40965 Exploits and Severity
• Vulners: CVE-2026-40965
• Cloud Foundry Security Advisory Archives
• Cloud Foundry UAA Concepts
• UAA API Documentation
• OpenCVE: UAA Vulnerabilities
• Cloud Foundry Security