CVE-2026-55102: hashi-vault-js: Vault tokens leaked via thrown errors

GHSA-5pq8-3ffp-7w5m MEDIUM
Published August 13, 2026
CISO Take

hashi-vault-js, an npm client for HashiCorp Vault, re-throws the raw Axios error on every API call, which means the `X-Vault-Token` header and any secret payloads submitted on write operations end up embedded in the exception object. Any application that logs caught exceptions with console.error, pino, winston, Sentry, or an APM will unknowingly write live Vault tokens and secret values to logs and monitoring systems in plaintext. There's no CVSS score, no EPSS data, no public exploit, and no listed downstream dependents, so this isn't a hands-on-keyboard exploit — it's a passive, self-inflicted credential leak that anyone with read access to your logging or observability stack can pick up. In AI/ML environments this matters because Vault is commonly used to broker LLM provider API keys and other pipeline credentials, so a leaked token could cascade into broader unauthorized access. Upgrade to hashi-vault-js 0.5.2 immediately, or as a stopgap, strip `err.config.headers` and `err.config.data` before any caught hashi-vault-js error reaches a logger or crash reporter, and rotate any Vault tokens that may already be sitting in historical logs.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Medium severity with no CVSS vector, no EPSS score, no CISA KEV listing, and no public exploit or scanner template — this is not an actively targeted vulnerability. However, exploitability is effectively trivial: no attacker action is required against the Vault service itself, only routine application logging behavior combined with an adversary who already has (or gains) read access to logs, APM traces, or crash-reporting dashboards (e.g., via a misconfigured Sentry project, an over-permissioned log aggregator, or a compromised CI/CD pipeline). The real risk is the secondary impact: a leaked Vault token grants direct read/write access to whatever secrets that token is scoped to, which could include LLM provider API keys, database credentials, or model registry tokens.

How does the attack unfold?

Error-Path Trigger
A hashi-vault-js API call fails (auth error, timeout, or network issue) and the library throws the raw AxiosError, which still contains the X-Vault-Token header and any submitted secret data.
Incidental Logging
The consuming application's error handler logs the caught exception via console.error, Sentry, pino/winston, or an APM tool, unknowingly persisting the live Vault token and secrets in plaintext.
Credential Discovery
An adversary with read access to logs, crash reports, or APM traces searches for and finds the exposed Vault token among routine error events.
AML.T0055
Vault Compromise
The adversary uses the stolen token to authenticate directly to the Vault API, gaining unauthorized access to every secret within that token's policy scope, including AI pipeline credentials.

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Microsoft APM npm <= 0.5.1 0.5.2
3.9K Pushed 7d ago 64% patched ~23d to patch Full package profile →

Do you use Microsoft APM? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
0.2%
chance of exploitation in 30 days
Higher than 5% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Trivial

What should I do?

1 step
  1. Upgrade to hashi-vault-js >= 0.5.2, which redacts err.config.headers['X-Vault-Token'] and err.config.data before re-throwing. If an immediate upgrade isn't possible, wrap all hashi-vault-js calls in try/catch and strip the err.config object (headers and data specifically) before passing errors to any logger, Sentry, or APM integration. Audit existing log storage, Sentry issues, and APM traces for any historical exposure of Vault tokens or secret values, and rotate any tokens found. Going forward, configure log scrubbing/redaction rules for the X-Vault-Token header pattern as a defense-in-depth control, and review Vault token TTLs/scopes so that any single leaked token has minimal blast radius.

What does CISA's SSVC say?

Decision Track
Exploitation none
Automatable No
Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data Leakage Auth Bypass Plugin API AML.T0055

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, Robustness and Cybersecurity
NIST AI RMF
GOVERN 6.1 - Third-party risks and dependencies are identified and managed
OWASP LLM Top 10
LLM02:2025 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-55102?

hashi-vault-js, an npm client for HashiCorp Vault, re-throws the raw Axios error on every API call, which means the `X-Vault-Token` header and any secret payloads submitted on write operations end up embedded in the exception object. Any application that logs caught exceptions with console.error, pino, winston, Sentry, or an APM will unknowingly write live Vault tokens and secret values to logs and monitoring systems in plaintext. There's no CVSS score, no EPSS data, no public exploit, and no listed downstream dependents, so this isn't a hands-on-keyboard exploit — it's a passive, self-inflicted credential leak that anyone with read access to your logging or observability stack can pick up. In AI/ML environments this matters because Vault is commonly used to broker LLM provider API keys and other pipeline credentials, so a leaked token could cascade into broader unauthorized access. Upgrade to hashi-vault-js 0.5.2 immediately, or as a stopgap, strip `err.config.headers` and `err.config.data` before any caught hashi-vault-js error reaches a logger or crash reporter, and rotate any Vault tokens that may already be sitting in historical logs.

