PHP2Shell: a few hours between the leak and the attack. Was your host on watch?

On 21 October, the PHP team rushed out four new versions to fix two critical flaws in the core of the language. They let an attacker run code on a server without an account or a password, sometimes before the application has even started. PHP runs WordPress, Drupal, Joomla, a large share of online shops and of town hall websites. Here is what happened, how to tell whether you are affected, and what to do this week.

A week on fast-forward #

• 24 August. Wiz researchers report the flaws to the PHP security team. The company Calif and OpenAI find them on their side too. All three teams worked with artificial intelligence models.
• 17 October. Amazon says it spotted, on its honeypot servers, an exploitation attempt dated that day, four days before the public announcement.
• 20 October. The planned disclosure date, the 22nd, leaks on Hacker News together with the flaw numbers. That same evening, PHP brings the release forward to the next day, 14:00 UTC.
• 21 October. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are released. The same day, watchTowr sees the first attacks on its honeypot network.
• 22 October. CERT-FR, the French national CERT, is aware of proofs of concept and observes exploitation attempts.
• 23 October. PHP reports a third flaw, CVE-2026-115560, which only affects rare configurations.
• 26 October. The US agency CISA adds both flaws to its catalogue of actively exploited vulnerabilities.

Between the leak and the first attacks observed, a few hours went by. On the servers we host, someone was watching.

Why it is serious: the flaw is not in your code #

Usually, a web vulnerability sits in a WordPress plugin, a poorly protected form or a forgotten library. Here, it sits in the engine that runs the code: CVE-2026-109618 and CVE-2026-109619, rated 9.2 out of 10. Put simply, there are two mechanisms.

• Memory running out at the wrong moment. When PHP runs out of memory while reading a request, for example during a file upload, it stops with half-prepared data. The cleanup that follows then treats that data as valid.
• Leftovers from the previous request. A request can leave behind an internal state that points to memory already freed. The next request, handled by the same process, uses it before it is reset.

According to Wiz, these defects go back more than ten years: every version since PHP 5.4 is affected by at least one of the two flaws. Wiz achieved code execution on the latest WordPress, Drupal and Joomla images. Even a plain “Hello World” page is vulnerable, since the application plays no part. Another risk: reading the server’s memory remotely, where passwords, API keys or certificates may sit.

PHP rates the risk highest for Apache with mod_php. There, a single unauthenticated request is enough to trigger the attack before the site’s code runs. Palo Alto Networks counts more than 22.6 million exposed instances that are potentially vulnerable.

Are you affected? #

Yes, if a server runs PHP to answer visitors, whatever the way it runs: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP or LiteSpeed.

• PHP 8.2, 8.3, 8.4 and 8.5: fixed in 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
• PHP 7.4, 8.0 and 8.1: no longer maintained by the project. Fixes from your distribution or your vendor, or migration.
• PHP 7.3 and older, PHP 5 included: no fix at all. Migration is mandatory.

Two traps come up often.

• PHP hides inside other products. You find it in hosting control panels, network appliances, business software. CISA points it out: it is not always visible.
• The version serving the site is not necessarily the one you think. A server can have several versions installed. Ask your provider which one actually answers visitors.

What to do this week #

1. Update PHP itself, not just WordPress or the plugins. Linux distributions received the fixes in advance, and their packages are available.
2. Restart every PHP process after the update. Otherwise, the old code stays in memory and the server stays vulnerable, even with the right package installed.
3. Do not rely on workaround settings. The PHP team says so itself: none of them makes an installation safe, only the update fixes it. One exception: for the third flaw, disabling session.upload_progress is enough until the next release.
4. Isolate what cannot be updated. That is CERT-FR’s advice for branches no longer maintained: cut access from the internet, then migrate. Note too that PHP 8.2 will receive no more fixes after 31 December 2026.
5. Look at the logs. Signs to watch, according to Wiz and CISA: unusual form uploads followed by memory errors or bursts of 500 errors, abnormally long session cookies, PHP processes restarting for no reason, or running commands and downloading tools.
6. Change your secrets if the server was exposed before the update. An update closes the door, it does not get out someone who may already be inside. And the memory may have leaked passwords or keys.

What this week says about hosting #

Every language has had, or will have, a week like this one. The right question is not whether PHP is safe. It is who watches your servers, and how long the fix takes to reach them.

For the applications we host and maintain, the platform is kept up to date and monitored day and night, on our servers in France. An alert like this one is handled on our side, without you having to call us: fix applied, check afterwards, nightly backups at hand.

Is your PHP site or application with another provider, or running on a version that is no longer maintained? We can review it with you: what is exposed, what needs updating, and if needed a migration plan or a takeover of its maintenance.

Sources #

• PHP, security announcements of 20, 21 and 23 October 2026: fixed versions, advisories for CVE-2026-109618 and CVE-2026-109619, informational advisory on CVE-2026-115560.
• CERT-FR, bulletin CERTFR-2026-ALE-014, Multiples vulnérabilités dans PHP (20 October 2026, updated on the 26th, in French).
• CERT-EU, Security Advisory 2026-018, Critical Vulnerabilities in PHP (23 October 2026).
• CISA, Critical Vulnerabilities in PHP Require Immediate Patching (21 October 2026, update of the 26th: added to the KEV catalogue).
• Wiz Research, PHP2Shell: AI uncovers critical RCE vulnerabilities (21 October 2026).
• watchTowr, PHP2Shell FAQ: timeline and exploitation observed.
• Unit 42 (Palo Alto Networks), Threat Brief: PHP2Shell (updated on 25 October 2026).
• The Hacker News, exploitation attempt four days before disclosure, according to Amazon.