nuts-node is the reference implementation of the Nuts specification. Prior to 6.2.3 and 5.4.31, 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. This vulnerability is fixed in 6.2.3 and 5.4.31.

Affected: Go: github.com/nuts-foundation/nuts-node

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