Is CVE-2026-55102 actively exploited?

No confirmed active exploitation of CVE-2026-55102 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-55102?

Upgrade to hashi-vault-js >= 0.5.2, which redacts `err.config.headers['X-Vault-Token']` and `err.config.data` before re-throwing. If an immediate upgrade isn't possible, wrap all hashi-vault-js calls in try/catch and strip the `err.config` object (headers and data specifically) before passing errors to any logger, Sentry, or APM integration. Audit existing log storage, Sentry issues, and APM traces for any historical exposure of Vault tokens or secret values, and rotate any tokens found. Going forward, configure log scrubbing/redaction rules for the `X-Vault-Token` header pattern as a defense-in-depth control, and review Vault token TTLs/scopes so that any single leaked token has minimal blast radius.

What systems are affected by CVE-2026-55102?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, RAG pipelines, model serving.

What is the CVSS score for CVE-2026-55102?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksRAG pipelinesmodel serving

MITRE ATLAS Techniques

AML.T0055 Unsecured Credentials

Compliance Controls Affected

EU AI Act: Article 15
NIST AI RMF: GOVERN 6.1
OWASP LLM Top 10: LLM02:2025

What are the technical details?

Original Advisory

## Summary Vault token and secret values are exposed in thrown errors when using `hashi-vault-js`. ## Details Every API method in `Vault.js` executes `throw parseAxiosError(err)`, which returns the raw `AxiosError` untouched. That error carries the full Axios configuration, including the `X-Vault-Token` header and the request body. Consuming applications that log caught errors (e.g., using `console.error`, `pino`, `winston`, Sentry, or APMs) inadvertently log the live Vault token in plaintext. Furthermore, write-path methods expose submitted passwords and secret values via `err.config.data`. ## Impact When consuming applications log intercepted exceptions, sensitive credentials such as tokens, passwords, and secrets are unknowingly exposed to application logs, monitoring services, and APM systems via the raw `AxiosError`. This may lead to authorization bypass or unauthorized access to the underlying Vault instance. ## Patches This vulnerability should be addressed by redacting `err.config.headers['X-Vault-Token']` and `err.config.data` before re-throwing, or by throwing a purpose-built error containing only safe properties like status and message. Users should upgrade to a version that includes this fix. ## Workarounds If users cannot immediately update the library, they can mitigate this issue by capturing all exceptions thrown by `hashi-vault-js` and sanitizing or omitting the `err.config` object before passing the errors to logging utilities or crash reporters. ## Acknowledgements hashi-vault-js would like to thank Sebastián Alba Vives for reporting this vulnerability. ## Resources - [CWE-532: Insertion of Sensitive Information into Log File](https://cwe.mitre.org/data/definitions/532.html) - [CWE-209: Generation of Error Message Containing Sensitive Information](https://cwe.mitre.org/data/definitions/209.html)

Exploitation Scenario

An AI agent orchestration service uses hashi-vault-js to fetch an LLM provider API key from Vault before making inference calls. During a transient Vault network blip, the fetch call throws, and the application's error handler logs the full exception via Sentry for observability. The logged exception includes the `X-Vault-Token` header used for that request. An adversary who has read access to the Sentry project — perhaps through an over-shared team invite, a leaked Sentry API key, or a compromised CI service account with log-viewing permissions — searches recent error events, finds the token, and uses it to authenticate directly against the Vault API. From there they read every secret the token's policy allows, including the LLM API keys and any other credentials stored alongside them, without ever touching the AI application itself.

Weaknesses (CWE)

CWE-209 — Generation of Error Message Containing Sensitive Information: The product generates an error message that includes sensitive information about its environment, users, or associated data.

  • [Implementation] Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
  • [Implementation] Handle exceptions internally and do not display errors containing potentially sensitive information to a user.

Source: MITRE CWE corpus.

Timeline

Published
August 13, 2026
Last Modified
September 14, 2026
First Seen
August 13, 2026

Related Vulnerabilities