The PHP project released emergency updates Wednesday for two critical vulnerabilities that could let an unauthenticated attacker execute code on a web server, setting off an immediate patching campaign across the public and private sectors. The flaws, tracked as CVE-2026-109618 and CVE-2026-109619, each carry a 9.2 severity rating. The official PHP changelog records the fixes, while CERT-EU said the patches became available at about 9:30 a.m. Eastern time.

The emergency is unusually broad because PHP runs behind a large share of the web. Palo Alto Networks’ Unit 42 estimated that more than 22.6 million internet-exposed instances may be vulnerable. That figure describes potential exposure, not confirmed compromise, but it shows why agencies are treating the defects as an infrastructure-level risk rather than a narrow software problem.

What the updates fix

Administrators should move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Those are the supported releases carrying the corrections. CERT-EU said installations serving web requests are at risk across common configurations, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed; it identified mod_php as the highest-risk setup. Security firm Huntress independently listed the same fixed branches and said technical details had leaked before the coordinated release.

Both vulnerabilities can be reached without authentication, but they arise through different paths. Researchers describe one as abusing PHP’s handling of an out-of-memory condition and the other as manipulating stale global state between requests. In practical terms, successful exploitation could give an attacker the ability to run commands with the privileges of the affected PHP process, potentially opening access to files, databases or application secrets. The precise impact would depend on the server’s configuration and what that process is allowed to reach.

Standard upstream support no longer covers PHP 8.1 and earlier branches. CERT-EU said limited source backports were prepared for some older lines, but operators running legacy installations may need a distribution-maintained package or a commercial long-term-support build. A web application update alone is not enough if the underlying PHP runtime remains unpatched.

Precautionary shutdowns spread

Several government, school and hospital websites in Europe were temporarily taken offline while their operators applied fixes or checked dependencies. Reuters documented precautionary shutdowns in the Netherlands, Germany, France and Finland, among other locations. Wired separately reported that security teams were racing to protect legacy systems that could not be upgraded immediately.

Those outages are not evidence that the affected institutions were breached. Officials in several countries said they knew of no security incident and described the shutdowns as preventive. Cloudflare said it was seeing early attacks emerge and was updating firewall mitigations, but Huntress said that as of 10 a.m. Eastern it had not observed exploitation across its own partner base. The two statements can coexist: attack activity may appear on parts of the internet before it is visible in every monitoring network.

U.S. agencies urge immediate action

The Cybersecurity and Infrastructure Security Agency told organizations to update immediately. In its CISA advisory, the agency said it had not observed exploitation at the time of publication but warned that unpatched systems remained at risk. The National Security Agency separately advised organizations that could not update at once to take affected systems offline until they could be fully mitigated, according to a second Reuters report.

For U.S. organizations, the first task is to inventory internet-facing systems rather than assume the issue is limited to a visible website. PHP can sit beneath content-management systems, customer portals, internal tools, hosting control panels and vendor-managed applications. Owners should confirm the runtime version with their hosting provider, apply an updated package, restart the relevant services and verify that the new version is actually running. Web-application firewalls may reduce exposure, but CERT-EU cautioned that temporary mitigations do not replace the fixed runtime.

What happens next

Security teams should preserve logs, watch for unusual child processes or unexpected outbound connections, and rotate credentials if they find signs of compromise. Organizations that cannot quickly determine whether a public-facing PHP service is patched should isolate it until its status is verified. The risk is highest during the period immediately after a patch release, when defenders are updating systems while attackers study the correction and public proof-of-concept material.

No authoritative source had confirmed a mass compromise by early Wednesday afternoon. That uncertainty should temper claims about damage, but it does not reduce the need for action: public exploit details are circulating, working fixes are available, and the vulnerable software is embedded across millions of exposed systems. The decisive next measure will be how quickly operators install the corrected versions—and whether telemetry from CISA, major cloud providers and incident-response firms shows exploitation broadening beyond the early activity already reported.