CVE-2026-27478: 
Java vulnerability analysis and mitigation

CVE-2026-27478 is a critical JWT issuer validation bypass vulnerability in Unity Catalog (the open-source multi-modal catalog for data and AI) that allows unauthenticated attackers to completely impersonate any user in the system. The flaw exists in the token exchange endpoint (/api/1.0/unity-control/auth/tokens) and affects all versions up to and including 0.4.0 of the io.unitycatalog/unitycatalog-server Maven package. It was published on March 11, 2026, with a patched version (0.4.1) released the same day. The vulnerability carries a CVSS v3.1 base score of 9.1 (Critical) (GitHub Advisory, Unity Catalog Advisory).

The root cause is the token exchange endpoint's failure to validate that the iss (issuer) claim in an incoming JWT corresponds to a pre-configured, trusted identity provider (CWE-290: Authentication Bypass by Spoofing; CWE-346: Origin Validation Error; CWE-1390: Weak Authentication). Instead, the endpoint blindly extracts the iss claim and dynamically fetches the JWKS endpoint from that issuer URL to perform signature validation — meaning any attacker-controlled OIDC server is treated as authoritative. Compounding the issue, the aud (audience) claim is also not validated, so tokens minted for entirely different services can be replayed. A working proof-of-concept Python script is included in the official advisory, demonstrating exploitation with a self-hosted Flask-based OIDC server (Unity Catalog Advisory, GitHub Advisory).

Successful exploitation allows an unauthenticated remote attacker to obtain a valid internal Unity Catalog access token impersonating any known user, granting full access to all catalogs, schemas, tables, volumes, and other data assets that the targeted user is authorized to access. Because no privileges or user interaction are required, the attack can be executed at scale against any reachable Unity Catalog instance. The confidentiality and integrity of all governed data assets are fully compromised, while availability is unaffected (GitHub Advisory, Unity Catalog Advisory).

A minimal, functional proof-of-concept exploit is publicly available and included directly in the official GitHub Security Advisory, lowering the barrier to exploitation significantly (Unity Catalog Advisory). The EPSS score is approximately 0.03% (9th percentile), indicating low current exploitation probability, and there is no evidence of active in-the-wild exploitation or threat actor attribution at this time (GitHub Advisory). The vulnerability is not listed in the CISA KEV catalog. The attack requires no privileges, no user interaction, and low complexity — only network access to the Unity Catalog server and knowledge of a valid user's email/sub claim.

1. Reconnaissance: Identify Unity Catalog server instances running version ≤ 0.4.0 accessible over the network. Enumerate valid user email addresses or sub claim values from any available directory, API response, or prior access.
2. Set up a rogue OIDC server: Host a minimal OIDC-compliant server (e.g., using Python/Flask) that exposes /.well-known/openid-configuration and a /jwks endpoint. Generate a fresh RSA-2048 key pair and publish the public key in JWKS format at the /jwks endpoint.
3. Craft a malicious JWT: Sign a JWT with the attacker-controlled private key, setting:
   • iss: URL of the attacker's OIDC server
   • sub / email: target user's identifier in Unity Catalog
   • aud: unity-catalog (or any value, since audience is not validated)
   • Valid iat and exp timestamps
4. Submit the token exchange request: Send an HTTP POST to /api/1.0/unity-control/auth/tokens on the target Unity Catalog server with the crafted JWT as the subject_token, using grant type urn:ietf:params:oauth:grant-type:token-exchange.
5. Receive a valid access token: The server fetches the JWKS from the attacker's iss URL, validates the signature (which succeeds since the attacker controls both key and JWKS), and returns a valid internal Unity Catalog access token for the impersonated user.
6. Access data assets: Use the returned access_token as a Bearer token to call Unity Catalog APIs (e.g., GET /api/2.1/unity-catalog/catalogs) and access all resources the impersonated user is authorized to view or modify (Unity Catalog Advisory).

• Network: Unexpected outbound HTTP/HTTPS requests from the Unity Catalog server to unknown external hosts (the attacker's OIDC server) on paths matching /.well-known/openid-configuration or /jwks; inbound POST requests to /api/1.0/unity-control/auth/tokens from unusual or external source IPs.
• Logs: Unity Catalog access logs showing token exchange requests (POST /api/1.0/unity-control/auth/tokens) followed immediately by API calls (GET /api/2.1/unity-catalog/catalogs or similar) from the same session, especially from IPs not associated with known identity providers; log entries showing JWKS fetches to non-configured issuer URLs.
• Application Behavior: Successful authentications for users who have not recently logged in through a legitimate IdP; access token issuance events where the iss claim in the incoming JWT does not match any configured trusted identity provider.

The primary remediation is to upgrade Unity Catalog (io.unitycatalog/unitycatalog-server) to version 0.4.1 or later, which introduces proper issuer validation against a trusted allowlist (GitHub Advisory, Unity Catalog Advisory). For organizations unable to upgrade immediately, apply network-level access controls to restrict access to the /api/1.0/unity-control/auth/tokens endpoint to only trusted internal networks or known identity provider IP ranges. Additionally, monitor outbound connections from the Unity Catalog server to detect JWKS fetches to unexpected external hosts as a compensating control.

The vulnerability was reported by security researcher lukas-reining and published by the Unity Catalog maintainers on March 11, 2026 (Unity Catalog Advisory). Coverage appeared on The Hacker Wire shortly after disclosure (The Hacker Wire), and the vulnerability was noted on Bluesky by CVE tracking accounts. Community reaction highlighted the severity of including a working PoC directly in the advisory, as it significantly lowers the exploitation barrier for a critical authentication bypass in a data governance platform.