Cloud Foundry UAA Flaw Turns Database Collation Into Token Authority

The Cloud Foundry Foundation disclosed CVE-2026-59335 on August 24. The flaw is an authorization bypass in the User Account and Authentication service's identity-zone management API. An authenticated caller that already holds zone-management authority can modify the protected system identity zone on affected deployments, take control of its JWT signing-key configuration, and forge tokens with arbitrary authorities. The vendor rates it 7.7 under CVSS 4.0 and 8.3 under CVSS 3.1. It is not an unauthenticated Internet takeover, but the resulting identity impact can extend to the UAA deployment and every resource that trusts its tokens.

The exploitable boundary is narrow and unusual. The advisory applies only to UAA backed by MySQL with the default database collation; PostgreSQL and HSQLDB deployments are not affected. All UAA versions before 78.16.0 and all cf-deployment versions before 57.0.0 are listed as affected. Operators should verify the running UAA release, database engine, effective collation, and every principal with zone-management authority, then upgrade to a current release at or above the fixed floor. Where suspicious identity-zone or signing-key changes appear, preserve evidence, rotate signing material, remove old verification keys to invalidate forged tokens, revoke privileged credentials, and investigate resources that trusted the affected issuer.

Cloud Foundry UAA provides authentication and delegated authorization for Cloud Foundry components and other applications. It supports OAuth 2.0, OpenID Connect, SAML, LDAP, SCIM, and multiple identity zones. A zone separates users, clients, providers, and policies within one service. The built-in zone has the identifier uaa and acts as the system zone for backward compatibility. That zone is not simply another tenant because platform components rely on its authorities and token issuer.

UAA's zone-management API accepts broad zones.write authority or a zone-specific zones.<zone id>.admin authority for updates. A zone administrator is supposed to operate only within the designated zone. CVE-2026-59335 breaks that expectation under its affected database condition. The Foundation says a caller holding zone-management authority can modify the system zone, including the JWT signing-key configuration, then create tokens carrying arbitrary authorities.

JWTs are accepted because resource servers trust the issuer's signature and claims. If an attacker can install or select signing material in the system zone, password resets and normal MFA checks are no longer the central question. The attacker can manufacture a token that appears to come from the trusted issuer. The advisory describes full UAA and protected-resource takeover as the impact, but availability is scored none; the immediate risk is unauthorized confidentiality and integrity across a changed security scope.

The Foundation calls the issue a case-insensitive check bypass and limits it to MySQL with the default database collation. MySQL documents that its default utf8mb4_0900_ai_ci collation performs nonbinary string comparisons without case sensitivity. A database can therefore treat strings that differ only by letter case as equal. That is useful for search and sorting, but dangerous when an application expects an identity-zone identifier to preserve a security distinction.

The public advisory does not publish an exploit request or the exact alternate identifier used. Operators should not invent a payload from the title alone. The confirmed engineering point is enough: the API's authorization logic and the database's comparison semantics disagreed, allowing a privileged zone caller to cross into the system zone. A string is not a safe tenant boundary unless canonicalization and equality rules are explicit and identical at every layer.

Changing a database collation is not the vendor's published mitigation. It can alter indexes, uniqueness, ordering, queries, and application behavior across a live identity store. Cloud Foundry directs customers to fixed software instead. Record the effective schema and column collations for scoping, but do not improvise a production database conversion as an emergency patch without vendor guidance, a tested migration, backups, and a recovery plan.

First, identify the software. UAA releases before 78.16.0 and cf-deployment releases before 57.0.0 are affected according to the advisory. Check the running component, not only the desired manifest or release artifact. Long-lived foundations can contain drift, partially updated jobs, standby instances, or recovery images. Capture the reported UAA version and deployment manifest from every active and failover environment.

Second, confirm the data layer. The advisory says MySQL of any version with the default database collation is affected, while PostgreSQL and HSQLDB are not. The important value is the effective collation used by the relevant identity-zone identifiers, not a general assumption about the database family. Preserve evidence of the engine, schema, column definition, connection configuration, and any custom migration that may have changed comparison behavior.

