Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-08-26T16:16:45.550Z",
  "pubdate": "2026-08-26T16:16:45.550Z",
  "executiveSummary": "OpenMetadata contains a critical authentication vulnerability involving an insecure post-authentication redirect mechanism. The vulnerability exists within the SAML, OIDC, and OAuth2 login handlers, where a caller-supplied redirect destination is accepted without validation against an allowlist of trusted domains.\nThis flaw allows an attacker to construct a malicious URL that, when accessed by a victim, redirects the authenticated session to an attacker-controlled destination. Crucially, the application appends the user's valid JWT and identity information (email and name) to this redirect URL. Consequently, an attacker can harvest authentication tokens for any user who authenticates via the compromised link, leading to complete account takeover.\nThe vulnerability affects all 1.x releases of OpenMetadata, with remediation implemented in version 2.0.0 by removing the user-supplied callback parameter entirely. The risk is classified as critical, as it requires no prior authentication from the attacker and can be exploited through simple social engineering tactics, resulting in unauthorized access to sensitive metadata and API resources.",
  "technicalDetails": "The root cause of this vulnerability is the improper implementation of post-authentication redirect handling within the SamlLoginServlet and equivalent OIDC/OAuth2 handlers. The application logic captures a user-supplied 'redirect' parameter from the incoming authentication request and persists this value directly into the HTTP session state without performing any domain or path validation.\nThe attack flow begins when an attacker crafts a malicious URL directed at the OpenMetadata login endpoint. This URL contains a 'redirect' parameter pointing to an attacker-controlled server. When an unsuspecting victim clicks this link and completes the authentication process, the authentication servlet retrieves the untrusted redirect target from the HTTP session. The Assertion Consumer Service (ACS) or equivalent callback logic then formats a response that embeds the newly minted JWT, user email, and user name into the query parameters of the redirect URL. The server then issues an HTTP 302 redirect, sending the victim's browser to the attacker-controlled server.\nBecause the server includes the session-authenticated JWT directly in the redirect URL, the attacker’s external server receives the victim's authentication credentials via the Referer header or direct URL logging. This mechanism results in a complete bypass of the intended authentication flow security boundaries.\nVulnerable components include the SamlLoginServlet, as well as the parallel OIDC and OAuth2 handler implementations within the OpenMetadata codebase. The vulnerability is present in all 1.x versions of OpenMetadata. The issue is exacerbated by the fact that the application does not utilize a whitelist or regex-based validation for redirect destinations, allowing for arbitrary external redirection and information disclosure.\nPost-exploitation, the attacker possesses a valid JWT that corresponds to the victim's account. Since the token authenticates API calls as the hijacked user, the attacker can impersonate the user to perform unauthorized data modifications, metadata exfiltration, or administrative actions within the OpenMetadata platform. The impact is significant as it effectively weaponizes the authentication mechanism against the users it is intended to protect."
}