PHP Patches Address Critical Flaws Affecting Web Request Installations

Two critical PHP vulnerabilities put a widely deployed web technology under immediate patching pressure. The flaws can let unauthenticated attackers execute code on affected servers or read sensitive data from process memory, according to research from Wiz. The PHP Foundation says there are no complete mitigations: updating is the only safe choice.

The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, affect PHP installations that serve web requests, including systems running versions as far back as PHP 5, released in July 2004. The Foundation’s security advisories are available for CVE-2026-109618 and for CVE-2026-109619. Patches are available for PHP 8.2 and later, the versions still supported by the project. Some distributions and third-party vendors may also issue fixes for older versions, but that support varies.

Why the flaws are hard to contain

PHP runs server-side code for a large share of the web. Its ecosystem includes publishing tools such as WordPress and Drupal, as well as e-commerce software such as Adobe Magento. That breadth means one weakness in a shared component can reach many organizations, including teams that may not know a legacy service still depends on PHP.

Security consultant Lukasz Olejnik described the potential reach as enormous, with millions of systems possibly affected. He warned that rapid exploitation could lead to wormable malware: malicious software able to spread from one vulnerable system to others. That outcome is a risk he raised, not a confirmed result of these flaws.

Wiz’s research describes a path to remote code execution and access to process memory. Data held there may include passwords, authentication tokens, API keys and certificates associated with other requests or the server itself. The exact exposure will depend on the affected application and the information present in memory, but the possibility makes the flaws relevant to both server control and data confidentiality.

Longtime security consultant Davi Ottenheimer characterized the issue as involving a file upload interface. His description points to a practical concern: if an attacker can send a crafted upload to a reachable vulnerable service, they may not need to identify the site’s underlying software first. In practice, whether a particular system can be reached through that route depends on how it is configured and exposed.

Attacks were reported before patch availability

Cloudflare said it was seeing early attacks before the PHP Foundation published the vulnerability details and fixes. Security firm Sansec had also predicted that attacks could begin quickly after the updates became available. Reports described the patched versions as arriving just before 10 a.m. ET on Wednesday.

Some organizations took websites offline as a precaution while waiting for the updates. Reports described inaccessible sites belonging to the Finnish National Land Survey, French public services and the Port of Rotterdam. Temporary shutdowns can limit exposure, but they also interrupt service; teams need to weigh that cost against the time required to identify and patch each affected system.

The PHP Foundation had issued an advance warning on October 20, saying both flaws had a critical CVSS score of 9.2 out of 10. It withheld technical details ahead of the fixes and said it could publish earlier if details became public or active exploitation emerged. Accounts from Bleeping Computer and Ars Technica said some information may have leaked before the planned disclosure. The warning gave administrators time to prepare, though it offered limited detail for identifying affected systems in advance.

AI aided discovery, while patching remains the task

Wiz said its researchers used AI tools in part to discover the vulnerabilities. OpenAI and security firm Calif separately said they found the issues and worked together. Wiz named its exploitation demonstration “php2shell” and reported that exploitation could be fairly easy in some cases. The companies’ accounts describe discovery and research; they don’t establish that every PHP deployment is equally exposed or that exploitation will succeed in every configuration.

AI-assisted discovery adds urgency to a familiar operational problem: defenders may have little time between the public disclosure of a flaw and attempts to exploit it. Olejnik argued that AI makes quick action especially important. The practical response still begins with knowing where PHP runs, including in older services and software supplied by other vendors.

Administrators should inventory PHP versions across their infrastructure, prioritize internet-accessible systems and apply the available updates. They also need to check for notices from software providers, since an application may bundle or depend on PHP without making that dependency obvious to its operators. Teams should monitor relevant systems for signs of exploitation while patching.

For installations that cannot be updated promptly, taking the affected service offline can reduce exposure until remediation is possible. If a system shows signs of compromise, isolating it and preserving web server and PHP logs can help establish what happened. The central operational question is now whether an organization can find every exposed PHP instance and bring it onto a patched release before attackers reach it.

PHP’s long history is part of the challenge: old installations may remain embedded in services long after their original maintainers have moved on. Teams should treat the update as an inventory and dependency check as well as a version change, and confirm that each internet-facing system is running a fixed release.