In short: The PHP vulnerability explained simply: PHP is the software on the web server that assembles websites at the moment someone opens them. With PHP2Shell, in certain exceptional cases PHP does not clean up properly, and attackers can exploit exactly that to run their own commands on the server without a password. The remedy is a PHP update followed by a restart, which your hosting provider or service provider generally installs.
Why everyone is talking about PHP right now
The news spoke of a "critical security vulnerability", authorities took websites offline, and the BSI (German Federal Office for Information Security) warned at level orange. For many owners and employees, that sounds threatening and incomprehensible at the same time. What is PHP, and why does it affect your own company website of all things?
This article explains the situation without jargon. Anyone who wants to go deeper afterwards will find the technical assessment under What is PHP2Shell?.
What PHP actually does: an everyday picture
Imagine your website as a restaurant. The guest is the visitor, the order is the page request. PHP is the kitchen: it takes every order, fetches the ingredients from the storeroom, that is, the database, and plates up the dish, that is, the finished page.
To make things fast, the kitchen has several cooks who work through many orders one after another. Specialists call them "workers". After every order, the workstation is supposed to be completely tidied before the next one comes.
A great many well-known systems run on PHP: WordPress, Shopware, TYPO3, Joomla, Nextcloud and countless custom developments. How PHP works in principle is explained in the article What is PHP?.
The PHP vulnerability explained simply: what goes wrong with PHP2Shell
PHP2Shell consists of two flaws. Both have to do with tidying up, and both occur only in exceptional situations.
The first flaw (CVE-2026-109618): Sometimes the kitchen runs out of space in the middle of preparation. Specialists say "out of memory": the memory is full. The work is then aborted while the order is only half prepared. During the subsequent tidying up, PHP mistakenly treats unfinished things as finished.
The second flaw (CVE-2026-109619): After an order, something stays on the workstation that should already have been cleared away. The next order handled by the same cook can access it before it is removed.
In both cases the same applies: anyone who knows exactly how to bring about this exceptional situation can get the kitchen to do things that were never ordered. In the worst case, they take control of the server. They do not need a password for this. How a request is processed in PHP step by step is described in the article on the request lifecycle.
You do not have to understand the technology to act correctly. One single question to your hosting provider or service provider is what matters: Has PHP on our server been updated and restarted, and can you confirm that in writing?
The most important terms at a glance
| Term | Explained simply |
|---|---|
| PHP | software on the server that assembles web pages when they are opened |
| Security vulnerability | a flaw that strangers can exploit |
| CVE number | globally unique identification number of a security vulnerability |
| CVSS 9.2 | severity on a scale up to 10; 9.2 counts as critical |
| Remote code execution | strangers can run their own commands on the server remotely |
| Shell | command line with which a server can be controlled |
| Patch | update that fixes the flaw |
| Backport | fix built into an older version without changing the version number |
| Restart | ending the old PHP processes so that the corrected version actually does the work |
Why update, restart and check belong together
Let us stay with the restaurant. The update is a new working instruction for the kitchen: this is how to tidy up from now on. But the cooks who are on shift right now carry on working to the old instruction. Only when the shift changes does the new one apply. That is exactly what the restart is: all old PHP processes are ended, and new ones start with the corrected version. Without a restart, the update is on the server but has no effect.
And the picture shows something else. A new working instruction prevents future mishaps but says nothing about whether, in the days before, someone was in the kitchen unnoticed and hid something. That is why a check for traces belongs after the update, especially if the server was reachable between 17 October and the update.
What you should do now: three typical starting situations
What to do depends on where your website is hosted.
- Your website is with a hosting provider (shared hosting). The hosting provider generally installs the PHP update. Your task: obtain a written confirmation and check in the customer menu whether a current PHP version is set. What else is your task is explained under Shared hosting: what the host does and what you have to do.
- An agency or an IT service provider looks after your website. Ask them whether the update has been installed and PHP restarted, and ask for a brief check for anomalies.
- You have your own server. Then you or your IT are responsible: update PHP, restart all PHP processes, preserve logs from 20 October onward and check for traces.
In all three cases the following applies: an update of WordPress or another system on the website does not close the vulnerability. And an update does not prove that nothing happened beforehand.
How does PHP SOS help?
- Explaining clearly: We tell you in plain words whether and how your systems are affected.
- Talking to the hosting provider: On request, we clarify the patch level directly with your hosting provider or service provider.
- Updating and checking: On your own servers, we install the update, restart PHP and check for traces.
- Putting it in writing: You receive a short documentation of the status.
More under PHP2Shell immediate help.
Conclusion
PHP2Shell sounds complicated; the situation at its core is not: the kitchen of your website does not tidy up properly in exceptional cases, and that can be exploited. The update fixes that. Your task is to make sure it is installed, activated and documented, and, if in doubt, to have someone check whether anyone was in the kitchen beforehand.
Frequently asked questions
What is PHP in simple terms?
PHP is a programming language that works on the web server. When you open a page, PHP assembles it at that moment, for example with current products, prices or your shopping cart, and sends it to your browser.
Is my website affected if I use WordPress?
WordPress runs on PHP, so the server underneath may be affected. Whether your website is at risk depends on the PHP status on the server, not on the WordPress version. Ask your hosting provider or service provider about the PHP update.
Can I be at risk as a visitor to a website?
The vulnerability affects servers, not visitors' computers. If a server is taken over, however, attackers could, for example, change content or redirect visitors to other sites. That is why the update matters for operators.
What does the name PHP2Shell mean?
It describes the possible consequence: via PHP, an attacker can in the worst case get a shell, that is, a kind of remote control for the server. The official designations are CVE-2026-109618 and CVE-2026-109619.