CVE-2014-6271 — Shellshock

Bash supported exporting functions through environment variables. The export syntax — () { …; } — was parsed by any newly-spawned bash process on import. A trailing semicolon let the imported “function” body include arbitrary commands. Any process boundary that turned untrusted input into a bash environment variable became RCE. The classic target was mod_cgi: HTTP headers became env vars; bash was the CGI interpreter; game over. The first patch was incomplete; the durable fix runs through six follow-up CVEs.

Affected versions

  • Bash 1.14 through 4.3 (with various patch levels) — vulnerable.
  • The fix shipped in patch levels: bash-3.2.53, bash-4.1.14, bash-4.2.50, bash-4.3.27, plus follow-up patches for the five sibling CVEs.
  • Modern Bash (5.x) — clean.

Indicator-of-exposure

Detection is simple but the surface is wide:

# The classic detection one-liner (CVE-2014-6271):
env x='() { :; }; echo VULNERABLE' bash -c 'true'

# The follow-up (CVE-2014-7169):
env X='() { (a)=>\\' bash -c 'echo date'; cat echo

If the first prints VULNERABLE or the second produces a file named echo containing the date, the bash on this host has not been fully patched.

The exposure that matters is any process boundary that maps untrusted input into a Bash environment:

  • Apache mod_cgi / mod_cgid invoking a #!/bin/bash CGI script.
  • DHCP clients that pass server-supplied options into a Bash hook script.
  • Forced-command SSH configs that run a Bash wrapper.
  • Setuid wrappers that drop into Bash.
  • Container entrypoints that re-exec Bash with attacker- controlled env.

Remediation strategy

  • Upgrade Bash to a current 5.x release, or to the patch level that includes the fix for all of the Shellshock-family CVEs (-6271, -7169, -6277, -6278, -7186, -7187). Do not stop at the first one.
  • Audit every CGI / DHCP-hook / setuid wrapper / SSH forced-command surface for use of Bash. Replace #!/bin/bash with #!/bin/dash (or /bin/sh if Debian-family) where the script doesn’t need Bash features.
  • Disable mod_cgi and mod_cgid in any web server that doesn’t need them.
  • Re-audit the system as a whole. Shellshock exposure on a host today implies a multi-year patching gap; the incident response is broader than one CVE.

When to use it

Use this recipe when a host, container image, appliance, embedded Linux image, CGI stack, DHCP client hook, SSH forced-command wrapper, or shell-based entrypoint may run vulnerable Bash or process untrusted environment variables. It is especially important when the system is old enough that Shellshock still appears in SCA, image, or host scans.

Use it to separate Bash patching from exposed-surface review and incident response. Do not use it as a one-line package bump when CGI, DHCP, SSH hooks, or container entrypoints can map untrusted input into Bash.

Inputs

  • Host inventories, container images, SBOMs, base-image manifests, package locks, distro advisories, Bash versions, CGI configs, Apache modules, DHCP hook directories, NetworkManager dispatchers, SSH authorized-key commands, setuid wrappers, and Docker entrypoints.
  • Detection evidence for CVE-2014-6271, CVE-2014-7169, CVE-2014-6277, CVE-2014-6278, CVE-2014-7186, and CVE-2014-7187.
  • Exposure evidence: public CGI routes, DHCP trust boundary, SSH wrapper use, setuid scripts, container env sources, web/DHCP/auth logs, affected package timing, and whether the distro is supported.
  • Script compatibility evidence before replacing Bash shebangs: Bashisms, tests, runtime owners, migration complexity, and dependency on mod_cgi.
  • Operator actions for credential rotation, log review, runtime upgrade, and broader patch-gap remediation.

The prompt

You are remediating Shellshock and its sibling CVEs on this
host or system image. Output exactly one of:

- A PR / change request upgrading bash and tightening the
  exposed CGI / DHCP / SSH-hook surface, plus an IR
  checklist for the operator.
- A TRIAGE.md if the host's patching gap is broader than
  this CVE family.

## Step 0 — Detect

1. Read bash version: `bash --version`.
2. Run all six Shellshock detection one-liners (or pull a
   detection script from a trusted source). Confirm none
   print the canary string.
