PHP Flaws CVE-2026-109618 and 109619: What to Do, a Week Later

On 21 October 2026, the PHP team released emergency fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which allow remote code execution on a vulnerable server. The press nicknamed them “PHP2Shell”. A week later, the picture is clearer than it was on day one: here is what is established, what is not, and what to do.

Why this article comes several days later

Writing within the hour means repeating what everyone else publishes, with a real risk of getting it wrong. The first 48 hours of a flaw like this are when the information moves the most. Here, for example:

• We learned afterwards, from Amazon Threat Intelligence, that the first exploitation attempts dated from 17 October, four days before the fixes.
• A third flaw, CVE-2026-115560, was added on 23 October on the PHP side, then on 26 October by CERT-FR.
• The first headlines announced mass takeovers; the measurements published since mostly show scanning, with little confirmed successful exploitation.

Above all, the priority in the following days is to patch, not to read a blog post. This one is for people who want a summary cross-checked against official sources, once the emergency has passed.

What is established

• Two flaws in the PHP engine itself, exploitable without authentication. A WordPress site with no plugins at all is therefore affected if it runs a vulnerable version.
• Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October at 4 pm (Paris time).
• Affected versions according to CERT-FR: all 5.x, 7.x, 8.0.x and 8.1.x (which are no longer supported), plus 8.2, 8.3, 8.4 and 8.5 releases older than the versions above.
• Timeline: first exploitation attempt observed on 17 October (Amazon), publication moved forward on 20 October after details leaked, fixes on the 21st, proofs of concept known to CERT-FR on the 22nd.

What needs nuance

• Cloudflare counted millions of attempts on 22 October. But honeypots mostly show scanning and fingerprinting, and no successful code execution on real systems was confirmed in the sources I consulted.
• Security vendors say attackers themselves struggle to build a reliable exploit. VulnCheck, for its part, built one that combines the two flaws to bypass ASLR. In other words: the window is open, not closed, and that is no reason to wait.
• The third flaw, CVE-2026-115560, requires according to the vendor “an unlikely combination” of configuration options and application code. Its fix is planned for the next update cycle.
• I do not detail the exact exploitation conditions here: neither CERT-FR nor the sources I consulted give them, and it is better not to guess.

What to do

1. Know your version. On the command line: php -v. On shared hosting, the version is usually chosen in the host’s customer area; a phpinfo() page also shows it, and should be deleted right afterwards.

2. Update to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or later). On a Linux server, use the distribution’s packages, which have been published (Ubuntu, for example). Updating WordPress or its plugins is not enough: the flaw is in PHP.

3. Leave 8.1 and earlier. There is no official fix. Either your distribution vendor backports the patch, or you migrate.

4. Meanwhile, apply CERT-FR’s workarounds:

   • CVE-2026-109618: set memory_limit=-1 and a low value for post_max_size.
   • CVE-2026-109619: set session.upload_progress.enabled=0 and restart every background process; on PHP 8.5, fatal_error_backtraces=0.

   CERT-FR is blunt about it: only the update fully protects you.

5. Protect upstream. A web application firewall (WAF) such as Cloudflare’s received rules on 21 October. It is a safety net, not a fix.

6. Look for traces. If the site was exposed before the fix, check for recent or unexpected PHP files (web shells), unusual outbound connections and access logs from 17 to 22 October.

What about shared hosting?

Updating PHP is then the host’s responsibility, not yours. Two useful checks: the version shown in your customer area, and the host’s announcement on the subject. If the offered version is 8.1 or older, now is the time to move to a supported branch.

Takeaways

• The disclosure day is not the first day of exploitation: Amazon says so explicitly.
• A flaw in the engine affects every site built on it, not only those with dubious plugins.
• Updating supported versions takes a few minutes; leaving an end-of-life branch takes a real project. Better to plan it before the next alert.

Sources

• CERT-FR: alert CERTFR-2026-ALE-014, multiple vulnerabilities in PHP
• BleepingComputer: Amazon says PHP2Shell exploitation began 4 days before patches
• Krebs on Security: widespread PHP flaw may cause many site outages
• Security Affairs: PHP2Shell, millions of attacks, no confirmed successful exploits yet