A webshell is one small file that turns your web server into an attacker's remote control, and fixing the original weakness doesn't remove it. Here's why ageing PHP websites make webshells easy to plant and hard to find, and what that means for your business.
Most talk about website security focuses on how attackers get in. Far less attention goes to what they do next, which is often where the lasting damage is done.
In many break-ins, one of the first things an attacker does is leave a webshell: a small file on your web server that lets them come back whenever they like. To your server, it looks like any other page of your website. To the attacker, it is a remote control. Fixing the plugin that let them in does not remove it. Changing your admin password does not remove it. It stays until someone finds it and deletes it.
Webshells aren't unique to PHP, but ageing PHP websites, and the way they are often hosted, make them unusually easy to plant and unusually easy to miss.
A small file that gives attackers a permanent way back in
Imagine a burglar who quietly cuts a spare key on the way out. You fix the broken window, but the key still works. A webshell is that key.
In November 2015, the US Cybersecurity and Infrastructure Security Agency (CISA) defined a webshell as "a script that can be uploaded to a web server to enable remote administration of the machine", and named PHP and ASP as the most common languages used. Among the usual ways in, it listed weaknesses in "WordPress or other CMS applications", poorly checked upload features and exposed admin pages.
On a typical older PHP website, any PHP file placed in a public folder will run as soon as someone visits its web address. There is no list of approved pages. So if an attacker can get one file into the right place, perhaps through an upload form that doesn't check what it is given, they can control the server on their very next request. Once an attacker finds any other way to run code, planting a webshell is usually one of their first steps, because it turns a one-off break-in into permanent access.
Webshells are also hard to find. In April 2020, the US National Security Agency (NSA) and the Australian Signals Directorate (ASD) described them as "a long-standing, pervasive threat that continues to evade many security tools". Attackers often hide their code inside a legitimate file, and the traffic looks like ordinary visits to your own website.
Microsoft's data shows how common they are. In February 2021, its security team reported "an average of 140,000 encounters of these threats on servers" every month from August 2020 to January 2021, "almost double the 77,000 monthly average" of the previous year.
What could go wrong for your business
A webshell gives an attacker ongoing access to your server. The realistic consequences include:
- Data theft over time. Customer records, orders and business documents the server can reach may be copied quietly, not just once but repeatedly.
- A route into the rest of your network. The NSA and ASD warn that attackers "frequently chain together web shells on multiple compromised systems to route traffic across networks, such as from internet-facing systems to internal networks". A webshell on your marketing website can become a way into everything else that server can reach.
- Repeat incidents. If a break-in is cleaned up without finding everything the attacker left behind, the NSA and ASD warn that "that access may be regained". Businesses can find themselves dealing with the same intruder again and again.
- Damage to trust and compliance concerns. A long-running, undetected compromise is harder to explain to customers and, depending on your sector, may carry reporting obligations.
None of this means your server has a webshell. But if one were there, you would want to know, and the nature of the threat is that it is designed not to be noticed.
Could your website be next?
Attackers don't usually handpick their victims. They use automated tools to scan large numbers of websites for known weaknesses, then plant webshells on whatever they manage to get into. Your site doesn't need to be large or well known to be caught up in this. It only needs to be reachable and running something with a known flaw.
Speed matters too. The NSA and ASD warn that attackers sometimes target web application weaknesses "within 24 hours of a patch release". After a critical flaw in Drupal 7 in October 2014, the Drupal security team told site owners to assume "every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC", just seven hours after the announcement. It added: "Simply updating to Drupal 7.32 will not remove backdoors." It advised sites that missed the window to restore from a backup taken before the attack.
That is the uncomfortable point about webshells. A website that has never had a visible incident may still have been compromised quietly, and a site that was fixed promptly may still carry something left behind. A clean history is not proof of a clean server.
Why legacy PHP applications deserve attention
Webshells aren't a flaw in modern PHP. A current PHP application, deployed with care, is no easier to backdoor than one built on any other technology. The problem is the way older PHP systems tend to be built and hosted:
- Folders the website can write to. Many older sites were set up with broad permissions so that plugins and uploads "just work". The NSA and ASD advise the opposite: "web applications should not have permission to write directly to a web accessible directory or modify web accessible code."
- Uploads stored alongside code. Older content management systems and hand-built admin panels often save uploaded files in places where PHP will still run them.
- No trusted copy to compare against. The NSA and ASD call comparing the live site with a verified clean copy "the best method of detecting these web shells". Systems that have been edited directly on the server for years have nothing to compare against.
- Long-unpatched entry points. According to php.net, PHP 7.4 has had no security support since 28 November 2022, yet as of 23 October 2026 W3Techs reports that 26.9% of websites using PHP still run PHP 7 and 7.7% run PHP 5. The longer a system runs on unsupported software, the more known ways in stay open.
To be fair, a webshell is possible on any technology, and CISA lists several other languages too. Modern platforms, including Node.js, typically don't run a file just because it lands in a public folder, which closes the easiest path but not every path.
What this means for your organisation
The questions that matter here are about visibility and confidence:
- Do we know exactly what files are on our web server, and would we notice if one changed?
- Is there a trusted, up-to-date copy of the website we could compare against or rebuild from?
- If we've had a security incident in the past, are we confident everything the attacker left was found?
- Is the software facing the internet still supported and receiving security fixes?
If those answers are uncertain, the application deserves a closer look. Not because a compromise is certain, but because you can't rule it out.
Understanding how your application is built, hosted and deployed is the starting point for any decision about its future.
Recommended next step
Don't wait until an intruder's return visit tells you something was missed. Our free Legacy PHP assessment looks at the areas that make webshells easy to plant and hard to find: your PHP version, your hosting setup, how files and uploads are handled, and how changes reach your live site. It is designed to give you a clear picture of potential security concerns, maintenance challenges and modernisation opportunities.
We'd then be glad to talk through what we find and the options in front of you. For some applications, the right step is to improve how the current system is hosted and deployed. For others, a move to the modern Node.js stack, which Sketchmonk builds on, may be the better path, depending on the application's requirements and your business goals. No platform makes a system immune, and good security habits matter on every stack. The aim is a system you can see into, trust and keep current.
Understand your risk before an incident forces you to.
Free Legacy PHP Risk Assessment
Worried something is already on your server? We'll review your PHP version, hosting setup, file permissions and deployment process, and tell you plainly where a webshell could hide and what your options are, from hardening what you have to a planned migration.
