On 21 October 2026, the PHP team corrected two critical faults (CVE-2026-109618 and CVE-2026-109619). They could allow an attacker to run code on a server without an account or password. Attempts to exploit were reported worldwide early in the morning, even before the patch was published.
These flaws were in PHP itself, the language that makes WordPress work. An update of WordPress, a theme or an extension could not correct them: only an update of PHP could. At Faaaster, we manage PHP.
You have nothing to do.
October 21, hour by hour (Paris time)
As early as morning: monitoring and preparation. We followed the PHP team's announcements, security researchers' alerts and our PHP package provider. We have prepared the update of all PHP versions used on our servers, including the oldest.
Around 2.30 p.m.: first protection. Even before the patch was available, we applied to all operating sites settings that closed one of the identified attack paths. We then checked each site to ensure that everything continued to work normally.
Around 3:00 p.m.: enhanced protection. We added a second setting, then checked all the sites again. We also added to our application firewall a rule dedicated to these faults, to filter known attack queries before they reached PHP.
4 p.m.: publication of the official patch. We immediately built and tested corrected PHP versions. We have also added an automatic control to our construction chain: it is now impossible to produce a server image with a version of PHP prior to this patch.
Around 5:00 p.m.: blocking the main attackers. We have blocked at our infrastructure level, for all sites at once, the IP addresses at the origin of the main waves of attacks.
Around 6:00 p.m.: lockdown. We have strengthened temporary protections. No extension or site setting can disable them anymore.
Between 6 p.m. and midnight: PHP update. The sites have been updated to the corrected versions, gradually and without general interruption of the platform. Each site kept its PHP version.
Attack analysis and site verification
Throughout the incident, we analyzed the consolidated logs of our entire platform to identify suspicious queries. It was this analysis that enabled us to identify and block the main attackers.
We then isolated the sites where suspicious requests had reached PHP, and we checked each of these sites.
No compromise was detected.
Why multiple protections at once?
A firewall rule blocks attacks that she knows how to recognize, but an attacker can change method. Temporary settings close known attack paths, but the PHP team recalls that they do not replace the patch. Updateing PHP remains the only definitive protection. So we combined all three: immediate settings, attack filtering and PHP update.
What impact on your site?
Your content, extensions, themes and database have not been modified.
We did not block forms or send files: your visitors would have lost the opportunity to contact you or order. We preferred targeted protections, then update PHP.
Should we do something?
No. For these flaws, no need to update WordPress, change your configuration or passwords.
If you notice unusual behavior on your site since October 21 (form, connection, basket, file submission), contact our support: we will look with you.
Sources followed
Our decisions were based on several complementary sources:
- PHP team official notice ;
- advisory CVE-2026-109618 ;
- advisory CVE-2026-109619 ;
- Official backport branches PHP 7.4, 8.0 and 8.1;
- changes packages provided by packages.sury.org ;
- virtual patching rule published in the Hub CrowdSec ;
- field information published by Cloudflare and Sansec ;
- Construction logs, PHP-FPM metrics, HTTP controls without cache and reconciliations of our own park.