3. Identify Bash-using boundaries:
   - `find / -name '*.cgi' -exec head -1 {} \\; | grep bash`
   - DHCP hook scripts under `/etc/dhcp` /
     `/etc/NetworkManager/dispatcher.d`.
   - SSH `authorized_keys` `command=` forced commands.
   - Container entrypoints that re-exec Bash.

## Step 1 — Upgrade Bash

1. `apt upgrade bash` / `dnf upgrade bash` to the
   distro's current packaged version.
2. Re-run all six detection one-liners. None should fire.

## Step 2 — Tighten exposed surfaces

For every Bash-using boundary identified in Step 0:

- **CGI scripts:** if the script doesn't need Bash features
  (associative arrays, `[[`-tests, process substitution),
  switch the shebang to `/bin/dash` or `/bin/sh`. If it
  does need Bash, keep Bash but document the exposure.
- **`mod_cgi` / `mod_cgid`:** disable in `httpd.conf` /
  `apache2.conf` if the application can serve via FastCGI,
  PHP-FPM, or a modern WSGI / ASGI stack instead.
- **DHCP hooks:** review for shell injection on
  server-controlled fields. The agent doesn't auto-rewrite
  these — flag for triage.
- **SSH forced commands:** audit the wrapper script;
  prefer a non-shell binary or a tightly-controlled allowlist.

## Step 3 — IR checklist (when patching gap is broader)

The TRIAGE.md must include:

- Confirm host distro is supported and currently patched.
- Rotate any credentials that ran through the exposed
  surface (CGI auth tokens, DHCP-distributed secrets).
- Audit web logs and DHCP logs for known Shellshock
  exploitation patterns: `User-Agent: () { :; };`,
  `Referer: () { :; };`, etc.
- Schedule a comprehensive runtime upgrade.

## Stop conditions

- Distro is end-of-life and no patched bash is available.
  Triage with a recommendation to migrate.
- A CGI script genuinely depends on Bash and the migration
  to FastCGI/WSGI is non-trivial. Flag and triage.
- The host's auth log shows unexplained sessions during the
  exposure window — this is incident response, not
  routine remediation.

## Scope

- Do not rewrite CGI scripts beyond the shebang change.
- Do not disable `mod_cgi` if a legitimate application
  depends on it; flag for triage instead.
- Do not bundle unrelated CVE fixes.

Verification — what the reviewer looks for

  • All six Shellshock-family detection one-liners pass after the upgrade.
  • The Bash-using boundary list in the PR body is complete and accurate (re-grep to confirm).
  • For surfaces where Bash was replaced with dash / sh, the script’s tests still pass — Bashisms ([[, ==, array syntax) are the common breakers.
  • The reviewer does not assume the absence of mod_cgi is the same as the absence of all Bash-CGI surfaces.

Watch for

  • Single-CVE patching. Many vendor advisories shipped a fix for -6271 days before -7169. A host patched against only the first is still exploitable. Test all six.
  • Bash on Alpine. Alpine’s default shell is ash, but containers that explicitly install bash inherit the same exposure. Audit Dockerfiles.
  • Container entrypoints. A CMD ["/bin/bash"] with attacker-controlled env (e.g., from an upstream input) re-creates the same surface inside a container. The generic remediation is to replace the entrypoint with a non-shell binary.
  • OS images that aren’t actively patched. Shellshock exposure on a host in 2026 is a tip-of-the-iceberg signal. The recipe says so; don’t treat the bash bump as the end of the conversation.
  • Proxies and load-balancers. Some appliances embed older Bash. The same shape applies; the fix path is the appliance vendor’s, not the host’s.

Output contract

Return one of:

  • A reviewer-ready PR/change request that upgrades Bash through all Shellshock sibling fixes, inventories Bash-using exposure boundaries, safely replaces Bash with a smaller shell where tests prove compatibility, disables unused CGI modules where owned, and attaches operator IR actions.
  • TRIAGE.md when the distro is end-of-life, the host has broader patching gaps, a Bash-dependent CGI migration is non-trivial, logs indicate possible compromise, or exposed-surface ownership is outside the repository.

The output must list Bash version, six-CVE detection results, exposed boundaries reviewed, shebang or module changes, tests run, log-review queries, credentials or surfaces requiring rotation, and runtime-upgrade owner. It must not rewrite CGI scripts beyond scoped shebang/module changes, disable required CGI functionality, or bundle unrelated CVEs.

References