The PHP Foundation has released emergency security updates for two critical vulnerabilities that could expose web-facing PHP systems to dangerous remote control by attackers. The flaws, identified as CVE-2026-109618 and CVE-2026-109619, affect PHP installations that serve web requests, according to the Foundation’s alerts.
Security specialists described the situation as urgent because PHP is deeply embedded in internet infrastructure. The language underpins a large number of websites and software systems, including publishing platforms such as WordPress and Drupal and e-commerce software including Adobe’s Magento. A serious weakness in a widely deployed web layer can leave organizations vulnerable even when the affected server is not a visible part of their technology estate.
A broad exposure across PHP’s history
The vulnerabilities reach back to PHP 5, which was released in July 2004, according to the reporting. That long time span is a particular concern for administrators: old PHP installations can remain in production, be inherited through legacy applications, or persist in infrastructure that has received little recent attention.
Only PHP 8.2 and newer are currently supported and will receive patches from the PHP project. The Foundation noted that some distributions and third-party vendors continue to produce fixes for older releases. That distinction places extra pressure on organizations running legacy environments. They need to establish not only whether PHP is present, but also which version is deployed, who supplies it and whether a usable update is available.
The Foundation’s guidance is unusually direct: updating is the only safe choice. It said there are no complete mitigations. In practical terms, teams should not treat configuration changes or perimeter defenses as substitutes for deploying the appropriate security update where it is available.
Why web administrators are moving quickly
Reports of the flaws arrived alongside warnings that attackers could move rapidly. Cloudflare said it was seeing early attacks emerge before the Foundation had published vulnerability details and fixes. Security firm Sansec expected mass attacks to begin within minutes of release.
That timing matters. Public disclosure of a critical web vulnerability can accelerate exploitation because attackers and defenders receive the same information at roughly the same moment. Defenders must identify affected systems, test and apply patches, and check that services return safely. Attackers need only find an exposed installation that has not yet been updated.
The potential consequences are especially severe where PHP is used to handle incoming web requests. The reported concern is that exploitation could allow attackers to gain remote control of victim systems. Once an attacker gains that kind of foothold, the incident may extend beyond the original application, depending on the system’s configuration and the privileges available to the compromised process.
Legacy systems are the difficult edge case
PHP’s age and broad adoption make forgotten installations a central risk. An organization may have modernized its main public site while retaining an older application, administration tool, support portal or vendor-managed component elsewhere in its environment. Those systems may still process web requests and may not be covered by ordinary update cycles.
The problem is not limited to a particular type of organization. PHP is used across publishing, commerce and general-purpose web development, so affected deployments can be found in many sectors. The relevant question for administrators is not whether their primary product was written in PHP, but whether any internet-facing or internally exposed service relies on it.
Unsupported versions demand special attention. The availability of patches from some distributions or vendors does not guarantee that every legacy installation has a fix. Where an update path is uncertain, organizations need to determine the version and supplier rather than assume that the existence of an upstream advisory automatically resolves their exposure.
Patch first, then verify
The immediate response is to apply the available security update to supported PHP installations and to pursue vendor or distribution fixes for older deployments. Because the Foundation says complete mitigations do not exist, postponing updates leaves a residual risk that other compensating controls cannot fully remove.
Organizations should also verify their inventories after patching. Public-facing services, content-management systems, e-commerce stacks and less prominent web applications all merit review. The objective is to find the systems that are easy to overlook, not merely the servers already known to be centrally managed.
The episode is a reminder that foundational software can create systemic risk when a critical weakness appears. PHP’s usefulness has made it a durable part of the web, but that durability also means old deployments can outlive the processes meant to secure them. With early attacks already reported and experts anticipating wider exploitation, the safest course is the one the PHP Foundation set out: update affected systems as quickly as possible.
This article is based on reporting by Wired. Read the original article.
Originally published on wired.com
