7 min readNew
Today the Netherlands was briefly disrupted, not by an attack but by precaution. MijnOverheid, DigiD, the site of the Dutch House of Representatives and countless other sites in the Netherlands went offline while waiting for a patch, NOS reported. A patch is a kind of band-aid for software: an update that closes a flaw in the program. Here it concerned two critical flaws in PHP, the software that many websites run on. With them, an attacker can run their own code on the server without signing in. The patch came on 21 October 2026. The advice from PHP itself is short: update now.
In this blog post you read which vulnerabilities they are, which versions fix them, who is most at risk, what you can do if you cannot update yet and how the release got out of hand.
Updated on 27 October 2026: PHP removed the warning about rpms.remirepo.net from the advisory on 21 October, so it is no longer here either, and two sentences now say exactly what the sources say.
The PHP project announced the release on 20 October and published the security advisory with two vulnerabilities on 21 October. Both have a CVSS v4.0 score of 9.2 and the rating Critical:
| CVE | Name | What goes wrong |
|---|---|---|
| CVE-2026-109618 | RCE via OOM corruption | When PHP runs out of memory, handling can stop halfway while internal data of the request is only partly built. The cleanup afterwards treats that data as valid. |
| CVE-2026-109619 | RCE via stale global state | Internal data of a request remains after its memory has been freed. A following request in the same worker process can then still use that data. |
According to the advisories, the first vulnerability leads to remote code execution without authentication, under the account of the web worker. For the second, they also mention leaking memory contents.
The advisory does not mention exploitation in the wild. The announcement of 20 October kept open the option to publish earlier if details leaked or exploitation appeared. Because the CVE numbers were already circulating, without technical details, PHP moved the release from 22 to 21 October, according to the PHP Foundation.
The PHP Foundation describes how the release planned for 22 October was brought forward by a day:
At the time of the release, the PHP security team found no working exploits among the proofs of concept that surfaced. Even so, the uncertainty was large enough to take sites such as MijnOverheid and DigiD in the Netherlands offline as a precaution until the patch was there.
According to the Foundation, the memory problem behind CVE-2026-109618 already surfaced in 2024, while a finding from an external audit by Quarkslab was being fixed. No concrete attack was known then, and the fix stalled for months because every solution had drawbacks. The Foundation itself calls that delay “a structural failure”.
That changed this summer. Within the program Patch the Planet, led by OpenAI, Calif started an audit of PHP on 30 July. On 11 August, Ryan A of Calif and, separately, OpenAI reported the same root cause as remote code execution. Wiz, which calls the vulnerabilities PHP2Shell, found them on 19 August with the help of Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol, confirmed attacks against Drupal and WordPress and reported them to PHP on 24 August. On 18 September OpenAI reported additional attack paths. According to OpenAI, Calif found the vulnerability with GPT-5.6 Sol, and as far as is known, AI models found the vulnerabilities before attackers did. OpenAI calls it “one of the most impactful security issues in recent memory” and warns that the same AI capabilities can help attackers build exploits quickly.
The Foundation writes that the security team is changing how it works: decisions can from now on be made by majority, and leadership steps in earlier when a fix stalls.
OpenAI has published a checker that lets you check the PHP version of a website or server in Codex, without sending attack requests. The checker only compares the version number the server shows; it does not confirm that the fix is actually in it.
PHP names “all PHP installations serving web requests”: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. According to PHP, the risk is greatest with mod_php. There, a working attack has been demonstrated in which a request without signing in hits the vulnerability before even a single line of the application’s code runs. PHP-FPM is affected too. According to the PHP Foundation, code execution through the first vulnerability is also confirmed on PHP-FPM, through paths in the application code; the technical advisory does not yet name a complete attack for FPM. According to the advisory of the second vulnerability, code execution through sessions has been demonstrated against both mod_php and PHP-FPM.
The versions before 8.2.35, 8.3.36, 8.4.27 and 8.5.12 are vulnerable. According to Wiz, every PHP version of the past decade, back to 5.4, is affected by at least one of the two vulnerabilities. Packages from your distribution or LTS vendor can contain the fix with an older version number; check that in your vendor’s security notices. About PHP 8.1 and older, the advisory says that the PHP project no longer updates them. The security team has, however, published minimal source code patches for PHP 7.4, 8.0 and 8.1, for those who compile it themselves.
The only complete solution is to update to one of these versions:
Where you get the update depends on how PHP is installed:
💡 Note: PHP 8.2 gets no more security updates after 31 December 2026. PHP therefore asks you to plan an upgrade to a supported version now.
PHP names a number of measures that close certain attack paths. They explicitly do not make an installation safe: “only an update is a complete solution”. Below is a selection; the advisory names more.
Against CVE-2026-109618:
memory_limit=-1, preferably in a way an application cannot override, such as php_admin_value in the FPM pool or the Apache configuration. Check that no pool, directory or application sets a limit again. According to PHP, a memory shortage deeper in the system can still hit the vulnerability.post_max_size low: 8M for applications without uploads, 32M if uploads are needed. Keep upload_max_filesize lower than post_max_size.RLIMIT_AS or RLIMIT_DATA for this: they can actually trigger the vulnerable path.Against CVE-2026-109619:
session.upload_progress.enabled=0 and restart every worker. Do this in php.ini, an FPM pool or a server configuration that applies before the request is processed. Do not rely on ini_set() or an FPM .user.ini. This closes the confirmed paths through sessions, but not other variants.fatal_error_backtraces=0 and restart every worker. This only closes the confirmed path through fatal backtraces.error_reporting, display_errors or @ does not help.The advisory says nothing about shared web hosting, where the hosting provider manages the PHP configuration. That seems a question for that provider.
The PHP vulnerabilities of 21 October 2026 are critical and affect every PHP installation that has not been updated and handles web requests, with mod_php as the greatest risk. Update to 8.2.35, 8.3.36, 8.4.27 or 8.5.12, and use the temporary measures only as a stopgap. If you are not sure where PHP runs, go through your web servers, intranets and management tools.