Two critical PHP bugs leaked. Here is what happened and what you should do

Two dangerous flaws in PHP let an attacker run their own commands on a web server without logging in. The details leaked a day before the planned release. Here is what happened, how the attack works, and what you should do.

PHP powers a very large part of the internet. According to W3Techs, about 69.3% of websites with a known server language use it. That includes WordPress, so millions of small business sites, blogs and online shops are involved.

Two critical PHP bugs leaked

It started with one post on Hacker News on 20 October at 15:20 UTC. The writer claimed two PHP bugs with the top danger score were about to be announced, and his only proof was a vague source. Security experts confirmed within hours that the bugs were real. By the next day, the FBI was telling companies to take servers offline if they could not update.

The original Hacker News post of 20 October 2026 that first warned about the two bugs. Source: news.ycombinator.com, item 50167754. 

Post by the FBI Cyber Division (@FBICyberDiv) on X, 21 October 2026, advising organisations to take systems offline if they cannot update right away. Source: @FBICyberDiv on X. 

Hacker News Post Claims PHP Vulnerabilities Without Verified Evidence

Post by the FBI Cyber Division (@FBICyberDiv) on X, 21 October 2026, advising organisations to take systems offline if they cannot update right away. Source: @FBICyberDiv on X.

What the two bugs are

A web server uses PHP workers. A worker takes a visitor’s request, builds the page, cleans up, and then waits for the next visitor. One worker handles many visitors one after another. Both bugs happen when this routine goes wrong.

PHP has a memory limit. When a request hits an error it cannot recover from, PHP stops that job at once and jumps out. Researchers found that PHP does not always tidy up properly when it does this. Some leftover data stays behind, and the next request can use it. Attackers can shape that leftover data to take control.

CVE-2026-109618: running out of memory

When a request uses up all of PHP’s memory at exactly the wrong moment, PHP stops halfway through setting something up. Later, the cleanup step reads that half-finished data as if it were fine. Researchers found several ways to cause this reliably. It was reported by Calif, Wiz, OpenAI, and Quarkslab.

CVE-2026-109619: leftover data after a fatal error

When PHP hits a fatal error, it also stops the job suddenly. Some internal pointers still point at memory that has already been released. A later request can then use this invalid information. It was reported by Wiz, Calif, and OpenAI.

How serious are they?

PHP Critical Vulnerabilities and High Risk for Apache mod_php

• Both score 9.2 out of 10 (Critical) on the CVSS v4.0 scale. The US National Vulnerability Database shows 9.8 on the older scale.
• No login and no user action are needed.
• Both are filed under CWE-824, which means using a pointer that was never properly set up.
• Researchers believe the problem goes back to PHP 5.4.0, though not every version has been tested.
• PHP says the risk is highest on Apache with mod_php. The second bug was also confirmed on PHP-FPM.
• Any code the attacker runs has the same permissions as the PHP process. That is not automatically full control of the machine, but it is enough to steal data and attack further.

PHP Vulnerabilities Affect Versions Dating Back to PHP 5.4

Fixed versions. See the official PHP changelog for the final list.

Not sure if your website is affected?

If you do not know which PHP version your site runs, the team at Code and Core can check your hosting or server setup, tell you whether you are exposed, and plan the update with you. PHP backend development and looking after existing projects are core services at Code and Core.

Contact Code and Core and tell us about your setup. We will help you from there.

How an attack works

The key point is that the weakness is in PHP, not in the website’s own code. Imperva’s researchers say even a page that only prints “OK” can be affected, because the risky work happens before any website code runs.

The main trigger is a PHP feature called session upload progress. It tracks file uploads while PHP reads the upload request. An attacker can send a specially built upload request that makes PHP run out of memory in the middle of this work. This leaves messy leftover data behind.

Good news: it is not easy

Imperva points out that the attack is hard to finish. Causing the problem is simple, but turning it into running commands is not. The attacker’s later request must reach the same worker and place carefully shaped data in just the right spot. If the timing is off, the worker usually just crashes or answers normally. That does not make the bugs safe to ignore, because skilled attackers can repeat the attempt.

The five attack methods researchers showed

Imperva describes five different ways to abuse these flaws. Three of them use the upload progress feature as the trigger.

• Session decoder leftover data. A huge session is built, memory runs out while it is read, and the next request on the same worker uses freed memory. Result: the worker crashes.
• OPcache stale class entry. OPcache is PHP’s speed-up cache. A memory failure leaves a half-used slot behind, and attackers can use it to point a file operation at a file they choose. Result: they can read files the PHP process is allowed to read, such as configuration files, database passwords, and API keys.
• Stale session module pointer. A pointer still refers to freed memory, and later use of it crashes the worker.
• Stale session ID pointer. PHP is tricked into treating random memory as a very long text value and sends about 67 KB of it back in a Set-Cookie: PHPSESSID header. Result: part of the server’s memory leaks out.
• Fatal error backtrace. If detailed error backtraces are turned on, a fatal error can touch freed memory while writing that backtrace. Result: a crash. This one does not use the upload feature.

