Shellshock — GNU Bash Environment Variable Command Injection (CVE-2014-6271)

Severity Assessment

• Exploitability: 10/10 — NVD assigned CVE-2014-6271 a critical network-exploitable score, and common deployment patterns exposed Bash through web CGI and other services that translated remote input into environment variables.
• Impact: 10/10 — Successful exploitation allowed command execution with the privileges of the vulnerable service invoking Bash.
• Weaponization Risk: 10/10 — The payload format was compact, easy to test, and immediately applicable to internet-facing services that passed request metadata into Bash.
• Patch Urgency: 10/10 — CISA and vendors urged immediate updates on September 24, 2014, and follow-on Shellshock fixes were needed because the first patch did not close the entire parser bug family.
• Detection Coverage: 6/10 — Network and log detections can identify common payload strings, but vulnerable entry points vary by service and may sit behind CGI, DHCP, SSH forced commands, or other environment-variable bridges.

Summary

Shellshock is the name commonly applied to CVE-2014-6271 and the related Bash parser vulnerabilities disclosed in September 2014. CVE-2014-6271 affected GNU Bash’s handling of exported function definitions stored in environment variables. When Bash imported a specially crafted environment variable, it could continue parsing and execute commands appended after the function definition.

The vulnerability was dangerous because many Unix and Linux services use environment variables as a bridge between network-facing software and child processes. Web servers running CGI scripts were the most widely discussed remote exposure path: HTTP headers and request metadata could become environment variables, and a CGI script that invoked Bash could trigger command execution before the script’s intended logic ran. Other service patterns could be affected when attacker-controlled values reached Bash through the process environment.

Stephane Chazelas discovered the issue, and Florian Weimer described it through open-source security coordination channels. Red Hat published public analysis and updates on September 24, 2014, and CISA issued an alert the same day. The initial fix for CVE-2014-6271 was followed by additional Bash parser fixes, including CVE-2014-7169, after researchers found related cases that were not fully addressed by the first patch.

Exploit Chain

Stage 1: Remote Input Becomes an Environment Variable

An attacker sends input to a service that maps remote data into environment variables. In a CGI web application, for example, HTTP request headers can be converted into variables such as HTTP_USER_AGENT, HTTP_COOKIE, or HTTP_REFERER before the CGI program executes.

Stage 2: Vulnerable Service Invokes Bash

The service or script launches Bash directly, or launches another command path that uses Bash to interpret shell logic. Bash starts by importing environment variables from the parent process.

Stage 3: Malformed Function Definition Is Parsed

The attacker-controlled environment variable begins with a Bash function-like value such as () { :; };. Vulnerable Bash versions incorrectly continue parsing after the exported function body instead of stopping at the function definition boundary.

Stage 4: Appended Commands Execute

Commands appended after the function definition execute during Bash startup. The resulting commands run with the privileges of the process invoking Bash, which may be a web server user, DHCP client context, restricted SSH command wrapper, or another service account.

Stage 5: Post-Exploitation Activity

After command execution, an attacker can download additional tooling, open a reverse shell, write files in locations permitted to the service account, enumerate local configuration, or attempt lateral movement. The vulnerability itself is an execution primitive; the observed impact depends on the exposed service, privilege context, network access, and local hardening.

Detection Guidance

Network and application logs should be searched for Shellshock function-definition payloads in request headers, query strings, cookies, and other user-controlled fields. Common payload markers include () {, };, and commands appended after a function-like prefix.

For web environments, inspect historical access logs for payloads in User-Agent, Referer, Cookie, and custom HTTP headers. CGI execution paths deserve priority because they commonly convert HTTP metadata into environment variables before invoking scripts.

Host telemetry should be reviewed for unexpected child processes spawned by web servers, DHCP clients, SSH forced-command handlers, mail filters, monitoring agents, or other services that may invoke Bash. Particular attention should be paid to shell processes launching network clients, file download utilities, interpreters, or outbound connections shortly after suspicious request traffic.

Vulnerability management should verify that Bash packages were updated through vendor-supported patches, not only that a single source patch was applied. Systems should be tested for both CVE-2014-6271 and related Shellshock parser variants because early remediation efforts sometimes fixed the original vector while leaving adjacent parser behavior exposed.

Indicators of Compromise

Payload Patterns

• Environment variable values beginning with () { followed by shell commands.
• HTTP headers containing () { :; }; or equivalent function-like prefixes.
• Shell metacharacters following a Bash function definition in web, DHCP, SSH, or mail-service logs.

Host Indicators

• Unexpected shell processes spawned by web server, CGI, DHCP, SSH, mail, or monitoring service accounts.
• Download utilities such as wget, curl, or equivalent tools launched by service users that do not normally execute them.
• New files, scripts, cron entries, or unauthorized SSH keys created by low-privilege service accounts after suspicious requests.

Network Indicators

• Outbound connections from servers immediately after requests containing Shellshock payload markers.
• Callback traffic to unrecognized external hosts from web server or service-account processes.
• Repeated scanning traffic that sends Bash function-definition strings across many paths or headers.

Disclosure Timeline

2014-09-24 — Public Disclosure and Initial Patch

CVE-2014-6271 was publicly disclosed on September 24, 2014. NVD published the vulnerability record, CISA issued an alert for the Bash remote code execution vulnerability, Red Hat published vendor guidance, and GNU Bash patch bash43-025 addressed the original parser issue.

2014-09-24 — Open-Source Coordination on oss-sec

The vulnerability was coordinated through the oss-sec mailing list, where the issue was described as command execution through specially crafted environment variables.

2014-09-25 — Incomplete-Fix Concern Emerges

Researchers identified related parsing behavior not fully addressed by the first patch, leading to the separate CVE-2014-7169 and additional vendor guidance. This expanded public treatment of Shellshock from a single CVE into a family of Bash parser fixes.

Late September 2014 — Broad Remediation Across Distributions

Linux and Unix vendors shipped updated Bash packages and additional follow-on fixes. Administrators were advised to update Bash through supported distribution packages and retest exposed services rather than relying only on manual source patching.

Sources & References

• National Vulnerability Database: CVE-2014-6271 — National Vulnerability Database, 2014-09-24
• CISA: Bourne-Again Shell Bash Remote Code Execution Vulnerability — CISA, 2014-09-24
• Red Hat: Bash specially-crafted environment variables code injection attack — Red Hat, 2014-09-24
• oss-sec: Bash environment variable command injection coordination — oss-sec, 2014-09-24
• GNU Project: Bash 4.3 patch 25 — GNU Project, 2014-09-24