CVE-2026-27478 - Unity Catalog JWT issuer bypass

Unity Catalog versions through 0.4.0 could trust the iss claim from an incoming JWT, dynamically fetch that issuer’s JWKS, and validate the token without first checking whether the issuer was a trusted identity provider. The implementation also lacked audience validation. An attacker could host an OIDC server, sign a token for a known user, and exchange it for an internal access token.

For data and AI platforms, this is a high-value context-layer failure: catalog, schema, table, model, and lineage permissions can be impersonated if the token boundary is weak.

When to use it

Use this recipe when a repository deploys Unity Catalog server or owns token exchange code for data, AI, notebook, model, lineage, or catalog access. It is designed for source-code/deployment remediation, JWT issuer/audience trust review, negative authentication testing, token exposure review, and evidence that attacker-controlled issuers cannot mint internal access tokens.

Inputs

  • Unity Catalog version, Maven/Gradle dependencies, server images, deployment manifests, token-exchange route config, trusted issuer/audience policy, and generated dependency or SBOM reports.
  • Source/config paths that validate JWTs, fetch JWKS, exchange tokens, map subjects/emails to users, authorize catalog/schema/table/model access, or configure OIDC clients.
  • Regression fixtures for forged issuers, wrong audiences, unknown key IDs, disallowed algorithms, subject/email mismatch, trusted issuer success, and token expiration.
  • Boundary evidence: identity providers, user/workload audiences, exposed token endpoint, catalog privileges, logs, token/session rotation owner, and rollout owner.

Affected versions

Package Vulnerable versions Fixed versions
io.unitycatalog:unitycatalog-server <=0.4.0 0.4.1

Indicator-of-exposure

  • The repository deploys Unity Catalog server <=0.4.0.
  • /api/1.0/unity-control/auth/tokens is reachable from users, workloads, agents, notebooks, CI jobs, or internal services.
  • Token exchange accepts arbitrary issuer metadata or JWKS discovery.
  • Audience, issuer, subject, and email claims are not pinned to the expected identity provider and client.

Quick checks:

rg -n "unitycatalog|unity-catalog|unitycatalog-server|/auth/tokens|token-exchange|jwks|issuer|audience|OIDC|JWT" .
mvn dependency:tree 2>/dev/null | rg "unitycatalog"
rg -n "io\\.unitycatalog:unitycatalog-server|unitycatalog-server" pom.xml **/pom.xml

Remediation strategy

  • Upgrade Unity Catalog server to 0.4.1+.
  • Configure an explicit trusted issuer allow-list and expected audience.
  • Reject tokens whose iss, aud, algorithm, key ID, subject, or email claims do not match configured trust policy.
  • Add negative tests with forged issuers and wrong audiences using local keys that never leave the test environment.
  • Rotate or expire tokens if a vulnerable token exchange endpoint was exposed.

The prompt

You are remediating CVE-2026-27478 in Unity Catalog token exchange. Produce
exactly one output:

- A reviewer-ready PR/change request that upgrades Unity Catalog, pins identity
  provider issuer/audience validation, refreshes generated artifacts, and adds
  negative authentication tests, or
- TRIAGE.md if this repository does not control an affected Unity Catalog
  deployment.

## Rules

- Scope only CVE-2026-27478 and directly related JWT/OIDC validation hardening.
- Do not attack live identity providers, production Unity Catalog instances, or
  real users.
- Do not print or commit JWTs, signing keys, refresh tokens, access tokens,
  catalog contents, table data, model metadata, service credentials, or audit
  logs containing secrets.
- Do not accept arbitrary issuer discovery from token claims.
- Do not auto-merge.

## Steps

1. Inventory Maven/Gradle dependencies, lockfiles, containers, Helm charts,
   Terraform, Unity Catalog configs, identity-provider configs, token exchange
   routes, docs, and SBOMs.
2. Determine every resolved `io.unitycatalog:unitycatalog-server` version. A
   target is vulnerable if it resolves to `<=0.4.0`.
3. Search token exchange configuration and code for dynamic `iss` trust, JWKS
   discovery, `aud` validation, accepted algorithms, key rotation, and claim to
   user mapping.
4. Upgrade to Unity Catalog `0.4.1+`. Regenerate dependency state, images,
   deployment manifests, SBOMs, generated docs, and dependency reports.
5. Configure identity trust policy:
   - allowed issuer URLs are explicit and exact;
   - expected audience/client IDs are enforced;
   - algorithms are restricted to expected signing algorithms;
   - `sub`/`email` mapping is validated against the trusted issuer;
   - JWKS cache and key rotation behavior is documented.
6. Add negative tests using local test keys:
   - forged issuer is rejected;
   - wrong audience is rejected;
   - unknown key ID is rejected;
   - token for unknown user is rejected;
   - valid configured issuer and audience still succeeds.
7. Add a PR body section named `CVE-2026-27478 operator actions` covering:
   affected deployments, before/after version, trusted issuers, expected
   audiences, token lifetime/rotation decisions, and audit logs to review for
   suspicious token exchange.
8. Run validation: dependency install, auth tests, integration tests where
   available, manifest render, container build, SBOM refresh, and dependency
   scan.
9. Use PR title:
   `fix(sec): enforce Unity Catalog JWT issuer trust`.

## Stop conditions

- Unity Catalog server is not present or is externally managed.
- All controlled targets already resolve `0.4.1+` and identity-provider policy
  is explicit.
- Verification would require testing against production identity providers or
  real user tokens.
- Required issuer/audience values are unknown; produce TRIAGE.md with the exact
  configuration decision needed.

Output contract

  • A reviewer-ready PR or change request that upgrades Unity Catalog, pins trusted issuer/audience validation, refreshes deployment artifacts, adds forged-token negative tests, and documents token/operator review.
  • Or a TRIAGE.md file that lists inspected dependencies/images/config, owner, observed version, token-exchange trust boundary, required fix, and residual risk.
  • The output must include exact validation commands and must not use real identity-provider secrets, mint live tokens, expose user claims, or weaken catalog authorization.

Verification - what the reviewer looks for

  • No controlled target resolves unitycatalog-server <=0.4.0.
  • Issuer and audience validation are explicit and tested.
  • Negative tests do not use real tokens or production identity providers.
  • Operator notes cover token lifetime, audit review, and rollout order.

Watch for

  • Multiple Unity Catalog deployments with different identity providers.
  • Test configs that accidentally allow any issuer for convenience.
  • Cached JWKS behavior that keeps accepting a formerly trusted or forged key.

References