Cybersecurity glossary

What is Shellshock (CVE-2014-6271)?

Learn what Shellshock (CVE-2014-6271) is, how Bash environment function parsing enabled remote code execution via CGI and SSH, which systems were hit, and how patching Bash closes the class.

Application securityUpdated August 11, 2026
Also known asShellshockCVE-2014-6271Bashdoor

Definition

Shellshock, primarily tracked as CVE-2014-6271 (with related follow-on CVEs), is a critical Bash vulnerability where specially crafted environment variables could still execute trailing commands after a function definition—allowing attackers to run arbitrary shell commands on systems that launched Bash with untrusted environment input, famously including CGI web servers.

Why Shellshock mattered

In September 2014, the Internet learned that GNU Bash—installed almost everywhere Unix-like systems exist—could be tricked into running extra commands through malformed environment variables. Shellshock (CVE-2014-6271) turned routine CGI headers into remote shell access on unpatched servers.

The vulnerability was conceptually simple, widely automated within hours, and present on appliances people never thought of as “running Bash web apps.” It became a template for later crises: a foundational interpreter bug with Internet-scale reach.

What CVE-2014-6271 actually is

Bash allowed environment variables to define shell functions. Vulnerable versions continued parsing and executing commands that appeared after the closing of a function definition in that environment string. Attackers who could influence environment variables therefore injected trailing payloads that Bash would run when started.

Vulnerable component

GNU Bash parsing of function-like environment variable values on affected releases.

Remote delivery path

CGI and other services that copy HTTP headers or network data into process environments.

Payload shape

A crafted variable that looks like a function definition followed by attacker shell commands.

Impact

Arbitrary command execution as the user running the Bash process—often the web server account.

Incomplete first patches led to additional CVEs. Real remediation meant updating through the full Bash advisory sequence, not assuming the first package bump was enough.

How Shellshock exploitation works

1

Find a Bash-launching service

CGI scripts, certain SSH configurations, or network services that spawn Bash with inherited environments.

2

Supply a crafted environment value

For CGI, malicious HTTP headers become environment variables automatically.

3

Bash parses the function export

Vulnerable Bash accepts the function definition form and continues into trailing attacker commands.

4

Commands execute on the host

Payloads download implants, modify web roots, join botnets, or pivot internally.

5

Automate Internet-wide scanning

Simple probes identified millions of potentially vulnerable endpoints within days of disclosure.

PropertyShellshockLog4ShellCommand injection
Primary CVECVE-2014-6271CVE-2021-44228Application-specific
Broken trust pointBash env function parsingLog4j JNDI lookupsUnsafe shell string building
Classic remote vectorCGI environment variablesLogged HTTP/user inputForm fields / APIs to shell
Fix focusPatch Bash; reduce CGIUpgrade Log4j; block JNDIAvoid shell; sanitize/parameterize
Still teaching today?Yes—interpreter edge casesYes—library features as RCEYes—everyday app flaw

Who was affected

Public CGI applications on Apache and other servers were the first mass targets. Embedded Linux devices, NAS appliances, and routers shipping old Bash builds followed. Enterprises discovered Shellshock on forgotten internal admin CGIs that were never meant to face scanners—but sometimes did.

SSH configurations using ForceCommand with Bash, mail filters, and DHCP client scripts also appeared in expert write-ups, reminding responders that “not a web server” was not a full exemption.

Mitigations

Patch Bash completely

Install vendor updates covering CVE-2014-6271 and follow-on parsing CVEs; verify version strings.

Shrink CGI attack surface

Retire Bash CGI, move to safer runtimes, and avoid mapping raw headers into shell environments.

Least privilege

Ensure web and automation accounts cannot write critical paths even if command execution occurs.

Network exposure control

Keep legacy admin CGIs off the public Internet; monitor for scanning patterns.

What practitioners should do today

  • Confirm Bash packages on servers, containers, and appliances include fixes for the Shellshock CVE family.
  • Inventory CGI and shell-based web entry points; prefer non-shell handlers.
  • Avoid passing untrusted HTTP data into environment variables consumed by shells.
  • Replace EOL embedded devices that cannot update Bash.
  • Review SSH ForceCommand and forced-command authorized_keys setups for Bash involvement.
  • Include shell interpreter versions in vulnerability management baselines alongside app libraries.
  • Detect post-exploitation patterns historically used after Shellshock (reverse shells, wget/curl implants).
  • Treat ‘ancient but internal’ CGI as high risk if reachable from broader enterprise networks.

Lessons Shellshock left for operations

Shellshock proved that language runtimes and shells are dependencies, not invisible OS wallpaper. It proved mass exploitation does not require sophisticated cryptography—only a reliable remote input path into a broken parser.

It also previewed modern SBOM thinking: knowing where Bash ships (including vendor firmware) matters as much as knowing your application frameworks.

The practical takeaway

Shellshock (CVE-2014-6271) let attackers execute commands by smuggling them into Bash environment function definitions—often through CGI headers. Patch Bash thoroughly, eliminate unsafe CGI shells, and assume any service that copies untrusted data into shell environments needs the same scrutiny you give application command injection.

Related security terms

Frequently asked questions

What is Shellshock in simple terms?

A bug in Bash meant that if an attacker could set certain environment variables, they could sneak extra shell commands that Bash would run. Web servers using CGI were a common way to set those variables remotely.

What is CVE-2014-6271?

CVE-2014-6271 is the original Shellshock vulnerability ID for GNU Bash’s flawed parsing of function definitions in environment variables. Additional CVEs covered incomplete fixes and related parsing issues.

Why were CGI apps so exposed?

CGI maps HTTP headers and request parameters into process environment variables. A vulnerable Bash CGI script therefore gave remote attackers a path to set the malicious environment and execute commands.

Did Shellshock affect only Linux web servers?

No. Any system launching vulnerable Bash with attacker-influenced environment variables was in scope—including some DHCP clients, SSH ForceCommand setups, and embedded devices—though CGI was the loudest Internet vector.

How do you test for Shellshock safely?

On systems you own, carefully crafted local environment tests can show whether trailing commands execute after a function definition. Never probe third-party systems without authorization.

How was Shellshock mitigated?

Patch Bash to versions that reject the unsafe parsing, reduce CGI exposure, avoid Bash for CGI where possible, and restrict which services pass untrusted data into shell environments.

Are related CVEs important?

Yes. Early patches were incomplete; CVE-2014-7169 and others required follow-up updates. Treat ‘we patched once in 2014’ as insufficient without verifying current Bash versions.

References

Explore authoritative guidance and frameworks related to shellshock (cve-2014-6271).

Explore every security definition

Return to the glossary to search by term, alias, starting letter, or security category.

Browse glossary