Shellshock: The 2014 Bash Bug That Hid in Plain Sight for Decades

On 24 September 2014, a vulnerability in Bash, the command shell used on most Linux and macOS systems, was made public. Nicknamed Shellshock, it allowed remote attackers to run commands on vulnerable servers, and within hours of disclosure, attackers were scanning the internet for targets. The flaw had existed in the software for many years without being noticed.

What Bash is, and why a bug in it matters

Bash is a command interpreter. Whenever you type commands in a terminal on a Linux server, Bash is typically reading them. It is also used behind the scenes: scripts, scheduled tasks and various server programs call it to do jobs. That wide use is why one bug in Bash could reach so many systems.

How the flaw worked

Bash allows functions to be defined and passed to child processes through environment variables, which are named values that programs can hand to each other. The bug, assigned CVE-2014-6271, meant that Bash did not stop reading at the end of the function definition. If extra commands were placed after it, Bash executed them as soon as it started.

The question was then how an attacker could get a malicious value into an environment variable. On web servers, that turned out to be easy in some configurations. The Common Gateway Interface, or CGI, passes details of a web request, such as the user agent string, to scripts through environment variables. If a CGI script was written in Bash, or called Bash, a visitor could send a crafted header and have the server run their commands.

Discovery and the patch scramble

The bug was found by Stéphane Chazelas, a Unix and Linux specialist, who reported it to the maintainers. The flaw is believed to have been in Bash for around 25 years. A first fix was released along with the disclosure, but it turned out to be incomplete, and additional vulnerabilities in the same area were reported in the following days, with further patches. This meant that administrators had to update more than once.

Attackers moved quickly. Researchers saw scanning and exploitation within hours of the announcement, and botnets used the flaw to recruit more machines.

Who was exposed

• Web servers using CGI scripts that called Bash.
• Some DHCP clients, which could be fed values by a malicious network.
• Certain embedded devices and network appliances that used Bash internally.
• SSH configurations that allowed restricted commands to be bypassed.

Whether a particular website was exposed depended on the details of its setup, which is a good reason for owners to ask their provider rather than assume.

What it showed about software

Like Heartbleed earlier in 2014, Shellshock reminded the industry that a tiny piece of widely used code can sit unexamined for decades. It also showed that old technologies such as CGI remain in use on production servers long after their best days. Removing what you no longer need is a security measure in itself.

How to check what your server is running

One lesson from the Shellshock weeks was that many administrators did not know what their servers had installed or which scripts were reachable from the web. A basic inventory solves most of this problem:

• List the operating system version and the packages that are installed, and check that automatic security updates are enabled.
• Look for CGI or script directories on the web server and ask whether each script is still needed.
• Subscribe to your operating system's security announcements, so that you hear about flaws on the day they are published.
• After applying a patch, confirm that the package version actually changed and that services were restarted.

Shellshock also demonstrated the value of defence in depth. Sites that had a web application firewall, that ran services with limited permissions and that kept good logs found it far easier to cope than those relying only on the hope that nobody would try.

Why patching twice was normal

Many administrators were frustrated that a single update did not close the problem. This is common with deep bugs: the first fix addresses the reported case, while researchers who now know where to look find related flaws nearby. The right response is not to stop patching but to treat the first week after such a disclosure as a period when you check for updates daily and re-test.

The practical lesson for site owners

Choose a host that patches the operating system quickly, and if you manage your own server, apply updates as soon as they are available and check afterwards that they took effect. Remove legacy scripts and unused features. Put a filtering layer in front of your site where you can, since it can block known attack patterns while a patch is being rolled out.

On our VPS plans you have full control, so keeping packages updated is your responsibility. If you would rather not manage it yourself, our shared hosting leaves the server layer to us. See our security page for more.