1. What happened: a leak forced PHP to act

Normally, a serious bug is fixed in silence and published on a fixed date. This time the plan broke.

On 20 October, a user on Hacker News posted that two PHP RCE flaws with a CVSS score of 10.0, affecting every version since PHP 5, would be made public on Thursday 22 October. The poster openly admitted to have no proof. A few hours later, the security company watchTowr confirmed on X that the leak was real and that the flaws were under embargo. (sources: Hacker News, The Hacker News)

PHP then published its own notice at 19:33 UTC and moved the release one day forward, to Wednesday. PHP also warns that it may release even earlier if details of the flaws become public, or if attacks are seen in the wild. Full details, affected versions and fixed versions only come with the release. (source: PHP announcement)

The same evening, CERT-EU, the cybersecurity service of the EU institutions, published Security Advisory 2026-018. Its message is short: prepare for immediate patching, and where you cannot patch at once, consider taking internet-facing applications off the public network until a fix is available. (source: CERT-EU)

2. What we know, and what we do not know yet

• Two CVEs: CVE-2026-109618 and CVE-2026-109619. CERT-EU and researchers use these numbers, but they first appeared in the leak. PHP's own notice does not name them. (source: CERT-EU)
• Severity: PHP rates both flaws 9.2 on CVSS version 4.0. The score of 10.0 you may see online comes from the leak, not from PHP.
• Impact: remote code execution according to watchTowr. CERT-EU adds that the score suggests an attacker may not even need to log in.
• Affected versions: not confirmed. CERT-EU writes that all versions from PHP 5 onwards could be affected. watchTowr's own FAQ says this has not been confirmed by PHP, and that no special configuration or feature has been described as a condition. (source: watchTowr FAQ)
• Attacks so far: none reported as of 21 October, and the flaws are not in the CISA list of known exploited vulnerabilities. Huntress says it has not seen exploitation at its customers and knows of no public exploit code. (source: Huntress)
• Still unknown: which part of PHP is broken, and whether an attack needs a specific setup (for example php-fpm, CGI or the Apache module), a certain configuration, or a login.

A tip we always give our students at Howest: in a story like this, separate facts from noise. In the Hacker News discussion, some users say a demo video and a private proof of concept are going around, showing a shell on a server after pasting something in a URL. The security companies have not confirmed this. Treat it as a warning sign, not as a fact. But do not wait for proof either. (source: Hacker News discussion)

3. The real problem: old PHP gets no fix

PHP only fixes the four branches it still supports. Several trackers, including Alpine Linux and researcher Kevin Beaumont, expect these version numbers, but PHP has not confirmed them yet: (source: PHP supported versions)

• PHP 8.5: from 8.5.11 to 8.5.12 (active support until 31 December 2027)
• PHP 8.4: from 8.4.26 to 8.4.27 (active support until 31 December 2026)
• PHP 8.3: from 8.3.35 to 8.3.36 (security fixes only, until 31 December 2027)
• PHP 8.2: from 8.2.34 to 8.2.35 (security fixes only, until 31 December 2026)

PHP 8.1, 8.0, 7.x and 5.x are end of life. If the flaws reach these versions, there will be no official patch. How big is that group? Security company Mallory counted about 884,000 internet-facing servers whose banner showed PHP 8.1 or older on 20 October. That is 59% of the roughly 1.5 million servers that show a PHP version at all. A banner is not proof that a server is vulnerable, but the order of size is clear. (source: Mallory)

Developers on Hacker News expect many classic LAMP servers with WordPress to be hit: sites where the PHP version is too old for a patch, or where nobody really owns the server anymore because a contractor set it up years ago. One small piece of good news: Linux distributions such as Debian, Ubuntu and Red Hat often put fixes into older version numbers (backporting). So check your distribution's security updates, not only the version string. (source: Hacker News discussion)

4. What to do today: a 6-step checklist

PHP has not published an official workaround. Until the patch is out, these steps help you prepare. Most come from Huntress, with the isolation advice from CERT-EU. (sources: Huntress, CERT-EU)

1. Make a list of every PHP install. Also the hidden ones: PHP inside vendor appliances, Windows software, and control panels like cPanel and Plesk.
2. Be ready at 16:00 Belgian time. Patch internet-facing systems first. Check your Linux distribution and your hosting provider for updated packages.
3. On an end-of-life version? Upgrade, take the system off the internet, or put it behind a VPN or a web application firewall until you can.
4. Cannot patch right away? Follow CERT-EU: consider isolating internet-facing applications from public networks until a fix is in place.
5. Watch what PHP starts. Set alerts when php-fpm, php-cgi, httpd or apache2 launch a shell, a script interpreter or a download tool. On Linux servers without endpoint detection, Florian Roth's process-watcher logs every program a PHP process starts. It only detects, it does not block anything.
6. Found something strange? Isolate the server, keep the web server and PHP logs, and look for web shells, new files in the web root, new cron jobs or scheduled tasks, and new user accounts.

A note on one unofficial tip: on Hacker News, a user shared a possible temporary mitigation from a researcher on X, setting session.upload_progress.enabled = Off in php.ini. PHP has not confirmed this. If you try it, test first, because applications that show upload progress bars may stop working. And see it as an extra layer, never as a replacement for the patch. (source: Hacker News discussion)

5. Lessons for the long term

Once the patch is in, it is easy to forget this story. Please do not. It teaches some lessons we repeat in every training session:

• You cannot patch what you do not know. Many companies will spend today searching where PHP is running. An up-to-date asset inventory and a software bill of materials (SBOM) turn hours of searching into minutes.
• End of life is a risk you choose. Old software works fine, until the day it cannot be fixed. Put end-of-life dates in your planning. For example: PHP 8.2 gets security fixes only until 31 December 2026.
• Attackers are fast. When the PHP flaw CVE-2024-4577 became public in June 2024, Akamai saw the first attack attempts within 24 hours. Once today's patch is out, attackers can compare old and new code to find the bug. (source: The Hacker News)
• Embargoes are fragile. Coordinated disclosure only works if everybody keeps quiet. One leak was enough to change the whole timeline. Your patch process must be able to move in hours, not weeks.
• Regulation makes this your job too. Under NIS2, essential and important entities must handle vulnerabilities and report significant incidents. Under the Cyber Resilience Act (CRA), manufacturers are responsible for vulnerabilities in the components they build into their products, open source like PHP included. Since 11 September 2026 they must also report actively exploited vulnerabilities in their products.

This article was written before the PHP release. For the final list of affected and fixed versions, always check the official PHP news page. We'll update links below as the story unfolds. For now, the news aggregation page on ycombinator is the best source of up-to-date information on PHP2Shell.