Description

Medplum is a developer platform that enables development of healthcare apps. Prior to version 5.1.6, the external identity provider callback at GET /auth/external accepts attacker-controlled redirect URIs that only need to start with a registered client redirect URI, rather than matching exactly. After a successful external IdP login, the server appends Medplum login and code values to that attacker-supplied URL and issues a redirect. Because the external login request state is serialized as raw JSON and later trusted by the callback, an attacker who can tamper with state.redirectUri can cause Medplum to redirect authorization artifacts to an attacker-controlled endpoint. When the registered redirect URI is a bare origin or another prefix that can be extended into a different hostname, this becomes a cross-origin authorization code leak. This issue has been patched in version 5.1.6.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-09-03T20:17:21.643Z",
  "pubdate": "2026-09-03T20:17:21.643Z",
  "executiveSummary": "Medplum versions prior to 5.1.6 contain an open redirect vulnerability within the external identity provider callback mechanism at GET /auth/external. The application fails to strictly validate redirect URIs, permitting attackers to supply a prefix-matched URL that facilitates the exfiltration of sensitive authorization artifacts.\nBy manipulating the 'state' parameter, which contains the serialized redirect URI, an attacker can coerce the application into redirecting successful authentication responses to an arbitrary, attacker-controlled domain. This vulnerability allows for cross-origin authorization code leakage, potentially leading to full account takeover or unauthorized access to protected healthcare resources.\nThe flaw impacts the authentication pipeline, specifically where the server consumes and trusts user-provided state data during the callback phase. Exploitation requires an attacker to successfully trick a victim into initiating an external IdP login, after which the authorization code and login tokens are dispatched to the adversary's endpoint rather than the legitimate application origin. This poses significant risks to data confidentiality and systemic integrity, necessitating immediate upgrades to version 5.1.6 or later.",
  "technicalDetails": "The vulnerability originates from inadequate validation logic within the external identity provider callback handler located at GET /auth/external. The system uses a prefix-matching algorithm rather than an exact-match check when verifying redirect URIs against registered client configurations. Consequently, if a registered redirect URI is a broad path or a base origin, an attacker can supply a malicious URI that satisfies the prefix condition while redirecting to a different, attacker-controlled hostname.\nThe exploit leverages the 'state' parameter utilized during the external IdP handshake. This state is serialized as raw JSON and subsequently trusted by the callback handler. Because the server assumes the integrity of this state data, an attacker can modify the 'redirectUri' field within the JSON structure before the IdP interaction completes. When the authentication flow returns to Medplum, the server processes the compromised 'state', appends the authorization code and login metadata to the attacker-supplied URL, and triggers an HTTP 302 redirect.\nThe attack flow follows these steps: 1) The attacker initiates an authentication request to the external IdP using a modified 'state' object containing a malicious 'redirectUri' that starts with the legitimate registered prefix but points to an adversary-controlled domain. 2) The victim completes the authentication process with the legitimate identity provider. 3) The identity provider redirects the victim's browser back to Medplum's GET /auth/external endpoint with the authorization grant. 4) Medplum validates the request against the tampered state. 5) Medplum appends the authorization code and login tokens to the attacker's URL and issues a redirect. 6) The victim's browser sends the sensitive authentication artifacts to the attacker's server, enabling the attacker to finalize the login process on behalf of the victim.\nThis behavior facilitates a cross-origin authorization code leak, effectively bypassing the security controls intended to bind authentication callbacks to authenticated application origins. The vulnerability is fundamentally a failure to implement strict input validation and secure deserialization practices for transport-sensitive parameters. The issue is resolved in version 5.1.6 through the implementation of exact-match URI validation, ensuring that only pre-registered, fully qualified redirect endpoints are processed during the authentication callback phase."
}