CVE-2014-6271, known as Shellshock, is a remote code execution vulnerability in GNU Bash, rated CVSS v2 10.0. For roughly 25 years, Bash mishandled specially crafted environment variables, executing trailing commands attackers appended to what looked like a function definition. Because so many systems pass untrusted data into environment variables before invoking a shell — web servers via CGI, DHCP clients, SSH ForceCommand setups — this local-looking parser quirk became a widely exploitable remote flaw overnight.
Timeline and impact
Shellshock was discovered by Stéphane Chazelas and disclosed on September 24, 2014. Mass scanning and exploitation began within hours; unlike bugs that need bespoke exploits, Shellshock could be fired with a single crafted HTTP header. The initial patch turned out to be incomplete, and a rapid series of follow-up identifiers — including CVE-2014-7169, CVE-2014-6277, CVE-2014-6278, CVE-2014-7186, and CVE-2014-7187 — addressed additional parser problems uncovered in the days after. The episode became a lesson in both the reach of a ubiquitous dependency and the difficulty of fully fixing a fragile parser under pressure.
The scale was immediate and worldwide. Within a day, automated scanners were spraying the crafted () { :; }; string across HTTP endpoints, and botnets began recruiting vulnerable web servers within hours of the first patch. Because the flaw sat in a program that had shipped on essentially every Unix-like system for decades, the exposed population included not just web servers but home routers, network appliances, industrial controllers, and countless embedded devices whose firmware was rarely — if ever — updated. Many of those devices are still running the original vulnerable Bash today. That long tail is exactly why Shellshock earned comparisons to Heartbleed from the same year: the fix was easy on maintained systems and effectively impossible on the enormous fleet of forgotten ones.
Technical root cause
Bash lets you export functions to child processes through the environment. Historically it did this by encoding a function as an environment variable whose value began with () {. When a new Bash process started, it scanned the environment, spotted values in that shape, and evaluated them to recreate the functions.
The bug: Bash did not stop parsing at the end of the function body. Anything placed after the closing brace was executed immediately during that import step. So an attacker who could set an environment variable to a value like the following got arbitrary command execution the moment Bash started:
env x='() { :; }; echo VULNERABLE' bash -c "echo test"
On a patched system this prints only test. On a vulnerable one it prints VULNERABLE first — proof that the trailing echo ran during environment import, before the intended command. The () { :; } is a trivial no-op function; the payload is everything after the ;.
The reason this crossed the network boundary is that many services copy untrusted input into environment variables and then spawn a shell:
- CGI web servers map HTTP request headers into environment variables such as
HTTP_USER_AGENT. A request withUser-Agent: () { :; }; /bin/some-commandexecutes the command if the CGI handler is Bash-backed. - DHCP clients could pass malicious server-supplied option strings into environment variables consumed by shell hook scripts.
- OpenSSH
ForceCommand/AcceptEnvconfigurations could let a restricted user smuggle a payload past the intended command restriction.
How to detect if you are affected
- Run the one-liner test above locally. Printing
VULNERABLEconfirms the flaw; printing onlytestindicates a patched Bash. - Version check. Bash releases predating the September 2014 fixes are affected. Because the first patch was incomplete, confirm your distro's build addresses the full CVE series, not just CVE-2014-6271.
- Do not forget appliances and containers. Legacy embedded devices, network gear, and minimal container images frequently carry old Bash builds and rarely see updates.
At fleet scale, a manual bash --version sweep is unworkable. Safeguard's software composition analysis inventories the Bash package version across hosts and images so exposure becomes a single query.
Remediation and patched versions
- Update Bash to your distribution's patched package covering the complete Shellshock CVE series, then confirm with the environment-variable test.
- Rebuild container base images. A patched host does not help if your images still ship a vulnerable Bash. Safeguard's container security scanning flags an old Bash inside image layers before they ship.
- Reduce the attack surface. Retire Bash-backed CGI where possible; prefer non-shell interpreters for request handling. This shrinks the class of bug, not just this instance.
- Hunt for exploitation in web server logs for
() {sequences in headers and query strings on any host that was internet-facing while unpatched.
How Safeguard surfaces and auto-fixes Shellshock
Shellshock is a reminder that "core system utility" and "attack surface" are the same thing when untrusted input reaches a shell. Safeguard tracks OS-level packages like Bash across your entire estate — hosts, images, and the forgotten appliances in between — and matches them against vulnerability intelligence, so an ancient Bash in a rarely rebuilt image cannot silently persist. Findings carry CISA KEV and EPSS context, so a trivially exploitable, internet-reachable RCE is prioritized rather than lost among low-risk noise.
Where the fix is a package upgrade, automated fix pull requests bump the Bash version in your image definitions and re-run your checks, and Griffin AI highlights which hosts actually expose a shell to untrusted input versus those where Bash is present but unreachable. If you are comparing how thoroughly different scanners cover OS-package CVEs like this one, our comparison against Snyk walks through it.
A parser that ran a few extra characters became one of 2014's defining internet emergencies. Continuous OS-level inventory is what keeps the next such bug from lingering unpatched in the corners of your fleet.
Get started at app.safeguard.sh/register, or read the docs at docs.safeguard.sh.