PHP Patches Address Critical Flaws Affecting Web Facing Installations

PHP’s latest security fixes address two critical flaws with an unusually broad potential reach: the vulnerabilities affect web request handling across PHP installations dating back to version 5. Only PHP 8.2 and later remain supported by the PHP project, so older deployments may depend on fixes from their distributor or another vendor. For teams managing long lived web services, finding every copy of PHP is likely to be as important as installing the patch.

The PHP Foundation identified the vulnerabilities as CVE-2026-109618 and CVE-2026-109619. Its advisories describe both as critical and say there are no complete mitigations: updating is the safe response. The Foundation rated each flaw 9.2 out of 10 on the Common Vulnerability Scoring System before publishing technical details. It had announced the forthcoming fixes on October 20, then released the updates on Wednesday, just before 10 am ET.

Why the exposure could spread

The reported effects include unauthenticated code execution on affected servers and access to sensitive process memory. According to Wiz’s research, that memory could contain passwords, authentication tokens, API keys, or certificates associated with other requests or the server. The researchers named their proof of concept php2shell and said exploitation could be fairly easy in some cases.

Independent security consultant Lukasz Olejnik described the reach as potentially enormous, given PHP’s role in websites and software built with systems such as WordPress, Drupal, and Adobe Magento. He warned that rapid exploitation could lead to wormable malware spreading across many systems. That outcome is a risk he raised, not a confirmed description of what has happened.

Cloudflare reported early attack activity before the PHP Foundation published its full advisories. Sansec predicted that large scale attacks could begin soon after the patches appeared. Those reports make response timing a practical concern: internet reachable servers may face probing before every operator has identified its PHP version and completed an update.

Security consultant Davi Ottenheimer compared the affected upload interface to an unlocked front door, arguing that a crafted upload could be sent to servers without first identifying the site or its software. The source material does not establish that every PHP installation is exploitable through an upload, so teams should use the vendor’s technical advisories to determine applicability to their particular configuration.

Inventory and patching are the immediate work

PHP’s long history complicates response. The flaws reach back to version 5, released in July 2004, but the PHP project currently supports only version 8.2 and newer. Some distributions and third party vendors still issue fixes for older versions; operators need to check those channels rather than assume that an unsupported version will receive an upstream patch.

A useful first step is to locate PHP across production servers, hosted applications, containers, development environments, and software bundles maintained by vendors. Prioritize systems that accept web requests from the internet, then match their versions and deployment details against the relevant advisories. Applying a patched PHP release may also require coordination with application owners or service providers, particularly where PHP is embedded in a larger product.

Before the fixes became available, some organizations took websites offline as a precaution. The PHP Foundation’s position is that there is no complete workaround, which makes patching the central remediation. Where an update cannot be applied promptly, the UK National Cyber Security Centre advised organizations to consider taking affected systems offline until remediation is possible. That choice has an availability cost, but leaving a potentially exposed service online also carries risk.

AI may change the response window

The discovery process involved several research groups. Wiz said its researchers used AI tools in part to identify the vulnerabilities; OpenAI and security firm Calif also said they independently found the issues and worked together. Olejnik argued that AI can make quick exploitation more likely. The reports support close attention to the speed of disclosure and attack activity, but they do not quantify how much AI shortened either process.

The PHP Foundation had given advance notice of the upcoming fixes without initially naming affected versions or describing the flaws. It said it could release the patches early if details became public or active exploitation emerged. Reports from BleepingComputer and Ars Technica said some information may have surfaced before the planned publication.

Teams should keep watching for updates from PHP distributors and vendors whose products include PHP, since a server level patch may not cover every bundled deployment. If monitoring shows signs of compromise, preserve relevant web server and PHP logs while isolating the affected system, so responders can investigate what happened. The practical measure of readiness now is simple: know where PHP runs, establish which systems are exposed, and verify that each one receives an applicable fix.