Last updated: October 23, 2026, 9:05 a.m. New York time. This is a developing story. We'll update this article as more details come out.

The PHP team just shipped PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. They fix two critical vulnerabilities that can let an attacker run code on your server without logging in. Both are rated 9.2 on CVSS v4.0. If PHP serves web requests for you, update now.

The PHP team doesn't usually announce a release ahead of time so a heads-up a day before, with two scores this high, means you should be ready to update as soon as possible.

Who Is at Risk

Here is how the security advisory on php.net puts it:

Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.

Every supported branch is affected. If you're on anything older than these versions, you need to update:

Branch Fixed in
PHP 8.5 8.5.12
PHP 8.4 8.4.27
PHP 8.3 8.3.36
PHP 8.2 8.2.35

On mod_php, the attack happens before PHP hands the request to your code. That means nothing in your app, like framework middleware or input validation, can stop it.

The Two Vulnerabilities

RCE via OOM Corruption (CVE-2026-109618)

When PHP runs out of memory mid-request, it jumps straight out of whatever it was doing to abort the request. If that happens while PHP is still setting up the request's internal data, the cleanup step that runs afterward can treat that half-built data as valid.

The advisory lists several ways an attacker can force that out-of-memory error with a crafted multipart request, the format browsers use for form posts and file uploads. The researchers confirmed full remote code execution over HTTP against Apache mod_php "with default PHP input and memory limits and normal prefork configurations with multiple workers." The advisory says source analysis shows FPM is also susceptible, "though no complete FPM exploit has been demonstrated for this SAPI." The PHP Foundation's write-up goes further and says RCE was also confirmed on PHP-FPM through application-level code paths.

Advisory: GHSA-w8hw-w9fx-j79w

RCE via Stale Global State (CVE-2026-109619)

A PHP worker handles many requests in a row. Some of the state it keeps between requests, such as error, session, and extension state, can point at memory that belonged to an earlier request. If a request ends in a fatal error, that memory can get freed while the worker still holds the pointer. The next request on the same worker can then use the stale pointer before PHP resets it.

The advisory confirms two ways in:

  • Fatal error backtraces on PHP 8.5. With fatal_error_backtraces enabled, the backtrace from a fatal error is stored this way. The advisory calls this "the strongest demonstrated case" and says it's the basis of the confirmed mod_php exploit.
  • Session upload progress. The advisory notes that it "is enabled by default, and no application call to session_start() is required." It was confirmed against both mod_php and FPM.

The PHP Foundation says the reporter also demonstrated RCE against a real-world application on Apache with mod_php.

Hiding errors doesn't help. The advisory says "Changing error_reporting, using @, or disabling display_errors or log_errors does not protect against this vulnerability."

Advisory: GHSA-6wmf-4rv5-p3rp

What CVSS v4.0 9.2 Means

CVSS is the Common Vulnerability Scoring System, a standard way to rate how serious a security bug is. FIRST, a global group of security response teams, maintains it. Version 4.0 is the current edition, published in November 2023.

Every bug gets a score from 0 to 10, and the score falls into a severity band:

  • Critical: 9.0 to 10.0
  • High: 7.0 to 8.9
  • Medium: 4.0 to 6.9
  • Low: 0.1 to 3.9

Both advisories carry the same vector, CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H. In plain terms:

  • An attacker can reach the bug over the network (AV:N)
  • They don't need an account (PR:N), and nobody has to click anything (UI:N)
  • Pulling it off is hard, and it depends on conditions on the target, like the PHP build and memory layout (AC:H, AT:P)
  • If it works, the impact on the server's confidentiality, integrity, and availability is high (VC:H/VI:H/VA:H)

For comparison, the worst bug in PHP 8.5.11, the SOAP server crash, was rated high.

