HashicorpCVEs & Vulnerabilities

The official vault docker images before 0.11.6 contain a blank password for a root user. System using the vault docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password.

The official Consul Docker images 0.7.1 through 1.4.2 contain a blank password for a root user. System using the Consul Docker container deployed by affected versions of the Docker image may allow a remote attacker to achieve root access with a blank password.

HashiCorp go-slug up to 0.4.3 did not fully protect against directory traversal while unpacking tar archives, and protections could be bypassed with specific constructions of multiple symlinks. Fixed in 0.5.0.

HashiCorp Nomad and Nomad Enterprise 0.9.0 up to 0.12.7 client Docker file sandbox feature may be subverted when not explicitly disabled or when using a volume mount type. Fixed in 0.12.8, 0.11.7, and 0.10.8.

HashiCorp Consul and Consul Enterprise 1.2.0 up to 1.8.5 allowed operators with operator:read ACL permissions to read the Connect CA private key configuration. Fixed in 1.6.10, 1.7.10, and 1.8.6.

HashiCorp Consul Enterprise version 1.7.0 up to 1.8.4 includes a namespace replication bug which can be triggered to cause denial of service via infinite Raft writes. Fixed in 1.7.9 and 1.8.5.

HashiCorp Nomad and Nomad Enterprise version 0.9.0 up to 0.12.5 client file sandbox feature can be subverted using either the template or artifact stanzas. Fixed in 0.12.6, 0.11.5, and 0.10.6

HashiCorp Vault and Vault Enterprise versions 1.0 and newer allowed leases created with a batch token to outlive their TTL because expiration time was not scheduled correctly. Fixed in 1.4.7 and 1.5.4.

HashiCorp Vault and Vault Enterprise versions 0.8.3 and newer, when configured with the GCP GCE auth method, may be vulnerable to authentication bypass. Fixed in 1.2.5, 1.3.8, 1.4.4, and 1.5.1.

HashiCorp Vault and Vault Enterprise versions 0.7.1 and newer, when configured with the AWS IAM auth method, may be vulnerable to authentication bypass. Fixed in 1.2.5, 1.3.8, 1.4.4, and 1.5.1..

HashiCorp vault-ssh-helper up to and including version 0.1.6 incorrectly accepted Vault-issued SSH OTPs for the subnet in which a host's network interface was located, rather than the specific IP address assigned to that interface. Fixed in 0.2.0.

HashiCorp Terraform Enterprise up to v202006-1 contained a default signup page that allowed user registration even when disabled, bypassing SAML enforcement. Fixed in v202007-1.

HashiCorp Consul and Consul Enterprise include an HTTP API (introduced in 1.2.0) and DNS (introduced in 1.4.3) caching feature that was vulnerable to denial of service. Fixed in 1.6.6 and 1.7.4.

HashiCorp Consul and Consul Enterprise did not appropriately enforce scope for local tokens issued by a primary data center, where replication to a secondary data center was not enabled. Introduced in 1.4.0, fixed in 1.6.6 and 1.7.4.

HashiCorp Consul and Consul Enterprise failed to enforce changes to legacy ACL token rules due to non-propagation to secondary data centers. Introduced in 1.4.0, fixed in 1.6.6 and 1.7.4.

HashiCorp Consul and Consul Enterprise could crash when configured with an abnormally-formed service-router entry. Introduced in 1.6.0, fixed in 1.6.6 and 1.7.4.

HashiCorp Vault and Vault Enterprise logged proxy environment variables that potentially included sensitive credentials. Fixed in 1.3.6 and 1.4.2.

HashiCorp Vault and Vault Enterprise 1.4.0 and 1.4.1, when configured with the GCP Secrets Engine, may incorrectly generate GCP Credentials with the default time-to-live lease duration instead of the engine-configured setting. This may lead to generated GCP credentials being valid for longer than intended. Fixed in 1.4.2.

HashiCorp Nomad and Nomad Enterprise up to 0.10.4 contained a cross-site scripting vulnerability such that files from a malicious workload could cause arbitrary JavaScript to execute in the web UI. Fixed in 0.10.5.

HashiCorp Vault and Vault Enterprise versions 0.11.0 through 1.3.3 may, under certain circumstances, have existing nested-path policies grant access to Namespaces created after-the-fact. Fixed in 1.3.4.

HashiCorp Vault and Vault Enterprise versions 0.9.0 through 1.3.3 may, under certain circumstances, have an Entity's Group membership inadvertently include Groups the Entity no longer has permissions to. Fixed in 1.3.4.

HashiCorp Sentinel up to 0.10.1 incorrectly parsed negation in certain policy expressions. Fixed in 0.10.2.

