Summary

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.

Technical Explanation

The vulnerable flow is exposed on the unauthenticated callback route GET /auth/external.

In externalCallbackHandler(), the server parses the external auth state and uses the decoded clientId and redirectUri after completing the IdP code exchange. If login succeeds and a client is found, the handler calls:

• getClientRedirectUri(client, body.redirectUri, true)

The third argument explicitly enables partial matching. In getClientRedirectUri(), the function returns the attacker-supplied requestedUri whenever:

• requestedUri.startsWith(uri)

As a result, any redirect URI beginning with a registered value is accepted. The returned URL is then passed into new URL(redirectUri), and the server appends login and code query parameters before calling res.redirect().

Although externalCallbackHandler() later performs an exact-match lookup, that result is only used for logging and does not block the redirect. Therefore, the request is still redirected to the attacker-controlled URL even when it is not an exact registered redirect URI.

A practical exploitation detail is that the registered redirect URI must be a prefix that can also prefix a different origin. For example:

• Registered: http://callback.audit.local
• Malicious: http://callback.audit.local.oastify.com/cb

The client-side external auth flow serializes the login request directly into the IdP state as JSON, which makes tampering straightforward in an intercepted or manually crafted authorization request.

Steps to Reproduce

Preconditions

• The target ClientApplication has an identityProvider configured.
• The target client has a registered redirect URI that is prefix-matchable into an attacker-controlled hostname, for example:
  • Registered redirect URI: http://callback.audit.local
• The attacker controls a collaborator endpoint such as:
  • https://<collaborator-host>/cb
• The attacker uses a forged state.redirectUri that starts with the registered value, for example:
  • http://callback.audit.local.oastify.com/cb
  • or a collaborator domain that matches your local proof setup

Example forged state

{"clientId":"<medplum-client-id>","redirectUri":"http://callback.audit.local.oastify.com/cb","codeChallenge":"attack-verifier-123","codeChallengeMethod":"plain"}

URL-encode the forged state

Replay the external callback with cURL Use a valid IdP authorization code obtained from a normal external login flow, then call the vulnerable callback directly: curl -i 'http://api.audit.local:8103/auth/external?code=<valid-idp-code>&state=<URLENCODED_FORGED_STATE>

Expected result The response is a 302 redirect to the attacker-controlled endpoint, including Medplum authorization artifacts in the query string:

Collaborator proof If redirectUri points to a Burp Collaborator, Interactsh, or another attacker-controlled HTTP endpoint, that service receives the inbound request containing the leaked code in the query string. This demonstrates that Medplum is willing to forward authorization artifacts to an attacker-controlled destination when state.redirectUri only prefix-matches a registered client redirect URI.

Optional impact validation If the attacker supplied the PKCE verifier in the forged state, the leaked Medplum code can then be redeemed:

Impact

The impact of this vulnerability is Critical, as it facilitates a full Account Takeover (ATO) of any user utilizing the external identity provider (IdP) flow.

1. Full Account Takeover (ATO): An attacker can successfully intercept the Medplum authorization 'code'. Because the attacker controls the 'state' object, they can provide their own PKCE 'code_challenge'. This allows the attacker to redeem the stolen code for a valid access token without knowing the victim's original secret, leading to total session hijacking.

2. Bypassing Modern OAuth Protections: This flaw explicitly bypasses the security benefits of PKCE (Proof Key for Code Exchange). By allowing an attacker to inject their own PKCE parameters into the tampered state, the server's verification mechanism is rendered useless against this specific redirection attack.

3. Cross-Origin Data Leakage: The 'startsWith' logic allows an attacker to break out of the intended origin. For example, a registered URI for 'https://app.medplum.com' could be extended to 'https://app.medplum.com.attacker.com', tricking the user and the browser's security model into sending sensitive credentials to an external host.

4. Access to Sensitive Healthcare Data (PHI): Given Medplum's role as a healthcare platform, a successful compromise grants the attacker the same permissions as the victim, potentially exposing Protected Health Information (PHI) and violating HIPAA or other regulatory compliance standards.

5. Victim Trust Exploitation: The attack occurs during a legitimate login flow. The victim interacts with the official Medplum server and their trusted IdP (e.g., Google or Microsoft), making the final redirection to the attacker-controlled URL nearly impossible for an average user to detect.

Mitigation

• Require exact string equality for redirect URIs.
• Bind external auth state to a server-side session or use a HMAC/Signature.
• Reject prefixable or ambiguous redirect URI shapes during registration.