Put together, these show how invalid leftover data can lead to full remote code execution, not just crashes or leaks.

Why it took so long to find

The weakness is old. Calif traces the first memory-limit bug of this kind in PHP back to 2004. The PHP Foundation says an outside audit in 2024 gave one of its developers early signs of this same problem, but nobody could show a real attack, so the fix stalled. The foundation calls that delay a structural failure.

AI changed the picture in 2026. On 11 August, Ryan Austin at Calif reported a working remote code execution, and OpenAI reported the same root cause on the same day. OpenAI says Calif found it using GPT-5.6 Soul through its Patch the Planet programme. Wiz sent more attack routes on 24 August, using Wiz Atlas, Gemini 4 Argon and GPT-5.6 Soul. A Wiz researcher wrote on X that, as expected in 2026, AI did most of the work.

AI-Assisted Research Uncovers Critical PHP Security Vulnerabilities

The PHP Foundation also says its security team has published 15 CVEs since 1 July and checked more than 100 other reports that were invalid, duplicates, or could not be reproduced.

How the leak happened

PHP planned a calm release on 22 October. The leak changed that. All times are UTC.

PHP planned a calm release on 22 October. The leak changed that. All times are UTC.

• 20 Oct, 3:20 PM
  The Hacker News post appears with the wrong date, the wrong score, and no details. The poster later said his source misled him about whether the bugs were under coordinated disclosure.

Hacker News Post Contains Incorrect Dates, CVSS Scores and Missing Technical Details

Hacker News Source Admits to Misleading the Poster About Coordinated Disclosure

• 20 Oct, 4:39 PM
  Security researcher Kevin Beaumont flags the leak on Mastodon.

Kevin Beaumont Reports Leaked PHP Zero-Day Vulnerabilities

• 20 Oct, 6:26 PM
  Watchtower confirms the bugs are real.

WatchTowr Confirms PHP Zero-Day Vulnerabilities and Warns of Early Disclosure

• 20 Oct, 7:33 PM
  PHP sends its official notice and moves the release to 21 October at 14:00.

Official PHP Announcement of an Upcoming Critical Security Release

PHP Security Release Rescheduled to 21 October 2026

PHP Foundation Announces Security Release Reaching 5.4 Million Views

• 20 Oct, about 8:00 PM
  The PHP Foundation says Calif accidentally published a proof-of-concept video. It was deleted, but copies spread.

Calf Accidentally Publishes PHP Vulnerability Proof-of-Concept Video

• 21 Oct, 03:03 AM
  Cloudflare turns on protection rules for all customers, including the free plan.

Cloudflare Deploys Emergency WAF Rules Ahead of PHP Vulnerability Disclosure

• 21 Oct, 07:41 AM
  The PHP Foundation says Chainguard published patched builds over six hours early, which let anyone study the fix.

Chainguard Breaks PHP Security Embargo by Publishing Patched Builds Early

• 21 Oct, about 2:00 PM
  The official patches are released.

Some organisations acted before the release. The German host Uberspace switched PHP off on all its servers. International Cyber Digest reported that a Dutch platform serving more than 100 local governments took council websites offline.

UberSpace temporarily took all servers offline due to a PHP security vulnerability, highlighting the importance of server security and timely software updates.

Attackers are exploiting PHP vulnerabilities before patches are released, forcing websites offline.

Are attackers using it yet?

It depends on who you ask.

• Watchtower says its decoy servers see active attack attempts.
• Cloudflare’s CTO said early attacks were starting, and called Cloudflare’s rules only a stopgap.

Cloudflare blocks early PHP attacks with temporary WAF rules until an official patch is released.

• Patchstack saw probing but no proof of break-ins as of 13:57 UTC on 21 October.

Patchstack detected probing attacks, with no confirmed breaches yet

• Imperva was told about the bugs before the public announcement and watched customer traffic. It saw nothing matching the known exploit patterns during that period.
• CISA lists exploitation as “None,” and neither bug is on its known exploited list yet.
• PHP’s team knew of no working public exploit when it released the fix.

Why stay careful

Earlier PHP bugs were abused soon after they became public. CVE-2024-4577 and CVE-2019-11043 are both on CISA’s known exploited list, and CISA says both were used in ransomware attacks.

Worried your site may already have been probed?

We can go through your server logs for the warning signs listed later in this post, such as PHP out-of-memory errors and unusual upload requests. If we find anything, we will help you clean up and secure the site.

Contact us and tell us about your setup. We will help you from there.

What hosting companies said

On shared hosting, you cannot update PHP yourself. PHP core developer Gina Peter Banyard wrote on Mastodon that hosting companies should be the ones handling this. WordPress said the same: no WordPress update is needed, and site owners should confirm their host’s plan.

WordPress security updates start with your hosting provider.

