What happened on 21 October
The PHP project's official announcement sums it up: versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. They are CVE-2026-109618 and CVE-2026-109619, rated 9.2 on the CVSS scale, and according to the analysis published by Google Cloud they affect every PHP version from 5.4 through 8.5.11. In other words: practically every PHP installation in production in the world, as of that date.
The disclosure was rushed. According to the PHP Foundation, the embargo agreed among vendors was broken more than six hours before the scheduled time, and the release, planned for 22 October, was brought forward by a day. The root cause had been under investigation since a 2024 audit and was reported independently by more than one research team in August 2026. CISA, the US government's cybersecurity agency, published an alert the same day and on 26 October added both flaws to its catalogue of known exploited vulnerabilities (KEV). The FBI issued its own public service announcement on 23 October.
Why mod_php is the worst case and PHP-FPM is not safe either
The PHP Foundation describes the most serious scenario in one sentence: on Apache with mod_php, an unauthenticated request can trigger this before any application code runs. That means it does not matter whether the system has a login, whether the framework is modern or whether the code was reviewed: the flaw is in PHP's own handling of the request, before your program starts. It is the typical configuration of old shared hosting and of servers set up ten years ago and never revisited.
Anyone running PHP-FPM, the most common model on recently configured servers, is in a better position but not a safe one: the same source confirms remote code execution on PHP-FPM through application-level code paths. The practical difference is that on FPM the exposure depends on what the application does with uploads and sessions; on mod_php, the server merely has to exist. In both cases, the only complete solution is the upgrade.
The part that matters for old systems: 8.1 and earlier have no fix
The project's announcement is blunt: PHP 8.1 and older no longer receive updates from the PHP project. The security team published minimal source backports for 7.4, 8.0 and 8.1, aimed at people who build their own PHP or have no long-term-support vendor, and advises contacting your Linux distribution or vendor to find out whether a backported fix exists. For the company with a PHP 7 system on ordinary hosting, that translates to: nobody is going to fix this for you.
CISA's guidance for that case is as hard as an agency usually gets: organisations that cannot update immediately, or that continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated. That is what Brazil saw on 21 October: according to Tecnoblog, Anatel services became inaccessible and SEI, the electronic records system used by public bodies, was still offline the next day. And the calendar keeps moving: PHP 8.2 reaches end of life on 31 December 2026. Anyone still on it in January is back in the same situation.
Temporary mitigation when you cannot upgrade today
The PHP project published measures for those who cannot update immediately, with a warning in capital letters: they reduce exposure to specific attack paths but do not make an installation safe. The first is counter-intuitive: set memory_limit to -1, that is, no limit, preferably via php_admin_value in the FPM pool or the Apache configuration so the application cannot override it. The reason is that CVE-2026-109618 exploits precisely the attacker-controlled memory allocation failure; removing PHP's limit removes that trigger, although an underlying allocation failure can still reach the vulnerable code.
The second is to lower post_max_size: 8M for applications without file uploads, 32M when uploads are needed, keeping upload_max_filesize below it. The third, for CVE-2026-109619, is to disable session.upload_progress.enabled and restart every worker, through server configuration and not ini_set, which runs too late. The announcement also recommends size and field-count limits at the web server or proxy, and fixing fatal errors an attacker can provoke. And it repeats: there are no complete mitigations; updating is the only safe choice.
How JBKR handled the systems under support (method, not heroics)
In the week of the disclosure the script was the same for every client with PHP systems on a monthly plan, and there is nothing special about it: it is what a maintained inventory lets you do. First, the list of versions per system and per server, which already existed because it is part of every client's onboarding assessment. Second, the order by exposure: internet-facing mod_php first, internet-facing PHP-FPM next, internal systems last. Third, the action per tier: anyone on 8.2 or higher got the fixed release; anyone on 8.1 or older got the temporary mitigations the same day and a date for the version upgrade, which has now stopped being optional.
Fourth, the record: what was done, on which server, at what time, in writing, for the client and for any future question from an auditor or a data subject. That record is also what lets you tell a client with confidence that they were not affected, instead of assuming. JBKR's support plan provides a same-business-day reply and work on critical failures started within 24 hours; an actively exploited vulnerability counts as a critical failure, even when the system is running normally.
The cost of postponing: the flaw as a modernization argument
The conversation about upgrading PHP tends to be postponed because the system works and because upgrading has a cost: incompatible libraries, removed functions, tests nobody wrote. The article on maintaining or modernizing a PHP, Java or .NET system gives the cost ranges for each path, and the version upgrade is almost always the cheapest of them. What PHP2Shell changed was the other column of the ledger: the cost of not upgrading stopped being theoretical and acquired a date, 21 October, and a concrete consequence, systems offline on official advice.
It is worth being honest about what the upgrade solves and what it does not. Going from PHP 7.4 to 8.3 does not make an old system modern; it resolves the exposure to this flaw and to the next ones, which will come, because PHP fixes vulnerabilities in supported versions and only in those. It is the first step of any modernization roadmap, which is why it appears as the first action in practically every assessment JBKR delivers. The article on cloud migration explains why upgrading the version and changing servers are separate decisions, even when they happen together.
A one-page checklist and the next step
For anyone with a PHP system who does not know where to start: find the exact version on every server, including staging and the one that only runs the monthly report. Find out whether it runs on mod_php or PHP-FPM. If the version is 8.2 or higher, apply the fixed release today. If it is 8.1 or older, apply the PHP project's three mitigations today, ask the host whether a backported fix exists, and schedule the version upgrade for the coming weeks, not next year. Confirm that a restorable backup from before 21 October exists, the subject of the article on backups and ransomware. Write everything down.
If the answer to any item is "I don't know", that is the sign that the system has no technical owner, and that is a bigger risk than the flaw. At JBKR the initial 30-minute assessment is free, and for PHP systems, this week, it starts with the version.
