GNU Bash through 4

CVE-2014-6271 is the original Shellshock bug: GNU Bash imports function definitions from environment variables and, in vulnerable builds, keeps parsing attacker-controlled text that follows the function body. In plain English, if some exposed service copies untrusted input into an environment variable and then launches Bash, the attacker can turn that hop into command execution. The vulnerable range is Bash through 4.3, but the first fix was incomplete, so truly safe builds are the vendor backports or later patch levels that also address CVE-2014-7169 and the follow-on parser issues.

The vendor's 9.8/CRITICAL score is technically fair for the exposed subset, but it overstates enterprise-wide reachability. Bash is not a network service. The exploit chain usually needs a second product or feature in front of it: CGI on Apache, forced-command SSH workflows, DHCP hooks, embedded web admin panels, or another component that bridges attacker input into Bash. That dependency is the main friction. Still, KEV status, trivial exploitation, and a long tail of forgotten appliances keep this firmly out of the backlog.

Why this verdict

• Downgrade for reachability: the attacker position is often *unauthenticated remote*, but only if a separate service like CGI, SSH forced-command, or appliance glue code passes input into Bash. That sharply reduces the fraction of real enterprise hosts that are actually one packet away from RCE.
• Not every Bash install is exposed: a workstation, internal server, or container image with Bash installed is not the same thing as an internet-exploitable target. The vendor CVSS treats the reachable case, while defenders need to prioritize the exposed subset.
• KEV and real-world exploitation push it back up: the exploit is trivial, public, and historically wormable, with active exploitation evidence and CISA KEV status. That means any externally reachable legacy path is still an easy win for attackers.
• Blast radius is workload-dependent: successful exploitation usually lands as the calling service account first. High impact is common, but full environment compromise is not automatic and depends on local privilege, secrets, and lateral movement opportunities.

Why not higher?

This is not higher because the vulnerable component is usually indirect. The attack chain commonly requires legacy CGI or another trust-boundary bridge, and many modern enterprise stacks never expose that bridge externally. A CVSS 9.8 makes sense for the subset that is reachable, but not for every Linux asset with Bash installed.

Why not lower?

This is not lower because the exploit is cheap, famous, KEV-listed, and still useful against neglected internet-facing assets. One forgotten appliance, old CGI app, or embedded admin page can turn this into immediate command execution with very little attacker effort.

1. Block exposed CGI and legacy admin paths — Put reverse-proxy, WAF, ACL, or firewall controls in front of known cgi-bin paths and embedded web interfaces immediately, within hours because this CVE is KEV-listed. This directly removes the most common remote trust boundary into Bash while patching catches up.
2. Hunt for Bash as a child of network services — Use EDR or audit telemetry to alert on bash, sh, curl, wget, perl, or python spawned by httpd, apache2, nginx helpers, lighttpd, sshd, or appliance web daemons. Deploy within hours for exposed systems, then keep it in place through the HIGH remediation window.
3. Segment and restrict egress from internet-facing Linux and appliances — Limit outbound package fetches and lateral movement from web tiers and network appliances so a successful Shellshock hit cannot immediately pull second-stage payloads or pivot. Apply to exposed assets within hours because active exploitation evidence overrides the normal mitigation timetable.
4. Inventory Bash behind services, not just packages — Prioritize systems where Bash is actually invoked by web, SSH, DHCP, or management workflows; package presence alone will drown you in false urgency. Build that inventory in the first pass and complete it well inside the HIGH remediation window.

Run this on the target host itself as a local check. Invoke it with bash ./check-shellshock.sh; no root is required, but you need permission to execute the local bash binary. The script performs behavioral tests for the original Shellshock parser bug and the immediate incomplete-fix follow-up, then prints VULNERABLE, PATCHED, or UNKNOWN.

#!/usr/bin/env bash
# check-shellshock.sh
# Behavioral verifier for CVE-2014-6271 and the immediate incomplete-fix follow-up (CVE-2014-7169).
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

if ! command -v bash >/dev/null 2>&1; then
  echo "UNKNOWN: bash not found"
  exit 2
fi

TMPDIR_LOCAL="${TMPDIR:-/tmp}"
probe_file="${TMPDIR_LOCAL%/}/shellshock_test_$$"
rm -f "$probe_file"

# Test for CVE-2014-6271: vulnerable systems print the injected marker before 'safe'.
out1="$({ env 'x=() { :;}; echo VULN6271' bash -c 'echo safe'; } 2>&1)"

# Test for the incomplete initial fix / CVE-2014-7169 behavior.
out2="$({ env 'x=() { (a)=>\\' bash -c 'echo date' ; } 2>&1)"
file_created=0
if [ -e echo ]; then
  file_created=1
  rm -f echo
fi

vuln=0
unknown=0

if printf '%s\n' "$out1" | grep -q '^VULN6271$'; then
  vuln=1
fi

if [ "$file_created" -eq 1 ]; then
  vuln=1
fi

# Sanity guard: if bash invocation failed unexpectedly, mark unknown unless already vulnerable.
if ! printf '%s\n' "$out1" | grep -q 'safe'; then
  unknown=1
fi

if [ "$vuln" -eq 1 ]; then
  echo "VULNERABLE"
  exit 1
fi

if [ "$unknown" -eq 1 ]; then
  echo "UNKNOWN"
  exit 2
fi

echo "PATCHED"
exit 0

Sources

1. NVD CVE-2014-6271
2. Red Hat Shellshock advisory
3. Ubuntu CVE-2014-6271 status
4. Debian security tracker CVE-2014-6271
5. CISA Known Exploited Vulnerabilities Catalog (print)
6. CERT alert TA14-268A mirror
7. Nmap http-shellshock NSE documentation
8. Cisco Talos: Shellshock exploits in the wild