On 21 October 2026, we had to patch two critical PHP vulnerabilities as an emergency on the servers we host and maintain. This post-mortem covers what happened, what we did, what did not go as well as we would have liked, and what remains to be done. The work is not over.
In short
- The official PHP patch was applied to production servers as soon as it was released, around 3:45 pm Paris time, with a few minutes of downtime per server.
- Attack attempts were detected in the early afternoon, before the patch. Based on our analysis so far, they did not succeed.
- Part of the vulnerability appears to remain exploitable despite the official patch. The protections applied in the morning stay in place and monitoring continues.
- We have identified several areas for improvement, first of all how we make urgent decisions with our clients.
Background
On 20 October, the PHP security team announced two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, rated 9.2 out of 10 (CVSS v4). They allow remote code execution on a server, without credentials. Every PHP installation that serves web requests is affected (PHP-FPM, mod_php, php-cgi): in other words, the vast majority of Magento, WordPress, Symfony and Drupal sites.
In such cases, details normally stay confidential until the patch is released, to give everyone time to prepare. This time, information leaked ahead of schedule, and PHP brought the release forward to 21 October, 4 pm Paris time. The risk of mass attacks was high from the moment of release: Matthew Prince, CEO of Cloudflare, reported thousands of exploitation attempts on their network in the 10 hours before the public announcement, tens of thousands in the 45 minutes after it, and millions since.
Timeline of 21 October (Paris time)
- Morning: we apply the first protective measures in circulation to all environments: disabling the PHP feature suspected to be involved, and emergency Cloudflare filtering rules for the sites behind Cloudflare.
- 1:45 pm to 2:51 pm: on one of the sites we manage, the system administration team detects attack requests targeting the vulnerability. Of 8 requests, 6 are blocked by the emergency Cloudflare rule; 2 get through this filter and are dropped by the attacker. At this stage, everything indicates that none succeeded: the protection applied in PHP that morning holds.
- Early afternoon: we write to our clients to ask for permission to put their site into maintenance as a precaution if needed. For a few critical clients, we tighten the Cloudflare rules and offer to shut their systems down a few minutes before the patch is released. The work planned for 4 pm is brought forward.
- Afternoon: we shut down the development and staging environments, to reduce the number of servers to handle in a hurry, and prepare the update of each production server.
- Around 3:45 pm: the patch is released about a quarter of an hour early. We apply it server by server, with a few minutes of downtime each time. As it arrived ahead of schedule, it was deployed instead of shutting down the critical clients’ systems.
- End of the day: we check on each server that the patched version is actually running.
What is not over
- According to the information available so far, some vulnerabilities would persist despite the patch: a PHP version patched on 21 October would remain exploitable in its default configuration. The morning measures, together with Cloudflare filtering, appear to block this; we are keeping them.
- The development and staging environments are being brought back gradually, and some work is still in progress.
- Monitoring continues. We will update this article if the situation changes.
What we need to improve
Deciding faster with our clients
Asking for permission to put a site into maintenance takes time, at the very moment when time is short. We want to agree on these decisions in advance, client by client.
Strengthening security across the whole system
Two attack requests got through the Cloudflare filtering: the protection held because several layers were in place, not thanks to a single one. Hardening work has started across our whole information system: development environments, access whitelists, two-factor authentication. It will continue.
Reducing the number of old versions
PHP versions that are no longer maintained received backported patches, but these are catch-up fixes, with no guarantee for the next vulnerability. A maintained version gets a patch within minutes; on a version that is too old, the patch may come later, or never, and sometimes the only protection left is to shut the site down.
What this episode says about what comes next
With artificial intelligence, vulnerabilities are found faster, but they are also exploited faster: the time between the announcement of a vulnerability and the first mass attacks is now counted in minutes, not days. On 21 October, several European public administrations, including the French prefectures, chose to take their sites offline as a precaution. Keeping systems up to date is becoming the condition for patching in time.
For technical teams
- Vulnerabilities: CVE-2026-109618 (memory corruption after a memory overflow) and CVE-2026-109619 (internal state reused from one request to the next), CVSS v4 9.2, unauthenticated remote code execution.
- Patched versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For the 7.x, 8.0 and 8.1 branches, patches backported by the maintainer of the PHP packages we use.
- Temporary measures, kept after the patch:
session.upload_progress.enabled = 0andsession.use_strict_mode = 1, emergency Cloudflare filtering rules, non-production environments shut down. - Applying the patch: package update, full restart of the web services, check that no process still runs the old version. Updating the package is not enough: PHP-FPM, Apache with mod_php and long-running processes (Magento queues, message consumers) keep the old code until they are restarted.
- Version numbers: a backported patch does not always change the PHP version number. A tool that only reads that number can be wrong either way; only the installed package version is reliable.
Sutunam clients: your project manager is available for any question about your servers.
Sources: PHP security advisory, 21 October 2026; Matthew Prince, Cloudflare; SecurityWeek; Reuters, via Global Banking & Finance.
