What the vulnerability is
The bugs are in PHP itself, not in your application, and PHP says they can allow unauthenticated remote code execution. PHP’s advisory lists two:
- CVE-2026-109618, “RCE via OOM corruption”. When PHP runs out of memory, it can stop halfway through setting up a request. The cleanup then treats the half-built data as valid.
- CVE-2026-109619, “RCE via stale global state”. Data from one request can outlive its freed memory. A later request on the same worker may use it.
Picture a kitchen that closes every station as if it was set up properly, even when the cook stopped halfway, and where the next order sometimes gets a plate that was already thrown away. In both bugs PHP trusts data it should not, and an attacker who steers that data can run their own code.
On mod_php it happens before any application code runs, so your framework’s validation, login checks and middleware never get a say. PHP says it has a demonstrated exploit on mod_php, and the second advisory says its session attack path also works on FPM. Both bugs are rated critical, CVSS v4.0 9.2. The researchers call the pair “PHP2Shell”.
How it was found and fixed
The reporters say they told PHP in August 2026. Calif found the first paths to code execution on 1 August, reported the bugs on 11 and 21 August, and says PHP confirmed its proof of concept on 15 August. Wiz Research reported on 24 August and says PHP acknowledged on 21 September. PHP’s own advisories don’t say when the reports arrived.
The CVE record credits Calif, Wiz and OpenAI with the find (Calif names its researcher, Ryan Austin), and Arnaud Le Blanc, Ilija Tovilo, Jakub Zelenka and Nora Dossche with the fix. Le Blanc authored the fix commit. Zelenka published both GitHub advisories.
The release was coordinated: distributions and LTS vendors got the patches early. On the morning of 20 October a Hacker News post said two critical PHP bugs were coming, Huntress reported. It gave a score and the CVE IDs, but not how the bugs work. Later that day PHP announced the release for 14:00 UTC on 21 October. It shipped at about 13:30 UTC, and the GitHub advisories went public at 13:34 UTC.
-
Discovery
Calif finds the bugs and reports them to PHP
According to its own write-up, the security firm Calif found the first paths to code execution on 1 August, reported the first bug to PHP on 11 August and the second on 21 August. It says PHP confirmed its proof of concept on 15 August.
Source: Calif write-up (timeline)
-
Disclosure
Wiz reports to the PHP security team
Wiz Research says it found its first PHP vulnerability on 19 August and reported the vulnerabilities to the PHP security team on 24 August.
Source: Wiz Research blog (timeline)
-
Disclosure
PHP acknowledges Wiz's reports
According to the Wiz timeline, PHP acknowledged Wiz's reports on this day and began developing a coordinated fix.
Source: Wiz Research blog (timeline)
-
21:03 and 21:04 UTC Disclosure
CVE numbers are reserved
The PHP project reserved CVE-2026-109618 and CVE-2026-109619 for the two bugs.
Source: CVE record, CVE-2026-109618
-
15:26 UTC Response
Fix commit authored
Arnaud Le Blanc authored the fix, "Avoid state corruption via bailout", with Ilija Tovilo, Jakub Zelenka, Nora Dossche and Nicolas Grekas as co-authors. It became public on 21 October.
Source: php-src commit 3584a98
-
Disclosure
News of the bugs leaks early
Huntress reported that on the morning of 20 October a post on Hacker News claimed two critical PHP vulnerabilities were about to be disclosed.
Source: Huntress blog
-
Advisory
PHP announces the release date
The PHP security team scheduled a security release for 21 October at 14:00 UTC, for two critical bugs rated CVSS v4.0 9.2. It kept the right to release earlier if details became public.
Source: php.net news, advance notice
-
12:55 UTC (21:55 JST) Reaction
Japan's Prime Minister asks site owners to get ready
Sanae Takaichi asked operators of public websites to check whether they use PHP and to prepare to apply the patch due at 23:00 JST. If patching fast is hard, she wrote, taking a site offline for a while is one way to reduce the risk.
Source: Post by Sanae Takaichi on X
-
About 13:30 UTC (15:30 CEST) Release
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are out
CERT-EU puts the release at 13:30 UTC, half an hour before the announced time.
-
13:45 UTC Release
Debian ships fixed packages
Debian published DSA-6574-1 for its php8.4 packages.
-
Release
Ubuntu publishes USN-8948-1
Ubuntu published security notices USN-8948-1 and USN-8948-2 with fixed PHP packages. The notices give the date, not the time.
Source: Ubuntu USN-8948-1
-
Advisory
Government agencies issue alerts
CISA urged organisations to patch immediately, and told those that cannot update right away, or that run PHP 8.1 or older, to take PHP systems offline until they are patched.
Source: CISA alert
-
Reaction
Reuters lists websites taken offline
Reuters reported that governments and companies took websites offline over the PHP flaws, among them the Port of Rotterdam and, in Japan, the National Tax Agency. Japan's Finance Ministry partially suspended its online services.
Source: Reuters factbox (via Euronext)
How the world reacted
This was not a routine patch. Public agencies told organisations to act immediately.
- United States. CISA “strongly urges organizations to immediately patch” and said those that cannot update, or still run PHP 8.1 or older, should take PHP systems offline until they are patched. It also said it had not observed exploitation as of publication.
- United Kingdom. The NCSC encouraged UK organisations to take immediate action.
- European Union. CERT-EU advised organisations to patch immediately.
- Netherlands. The Dutch NCSC took its own website offline as a precaution before the release, and asked organisations to assess every internet-facing PHP system.
- Canada. The Cyber Centre told organisations to update immediately to a fixed, supported release.
- Japan. IPA published a pre-alert on 21 October and JPCERT/CC an alert on 22 October. Prime Minister Sanae Takaichi posted on X at 21:55 JST on 21 October, asking website operators to prepare for the patch. Nikkei reported the next day that she temporarily closed her own homepage.
Many organisations chose to go offline rather than wait. A Reuters factbox lists the Port of Rotterdam, the Dutch government portal Overheid.nl, the KNVB football association, German federal IT provider ITZBund, prefecture sites of France’s Interior Ministry, and Japan’s National Tax Agency. Reuters says Japan’s Finance Ministry partially suspended its online services. A Wikimedia spokesperson told Newsweek it had taken down a number of systems as a precaution until they could be patched.
Hosting companies moved too. Hostinger says it deployed ModSecurity rules before the fix and finished patching PHP on its non-VPS servers by 07:20 UTC on 22 October. Laravel says Laravel Cloud patched every running application, and tells Forge users to click “Update PHP”.
How many servers are exposed is hard to say. Censys counted 6,292,667 hosts running PHP on 21 October. That number covers all PHP hosts it can see, not only unpatched ones.
What to do if you run PHP
1. Update. Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. If you use your distribution’s packages, install its fix, for example USN-8948-1 on Ubuntu or DSA-6574-1 on Debian. Distributions often backport fixes, so the version number they show may not match the upstream one. Compare the package version with the one in the notice.
2. Restart the processes that serve requests. Running workers keep the old PHP in memory until they restart. Some packages restart PHP-FPM for you, others do not, so restart it yourself to be sure. If you use mod_php, restart Apache.
sudo systemctl restart php8.3-fpm3. Check what is really running. php -v shows the command line PHP only. Your site runs on FPM or the web server module. Check two things: the installed FPM version, and that the workers started after the upgrade.
php-fpm8.3 -v
systemctl status php8.3-fpmThe first command shows the version installed on disk. It shows the new version even if the old workers are still running, so it is not enough on its own. In the second, the “Active: since” time must be later than the moment you upgraded. Use the version you run in place of 8.3.
If you manage servers through a dashboard such as Laravel Forge, confirm on the server itself. A dashboard can show what it installed, not what your workers are running right now.
4. If you cannot update today, use the official workarounds, and treat them as temporary. PHP lists mitigations such as setting memory_limit=-1 through php_admin_value, a low post_max_size, size limits at the web server or proxy, and session.upload_progress.enabled=0 followed by a restart of every worker. In PHP’s own words, these “reduce exposure to specific attack paths but do not make an installation safe”. The release announcements say it more plainly: “There are no complete mitigations, updating is the only safe choice.”
5. Plan your way off PHP 8.1 and older. PHP 8.1 and older no longer receive updates from the PHP project. PHP published minimal source backports for 7.4, 8.0 and 8.1 for people who build from source, and some vendors offer their own backports. The lasting fix is a supported version.
How our team responded
BinarCode is a PHP-first company, so this advisory hit close to home.
Our team read the advisory on 21 October, the day it came out. The same day, we applied the official workarounds on the servers we look after. We upgraded PHP as soon as the patched builds and the Ubuntu packages were available, and finished the last remaining servers on the evening of 21 October. On 22 October we ran the final checks.
If your team runs PHP and wants a second pair of eyes on keeping it safe, we are happy to help.
Worth reading
- So, about the PHP security release by Nuno Maduro, creator of Pest and Larastan: what he did with his own apps when PHP2Shell dropped, the people who shipped the fix, and why you should build as if you are already going to get hacked.
Author
Eduard Lupacescu
Leads BinarCode's vision and growth, with over 12 years building software products and teams. Focused on turning client challenges across Western Europe, the US, and Israel into reliable, business-driven engineering outcomes.