The headlines this week mention “web shells” being dropped on hacked Cisco SD-WAN appliances. If that phrase keeps sliding past you, you’re not alone — security writers tend to use it without ever defining it. Worth knowing, because web shells are how an initial breach turns into an ongoing problem.

A web shell is a small malicious script — often just one file — an attacker plants on a server they’ve compromised. Once it’s there, they can come back any time and run commands by visiting a particular URL in their browser. Think of it as a hidden side door fitted to the back of your shop. The vulnerability was how they got the door in. The web shell is the door they use after that, sometimes for months.

What makes them nasty is how quietly they sit. They look like legitimate website files (often a JSP, PHP, or ASP page named something boring like update.jsp), don’t generate much network noise, and survive reboots. Patching the original vulnerability closes the front door — but it leaves the web shell’s side door wide open.

In this week’s Cisco SD-WAN exploitation campaign, at least ten threat clusters dropped variants of XenShell, Godzilla, Behinder, and Sliver beacons after exploiting CVE-2026-20182. Patching is necessary; it isn’t enough.

The practical implication for your business: any time a server, firewall, or network appliance has been compromised, patching alone doesn’t make it safe. You have to assume something was left behind and go looking for it. That’s what an incident response check is for — not paranoia, just how modern attacks actually work.