HashiCorp CAP 0.14.0 Fixes JWT Claim Validation Mismatch

P2 — VALIDATE AND UPDATENot provided by the authority · Not provided by the authorityEXPLOITATION: NOT STATED

Quick Answer

Upgrade the cap dependency to 0.14.0 or later, rebuild consumers and test that validated issuer and subject values match authorization decisions.

Confirm Scope And Apply The Supported Remediation

What to do now: Identify Go applications using cap/jwt, resolved dependency versions, configured issuer/subject expectations and trusted identity providers. Match the advisory conditions to deployed configuration and authorization policy before assigning exposure. Apply the exact edition-specific fixed release listed above through the supported upgrade or dependency-management process. Verify the deployed binary uses the corrected dependency and test accepted and rejected claim forms. Retain dependency locks, build provenance and authentication test results.

Open the authoritative advisory

Last verified: 2026-11-14 UTC. Recheck the authoritative advisory and supported distribution channel before changing production.

Scope And Authority

Product scopeHashiCorp CAP JWT library
AdvisoryHCSEC-2026-60
CVECVE-2026-19194
Authoritative release date2026-11-13T21:16:59.112Z — vendor advisory publication timestamp; no later revision is recorded.
Authority revision dateNo separate material revision date is provided by the authority.
Affected versionsHashiCorp cap/jwt through 0.13.0 in applications configuring Expected.Subject or Expected.Issuer. Exploitation requires attacker-controlled claims in a JWT signed by a trusted key; applicability depends on the consuming application.
Fixed versionHashiCorp cap dependency 0.14.0 or later.
CVSS base scoreNot provided by the authority
CVSS severityNot provided by the authority
Exploitation statusThe HashiCorp advisory does not confirm exploitation in the wild.; no exploitation claim is inferred.

What Changed

The CAP JWT library could validate registered claims differently from the claims returned to an application, allowing issuer or subject expectations to be bypassed under the stated trust conditions.

What To Validate Now

  1. Inventory. Identify Go applications using cap/jwt, resolved dependency versions, configured issuer/subject expectations and trusted identity providers.
  2. Establish applicability. Match the advisory conditions to deployed configuration and authorization policy before assigning exposure.
  3. Remediate. Apply the exact edition-specific fixed release listed above through the supported upgrade or dependency-management process.
  4. Validate. Verify the deployed binary uses the corrected dependency and test accepted and rejected claim forms. Retain dependency locks, build provenance and authentication test results.
  5. Retain evidence. Preserve asset and owner identifiers, the applicability decision, before-and-after versions, change approval, installation output, validation results, and any exception or rollback record.

Operational Cautions

HashiCorp reports no demonstrated unauthorized access in Vault, Boundary or other downstream applications. Do not infer those products are exploitable solely from library presence. Applications without the respective issuer or subject expectation are outside that check-specific bypass.

Evidence To Retain

  • Exact product, release stream, package or application version, enabled feature, environment, and accountable owner.
  • UTC timestamps, authority revision, approved change record, installer or package-manager output, and resulting version.
  • Relevant logs and monitoring evidence, test results, exceptions, compensating controls, and rollback decisions.

Related TechGeeks Resources

Authoritative References

Correction policy: If the authority changes affected versions, fixed versions, severity, exploitation information, mitigations, or required action, TechGeeks will update this notice and its verification date.