HashiCorp Vault Fixes Expired Login MFA Request Redemption
Tech GuruQuick Answer
Update two-phase Vault Login MFA deployments and validate request expiry, credential-rotation response and proxy client-address forwarding.
Confirm Scope And Apply The Supported Remediation
What to do now: Record Vault edition, version, two-phase MFA use, authentication methods, load balancers and client address forwarding. 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 expired requests cannot complete and normal MFA succeeds. Test the new per-entity, per-IP and global pending-request limits; retain authentication and token-issuance evidence.
Last verified: 2026-11-14 UTC. Recheck the authoritative advisory and supported distribution channel before changing production.
Scope And Authority
| Product scope | HashiCorp Vault Community Edition and Vault Enterprise |
|---|---|
| Advisory | HCSEC-2026-59 |
| CVE | CVE-2026-92738 |
| Authoritative release date | 2026-11-13T20:22:29.003Z — vendor advisory publication timestamp; no later revision is recorded. |
| Authority revision date | No separate material revision date is provided by the authority. |
| Affected versions | Vault Community Edition and Vault Enterprise 1.10.0 through 2.2.1 using two-phase Login MFA. Single-phase Login MFA is not affected; an attacker must have completed the first factor and still satisfy the second factor. |
| Fixed version | Vault Community Edition 2.2.2; Vault Enterprise 2.2.2, 1.21.14 or 1.19.26. |
| CVSS base score | Not provided by the authority |
| CVSS severity | Not provided by the authority |
| Exploitation status | The HashiCorp advisory does not confirm exploitation in the wild.; no exploitation claim is inferred. |
What Changed
Expired two-phase Login MFA requests could remain redeemable when cleanup was delayed by a backlog, potentially allowing token issuance after primary credential rotation. The second factor is still required.
What To Validate Now
- Inventory. Record Vault edition, version, two-phase MFA use, authentication methods, load balancers and client address forwarding.
- Establish applicability. Match the advisory conditions to deployed configuration and authorization policy before assigning exposure.
- Remediate. Apply the exact edition-specific fixed release listed above through the supported upgrade or dependency-management process.
- Validate. Verify expired requests cannot complete and normal MFA succeeds. Test the new per-entity, per-IP and global pending-request limits; retain authentication and token-issuance evidence.
- 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
Pending requests do not survive restart or seal, but disruptive recovery actions need an approved plan. Correct client-IP forwarding is necessary to avoid legitimate users sharing one pending-request limit. Do not describe this as a second-factor 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.
