CVE-2026-81029: OpenMetadata before 2.0.0 JWT Disclosure via Unvalidated SAML and OIDC Redirect URI
OpenMetadata accepts a caller-supplied post-authentication redirect target and appends the issued token to it. SamlLoginServlet reads the callback request parameter and stores it in the HTTP session without comparing it against any configured or registered destination, and the assertion consumer servlet later formats that stored value into a URL carrying the freshly issued JWT together with the account's email and name before sending the redirect. The OIDC and OAuth2 handler follows the same pattern with its own redirect parameter and the issued identity token. A request naming a destination the attacker controls therefore causes the server to deliver a valid token for whoever completes the login to that destination. Because the token authenticates API calls as that account, a user who follows such a link and authenticates hands over control of their account. Version 2.0.0 removes the caller-supplied callback parameter; no 1.x release validates it.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
OpenMetadatato a version that resolves this vulnerability.Fixed in 2.0.0 - Compensating control
Ensure the post-authentication redirect URI/target for SAML and OIDC/OAuth2 is constrained to configured/registered destinations (do not allow caller-supplied callback/redirect parameters to be used without validation/comparison against allowed destinations).
Event History
Frequently Asked Questions
Who is exposed to token theft?
Any user who completes a SAML, OIDC, or OAuth2 login after following an attacker-controlled login link can have their issued JWT or identity token redirected to the attacker. The stolen token can authenticate API calls as that user.
Does exploitation require an existing account or prior access?
No attacker privileges are required. The attacker needs to induce a user to use a login flow with a redirect destination controlled by the attacker and have that user authenticate.
Are OpenMetadata 1.x deployments affected by default?
No 1.x release validates the caller-supplied callback or redirect parameter. The issue is removed in version 2.0.0, which no longer accepts the caller-supplied callback parameter.
What can be done if upgrading is not immediately possible?
The provided information does not identify a supported configuration workaround. Reduce exposure by preventing users from initiating authentication through untrusted or externally supplied login URLs until version 2.0.0 can be deployed.