Skip to content
ITLAB
ESEN

22 / 10 / 2026 · From the lab

PHP fixes two critical vulnerabilities: update now

PHP released patches for two critical remote code execution flaws (CVSS v4.0 9.2). Fixed versions, who is affected and what to do right away.

On 21 October 2026 the PHP project released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing two critical vulnerabilities that can allow unauthenticated remote code execution. Its advisory urges an immediate update and warns that there are no complete mitigations.

  • CVE-2026-109618 and CVE-2026-109619: CVSS v4.0 9.2 (critical) per PHP; NVD scores them 9.8 under CVSS v3.1. The weaknesses listed include use-after-free (CWE-416).
  • They affect every version below the fixed ones. Wiz Research, which publicized them as "PHP2Shell", states that versions from the last decade, back to 5.4, are affected.

Who is affected

It is common to assume that only Apache with mod_php is at risk. According to php.net, every installation serving web requests is at risk, including PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest for mod_php, with an attack demonstrated before any application code runs, and one of the GitHub advisories reports remote code execution validated against FPM as well under certain conditions.

PHP 7.4, 8.0 and 8.1 no longer receive updates; the security team published minimal source backports and some distributors ship their own packages. PHP 8.2 stops receiving security fixes on 31 December 2026.

Exploitation status

CISA stated on 21 October that it had not observed exploitation. The PHP Foundation reports that proofs of concept circulated after a leak, with no functional exploits identified at the time of disclosure. As of 22 October 2026 (date checked), the CVEs are not in CISA's KEV catalog and we found no reliable reports of exploitation.

How it was handled

It is common to credit the discovery to Wiz alone. According to the PHP Foundation, Calif and OpenAI privately reported the root cause on 11 August and Wiz contributed further vectors on 24 August. A frequent reading is that the patch arrived quickly; the Foundation acknowledges that the underlying problem was spotted in a 2024 audit, without a concrete exploitation path, and calls the delay "a structural failure" caused by its decision process and lack of resources.

It is also common to assume that the one-day advance notice was planned. According to the Foundation, on 20 October around 15:00 UTC the CVE IDs began circulating online without technical details; PHP brought its pre-announcement forward (19:30 UTC) and moved the release from 22 to 21 October at 14:00 UTC, because distributors were still packaging the fix. One distributor also broke the embargo hours early. We found no other pre-announcement of a security release in the php.net archive (2019 to 2026): this was an exceptional measure.

Wiz says it used AI (Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol). The fixes were written by the PHP security team, with developers funded by the PHP Foundation.

What to do now

  1. Take inventory of systems running PHP, including software that embeds it.
  2. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to the fixed distribution package, starting with internet-facing systems, and restart all PHP processes.
  3. If you cannot update immediately, or run PHP 8.1 or older: CISA recommends taking those systems offline until they are updated. The interim measures on php.net reduce exposure but do not make an installation safe; according to CISA, a web application firewall may provide some protection.
  4. Managed hosting: confirm the version and update date with the provider.
  5. Monitor: watch for PHP processes launching command shells or downloading tools, and retain the logs.

IT Lab's view

IT Lab updated its servers after the patches were released, without incidents. Patching on time requires an inventory and procedures before the advisory.

Coordinated disclosure essentially worked: private reports, patches for every supported branch, backports for older ones and distributors with the fix in advance. It was not flawless: the root cause had been known since 2024, there was a leak and the embargo was broken. We value the Foundation's transparency in acknowledging this.

Wiz credits AI with part of the discovery of a flaw present for years. If that trend holds, more vulnerabilities will be found, faster; the difference will lie in each organization's ability to update promptly.

In IT Lab's judgment, this episode does not by itself justify switching platforms. Many institutions run open-source software built on PHP, such as WordPress and Drupal; Drupal.org states that "more than 150 governments" use it. No language is free of serious vulnerabilities, and ecosystems with long dependency chains, such as JavaScript's, carry their own risks. Migrating moves the risk; reducing it requires inventory, timely updates and monitoring.

Frequently asked questions

My site runs WordPress or Drupal. Is it affected? If the server runs PHP below the fixed versions, yes. Updating the CMS does not fix the flaw.

Is changing the configuration enough? No. The advisories state that updating is the only complete mitigation.

I use PHP-FPM. Am I safe? No. php.net lists FPM among the installations at risk.

Is it being actively exploited? As of 22 October 2026 there are no reliable reports, but proofs of concept are circulating. It is prudent to act as if exploitation were imminent.

What about PHP 7.4, 8.0 or 8.1? Unsupported: plan a migration.

This note will be updated if the official recommendations or the exploitation status change.

IT Lab provides patch management and exposure reviews for organizations in Chile: version inventory, coordinated updates and post-update checks. Let's talk.

Sources

Do you need someone to take care of your technology?

Tell us what you need to organize, protect or solve. The first conversation has no cost: we assess whether our model fits you and what the next steps would be.

Let's talk about your business