CVE-2026-19194 · Package
NO FIX YET · SEE WHAT TO DO
The HashiCorp cap JWT validation library before 0.14.0 can validate one claim while downstream code authorizes using a different value, via non-canonical claim names. An attacker holding a JWT signed by a trusted key can use attacker-controlled claims to get unauthorized access.
first public Nov 13, 2026 · 1 source
Check it with your coding agent
It reads this page and tells you if your code or app is affected.
Applications that use the HashiCorp cap library to validate JWTs and make authorization decisions from the claims. Exposure needs a JWT signed by a key the application trusts and attacker-controlled claims in that token. Services that do not use cap for JWT validation can skip it.
Not affected if cap-not-used, jwt-not-validated-by-cap
Who cares go, hashicorp-cap, jwt
go list -m github.com/hashicorp/capgithub.com/hashicorp/cap in go.mod and go.sum0.14.0The HashiCorp cap JWT validation library before version 0.14.0 is vulnerable to a claims validation bypass that may cause downstream applications to make authorization decisions using claim values different from those validated. Exploitation requires attacker-controlled claims in a JWT signed by a key trusted by the application. This vulnerability (CVE-2026-19194) is fixed in cap 0.14.0.
This page as .md · .json · CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
InfraStack checks it against your stack and answers on your report, with the evidence and the fix.