PHP2Shell: is my website affected by the PHP vulnerability?
Two critical vulnerabilities in PHP threaten millions of websites, and updating WordPress does not help. Who is affected, why a patch alone is not enough and how I check your website.
On 21 October 2026 the PHP project closed two critical security vulnerabilities known as PHP2Shell. They let attackers run their own code on web servers without logging in. PHP powers almost 70 per cent of all websites, including WordPress, Joomla and most online shops. Whether your site is affected does not depend on the CMS, but on where it runs and on which PHP version.
Sources: PHP security advisories (CVSS 4.0), W3Techs, Qualys Threat Research, as of October 2026.
What is PHP2Shell?
PHP is the programming language the web server uses to assemble a page before it reaches the browser. Both vulnerabilities lie in the way PHP handles incoming requests and cleans up afterwards. A crafted request, such as a manipulated form upload, can make PHP use memory incorrectly. In the end the server runs code the attacker sent along. No login is needed. Researchers also showed that attackers can read contents of the server’s memory, including passwords and access keys.
The details became public on 20 October, ahead of the planned date, and the updates followed on 21 October at around 4 pm German time. Amazon saw the first attack attempts as early as 17 October, and Cloudflare counted millions of attempts. Many public authorities, universities and hospitals in Germany took their websites offline as a precaution, among them Charité and parts of berlin.de and mainz.de. Anyone who has not patched should assume that automated attacks found their site long ago.
Is my website affected by the PHP vulnerability?
In principle the PHP vulnerability affects every website that runs on PHP. Who has to act depends on how the site is run:
The hosting provider updates PHP on its servers. Hetzner did this for every version it offers in its web hosting by the morning of 22 October, and IONOS and All-Inkl also report it done. You should still check which PHP version is set for your site and whether it was attacked before the update.
Nobody but you is responsible here, even if the server is hosted at Hetzner, IONOS or Strato. You have to install the update and then fully restart PHP. If an old PHP process keeps running, the hole stays open.
PHP 8.1 and older no longer get ready-made updates from the PHP project. Whether your version is protected depends on whether your hosting provider or distribution has backported a fix. The version number does not tell you. In the long run only moving to a supported version helps.
An agency built the site, the domain is registered somewhere, and nobody has looked at it for years. This is the most common case and the most dangerous one, because nobody feels responsible.
Why updating WordPress is not enough
WordPress, Joomla, TYPO3 or a shop system run on PHP, just as a program runs on an operating system. The vulnerability sits one level below. Updating the CMS or its plugins is still worthwhile, but it changes nothing about PHP2Shell. What matters is the PHP version on the server, and the hosting provider or whoever runs the server sets it, not the website itself.
Patched, so everything is fine?
Not necessarily. Between 17 and 22 October practically every PHP site was exposed, and the attacks were automated. Whoever got in during that time often left a small back door, a so-called web shell. It survives the update and keeps working. The normal access logs are of little help, because they do not record the content of such requests.
Signs of a break-in are new or changed files in the website’s directory, unknown administrator accounts, new scheduled tasks on the server, or PHP processes starting programs that have no business there. Since 23 October a further session vulnerability has also been known, CVE-2026-115560, which the updates of 21 October do not close. It only affects special cases, but I check it as well.
What a neglected website can cause
I have seen it several times: through holes like these, malware got onto customer websites nobody was looking after any more. Often it then sends spam in bulk. The consequences reach far beyond the website: the domain ends up on international blocklists, and mail servers around the world stop accepting its messages.
If personal data falls into the wrong hands during a break-in, for example from a contact form or a shop, there may also be a duty to notify the data protection authority. Under Art. 33 GDPR the deadline is 72 hours after becoming aware of it.
How I check your website
I also check sites I did not build and whose hosting I do not know. All you need are the access details for the hosting or the server, where they exist.
- Inventory: Where is the site hosted, who runs the server, which PHP version is running, and is it protected against PHP2Shell?
- Securing: Where the update is missing, I install it or apply the PHP project’s interim measures until that is possible. On web hosting I switch to a supported PHP version.
- Looking for traces: I check files, administrator accounts and the server for signs of a break-in and remove whatever does not belong there.
- Result: You get a short assessment of what I found, what I have fixed and where further action is needed.
The patch alone does not settle it for good. PHP2Shell will not be the last vulnerability of this kind, and the next PHP vulnerability will come. Like any computer, a website needs regular updates and someone who keeps an eye on it. I take care of this website maintenance on an ongoing basis for a monthly flat fee if you wish.
Frequently asked questions
Am I at risk as a visitor to a website?
Not directly. The vulnerabilities are on the web servers, not on your computer or smartphone. Those at risk are website operators and the data stored on their sites.
How do I find out which PHP version my website uses?
On web hosting the provider’s control panel usually shows the version under the domain settings. In WordPress, “Tools → Site Health → Info” shows the PHP version. On your own server the version number alone is not enough, because Linux distributions often include fixes without changing it.
Do I have to take my website offline?
Not once the update is installed. If the site runs on your own server without the update, or on an old PHP version without a fix, the BSI advises switching it off temporarily if in doubt. That is unpleasant, but less bad than a break-in.
Sources
- Vulnerabilities, versions, interim measures: PHP – security advisory GHSA-w8hw-w9fx-j79w, PHP – security advisory GHSA-6wmf-4rv5-p3rp (as of October 2026)
- BSI warning: BSI – PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit (in German, version 1.2, 22 October 2026)
- BSI warning level, sites taken offline, attack attempts: heise online – php2shell: Updates trudeln ein, viele Webseiten offline, Angriffe laufen, ZDFheute – Sicherheitslücke bei PHP: Millionen Webseiten bedroht (in German, as of 22 October 2026)
- Prevalence, share of old versions: Qualys – PHP2Shell: Find, Mitigate, and Patch Now, W3Techs – Usage statistics of PHP (as of October 2026)
- Timeline, traces of a break-in: watchTowr – PHP2Shell FAQ, TuxCare – PHP2Shell Patch Guide (as of October 2026)
- Status at Hetzner: Hetzner Status – PHP security issues CVE-2026-109618 and CVE-2026-109619 (as of 22 October 2026)
- Status at IONOS and All-Inkl: IONOS Newsroom, ALL-INKL.COM – Wichtig zu wissen (in German, as of 22 October 2026)
Hornetsecurity for Microsoft 365: when additional email security makes sense
Why I usually add Hornetsecurity for email protection when clients use Business Standard, how the switch works, and when I recommend Business Premium instead.
Read article→
IT for medical practices: coordinating practice software, network and backup
What the KBV's IT security guideline requires of practices, where the TI service provider's job ends, and how I set up the practice network and backup.
Read article→
A ransomware attack in practice: 60 employees back at work within 48 hours
Every computer and file share encrypted, but not the backups. How an offline backup brought a company back without paying a ransom, in which order the systems returned and what changed afterwards.
Read article→