vulns.co
/
GKData.io MCP

Back to Gadgets

DPoP sender constraint dropped

DPoP (RFC 9449) is meant to sender-constrain an access token to a key the client holds. The gadget is a token issued as sender-constrained that a resource server, or a refresh response, still accepts as an ordinary bearer token. Also inventory a proof that…

Tags: oauth, dpop, token, replay

Typical severity: P3-P5

What it becomes

Low alone if the access token never leaves the client, and it becomes replay of a stolen token when the resource server accepts it without a DPoP proof.

Where to look

  • token responses that claim a sender-constrained token type
  • resource servers on API calls
  • refresh responses that re-issue an unconstrained token

Chains

  • Token replay: A token that was issued with a DPoP binding is accepted with no proof, so possession of the token is enough.
  • Proof reuse: The server accepts a proof for a different method, URI, or access token than the one it was built for.

Notes

  • Use a client and token you were issued. Do not replay a token from another user.
  • DPoP is not PKCE. PKCE (RFC 7636) binds the authorization code. DPoP (RFC 9449) binds the access token. Report the one the server actually dropped.