Third and fourth, map multi-zone use and authority. Exploitation needs an authenticated caller with zone-management power and a reachable identity-zone management API. Inventory users, OAuth clients, automation, brokers, and service accounts carrying zones.write or zones.<zone id>.admin. Record token lifetimes, credential storage, API exposure, and the periods those grants existed. A deployment can meet the software and database conditions yet lack a plausible attacker-held zone credential; that lowers immediate likelihood but does not remove the patch requirement.

Cloud Foundry recommends UAA 78.16.0 or later, or cf-deployment 57.0.0 or later. The cf-deployment 57.0.0 release includes UAA 78.16.0. Operators should select the newest supported line compatible with their foundation rather than stopping automatically at the minimum. Verify the component release embedded in the final manifest and the running jobs after deployment, then test login, token issuance, SSO, zone administration, client credentials, SCIM, and resource-server validation.

The platform release has its own upgrade work. The cf-deployment 57.0.0 notes make MySQL 8.4 the default and warn operators to follow the Percona XtraDB Cluster in-place upgrade procedure before updating. That database change is separate from the authorization flaw, but it affects the same maintenance plan. Read every intervening release note, back up UAA and CredHub data, validate BOSH health, preserve rollback artifacts, and avoid turning a security fix into an identity outage.

After the upgrade, prove that all instances run the fixed code and that old artifacts cannot be restored accidentally. Check canaries, availability zones, disaster-recovery foundations, test environments connected to production identity, and automation repositories. Confirm that zone-specific administrators still manage their intended zones and cannot change the system zone. A successful BOSH deployment command is evidence of orchestration, not proof of the effective authorization boundary.

Before maintenance rotates logs or restarts UAA, preserve identity-zone API activity, authentication and token events, client changes, database audit records, BOSH tasks, operator access, network flows, and the current zone configuration. Review updates to the system zone, activeKeyId changes, added or removed keys, new privileged clients, unexpected zones.* grants, unusual token issuance, and access to high-value platform APIs. Compare each change with an approved operator action and a trusted configuration baseline.

UAA documentation explains that a zone token policy can hold multiple signing keys. Changing activeKeyId selects the key for new tokens, while old keys can remain available for verification. Removing an old key invalidates tokens signed by it. If evidence indicates unauthorized signing-key control, patch first, install trusted replacement material, remove untrusted and superseded verification keys, revoke affected clients and users, and force reauthentication across resources that accept the issuer.

Key rotation has a blast radius. Resource servers may cache public keys, accept long-lived JWTs, or use introspection differently. Coordinate cache expiry, service restarts, session invalidation, and emergency access before the change. Then investigate actions performed with apparently valid but anomalous tokens. Do not claim exploitation merely because an old version and MySQL are present; likewise, do not treat a clean password log as clearance when forged JWTs could bypass the normal login trail.

The structural lesson is broader than Cloud Foundry. Tenant and zone identifiers cross HTTP paths, headers, application objects, caches, databases, logs, and policy engines. Each layer may normalize Unicode, case, whitespace, encoding, or separators differently. Choose one canonical representation at creation, reject ambiguous variants, store an immutable internal identifier, and perform authorization against the object resolved from that identifier rather than against an untrusted spelling supplied by the caller.

Database collation should support the product's intended behavior, not quietly define it. Use binary or explicitly chosen comparison semantics for security identifiers where appropriate, enforce uniqueness under the same rules used by authorization, and test negative cases against every supported database. Include mixed case, normalization variants, encoded input, aliases, and the protected system identifier. Run the same authorization suite on MySQL, PostgreSQL, and any embedded test database so a passing HSQLDB test does not mask production behavior.

Finally, treat zone administration as high privilege even when it is called tenant administration. Minimize zones.write, split creation from ongoing management, issue short-lived credentials, alert on changes to the system zone and token policy, and review grants regularly. The fix closes this bypass. A precise authority inventory, consistent identifier semantics, immutable audit records, and rehearsed signing-key recovery reduce the damage from the next disagreement between an identity service and its storage layer.