CVE-2026-27478: Authentication Bypass via Dynamic JWKS Discovery in Unity Catalog

Unity Catalog implements an OAuth 2.0 Token Exchange protocol (RFC 8693) to exchange external OIDC identity tokens for internal access tokens. This functionality is exposed via the /api/1.0/unity-control/auth/tokens endpoint. The server accepts a subject_token in the form of a JSON Web Token (JWT) and validates it before issuing internal credentials.

The vulnerability, identified as CVE-2026-27478, stems from a failure to validate the origin of the incoming token prior to performing cryptographic operations. The system exhibits weaknesses categorized under CWE-290 (Authentication Bypass by Spoofing) and CWE-346 (Origin Validation Error). The core issue is the implicit trust placed in the token's unverified payload.

An unauthenticated remote attacker can exploit this flaw to bypass authentication controls entirely. By forging a JWT with a specific payload, the attacker can spoof the identity of any registered user. This grants the attacker unauthorized access to the Unity Catalog environment under the context of the impersonated identity.

The exploit relies on manipulating the dynamic discovery mechanism used by the OpenID Connect (OIDC) protocol. The server trusts the attacker-controlled input to dictate the location of the cryptographic keys used for verification, creating a circular trust dependency that compromises the entire authentication flow.

The root cause of CVE-2026-27478 is a fundamentally insecure implementation of the OIDC discovery process. When the server receives an incoming subject_token, it parses the unverified token payload to extract the iss (issuer) claim. This extraction occurs before any cryptographic signature validation takes place.

Once the iss claim is extracted, the server uses it to dynamically construct an OIDC discovery URL. It appends /.well-known/openid-configuration to the issuer value and makes an outbound HTTP request. The server parses the resulting JSON document to locate the jwks_uri field, which specifies the location of the JSON Web Key Set (JWKS).

The server subsequently fetches the JWKS from the specified URI to retrieve the public keys. Finally, it uses these public keys to verify the signature of the incoming JWT. The vulnerability exists because the server fails to cross-reference the extracted iss claim against a definitive whitelist of trusted identity providers.

This implementation creates a critical logic flaw. Because the server trusts the unverified claim to locate the verification keys, an attacker can supply an issuer URL pointing to their own infrastructure. The server will fetch the attacker's public keys and use them to successfully verify a token signed with the attacker's corresponding private key.

In the vulnerable implementation, the token exchange endpoint blindly accepted the parsed issuer string to drive the network retrieval of cryptographic material. The code lacked any boundary checks to verify that the issuer belonged to a recognized entity such as Okta, Azure AD, or Google Workspace.

The fix was implemented in commit 89b91863e4ec0ead5865a602a4203ed254c151da and introduces strict validation logic. The patch requires administrators to define a server.allowed-issuers configuration property. The server now loads this comma-separated list into memory during initialization and uses it as a mandatory validation gate.

// Conceptual representation of the patched validation logic
String issuer = extractIssuerFromUnverifiedToken(token);
 
if (!allowedIssuers.contains(issuer)) {
    throw new AuthenticationException("Untrusted issuer: " + issuer);
}
 
// Discovery request only proceeds if the issuer is whitelisted
JWKSet jwkSet = fetchJwksFromIssuer(issuer);

Additionally, the patch addresses cross-application token replay by introducing audience validation. The server now requires a server.audiences configuration property. During token validation, the code verifies that the aud (audience) claim within the JWT matches the configured client identifier for the Unity Catalog instance.

Exploitation of CVE-2026-27478 requires no specialized tools beyond a standard HTTP client and a publicly accessible web server. The attacker first establishes a lightweight rogue OIDC provider. This infrastructure must serve a valid OIDC discovery document at /.well-known/openid-configuration and host a JWKS file containing an RSA public key generated by the attacker.

With the rogue infrastructure in place, the attacker crafts a malicious JWT. The payload is configured to target a specific identity within the Unity Catalog system, typically an administrator, by setting the sub or email claim. Crucially, the attacker sets the iss claim to the URL of their rogue web server.

The attacker signs the forged JWT using the private RSA key corresponding to the public key hosted on their rogue server. They then submit this token to the Unity Catalog /api/1.0/unity-control/auth/tokens endpoint via an HTTP POST request.

Successful exploitation of this vulnerability yields complete authentication bypass. The attacker receives a valid internal access token corresponding to the impersonated identity. This token grants the attacker all permissions and privileges associated with that user within the Unity Catalog environment.

If the impersonated account holds administrative privileges, the attacker gains full control over the metadata catalog. They can read sensitive schema definitions, alter data access policies, and modify or delete registered data assets. The attacker can perform these actions without triggering standard authentication failure alerts.

The CVSS v3.1 vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, resulting in a Base Score of 9.1 (Critical). The score reflects the network-based attack vector, the low complexity of the exploit, and the total lack of required privileges or user interaction.

Exploit Prediction Scoring System (EPSS) data indicates a score of 0.00023, placing it in the 6.59th percentile. This low score reflects a lack of observed exploitation in the wild at the time of assessment. However, the trivial nature of the exploit methodology dictates that organizations prioritize remediation immediately.

The primary remediation for CVE-2026-27478 is upgrading the Unity Catalog server to version 0.4.1 or later. The patch completely resolves the circular trust dependency by enforcing explicit issuer whitelisting. Administrators must download the updated release and deploy it according to standard operational procedures.

Following the upgrade, administrators must update the etc/conf/server.properties file to define the required security parameters. The server.allowed-issuers property must contain a comma-separated list of legitimate OIDC provider URLs. The server.audiences property must specify the expected client identifier to prevent token replay attacks.

For environments where immediate patching is impossible, security teams must implement strict network egress filtering. Firewalls should block the Unity Catalog server from initiating outbound HTTP connections to unauthorized external domains. This prevents the server from retrieving the attacker's rogue JWKS file.

Additionally, security operations centers should monitor application logs and network traffic. Analysts should create alerts for outbound requests originating from the Unity Catalog server that target /.well-known/openid-configuration on unrecognized domains. Reviewing the /api/1.0/unity-control/auth/tokens endpoint logs for anomalous iss claims provides retrospective detection of exploitation attempts.