CVE-2026-41164: Nuts Node Auth Bypass Vulnerability

CVE-2026-41164 Overview

CVE-2026-41164 affects nuts-node, the reference implementation of the Nuts specification for decentralized identity and data exchange. The vulnerability resides in the v1 access token introspection endpoint at /auth/v1/introspect_access_token. The endpoint accepts any JSON Web Token (JWT) signed by a key present on the node without validating the JWT type, issuer-to-key binding, or required claims. An attacker can replay a Verifiable Presentation (VP) JWT as an access token and receive an active: true introspection response. The flaw is categorized as Insufficient Verification of Data Authenticity [CWE-345]. Maintainers fixed the issue in versions 6.2.3 and 5.4.31.

Critical Impact
A Verifiable Presentation JWT can be replayed against the introspection endpoint and validated as an active access token, undermining authorization decisions in downstream services.

Affected Products

nuts-node versions prior to 5.4.31 (5.x branch)
nuts-node versions prior to 6.2.3 (6.x branch)
Services relying on /auth/v1/introspect_access_token for authorization decisions

Discovery Timeline

2026-05-26 - CVE-2026-41164 published to the National Vulnerability Database
2026-05-26 - Last updated in NVD database

Technical Details for CVE-2026-41164

Vulnerability Analysis

The nuts-node implements an OAuth 2.0-style token introspection endpoint defined in its v1 authentication API. Introspection endpoints exist to let resource servers verify whether a bearer token is valid and active. In a correct implementation, the endpoint must validate that the presented JWT is specifically an access token, that it was issued by the expected authorization server, and that mandatory claims such as typ, iss, aud, and exp are present and consistent.

The vulnerable nuts-node implementation skips these checks. It accepts any JWT signed by a key currently loaded on the node and reports the token as active. Nuts nodes routinely sign multiple JWT types, including Verifiable Presentations used for credential exchange. An attacker who can obtain or capture a signed VP JWT can submit it to the introspection endpoint and receive a positive response. Downstream services that trust the introspection result will then grant access as though a valid access token had been presented.

Root Cause

The root cause is missing data authenticity verification on the introspection endpoint. The code path validates only the cryptographic signature against keys known to the node. It does not enforce a JWT typ discriminator, does not bind the signing key to a specific issuer role, and does not require access-token-specific claims. This conflates two distinct token classes inside one signing trust domain.

Attack Vector

Exploitation requires that the attacker possess or obtain a Verifiable Presentation JWT signed by a key the target node trusts. The attacker submits this VP JWT to /auth/v1/introspect_access_token. The endpoint returns active: true, and any resource server consulting the introspection result accepts the token as a valid OAuth access token. The attack succeeds across the network but requires existing low-privilege access to obtain a usable VP JWT and user interaction within the credential exchange flow, which constrains practical exploitation.

Detection Methods for CVE-2026-41164

Indicators of Compromise

Requests to /auth/v1/introspect_access_token returning active: true for tokens whose typ claim is not at+jwt or equivalent access token type
Introspection responses where the introspected token contains Verifiable Presentation structures such as vp or verifiableCredential claims
Repeated introspection lookups of the same JWT identifier from differing client identities

Detection Strategies

Parse introspection request bodies and log the decoded JWT header typ and payload claim set for offline analysis
Alert when introspection succeeds for JWTs that lack standard access token claims such as scope, client_id, or exp bound to short lifetimes
Correlate VP issuance events with subsequent introspection calls referencing the same jti

Monitoring Recommendations

Enable verbose logging on the nuts-node authentication module and forward logs to a centralized analytics platform
Monitor downstream resource servers for authorization grants tied to introspection responses lacking expected access token claims
Track version inventory of nuts-node deployments and alert on instances older than 5.4.31 or 6.2.3

How to Mitigate CVE-2026-41164

Immediate Actions Required

Upgrade nuts-node to version 6.2.3 on the 6.x branch or 5.4.31 on the 5.x branch
Audit recent introspection logs for VP JWTs that were accepted as active access tokens
Restrict network exposure of /auth/v1/introspect_access_token to trusted resource servers only

Patch Information

The Nuts Foundation released fixed builds in nuts-node 6.2.3 and 5.4.31. The patches add validation of the JWT type and required access token claims on the introspection endpoint. Details are available in the GitHub Security Advisory GHSA-9hmg-827w-9rhj.

Workarounds

Block external access to the v1 introspection endpoint at the reverse proxy or API gateway until patching is complete
Require resource servers to perform an additional check that the introspected token contains an expected access token typ value before granting access
Rotate signing keys after patching if log review indicates the endpoint was abused

bash

# Configuration example: restrict introspection endpoint at reverse proxy
location /auth/v1/introspect_access_token {
    allow 10.0.0.0/8;       # trusted resource servers
    deny all;
    proxy_pass http://nuts-node-upstream;
}