Two critical PHP vulnerabilities fixed, check your hosting provider’s update plan.

• Hostinger posted on X at 16:25 UTC on 21 October that it tested the bugs on live servers and they cannot be used to take over sites it hosts, WordPress included. It is still applying PHP’s fix to all hosting and says customers need to do nothing. This is Hostinger’s own claim. When this post was written, its status page and blog had no notice.

Hostinger says no action is needed as it rolls out PHP security fixes across its servers.

• The “142,401 Hostinger hosts” number going around comes from Mallory, using Shodan data from 20 October. Mallory’s own chart says it counts all PHP hosts on those networks, patched or not. It does not show how many are unpatched.

Amazon and Hostinger lead in PHP hosting numbers, highlighting the scale of the security update.

• SiteGround and DreamHost said protections were in place. Namecheap said it was installing patches.

SiteGround and DreamHost confirm PHP vulnerability protections are in place.

• cPanel released the fix for PHP 8.2 to 8.5 and backported it to its older 7.4, 8.0, and 8.1 packages.

cPanel updates PHP security patches to fix critical vulnerabilities. Keep your servers secure!

A VPS is different. Hostinger’s own page says that on a regular VPS, the customer looks after everything, security updates included.

Running a VPS or your own server?

The update is your job, and it can feel risky when a live site depends on it. At Code and Core, we can update PHP for you, test that your site still works afterwards, and set up regular maintenance so the next security fix does not catch you off guard.

Contact Code and Core and tell us about your setup. We will help you from there.

What you should do

On shared hosting

• Check your PHP version in your host’s control panel. On Hostinger, it is under PHP Info in the website dashboard, where only versions 8.2 to 8.5 can be chosen.

Hostinger now supports PHP 8.2–8.5! Upgrade for better security.

• If you use PHP 8.1 or older, the PHP project does not issue updates for those branches. Small source backports exist for 7.4, 8.0, and 8.1, but they are mainly for people who build PHP themselves. Move to a supported version.

PHP 8.1 release date and version information.

• Ask your host in writing what they have patched and when.

On WordPress

• Go to Tools, then Site Health, then Info, then Server to see your PHP version. The WordPress guide explains this screen.

Check your PHP version in WordPress Site Health settings.

• Remember that updating WordPress, Laravel or plugins does not fix this.

Patched PHP versions and why WordPress, Laravel, or plugins alone cannot fix the vulnerability.

On your own server

• Install the fixed PHP from your Linux distribution or vendor.
• Do not trust the version number alone. Red Hat and Ubuntu say packages often include the fix but keep an old-looking number. Read your distribution’s security notice, such as Red Hat’s or Ubuntu’s.
• A firewall rule from Cloudflare or your host buys time. Cloudflare’s CEO called it a strong Band-Aid, not a cure.

Cloudflare’s CEO called it a strong Band-Aid, not a cure.

• If you cannot update at all, the UK’s NCSC and the FBI say to consider taking the system offline until it is fixed.

Temporary steps if you cannot patch today

Imperva suggests these short-term measures. They reduce risk but are not a complete fix for either bug. Test them first, because they can affect your site’s speed and features.

• Add opcache. enable = 0 in your active php.ini file. This turns off OPcache.
• Add session.upload_progress.enabled = 0. This removes the trigger used in three of the five attack methods.
• Check whether detailed fatal-error backtraces are turned on and follow the official guidance.
• Limit who can reach the affected service until you can update.
• Give the PHP process only the files, passwords, and services it really needs, so a break-in does less damage.

Signs of an attack to look for

• Very large upload requests, or requests with an unusually high number of form fields.
• Strange session-related values in requests.
• Unusually long PHPSESSID values in server responses.
• PHP out-of-memory errors or repeated worker crashes that line up with odd requests.

If you think you were attacked, check for code execution as well as stolen data. Look for unexpected child processes, changed application files, new ways for the attacker to return, unusual outgoing connections, and passwords that may have been exposed.

Need help with any of this?

If you are dealing with this problem and are not sure how to check your PHP version, cannot update your server yourself, or want your site checked for signs of an attack, please contact us at Code and Core. We will look at your setup and tell you clearly what to do next.

Contact Code and Core and tell us about your setup. We will help you from there.

Sources

Imperva Threat Research, “PHP2Shell: When PHP Runs Out of Memory at the Wrong Moment”, 21 October 2026:Imperva blog
PHP changelog:php.net/ChangeLog-8.php
PHP supported versions:php.net/supported-versions.php
PHP usage share:W3Techs
Bug records:CVE-2026-109618,CVE-2026-109619
Known exploited list:CISA KEV catalog
Earlier exploited PHP bugs:CVE-2024-4577,CVE-2019-11043
Imperva WAF release notes:Gateway 14.7,Gateway 15.5,Elastic WAF 2.2.1
Hostinger statement:@hostinger on X
WordPress PHP version check:Site Health screen
Distribution advisories:Red Hat,Ubuntu

Frequently asked questions