The PHP Patch Needs Someone Authorized to Install It

The PHP Foundation disclosed two critical vulnerabilities on October 21, and PHP developers released fixes that morning, Wired reports. Reuters also reported that websites had been taken offline over PHP risks. The emergency concerns software running across the web, including the foundations of publishing and commerce systems.

According to the foundation’s alert quoted by Wired, CVE-2026-109618 and CVE-2026-109619 affect “all PHP installations serving web requests” going back to PHP 5. Only PHP 8.2 and newer receive supported upstream patches, although some distributions and third-party vendors supply legacy fixes. The advisory’s operational instruction is unusually plain: “There are no complete mitigations, updating is the only safe choice.”

Exposure is not proof of compromise. Cloudflare told Wired it was seeing early attacks, but that report does not establish that every vulnerable website suffered an intrusion. Nor does a website going offline establish that attackers disabled it. An operator can interrupt service to reduce risk. The available Reuters material does not identify the affected sites or establish the circumstances of each shutdown.

The fix now has to cross an organizational boundary. PHP maintainers publish repaired software; they do not administer every website that depends on it. A managed hosting provider may control the installed runtime. A site operator with its own servers may hold that responsibility directly. Other arrangements divide packaging, deployment, and application testing among separate teams. The patch cannot approve its own maintenance window.

That division matters to a shop taking orders or a publisher serving readers. The person answering customer complaints may lack permission to change PHP. The provider holding that permission may require the customer to authorize an interruption. Those arrangements are not inherently defective. They become a security problem when nobody can identify the person empowered to act without first arranging a meeting about the meeting.

Operators should establish which PHP installations actually serve their sites and which supported or vendor-maintained fixes cover those installations. An update plan also needs a way to check application behavior and confirm that the running service uses the repaired software. A downloaded package is not evidence that every relevant process now runs the corrected version. Patching also does not, by itself, determine whether an earlier intrusion occurred.

Hosting providers can clarify deployment responsibility and patch availability. Site operators can name the person authorized to interrupt service and the person responsible for verification. Where operators have taken sites offline, reopening should follow confirmed deployment and appropriate checks, not simply the announcement that a fix exists. The next decisions belong to the people who control the running website.