TL;DR
Shellshock lets an attacker run commands on a machine by stuffing them into an environment variable that an old Bash reads. It was patched in 2014. It still answers on appliances, container images and hosting stacks that were built once and never rebuilt. The fix is inventory, patch, rebuild, and a check you can rerun.
What the bug actually does
Bash stores functions in environment variables. Before the patch, a value could carry a trailing command and Bash would run it at startup. Any path where an attacker controls an environment variable becomes remote command execution. Common routes are CGI scripts on shared hosting, mail filters, DHCP clients, and anywhere a request header reaches a shell.
Nothing about it is clever. There is no exploit chain and no privileged position needed. One crafted request to an exposed CGI endpoint is enough.
Where it still shows up
- Network appliances and storage boxes that run a Linux image from before 2015 and have never had firmware replaced
- Container images pinned to an old base layer, rebuilt from a Dockerfile that nobody reads any more
- Shared hosting accounts where CGI is still enabled for a legacy form or script
- Backup and monitoring agents installed once and forgotten
- Old virtual machines kept alive for one line of business application
How a cleanup actually runs
First we inventory every host and image that can execute a shell, because the answer is rarely one server. Then we test Bash on each of them, not the operating system version, since a patched OS can still carry an old shell in a container.
Where a host cannot be patched, it gets isolated from the internet and replaced on a schedule. Where an image cannot be rebuilt, it is retired. Then we check the logs for the pattern that indicates someone already tried, and we rotate every credential that lived on the affected host.
What we recommend, in order
Run an inventory of every host, appliance and image that can execute Bash. Test the shell itself on each one. Patch or isolate what fails. Rebuild images from a current base rather than patching inside a running container. Add a monthly check that repeats the same test, so the next one is caught by routine rather than by an incident.
If you have never done that inventory, the useful first step is a security review of what is actually exposed, not a scan report you cannot action.