Skip to main content
HIGH7.4GHSA-jgf3-f6rg-8x3h
CVSS vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N
Affected projects
sops
Disclosed
Last updated

Affected versions

ProjectVulnerable range
github.com/getsops/sops/v3*

References

Summary​

When SOPS decrypts a file, it attempts each identity specified in the encrypted file's metadata in sequence, including any HashiCorp Vault or OpenBao key identified by an hc_vault metadata entry. If a Vault token is available — either in ~/.vault-token or the VAULT_TOKEN environment variable — SOPS contacts the vault_address from the file's metadata and sends the token in the X-Vault-Token HTTP header. Because SOPS performs no validation of the vault_address field, an attacker who can supply a crafted SOPS-encrypted file can set vault_address to an attacker-controlled server and cause SOPS to exfiltrate the victim's Vault or OpenBao authentication token.

Impact​

Any user who decrypts an attacker-provided SOPS-encrypted file while a Vault token is configured — whether in ~/.vault-token or the VAULT_TOKEN environment variable — will have that token sent to the attacker's server. This affects all SOPS versions prior to 3.13.0 and all operating environments where SOPS decrypts files sourced from untrusted parties (CI pipelines consuming third-party encrypted files, security reviews of external repositories, developer workstations). The exfiltrated token may grant read or write access to secrets in Vault or OpenBao depending on the token's policy, constituting a high-severity credential compromise.

Detection​

Review the systems and pipelines where SOPS is used to decrypt files received from external or untrusted sources. Examine SOPS audit logs and network egress logs for outbound HTTPS connections from SOPS processes to hosts other than the expected Vault or OpenBao servers. If a VAULT_TOKEN environment variable or ~/.vault-token file is present on a system where untrusted SOPS files are decrypted, treat the token as potentially compromised and rotate it. On SOPS 3.13.0 and later, set SOPS_HC_VAULT_ALLOWLIST to restrict which Vault servers SOPS may contact, and review logs for blocked connection attempts that indicate exploitation was tried.

Mitigation​

Upgrade to SOPS 3.13.0 or newer, which introduces the SOPS_HC_VAULT_ALLOWLIST environment variable. Set this variable to a comma-separated list of allowed Vault or OpenBao server URL prefixes before using SOPS to decrypt any file. To block all Vault server contact, set SOPS_HC_VAULT_ALLOWLIST=none. To restrict to a specific server, set it to the server's URL prefix (for example, https://vault.example.com:8200). Note that a future SOPS release will change the default from all (unrestricted, the pre-3.13.0 behavior) to none, so setting this variable explicitly is strongly recommended. On versions prior to 3.13.0, the only mitigation is to remove or invalidate the ~/.vault-token file and unset VAULT_TOKEN before decrypting any file from an untrusted source, which prevents any Vault contact but also disables legitimate Vault-encrypted file decryption.

References​