Safeguard
Security Guides•

Shellshock: why a shell treated environment variables as code

Shellshock (CVE-2014-6271) let attackers run commands via crafted environment variables in Bash. How it reached web servers, SSH and DHCP clients.

Safeguard Security Team
3 min read

Shellshock, CVE-2014-6271, was a flaw in GNU Bash through version 4.3. Bash processed trailing text after a function definition stored in an environment variable and ran it. Any program that put attacker-controlled data into an environment variable and then started Bash could end up running the attacker's commands.

The mechanism, simply

Bash lets you pass a function to a child shell by exporting it in an environment variable. Normally the variable holds only the function definition. In vulnerable versions, if extra commands followed the definition, Bash executed them as the child shell started.

The bug sat in the loading step. Nothing about the variable's name or origin was checked. If something outside the shell controlled the value, that something controlled the shell.

Why the reach was so wide

The records for the CVE cite three common routes:

  • Web servers running CGI scripts. Apache's mod_cgi and mod_cgid place parts of an HTTP request, such as headers, into environment variables, and the script may run under Bash.
  • OpenSSH with ForceCommand. That feature runs a configured command through the user's shell with environment data from the client.
  • DHCP client scripts. Data from a DHCP server can end up in environment variables passed to shell scripts.

In each case, the attacker did not need to log in. A single crafted request could be enough.

Severity and status

The CVE record, published 24 September 2014, carries a CVSS 3.1 score of 9.8 and is classified as OS command injection. It is listed in CISA's Known Exploited Vulnerabilities catalog, added on 28 January 2022. That is a reminder that old bugs stay on attackers' lists as long as unpatched systems exist.

The incomplete first fix

The record notes that the original patch was incorrect, and the vulnerability remained after it. A second identifier, CVE-2014-7169, was assigned for what was left. See why the first fix is sometimes incomplete.

What to do with this knowledge today

  • Check what still ships old Bash. Embedded devices, old appliances and legacy containers can be years behind.
  • Avoid shelling out with untrusted data. Pass arguments as arrays and avoid running a shell where you do not need one.
  • Keep CGI off by default. If you must use it, run scripts under a minimal interpreter instead of a full shell.
  • Sanitise environment passing. Do not forward request data into the environment unless a feature needs it.
  • Inventory base images. Container images carry their own shell packages. A scan tells you which ones are old.

Safeguard's SBOM and dependency scanning, including container image scans, can flag outdated system packages in an image. A free scan is available at gold.safeguard.sh/scan.

Quick check

Did exploitation need a login?

Not in the main routes. A crafted HTTP request to a CGI script could be enough.

Which Bash versions were affected?

GNU Bash through 4.3, according to the CVE record.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.