CVE-2026-41164

## Summary The v1 access token introspection endpoint (`/auth/v1/introspect_access_token`) accepts any JWT signed by a key present on the node, without validating the JWT type, issuer-to-key binding, or required claims. This allows a Verifiable Presentation (VP) JWT to be replayed as an access token and receive an `active: true` introspection response. ## Background In the v1 auth flow ([Nuts RFC003](https://nuts-foundation.gitbook.io/v1/rfc/rfc003-oauth2-authorization)), access tokens are JWTs signed by the authorizer's key with: - `iss` = authorizer organization DID - `sub` = requester organization DID - `service` = purpose of use (e.g. `"eOverdracht"`) - `typ` header = `"JWT"` (default, not explicitly set) Verifiable Presentations are also JWTs with `typ: "JWT"` (per W3C VC Data Model 1.1). The W3C VC Data Model 2.0 changed this to `vp+jwt` specifically to prevent this class of confusion attack (See [Securing Verifiable Credentials using JOSE and COSE 3.1.1](https://www.w3.org/TR/vc-jose-cose/#securing-with-jose)). ## Vulnerability details The introspection endpoint performs only standard JWT checks. It does not perform the following Nuts-specific access token checks: 1. **Validate the `typ` header**: both ATs and VPs use `"JWT"` 2. **Bind `iss` to the signing key**: it doesn't verify that the `iss` claim matches the DID extracted from the `kid` 3. **Validate required claims**: `service` can be empty; `vp` claim is silently ignored by `FromMap()` which uses lenient JSON unmarshaling ## Attack scenario **Prerequisites:** Attacker (Org B) has received a VP JWT from the victim (Org A) during a normal access token request flow. 1. Org A creates a VP JWT signed with Org A's key and sends it to Org B (normal protocol flow) to request an access token 2. Org B presents this VP JWT to Org A's resource server as a bearer access token 3. Resource server calls Org A's v1 introspection endpoint 4. Introspection checks `privateKeyStore.Exists(kid)`, which passes, bec