CVE-2026-55102 in hashi-vault-js
Summary
by MITRE • 09/14/2026
hashi-vault-js is a Node.js module for interacting with the HashiCorp Vault API. Prior to 0.5.2, every API method in src/Vault.js passes failed requests through parseAxiosError(), which rethrows the raw AxiosError while retaining AxiosError.config and the equivalent response configuration. These objects can contain the X-Vault-Token request header and err.config.data request body, including submitted passwords or secret values. When a consuming application records the caught exception through console logging, structured loggers, monitoring, crash reporting, or an application performance monitoring service, the live Vault token and request secrets can be stored in plaintext and exposed to anyone with access to that output. A stolen token can permit unauthorized access to the Vault instance under the token's policies. This issue is fixed in version 0.5.2.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/14/2026
The hashi-vault-js library serves as a Node.js interface for interacting with the HashiCorp Vault API, facilitating secure management of secrets and credentials within application architectures. A critical security flaw existed in versions prior to 0.5.2 regarding how HTTP request failures were handled by the core module. Specifically, every API method utilized an error handling routine that invoked parseAxiosError when a request failed. This function was designed to rethrow the raw AxiosError object rather than sanitizing it before propagation. Consequently, the full context of the failed network call remained attached to the exception, including sensitive metadata and payload data that should not be exposed in standard application logs or error reporting mechanisms.
The technical root cause lies in the retention of the Axios configuration object within the thrown error instance. This config object contains detailed information about the HTTP request, most notably the X-Vault-Token header which holds the active authentication token for accessing Vault resources. Additionally, it retains the data property from the request body, which may include plaintext passwords, API keys, or other secret values submitted during operations such as writing secrets to a vault path. Because these objects are preserved in their entirety within the error structure, any downstream process that serializes or logs the exception will inadvertently capture this sensitive information.
The operational impact of this vulnerability is severe due to common development practices regarding error handling and observability. When an application catches exceptions from hashi-vault-js calls, it often passes them through logging frameworks, structured loggers like Winston or Bunyan, monitoring services such as Datadog or New Relic, or crash reporting tools like Sentry. These systems typically serialize the entire exception object to provide developers with context for debugging failed requests. In this scenario, the serialization process captures the raw AxiosError along with its attached config and response objects. As a result, live Vault tokens and submitted secrets are written in plaintext to log files, database entries, or remote monitoring dashboards. This creates an unintended data leakage channel where credentials can be viewed by anyone with access to these logs or monitoring interfaces, including DevOps engineers, support staff, or potentially external attackers if the logging infrastructure is compromised.
From a threat modeling perspective, this vulnerability aligns with CWE-209: Generation of Error Message Containing Sensitive Information and CWE-532: Insertion of Sensitive Information into Log File. It also relates to ATT&CK technique T1530: Data from Local System Retrieval, as the attacker gains access to sensitive data stored within application logs or monitoring systems rather than directly compromising the Vault server itself. The exposure of a valid Vault token allows an adversary to perform unauthorized actions against the HashiCorp Vault instance based on the policies associated with that specific token. This could lead to further privilege escalation, exfiltration of additional secrets, or modification of critical configuration data within the vault, thereby undermining the entire security posture of the application ecosystem relying on this secret management system.
The issue was addressed in version 0.5.2 by modifying the error handling logic to prevent the leakage of sensitive request details. The fix ensures that when an AxiosError is rethrown or processed, the configuration object containing headers and body data is sanitized or excluded from the final exception payload presented to consuming applications. Developers using this library should immediately upgrade to version 0.5.2 or later to mitigate this risk. For environments where older versions are still in use, it is imperative to implement custom error handling wrappers that explicitly strip sensitive fields such as headers and request bodies before logging exceptions. Additionally, organizations should audit existing log storage systems for any previously leaked tokens or secrets generated by vulnerable instances of the library and rotate those credentials immediately to prevent unauthorized access.