# PHP2Shell: what the PHP flaw means for your website | Fokuus

[Home](https://fokuus.be/en/) [Blog](https://fokuus.be/en/blog/) PHP2Shell: what the PHP flaw means for your website 

# PHP2Shell: what the PHP flaw means for your website

PHP2Shell: two critical vulnerabilities in PHP, the language WordPress runs on. What happened hour by hour, who saw exploitation and which versions contain the fix.

[Anton Pycarelle](https://fokuus.be/en/about/)  22 October 20266 min read time

## In this article

- [What is PHP2Shell?](https://fokuus.be/#wat-is-php2shell)
- [From leaked number to fix](https://fokuus.be/#van-uitgelekt-nummer-tot-fix)
- [Who saw what exploitation, and when](https://fokuus.be/#wie-zag-welk-misbruik-en-wanneer)
- [What governments and WordPress.org advise](https://fokuus.be/#wat-overheden-en-wordpress-org-adviseren)
- [Old PHP versions are the hardest case](https://fokuus.be/#oude-php-versies-zijn-het-moeilijkste-geval)
- [Who updates PHP for you?](https://fokuus.be/#wie-werkt-bij-jou-php-bij)

A flaw in PHP can't be fixed with a WordPress update. It sits one layer lower, in the software on the server, so whoever manages that server has to act: for most SMEs the hosting provider, not the site owner. That is the core of PHP2Shell, the PHP flaw for which Smartschool, VDAB, FPS Finance and a number of hospitals in Belgium took their websites offline as a precaution, [VRT NWS reported](https://www.vrt.be/vrtnws/nl/2026/10/21/cyberbeveiliger-ziet-eerste-aanvallen-rond-kwetsbaarheden-in-pop/) .

## What is PHP2Shell?

PHP2Shell is the nickname for two critical vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619, which allow someone to run their own code on a web server running PHP without logging in. On 21 October 2026, the PHP project released [urgent updates](https://www.php.net/archive/2026.php#2026-10-21-5)  for them and gave both vulnerabilities in its [advance announcement](https://www.php.net/archive/2026.php#2026-10-20-1)  a severity score of 9.2 out of 10.

PHP is the programming language that builds a page on the server as soon as someone requests it. [W3Techs](https://w3techs.com/technologies/details/pl-php)  reports that 69.3 percent of the websites whose server-side language is known run on PHP (measured on 22 October 2026). That includes WordPress, which accounts for [39.6 percent of all websites](https://w3techs.com/technologies/details/cm-wordpress)  and, as its [own system requirements](https://wordpress.org/about/requirements/)  state, depends on PHP.

In plain language: with the first flaw, PHP runs out of memory in the middle of a request and then treats half-finished data as valid. With the second, leftovers of a previous request linger, which a following request then picks up again. Both can end with an outsider's code running on your server. In the most dangerous setup, Apache with mod_php, a request without a login can already start the attack, according to the PHP team, before your website software does anything.

## From leaked number to fix

Normally, a flaw like this stays secret until the fix is ready. Linux distributions get the fix in advance, so their users can update straight away. That went wrong this time, according to [the PHP Foundation](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/)  itself.

Around 17:00 Belgian time on 20 October, the CVE numbers appeared online, still without technical details. At 21:30, PHP moved the release forward from 22 to 21 October. That same evening, Calif, one of the companies that reported the flaws, accidentally put a video of a working attack online. On 21 October at 09:41, Chainguard published the fix, more than six hours before the agreed time; according to the PHP Foundation, attackers could therefore already study it. The updates themselves came out around 15:30, according to [CERT-EU](https://cert.europa.eu/publications/security-advisories/2026-018/) .

Almost a day passed between the numbers leaking and the fix, and Amazon saw the first attack attempt four days earlier.

## Who saw what exploitation, and when

One distinction first: an attempt is not a break-in. Many reports come from honeypots, decoy servers that attract attackers. An attempt on one proves that someone is trying, not that it succeeds on real sites.

[Amazon](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/)  saw a first attempt on such a honeypot on 17 October, without knowing how the attacker had already obtained information by then. On 21 October between 04:00 and 10:00, more followed, from several attackers; according to Amazon, it is unclear whether they would have succeeded on real systems. The Dutch NCSC wrote on 21 October, before the patch, that [public proof-of-concept code](https://www.ncsc.nl/alerts/ernstige-kwetsbaarheden-in-php-bereid-je-voor-op-patchen)  existed, but it saw no active exploitation itself. [Cloudflare](https://blog.cloudflare.com/php-vulnerabilities-waf-protection) , with filtering rules active from 05:02, did see attack traffic aimed at its customers.

At the time of the release, the PHP team found that none of the public proofs of concept worked. That doesn't rule out working attacks: Calif showed one in its video, and [watchTowr](https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/)  says it has reproduced both vulnerabilities itself. [CISA](https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching) , the US cybersecurity agency, had not yet observed any exploitation at the time of its warning on 21 October; CERT-EU rated the likelihood of it higher because proofs of concept were circulating. Meanwhile, watchTowr is seeing active attack attempts on both vulnerabilities and Amazon speaks of widespread exploitation.

My reading: that attempts are being made is certain; I found no publicly confirmed successful break-in via PHP2Shell in these sources. For an SME with a PHP site, that means two things. There is no point waiting until victims appear in the news: Amazon recommends looking for traces from 17 October, not from the disclosure. And panic doesn't help either, because the only complete fix is ready: update PHP.

## What governments and WordPress.org advise

They agree on one thing: update PHP now. If that isn't possible straight away, their advice differs. CISA and the [Dutch NCSC](https://www.ncsc.nl/alerts/kwetsbaarheden-php-patches-beschikbaar-update-nu)  are the strictest. Anyone who can't update right away or is still on 8.1 or older must, according to CISA, take their PHP systems offline until they are updated. The NCSC writes: "Until systems have been updated, it is necessary to keep them offline as a precaution." The [UK NCSC](https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php)  first refers to PHP's temporary measures and only advises considering taking systems offline if those fail. CERT-EU asks organisations to consider shielding internet-facing applications.

Do you need to update WordPress for this flaw? No. [WordPress.org](https://wordpress.org/news/2026/10/critical-php-security-release/)  wrote on 21 October that no WordPress update is needed or planned for these vulnerabilities, because they are in PHP, and refers you to your web host for the PHP update. Updating a plugin or theme doesn't fix it either, Cloudflare stresses.

## Old PHP versions are the hardest case

Which PHP versions are safe? You are protected against PHP2Shell with the patched version of your own series or a higher number within that series: 8.5.12, 8.4.27, 8.3.36 or 8.2.35. So if you run 8.3.20, you are not covered, even though that number is higher than 8.2.35, unless your provider built the fix into that version themselves (see below). PHP 8.1 and older get no new release from the PHP project, at most a minimal source code patch (for 7.4, 8.0 and 8.1) for those who compile PHP themselves. And after 31 December 2026, 8.2 will receive [no more security fixes](https://www.php.net/supported-versions.php) .

That affects many sites: according to W3Techs, more than a third of the websites that use PHP still run version 7 or 5 (measured on 22 October 2026). An old version number is not automatically vulnerable, though: some Linux distributions, LTS providers and hosts also build the fix into older versions; php.net refers you to your provider for this. Only whoever manages your PHP knows whether that has happened in your case.

## Who updates PHP for you?

More important than all the technical details is that one question. If nobody in your business knows the answer, that is the real problem, regardless of this flaw. Most of the sites we build are static and run on Netlify without PHP on the web server; you can read why we choose that in [our post on maintenance](https://fokuus.be/en/blog/website-onderhoud-hoeveel-nodig/) .

If you do have a PHP or WordPress site: [our step-by-step plan](https://fokuus.be/en/blog/website-getroffen-php-lek/)  shows how to check whether your site has been affected, [our checklist](https://fokuus.be/en/blog/php-wordpress-site-beveiligen/)  covers what to put in place structurally. If you'd like us to take a look with you, that's possible via [hosting and maintenance](https://fokuus.be/en/hosting-onderhoud/) .

PHP WordPress Website security Hosting

Share [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Ffokuus.be%2Fen%2Fblog%2Fphp2shell-php-lek%2F) [DotsApp](https://wa.me/?text=PHP2Shell%3A%20wat%20het%20PHP-lek%20betekent%20voor%20je%20website%20https%3A%2F%2Ffokuus.be%2Fblog%2Fphp2shell-php-lek%2F) [Email](mailto:?subject=PHP2Shell%3A%20wat%20het%20PHP-lek%20betekent%20voor%20je%20website&body=https%3A%2F%2Ffokuus.be%2Fblog%2Fphp2shell-php-lek%2F)

## Get Fokuus updates.

New articles and Fokuus's updates in your mailbox. You can unsubscribe at any time.

## Anton Pycarelle

Founder of Fokuus

Anton builds and optimizes websites for Belgian SMEs from Kortrijk. He writes about choices and experiences from real projects.

[More about Fokuus](https://fokuus.be/en/about/)

## Keep reading.

[All articles](https://fokuus.be/en/blog/)

Maintenance & Technique · 7 min reading time 

### Secure a WordPress or PHP site: 10 things to check

Secure a WordPress or PHP site: ten points, from a supported PHP version to an emergency plan, and who does each: you, your web developer or your host.

[Maintenance & Technique · 7 min reading timeSecure a WordPress or PHP site: 10 things to checkSecure a WordPress or PHP site: ten points, from a supported PHP version to an emergency plan, and who does each: you, your web developer or your host.](https://fokuus.be/en/blog/php-wordpress-site-beveiligen/)

Maintenance & Technique · 7 min reading time 

### Is my website affected by the PHP flaw? How to check

Does the October 2026 PHP flaw affect your website? Five steps to check whether your site runs on PHP, which version, whether your host has already patched and whether there are traces of an attack.

[Maintenance & Technique · 7 min reading timeIs my website affected by the PHP flaw? How to checkDoes the October 2026 PHP flaw affect your website? Five steps to check whether your site runs on PHP, which version, whether your host has already patched and whether there are traces of an attack.](https://fokuus.be/en/blog/website-getroffen-php-lek/)

[Bron](https://fokuus.be/en/blog/php2shell-php-lek/) · [Agentdocumentatie](https://fokuus.be/developers/)
