glibc's CVE-2015-7547 and HashiCorp Tools
CVE-2015-7547
was announced on the morning of February 16th. We would like to address HashiCorp users on how this affects any HashiCorp tooling.
The significance of this CVE was quickly understood because most versions of glibc in popular Linux distributions were vulnerable to a Remote Code Execution attack. The problem stems from the way glibc
's getaddrinfo(3)
call mishandle large DNS responses which results in a stack-based buffer overflow.
This statement details the HashiCorp tools which are affected by this CVE and various mitigation steps administrators can take to protect against this vulnerability. Recent updates to our build toolchain have prevented most of our tools from being affected by this vulnerability.
» Status of Tools
The impact of CVE-2015-7547
on HashiCorp tools is limited to only those tools that were compiled using cgo
or somehow link to a vulnerable glibc
. At the time of this publication, the list of affected and unaffected binaries provided by HashiCorp include:
Tool | Vulnerable | Unaffected | Notes |
---|---|---|---|
Consul | <= 0.5.2 | >= 0.6.0 | |
Nomad | All releases | N/A | Patched glibc is required |
Otto | N/A | All releases | |
Packer | <= 0.7.1 | >= 0.7.2 | |
Serf | N/A | All releases | |
Terraform | <= 0.6.6 | >= 0.6.7 | |
Vagrant | All releases | N/A | Patched glibc is required to the embedded Ruby |
Vault | <= 0.3.0 | >= 0.3.1 |
This is not a vulnerability in HashiCorp's tools; it is a vulnerability in a library (glibc
) that specific versions of HashiCorp's tools use at runtime. The correct fix for the affected versions is detailed below and involves upgrading glibc and restarting processes.
If the base OS is running a vulnerable version of glibc
and the specific HashiCorp tool is unaffected according to the table above, then the HashiCorp tool remains unaffected because their DNS resolution is performed without using glibc's getaddrinfo(3)
. Similarly, Vagrant on Mac OS-X or Windows is not vulnerable because its getaddrinfo(3)
implementation is not derived from glibc.
» Impact
An attacker who can cause a DNS response to be sent in excess of 2048
bytes for UDP-based queries or 1024
bytes for TCP-based queries and can craft a malicious payload will be able to compromise a vulnerable process with a stack-based buffer overflow.
This is a high-risk vulnerability because this represents a Remote Code Execution (RCE) vulnerability for any affected host even if the host is not directly exposed to the Internet. Both Debian and Red Hat have marked this as a "critical" security issue (Red Hat's highest classification), Ubuntu has released updates on the same day. Many other Linux distributions followed suit with expedited releases, too.
OSes other than Linux are not vulnerable to this RCE (e.g. Alpine Linux, Windows, Mac OS-X, FreeBSD).
» Workaround
There are several workarounds detailed in Google's disclosure announcement on their Security Blog.
» Solution
Perform one of the following:
-
Recompile your OS's
glibc
using the following patch provided by Carlos O'Donell from Red Hat:https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
-
Upgrade your glibc using your distribution's package management framework to a patched version.
For applications running in a container engine (such as Docker), the container must be rebuilt with an upgraded glibc. Upgrading the host's glibc will not impact the glibc in the containers.
After upgrading glibc, it is necessary to restart any process whose age is older than the glibc binary on disk (in many cases this means a reboot).
» References
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7547
https://lists.debian.org/debian-security-announce/2016/msg00050.html
https://access.redhat.com/security/cve/CVE-2015-7547
http://www.ubuntu.com/usn/usn-2900-1/
https://aws.amazon.com/security/security-bulletins/cve-2015-7547-advisory/
https://www.suse.com/security/cve/CVE-2015-7547.html
https://googleonlinesecurity.blogspot.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html
https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
http://dankaminsky.com/2016/02/20/skeleton/
» Final Thoughts
At HashiCorp, security is a dominant part of our ethos and we are sometimes impacted by elements out of our control (CVE-2015-7547
is a great example of this). While this CVE preempted the majority of the InfoSec news cycle for the week, internally we have been in process of changing our reporting and disclosure handling for our tools and customers. We will announce this new process shortly.
Sign up for the latest HashiCorp news
More blog posts like this one

Secure AI identity with HashiCorp Vault
HashiCorp Vault's dynamic credentials give AI applications traceable, short-lived identities with just-in-time access, replacing risky static credentials. Try our proof-of-concept LangChain application to see how this can work.

SCEP: A bridge from legacy PKI to modern certificate management
Vault Enterprise now supports SCEP, empowering secure certificate enrollment for legacy and device-constrained environments while helping teams plan their evolution to modern protocols like EST and ACME.

Build secure, AI-driven workflows with Terraform and Vault MCP servers
At AWS Summit New York, HashiCorp introduced new capabilities that bring Terraform, Vault, and Vault Radar into the age of AI agents — advancing secure, automated infrastructure through composable, agentic systems.