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.
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?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Microsoft APM | npm | <= 0.5.1 | 0.5.2 |
Do you use Microsoft APM? You're affected.
How severe is it?
What should I do?
1 step-
Upgrade to hashi-vault-js >= 0.5.2, which redacts
err.config.headers['X-Vault-Token']anderr.config.databefore re-throwing. If an immediate upgrade isn't possible, wrap all hashi-vault-js calls in try/catch and strip theerr.configobject (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 theX-Vault-Tokenheader 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?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
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
MITRE ATLAS Techniques
AML.T0055 Unsecured Credentials Compliance Controls Affected
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
Primary
CWE-532 Insertion of Sensitive Information into Log File
Primary
CWE-209 Generation of Error Message Containing Sensitive Information CWE-532 Insertion of Sensitive Information into Log File 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.
References
- github.com/kyndryl-open-source/hashi-vault-js/commit/ed0797a2d09c1fe0fd20764dde66cbc29241d9fb x_refsource_MISC
- github.com/kyndryl-open-source/hashi-vault-js/pull/67 x_refsource_MISC
- github.com/kyndryl-open-source/hashi-vault-js/releases/tag/v0.5.2 x_refsource_MISC
- github.com/advisories/GHSA-5pq8-3ffp-7w5m
- github.com/kyndryl-open-source/hashi-vault-js/security/advisories/GHSA-5pq8-3ffp-7w5m
Timeline
Related Vulnerabilities
CVE-2026-46858 9.1 Oracle APM: unauthenticated write/DoS via JVM Diagnostics
Same package: apm CVE-2026-57947 8.5 Pinpoint APM: SSRF via alarm webhook registration
Same package: apm CVE-2026-45539 7.4 Microsoft APM: symlink attack leaks host files in agent deps
Same package: apm CVE-2026-57948 6.8 Pinpoint: insecure JWT cookie enables session hijacking
Same package: apm CVE-2026-49835 5.9 Sigstore TSA: unbounded metrics label DoS
Same package: apm