A decades-old Bash flaw called Shellshock reached the web via CGI

What happened

On 24 September 2014, the public disclosure of CVE-2014-6271 revealed that GNU Bash, the command shell installed on the overwhelming majority of Linux and Unix systems, processed environment variables in a way that let an attacker append and execute arbitrary shell commands. According to Red Hat's advisory, an attacker could use the flaw to override or bypass environment restrictions to execute shell commands, and it became remotely exploitable wherever a service, such as a CGI web script, passed untrusted network input into an environment variable later read by Bash. Because Bash had shipped with this behaviour for roughly two decades, the flaw, quickly named Shellshock, was present on an unusually broad range of systems: web servers, embedded devices and network appliances among them.

The CERT Coordination Center's vulnerability note records that the first patch, released the same day, did not fully close the flaw. Within days, researchers found the fix could still be bypassed, and four further CVE identifiers were assigned to variations on the same underlying parsing problem as vendors iterated toward a complete fix.

Confidence and limits

Both sources are technical advisories written to describe the vulnerability and coordinate a fix rather than to attribute or measure exploitation. Red Hat's advisory documents its own product's exposure and the general attack pattern; the CERT note lists which vendors reported themselves affected, based on vendor self-reporting rather than independent testing of every listed product. Neither source states how many systems worldwide were actually compromised, and this article does not estimate that figure.

Why it mattered

Shellshock demonstrated that a vulnerability's age is not protection: a parsing quirk that had existed in Bash since the early 1990s became critical only once web applications routinely fed untrusted, attacker-controlled data into environment variables that reached the shell. It also became a widely cited early example of how difficult it can be to patch shared, deeply embedded software completely; the sequence of follow-on CVEs showed that a first fix addressing the reported proof of concept can still leave the underlying design flaw exploitable in a slightly different form.

Defensive takeaway

Confirm that systems patched for CVE-2014-6271 also received the later fixes for the related CVEs, and, for any current advisory, treat a first patch as provisional until a vendor confirms the underlying issue, not just the reported proof of concept, is resolved.

• Do any of your systems still run a Bash version predating the full set of 2014 Shellshock-related patches?
• Does any of your infrastructure pass network-supplied input into environment variables that reach a shell interpreter?
• When you apply an emergency patch, do you track whether the vendor later issued a follow-up fix addressing the same root cause?

Shellshock is a reminder that a vulnerability's severity depends on where old code ends up being used, not only on when it was written, and that a patch released within hours of disclosure can still require several follow-up releases before the underlying flaw is fully closed.