Cloud Foundry UAA leaks its private key: CVE-2026-40965 (CVSS 10.0)

"UAA (User Account and Authentication)," the authentication server in the enterprise application platform "Cloud Foundry," has a flaw where a private key that must never be exposed leaks from a page anyone can reach (CVE-2026-40965). The CVSS severity is 10.0 out of 10 (the maximum). Once the "key" that verifies who is allowed in is stolen, an attacker can freely forge the tokens used to impersonate legitimate users.

UAA is, in effect, the reception desk at the entrance: it accepts logins and issues a pass (a token) that says "this person is genuine." The flaw is that the desk left the secret stamp it uses to sign those passes (the private key) sitting in a place anyone could see. This article walks through what happens, whether you are affected, and what to do now.

The flaw at a glance

First, the key facts. The defining traits: the private key itself can be retrieved without any login, and the impact is limited to deployments using EC (Elliptic Curve) keys.

CVSS 10.0 means the worst case: unauthenticated, network-reachable, with impact spreading beyond the affected component. As noted below, though, the impact is limited to deployments using EC keys; the RSA configuration common by default is not affected. Confirming your configuration is the starting point.

The reception desk's stamp was left on a public shelf — and what follows

What makes this flaw so dangerous is that what gets stolen is not ordinary data but the secret stamp used to sign the passes themselves. The people who put a price on it are ransomware crews that encrypt corporate cloud platforms for a payout, initial-access brokers who harvest and resell footholds, and nation-state hackers after the business data sitting in SAP and core clouds. With the private key in hand, they can mint genuine-looking tokens that claim to be "the administrator." The moment the key is read once from that public page, the power to impersonate every app and every user on the platform passes wholesale to the attacker.

Impersonation does not stop at one step. Once in as an administrator with a forged token, the attacker can open the business apps running on the platform, the customer databases, and the vaults holding API keys and credentials, one after another. Initial-access brokers sell this route to ransomware operators for thousands to tens of thousands of dollars, and buyers encrypt the data, stall operations, and apply double extortion — "pay, or we publish the stolen customer and transaction records." For an organization running core operations on this platform, such as via SAP BTP, the damage may spread beyond that one company to the partner systems it connects to.

The cleanup falls on the IT department that runs the platform, and on management. Impersonation-based unauthorized access or a data breach triggers a duty to report to the Personal Information Protection Commission and notify the individuals, plus explanations to partners, damages, and lost trust. The tricky part is that once the key has leaked, patching alone is not the end. Unless the leaked stamp is replaced, the attacker can keep forging passes with the old one. Whether you can go as far as regenerating the key is what decides if you can cut off the damage.

What Cloud Foundry and UAA actually are

Cloud Foundry is a "PaaS (Platform as a Service)" — base software for running an organization's own applications. A developer pushes code, and the platform automatically provisions and deploys it. Released as open source, it has been used in the internal clouds of large enterprises and telecom carriers. In Japan, SAP's business cloud "SAP BTP" is built on Cloud Foundry, so many Japanese enterprises that use SAP indirectly run on this foundation.

Within it, UAA (User Account and Authentication) is the authentication server that handles all logins. It supports standard mechanisms such as OAuth2, OpenID Connect, and SAML, and issues a digital pass called a "JWT" to users who log in successfully. That pass is signed with UAA's private key to prove "this was indeed issued by UAA," and each app trusts the user by verifying that signature.

In short, UAA is the platform's "anchor of trust." The public key used to verify signatures can safely be published for apps to use. This time, however, the private key used to create signatures came out of that same public page alongside it — the anchor's stamp was sitting on the shelf next to the verification sample. That is the essence of the issue.

Inside CVE-2026-40965: EC private key exposed via a public endpoint

Per NVD (the US vulnerability database) and vulnerability databases, the problem is UAA's public /token_keys endpoint. This page should return only the public keys used to verify token signatures. But in deployments using EC (Elliptic Curve) keys, it also returned the private key components used to create signatures.

The CVSS vector is AV:N/AC:L/PR:N/UI:N: if reachable over the network, the private key is obtainable with low complexity, no login, and no user action — a worst-case profile. The fact that impact spreads to other systems (S:C) was also scored, yielding the maximum 10.0. Crucially, only deployments using EC signing keys are affected; the RSA configuration common by default is not. First confirm which your UAA uses.

Affected are uaa_release v76.12.0–v78.12.0 and cf-deployment v30.0.0–v56.0.0 that bundle it. Fixes are available in uaa_release v78.13.0+ and cf-deployment v56.1.0+.

A "key leaks" flaw has happened here before

A private-key-leak flaw in UAA is not new. In 2025, CVE-2025-22246 (private key exposure in logs) was disclosed, where UAA wrote the private key into its logs, and Cloud Foundry urged an upgrade. This time it leaks not via "logs" but via a "page anyone can see," making it more serious.

The common headache with key-leak flaws is that patching does not invalidate a key that has already leaked. If an attacker quietly grabbed the key before disclosure, they can keep forging passes with it after the fix. That is why, for key-exposure incidents, the standard practice is to pair "applying the fix" with "regenerating (rotating) the leaked key." The flaw is not on CISA's Known Exploited Vulnerabilities (KEV) catalog as of writing, but given it is an identity-server key, do not let your guard down.

Quick chart: are you affected?

Your configuration changes the response. The key type (EC/RSA) and operating model split the priority as below.

If you self-manage Cloud Foundry, first confirm whether the signing key is EC or RSA; if EC, treat it as top priority. If you use it in managed form via SAP BTP, IBM Cloud, and the like, the provider handles the platform-side fix, so checking each provider's security notice is the fastest route.

What IT departments should check now

The top priority is confirming whether your UAA uses EC signing keys. If it does and you run an affected version, update immediately to uaa_release v78.13.0 / cf-deployment v56.1.0 or later. Calling /token_keys from outside and checking that only public keys are returned (no private key components mixed in) is a useful verification.

And the step most often missed in key-leak cases is rotating (regenerating) the signing key. Since the key may have been grabbed before disclosure, applying the fix alone will not stop passes forged with the old key. Plan the full response through to regenerating the signing key after the update and invalidating tokens signed with the old one. Also review authentication logs for traces of suspicious token issuance or access.

If you do not self-manage but use it via a managed service such as SAP BTP or IBM Cloud, asking the provider about their response is the reliable route. To track major vulnerabilities affecting widely used products in Japan, also see our 2026 first-half roundup of major vulnerabilities.

FAQ

Summary

CVE-2026-40965 in Cloud Foundry's UAA authentication server is a flaw where the private key used to sign tokens leaks from a page anyone can see. An attacker with the key can forge tokens that impersonate legitimate users, putting the platform's apps and data broadly at risk. The CVSS is the maximum 10.0, but the impact is limited to deployments using EC keys; RSA is not affected. First confirm your key type, and if affected, update to uaa_release v78.13.0 / cf-deployment v56.1.0 or later. Then carry the response through to regenerating the signing key — the step most often missed — to cut off the damage. For managed use such as SAP BTP, check the provider's notice.

References

• ▸NVD - CVE-2026-40965 (Cloud Foundry UAA private key exposure)
• ▸Vulnerability-Lookup - CVE-2026-40965
• ▸Cloud Foundry - CVE-2025-22246 UAA Private Key Exposure (prior case)
• ▸Cloud Foundry Docs - User Account and Authentication (UAA)
• ▸GitHub - cloudfoundry/uaa
• ▸SAP Help Portal - Cloud Foundry UAA Server