Shellshock Explained: The Bash Bug That Hid in Plain Sight for 25 Years

What Happened

Bash lets you define shell functions and store them in environment variables so child processes can reuse them. The bug was in how Bash parsed those variables: if a variable's value looked like a function definition followed by extra commands, Bash would run the extra commands too — even though it was only supposed to store the function.

This became dangerous because many web servers pass user input (like HTTP headers) into environment variables before handing them to Bash, for example through CGI scripts. An attacker could put a malicious "function" in a header like User-Agent, and the server would execute it.

What This Means

Like EternalBlue and Log4Shell, this was a remote code execution bug — but what made it unusual was its age. The flawed parsing logic had shipped in Bash since 1989, sitting unnoticed in essentially every Unix-like system on the planet for 25 years before anyone caught it.

Why You Should Care

Shellshock is a reminder that "old and widely used" doesn't mean "well audited." Foundational software that everyone assumes is solid can carry bugs for decades simply because it works fine in normal use and nobody goes looking. It also showed how dangerous it is to let untrusted network input flow into a shell environment without sanitization.

What You Can Do

• Patch Bash and keep base OS images updated — this fix shipped to every major distribution within days, but only helps if you actually apply it.
• Avoid passing untrusted input (headers, form fields) into shell environment variables or shell commands at all; use safer APIs that don't invoke a shell.
• Run web-facing services with the least privilege necessary, so a successful exploit has limited blast radius.
• Treat foundational, "boring" infrastructure software as part of your attack surface — track its CVEs the same way you'd track a web framework's.