HashiCorp Nomad and Nomad Enterprise up to 0.10.2 incorrectly validated role/region associated with TLS certificates used for mTLS RPC, and were susceptible to privilege escalation. Fixed in 0.10.3.

HashiCorp Consul and Consul Enterprise 1.4.1 through 1.6.2 did not uniformly enforce ACLs across all API endpoints, resulting in potential unintended information disclosure. Fixed in 1.6.3.

HashiCorp Consul and Consul Enterprise up to 1.6.2 HTTP/RPC services allowed unbounded resource usage, and were susceptible to unauthenticated denial of service. Fixed in 1.6.3.

HashiCorp Nomad and Nonad Enterprise up to 0.10.2 HTTP/RPC services allowed unbounded resource usage, and were susceptible to unauthenticated denial of service. Fixed in 0.10.3.

HashiCorp Vault Enterprise 0.11.0 through 1.3.1 fails, in certain circumstances, to revoke dynamic secrets for a mount in a deleted namespace. Fixed in 1.3.2.

When using the Azure backend with a shared access signature (SAS), Terraform versions prior to 0.12.17 may transmit the token and state snapshot using cleartext HTTP.

HashiCorp Nomad 0.9.0 through 0.9.1 has Incorrect Access Control via the exec driver.

HashiCorp Consul 1.4.0 through 1.5.0 has Incorrect Access Control. Keys not matching a specific ACL rule used for prefix matching in a policy can be deleted by a token using that policy even with default deny settings configured.

HashiCorp Consul 1.4.3 lacks server hostname verification for agent-to-agent TLS communication. In other words, the product behaves as if verify_server_hostname were set to false, even when it is actually set to true. This is fixed in 1.4.4.

HashiCorp Consul (and Consul Enterprise) 1.4.x before 1.4.3 allows a client to bypass intended access restrictions and obtain the privileges of one other arbitrary token within secondary datacenters, because a token with literally "<hidden>" as its secret is used in unusual circumstances.

HashiCorp Consul 0.5.1 through 1.4.0 can use cleartext agent-to-agent RPC communication because the verify_outgoing setting is improperly documented. NOTE: the vendor has provided reconfiguration steps that do not require a software upgrade.

HashiCorp Vault before 1.0.0 writes the master key to the server log in certain unusual or misconfigured scenarios in which incorrect data comes from the autoseal mechanism without an error being reported.

An Amazon Web Services (AWS) developer who does not specify the --owners flag when describing images via AWS CLI, and therefore not properly validating source software per AWS recommended security best practices, may unintentionally load an undesired and potentially malicious Amazon Machine Image (AMI) from the uncurated public community AMI catalog.

It is possible to exploit an unsanitized PATH in the suid binary that ships with vagrant-vmware-fusion 4.0.25 through 5.0.4 in order to escalate to root privileges.

Hashicorp vagrant-vmware-fusion 5.0.4 allows local users to steal root privileges if VMware Fusion is not installed.

The vagrant update process in Hashicorp vagrant-vmware-fusion 5.0.2 through 5.0.4 allows local users to steal root privileges via a crafted update request when no updates are available.

aws/resource_aws_iam_user_login_profile.go in the HashiCorp Terraform Amazon Web Services (AWS) provider through v1.12.0 has an inappropriate PRNG algorithm and seeding, which makes it easier for remote attackers to obtain access by leveraging an IAM account that was provisioned with a weak password.

If HashiCorp Vagrant VMware Fusion plugin (aka vagrant-vmware-fusion) 5.0.3 is installed but VMware Fusion is not, a local attacker can create a fake application directory and exploit the suid sudo helper in order to escalate to root.

In HashiCorp Vagrant VMware Fusion plugin (aka vagrant-vmware-fusion) 5.0.1, a local attacker or malware can silently subvert the plugin update process in order to escalate to root privileges.

In HashiCorp Vagrant VMware Fusion plugin (aka vagrant-vmware-fusion) 5.0.0, a local attacker or malware can silently subvert the plugin update process in order to escalate to root privileges.

An insecure suid wrapper binary in the HashiCorp Vagrant VMware Fusion plugin (aka vagrant-vmware-fusion) 4.0.24 and earlier allows a non-root user to obtain a root shell.

HashiCorp Vagrant VMware Fusion plugin (aka vagrant-vmware-fusion) before 4.0.24 uses weak permissions for the sudo helper scripts, allows local users to execute arbitrary code with root privileges by overwriting one of the scripts.

The sudo helper in the HashiCorp Vagrant VMware Fusion plugin (aka vagrant-vmware-fusion) before 4.0.21 allows local users to gain root privileges by leveraging failure to verify the path to the encoded ruby script or scrub the PATH variable.