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. Cloud Foundry holds a modest share of the broader PaaS market, but it has significant adoption in enterprise and government environments, where it is the backbone of cloud-native application deployment. UAA issues and validates the JWTs that authenticate users and services across the platform.

CVE-2026-40965 has a CVSS v4.0 score of 10.0, the maximum possible. The score reflects 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 it for the public keys they need to validate token signatures. The endpoint lists every currently valid key, which is how it supports key rotation. The security model rests on one assumption: the endpoint exposes only public key components, so callers can verify signatures without gaining the ability to sign.

Root Cause: EC Key Serialization Flaw

The vulnerability is in the getJwkMap() method of the KeyInfo.java class, which builds the JSON map that gets 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, it 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());
 }

On the original code path, jwk.toJSONObject() returned every JWK field, including the d parameter for EC keys. Any HTTP client that queried /token_keys received the complete EC private key along with 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 recognized only RSA keys as "asymmetric" and therefore safe to serve to unauthenticated callers. EC keys were missing from this allow list, which could cause inconsistent behavior:

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

Attack Flow

Exploiting this vulnerability is straightforward:

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

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

3. The attacker extracts the private key from the response. No special parsing is needed, because d is a standard JWK field.

4. With 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. Every service that trusts the UAA as its token issuer accepts the forged tokens, because their signatures verify correctly against the public keys published at the same endpoint.

The asymmetric cryptographic trust model collapses completely. JWT signing uses asymmetric key pairs so that the private key stays secret while the public key can be distributed freely. Once the endpoint that distributes the public key also exposes the private key, nothing distinguishes a legitimate token from a forged one.

Why RSA Configurations Are Unaffected

The vulnerability is specific to the serialization logic for EC keys. RSA key configurations are not affected, because the UAA server correctly filters out RSA private key components before publishing keys through the /token_keys endpoint. That difference in handling is the core of the bug. RSA keys got careful extraction of their public components, and 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). Because the /token_keys endpoint is designed to be publicly accessible, requests to it do not look anomalous in themselves, and exploitation is difficult to detect through standard monitoring.

Patch Information

The fix for CVE-2026-40965 is PR #3861 ("Ensure EC keys work as expected"), authored by Duane May (@duanemay). It was merged into the develop branch of cloudfoundry/uaa on April 22, 2026 (commit aa6fdddb), 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. The fix itself touches two production source files, and thorough new test coverage backs it up.

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

This is the main fix. The one-line change chains .toPublicJWK() before .toJSONObject(), using 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());
 }

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

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

The endpoint's access-control logic now classifies both RSA and EC keys as asymmetric:

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

The patch adds a new private helper method:

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

The change applies to both the single-key endpoint (getKey) and the multi-key listing endpoint (getKeys). Unauthenticated clients now get EC public keys on equal footing with RSA keys, but only their public components.

Test coverage

The remaining 3 files in the commit are tests that guard against regressions. Unit tests in KeyInfoBuilderTest and TokenKeyEndpointTests check that the d parameter is absent and that EC keys are served to unauthenticated users alongside RSA keys (while symmetric keys stay gated behind authentication). Integration tests in TokenKeyEndpointMockMvcTests exercise the actual /token_keys and /token_key HTTP endpoints end to end. They parse the JSON response and assert that exactly 7 JWK fields are present, with no d parameter.

Post-Patch Actions

Upgrading alone is not enough. The vulnerability exposes EC private key material through a publicly accessible endpoint, so any EC keys 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 the 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, because forged tokens would pass all standard validation checks.

Deployments that cannot upgrade immediately can switch their JWT signing key configuration from EC to RSA as a temporary workaround. That 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, so operators using the CF Deployment pipeline have a single upgrade path.

Important configuration qualifier: Only deployments that use 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 check their UAA key configuration to determine exposure.

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

Vendor Security History

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

Key-handling vulnerabilities have recurred. CVE-2025-22246 also involved private key exposure in UAA, though through a different mechanism (logging). CVE-2026-22734 allowed a SAML 2.0 signature bypass that let an attacker obtain tokens for any user. Taken together, these vulnerabilities suggest a systemic pattern in how UAA handles cryptographic material and authentication flows.

The Cloud Foundry Foundation Security Team has handled disclosure and patching in a timely way. The advisory and fix for CVE-2026-40965 were released simultaneously on May 14, 2026. Still, the cumulative record raises questions about how much security review this critical authentication component gets. Organizations relying on Cloud Foundry should consider 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