Remote code executionCVE-2014-62712014 6 min read

What was Shellshock?

Bash had a quirk: it would run code tucked inside an environment variable. Web servers passed attacker-controlled headers into environment variables. So a single HTTP request could run commands on the server.

25 years
the quirk sat in bash unnoticed
1 header
was enough to run a command
0
authentication required
Millions
of CGI-based servers exposed

What happened

In September 2014 researchers disclosed Shellshock, a flaw in bash, the shell running on most Unix and Linux systems. Bash would treat specially crafted environment variables as code and run it.

On its own that sounds niche. The problem was how often web servers handed attacker-controlled data to bash through environment variables, which turned a shell quirk into remote code execution across the internet.

How a header became a command

Older web setups using CGI copied incoming request headers into environment variables before calling a script. If that script touched bash, the crafted header got parsed, and the code after it ran.

So an attacker put their command in a header like User-Agent and sent a normal-looking request. The server ran the command without anyone logging in.

The command rides inside an ordinary request header
User-Agent: () { :;}; /bin/bash -c 'id > /tmp/owned'

// the server copies the header into an env var,
// bash parses the trailing code and runs it.

Why it was everywhere

Bash is on almost everything, and the vulnerable pattern lived in a lot of glue code nobody thought about. There was no single product to blame, just a default that turned out to be dangerous.

Mass scanning began within a day. The fix was simple once you knew, but knowing which of your systems used the vulnerable path was the hard part.

How it unfolded

  1. 1989
    The function-parsing behavior enters bash and stays for decades.
  2. Sep 24, 2014
    Shellshock is disclosed. Patches and mass scanning arrive within days.
  3. Late Sep 2014
    Follow-up flaws and bypasses keep teams patching bash repeatedly.
Where buggy.run fits

Command injection shows up when input reaches a shell, and the only way to know is to send the inputs and watch what the server does.

buggy.run probes the inputs your app exposes, including headers, and reads the responses for signs that your server is doing something an attacker asked it to.

What to take away

  • Keep base images and shells patched. This class of bug lives in your platform, not your code.
  • Never pass untrusted input into a shell. Use safe APIs instead of shelling out.
  • Retire CGI and other patterns that hand request data straight to the system.
  • Layer defenses so one parsing quirk is not the whole game.

Find your unnoticed bug before someone else does.

buggy.run signs in, captures your real traffic, and hunts the quiet flaws that scanners miss. You get every finding in plain English with the fix.