Compliance Impact

The vulnerability allows a Verifiable Presentation (VP) JWT to be replayed as an access token, potentially enabling unauthorized access to resources by tricking the resource server into accepting a replayed token.

Such unauthorized access could lead to exposure or misuse of sensitive data, which may impact compliance with data protection regulations like GDPR or HIPAA that require strict access controls and protection of personal or health information.

However, the severity is considered moderate due to mitigating factors such as short-lived VPs, empty service and issuer claims in the replayed token, and resource servers requiring valid service, issuer, and audience values for routing, which reduce the risk of successful exploitation.

To maintain compliance, it is important to apply the fixes introduced in versions v5.4.31 and v6.2.3 and later, which add proper validation of JWT type, issuer-to-key binding, and required claims, or to implement explicit validation of introspection responses on resource servers as a workaround.

Useful 0 Not Useful 0

Executive Summary

The CVE-2026-41164 vulnerability is a JWT type confusion issue in the nuts-node software's access token introspection endpoint (/auth/v1/introspect_access_token). This endpoint accepts any JWT signed by the node's key without properly validating the JWT type, issuer-to-key binding, or required claims.

Because both access tokens and Verifiable Presentation (VP) JWTs use the same "JWT" type header, the introspection endpoint can be tricked into accepting a VP JWT as a valid access token. This allows an attacker to replay a VP JWT as an access token and receive an active: true response from the introspection endpoint.

The vulnerability arises from missing checks on the typ header (which should require "at+jwt" for access tokens), the binding between issuer and key ID, and required claims like service.

Useful 0 Not Useful 0

Impact Analysis

An attacker could exploit this vulnerability by presenting a Verifiable Presentation JWT from a victim organization as a bearer access token, thereby tricking the resource server into accepting it as valid.

This could potentially allow unauthorized access to resources protected by the nuts-node system.

However, the severity is considered moderate due to mitigating factors such as the short lifespan of VPs, empty service and issuer claims in the replayed token, and the requirement for resource servers to validate service, issuer, and audience values for routing.

Resource servers can also mitigate the risk by explicitly validating the introspection response.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability involves the acceptance of any JWT signed by a node's key at the /auth/v1/introspect_access_token endpoint without proper validation. To detect exploitation attempts, monitor network traffic for JWT tokens being sent to this endpoint and inspect the JWT headers and claims.

Specifically, look for JWTs where the typ header is not "at+jwt", or where the issuer-to-key binding and required claims like service are missing or empty.

You can use commands to capture and decode JWT tokens from network traffic, for example:

• Use tcpdump or Wireshark to capture HTTP POST requests to /auth/v1/introspect_access_token.
• Extract the JWT token from the request body.
• Decode the JWT token header and payload using tools like jwt-cli or online JWT decoders to verify the typ header and claims.
• Example command to decode JWT token locally (assuming token is stored in a variable TOKEN):
• jwt decode $TOKEN
• Alternatively, use curl to send introspection requests and observe responses for tokens that should not be accepted.

Useful 0 Not Useful 0

Mitigation Strategies

The vulnerability is fixed in nuts-node versions 6.2.3 and 5.4.31 by adding proper validation of the JWT typ header, issuer-to-key binding, and required claims.

Immediate mitigation steps include:

• Upgrade nuts-node to version 6.2.3 or 5.4.31 or later to apply the official fix.
• If upgrading is not immediately possible, configure resource servers to explicitly validate the introspection response, ensuring that the service, issuer (iss), and audience (aud) claims are present and valid before accepting tokens.
• Monitor and restrict access to the /auth/v1/introspect_access_token endpoint to trusted clients only.

Useful 0 Not Useful 0