How to Update

  • Distribution packages. The PHP team says Linux distributions and LTS vendors got the patches in advance, so check your vendor for updated packages.
  • Building from source. Grab the source downloads. Windows source and binaries are on the Windows downloads page.
  • Docker. If you build on an official php image, rebuild and redeploy once the new tags are up. A restart alone keeps the old binary.
  • Remi's repository. The notice urges people who rely on the volunteer-run rpms.remirepo.net to switch to distribution packages or build from source for now. It says "The repo will not have updates today."
  • Restart every worker. FPM pools, Apache, and any long-running workers keep the old code in memory until they restart.

PHP 8.1 and older no longer get fixes from the PHP project. Given how bad these are, the security team published minimal source backports for PHP 7.4, PHP 8.0, and PHP 8.1 for people who build from source or don't have an LTS vendor. Otherwise, check with your vendor or move to a supported version.

PHP 8.2 reaches end of life on December 31, 2026, and gets no security fixes after that date.

If You Can't Update Yet

The release notes are clear that "There are no complete mitigations, updating is the only safe choice." The advisory lists settings that block the confirmed attack paths, but it says they "do not make an installation safe." Use them only to buy time.

For the OOM bug (CVE-2026-109618):

  • Set memory_limit=-1 somewhere apps can't override it, like php_admin_value in the FPM pool or Apache config. Check that no pool, directory, or app setting puts a finite limit back.
  • Lower post_max_size: 8M if you don't need file uploads, 32M if you do. Keep upload_max_filesize below it. Consider request size and count limits at the web server or proxy too.
  • Use a container or cgroup memory limit, ideally one that kills only the affected worker. Don't use RLIMIT_AS or RLIMIT_DATA, because they trigger the vulnerable path.

For the stale state bug (CVE-2026-109619):

  • Set session.upload_progress.enabled=0 in php.ini, the FPM pool, or the server config, then restart every worker. ini_set() and .user.ini files apply too late to help.
  • On PHP 8.5, set fatal_error_backtraces=0 and restart every worker.
  • Remove invalid or deprecated per-request settings that print warnings before the request starts, and fix fatal errors and timeouts an attacker can trigger.

The full advisory has the exact wording for each of these.

What We Don't Know Yet

Here is a list of things we don't know:

  • Whether either bug is being exploited in the wild. The release notes don't say, but the assumption is it will be. The PHP Foundation says the security team inspected the proofs of concept circulating before the release and "did not identify any functional exploits at the time of release/public disclosure."
  • When official Docker images and individual distributions will have the fixed builds

Timeline

The early entries come from the PHP Foundation's account. Times are UTC.

  • 2024: While fixing a finding from PHP's external security audit, a Foundation-contracted core developer spots the first signs of the out-of-memory bug. No concrete exploit is found, and the fix stalls.
  • August 11, 2026: Calif and OpenAI report an RCE with the same root cause. Fixing it becomes the security team's top priority.
  • August 24, 2026: Wiz reports the bugs.
  • September 18, 2026: OpenAI reports more ways to trigger it.
  • October 20, around 15:00: The two CVE IDs start circulating on forums and social media, with a wrong release time and a wrong CVSS score of 10.0. No technical details leak.
  • October 20, 19:30: The PHP security team posts advance notice and moves the release up a day, from October 22 to October 21 at 14:00 UTC.
  • October 20, around 20:00: Calif mistakenly publishes a video of its proof of concept, and copies spread on social media.
  • October 21, 07:41: Chainguard publishes container images with the fix, more than six hours before the coordinated release.
  • October 21, 2026: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 ship, along with the two advisories.

Read More

Updates

  • October 21, 2026: The PHP team released the fixes. Added the fixed versions, CVE IDs, what each bug does, who is at risk, how to update, and the interim mitigations.
  • October 21, 2026: Added details from the PHP Foundation's account: confirmed RCE on PHP-FPM, why the release moved up a day, the leak timeline, and the security team's finding that no working exploits were circulating at release. Removed a line saying the release went out ahead of schedule, which we couldn't confirm.
  • October 23, 2026: The PHP security team now suggests keeping session.upload_progress.enabled=0 until the next regular bugfix release, to block a rare RCE path tracked as CVE-2026-115560. If you already set it, keep it in place. Read our article on the advisory.