Skip to content

GHSA-6239-28c2-9mrm BIT-vault-2021-38554 CVE-2021-38554 GO-2022-0632

Improper Removal of Sensitive Information Before Storage or Transfer in HashiCorp Vault

Medium Go
Severity
5.3 / 10
Medium · CVSS 3.1
Exploit chance (EPSS)
0.91%
Chance of exploitation in the next 30 days. Higher than 60.00% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-212 Improper Removal of Sensitive Information Before Storage or Transfer
Fix
1.6.6
Upgrade github.com/hashicorp/vault to this version or later

Description

HashiCorp Vault and Vault Enterprise’s UI erroneously cached and exposed user-viewed secrets between sessions in a single shared browser. Fixed in 1.8.0 and pending 1.7.4 / 1.6.6 releases.

Affected versions

Go

PackageVulnerableFixed in
github.com/hashicorp/vault
< 1.6.6
1.6.6
github.com/hashicorp/vault
>= 1.7.0, < 1.7.4
1.7.4
github.com/hashicorp/vault
< 1.6.6
>= 1.7.0, < 1.7.4
1.6.6
1.7.4

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

github.com/hashicorp/vault Go → 1.6.6

go
go get github.com/hashicorp/vault@v1.6.6 && go mod tidy

Severity breakdown

CVSS 3.1 5.3

CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N

Attack vector
Network
Attack complexity
High
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
None

Weakness

CWE-212: Improper Removal of Sensitive Information Before Storage or Transfer

The product stores, transfers, or shares a resource that contains sensitive information, but it does not properly remove that information before the product makes the resource available to unauthorized actors.

How to prevent it
  • Requirements: Clearly specify which information should be regarded as private or sensitive, and require that the product offers functionality that allows the user to cleanse the sensitive information from the resource before it is published or exported to other parties.
  • Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
  • Implementation, Operation: Some tools can automatically analyze documents to redact, strip, or "sanitize" private information, although some human review might be necessary. Tools may vary in terms of which document formats can be processed. When calling an external program to automatically generate or convert documents, invoke the program with any available options that avoid generating sensitive metadata. Some formats have well-defined fields that could contain private data, such as Exchangeable image file format (Exif), which can contain potentially sensitive metadata such as geolocation, date, and time [REF-1515] [REF-1516].
  • Implementation: Use naming conventions and strong types to make it easier to spot when sensitive data is being used. When creating structures, objects, or other complex entities, separate the sensitive and non-sensitive data as much as possible.
  • Implementation: Avoid errors related to improper resource shutdown or release (CWE-404), which may leave the sensitive data within the resource if it is in an incomplete state.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-88v5-9hxc-f85r
HashiCorp Vault Vulnerable to Denial-of-Service via Unauthenticated Root Token Generation/Rekey Operations
High Also affects github.com/hashicorp/vault
GHSA-8r5m-3f66-qpr3
HashiCorp Vault has Server-Side Request Forgery in ACME Challenge Validation via Attacker-Controlled DNS
High Also affects github.com/hashicorp/vault
GHSA-72gw-fmmr-c4r4
HashiCorp Vault May Expose Tokens to Auth Plugins Due to Incorrect Header Sanitization
High Also affects github.com/hashicorp/vault
GHSA-m2w4-8ggf-rj47
HashiCorp Vault has a KVv2 Metadata and Secret Deletion Policy Bypass that leads to Denial-of-Service
High Also affects github.com/hashicorp/vault
GHSA-vp5w-xcfc-73wf
Hashicorp Vault and Vault Enterprise vulnerable to a denial of service when processing JSON
High Also affects github.com/hashicorp/vault
GHSA-9g4h-h484-3578
HashiCorp Vault and Vault Enterprise's AWS Auth method may be susceptible to authentication bypass
High Also affects github.com/hashicorp/vault
GHSA-8f82-53h8-2p34
HashiCorp Vault Community Edition Denial of Service Though Complex JSON Payloads
High Also affects github.com/hashicorp/vault
GHSA-7rx2-769v-hrwf
HashiCorp Vault ldap auth method may not have correctly enforced MFA
High Also affects github.com/hashicorp/vault
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor