PHP2Shell explained plainly: what the PHP security flaw means in everyday life

This English version is an automatically translated version of the German original.

On 23 October, a serious security vulnerability in PHP was published. PHP is software that many systems on the internet run on - WordPress, many online shops, booking systems, club websites. The flaw is called PHP2Shell and was rated 9.2 out of 10 on the severity scale - a score reserved for what is truly serious.

What the flaw can do

Simply put: attackers can run arbitrary commands on a vulnerable server - without a password, without anyone having to click a link. They only need to address the PHP instance in a targeted way, like a normal visitor. Security researchers have demonstrated that unmodified standard installations of WordPress, Drupal and Joomla and many other solutions are affected.

When you visit a web page, servers process requests in short work steps. The flaw lets an attacker derail these steps so that the server then does what the attacker wants - including reading other visitors' data, such as credentials being transmitted or data stored on the server.

What this means for small businesses

Take a typical example: a craft business with a WordPress website and a contact form.

• Customer data lies exposed. Names, addresses, inquiries, orders - everything the website stores is reachable. That quickly becomes a GDPR problem: data breaches are subject to mandatory reporting, and "we didn't know" is no defense when the patch has been available for weeks.
• The website works for the attacker. Taken-over sites are used to infect visitors with malware or to run phishing pages under the company's own name. The reputational damage hits the business, not the attacker.
• One open hole is enough. Our services run in Docker containers - self-contained program environments that share the same server but not the same environment. On the affected system there were about seventy-five containers, but only eight of them contained PHP. At first glance that may seem harmless, but it isn't: containers on the same network can "see" each other. Whoever breaks into a vulnerable container is already in the hallway - and typically finds credentials for databases and other services there. An inconspicuous side project can thus become the entry point into the customer database.
• The protective technology is affected too. The same flaw sits in network devices such as routers, firewalls and NAS systems - wherever an admin interface or login page is powered by PHP. A concrete example is the pfSense firewall: its web interface runs on PHP, and its "Captive Portal" - the sign-in page known from Wi-Fi portals in hotels or company guest networks - is deliberately reachable for strangers. A tool whose only real purpose is to keep strangers out thus becomes the entry point for attackers.
• The analysis isn't simple either: The version number can be deceptive. Someone who has "PHP 8.3.6" installed is not automatically vulnerable - Linux distributions sometimes retrofit security patches into older versions. And the reverse applies as well: updating once isn't enough for good; the programs around it (containers, apps) must be at a secure state too.

What we did at WIT

We checked our systems the same day: one program (Piler, our mail archive) got a specially provided corrected version because no fix was yet available in the official release. Other projects were faster: Firefly III, for example, was already fixed by its developers and only needed updating and restarting. Two less important services we shut down for now rather than leave them running vulnerable, and we are still evaluating whether we keep using them or switch to alternative solutions. Repairing them manually isn't worth it here.

Planning has to be pragmatic: it isn't worth trying to patch every program yourself. What matters is choosing software from vendors who react quickly in such situations - because that way the vendor also takes on future responsibility for timely fixes, and you stay protected long-term. In addition, servers should be set up so that a successful attack on one component doesn't automatically endanger other systems. Geoblocking, which we implement on our servers with CrowdSec, can likewise limit the attack vector: many probing requests come from countries for which access to our customers' websites and platforms isn't necessary anyway. With geoblocking, attackers from Russia or India are locked out before they can even check whether security holes exist.

What website operators should do now

1. Ask your hoster whether PHP has been updated - with managed hosting that's their job, but asking never hurts.
2. Actually restart services after updates - a "reload" isn't enough; running processes keep the old, vulnerable state.
3. Switch off services that aren't needed - what isn't running can't be attacked.
4. Treat guest Wi-Fi and admin interfaces separately - a Wi-Fi portal for customers is deliberately open and deserves special attention.

The detailed technical documentation was published by our Trurl (specialist AI), with research sources, in the post "PHP2Shell, or: the day the floor turned out to be the bug".

Manfred Wisniewski, owner of WIT. The technical original of this post was researched with the support of the AI models SWE-2, GPT-6 Astra and Claude Fable 5.1, and transferred and simplified from the technical original into German with the help of AI.