Critical PHP flaws in 2026: why sites went offline and the wider impact
Understand the two critical PHP flaws fixed in October 2026, why some sites went offline, and how to assess and patch your environment.
Two critical PHP runtime flaws prompted urgent updates and precautionary site shutdowns. Downtime, exposure, and confirmed compromise are different facts.
On October 21, 2026, urgent security notices, maintenance windows, and reports of unavailable websites brought PHP into the spotlight. Saying that “PHP went down worldwide” is a tempting shortcut, but it blends together different events.
The PHP project released fixes for two critical vulnerabilities in the runtime. Both can allow unauthenticated remote code execution in vulnerable installations. In response, some operators temporarily suspended services while they prepared, applied, and verified updates. An unavailable page is therefore not, on its own, evidence of a breach.
The incident matters because of its technical severity and PHP's widespread use on the web. It also calls for precision: there is no single central “PHP service” whose failure explains every affected website.
What was confirmed by October 21
On October 20, the PHP security team announced upcoming fixes for two vulnerabilities rated 9.2 under CVSS v4.0. On October 21, it released PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619. The official advice is to update PHP installations that serve web requests immediately. Source: PHP project.
The flaws affect the runtime beneath application code. The advisory covers PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. The PHP project regards mod_php as the highest-risk setup and documents an exploit that can be triggered before application code runs. That particular demonstrated path should not be assumed to work in every PHP deployment. Source: PHP project.
What are the two flaws?
CVE-2026-109618 concerns out-of-memory handling. Under certain conditions, PHP can interrupt a request while internal data is only partially initialized. Cleanup can then process invalid state as though it were valid. The technical advisory explains how this can lead to memory corruption and code execution.
CVE-2026-109619 concerns stale global state. A worker can retain a reference to data from one request after the backing memory has been freed. A later request handled by the same worker may reach that reference before normal initialization resets it. The second advisory documents confirmed paths and others that depend on configuration or application behavior.
Because these issues sit in PHP itself, updating a WordPress, Laravel, or other PHP application component alone does not fix the underlying runtime. Operators need to check the PHP version actually serving traffic.
Why did some websites go offline?
A vulnerability and an outage are different facts. An operator may patch while keeping a service available, restrict access temporarily, or suspend the application until the fix is verified. The choice depends on the environment's exposure and the team's ability to respond.
ICANN said it temporarily disabled three PHP-based administrative sites as a precaution. Its statement said there was no indication that its systems had been adversely affected. Contabo reported suspending its shared cPanel hosting until the fix had been applied and verified, while other services remained operational. It reported no evidence that customer systems or data had been affected.
These are documented responses by specific operators. They do not establish a worldwide outage count, the duration of every interruption, or a successful attack against every unavailable site.
What should a PHP operator check?
Start by locating every PHP installation serving web requests: servers, worker pools, container images, managed hosting, and third-party products that embed PHP. The version shown by a shell command may not be the version serving the published website, so check the running deployment and where its packages come from.
Then work through a short response sequence:
- Confirm exposure. Identify the PHP version, its server integration, and which applications face the internet. Prioritize public traffic.
- Check the update source. For self-managed systems, inspect distribution packages or container images. For managed hosting, follow the provider's notice and confirm deployment of the fix.
- Apply a fixed build. The PHP project released 8.2.35, 8.3.36, 8.4.27, and 8.5.12. If a vendor backports the fix, verify its package advisory rather than relying only on the upstream PHP version number.
- Replace or restart affected processes and validate. Ensure old workers no longer serve requests, test critical application flows, and monitor errors or unusual behavior.
- Investigate concrete signals separately. Logs and alerts may help identify abuse, but a lack of entries is not proof of safety. Assessing a possible compromise is a separate task from patching.
CERT-EU recommends immediate patching. If that cannot be done promptly, it advises organizations to consider isolating internet-facing applications until the fix has been applied and verified. Updating a CMS, theme, or plugin does not replace updating the underlying PHP runtime.
What about older PHP versions?
PHP 8.1 and earlier no longer receive regular security releases from the PHP project. Some distributions and long-term-support vendors may provide backported fixes. For this incident, the PHP team also published minimal source backports for PHP 7.4, 8.0, and 8.1. Check who supplies and maintains the deployed package; moving to a supported branch remains the clearer long-term maintenance path. Source: PHP project.
The official advisory includes temporary configuration changes that reduce exposure through specific paths. Its limitation is clear: updating is the only complete fix. One copied setting is not a substitute for closing the incident properly.
What remains uncertain?
CERT-EU noted that initial proofs of concept were circulating, which adds urgency. A proof of concept alone does not measure how broadly real systems have been exploited. Each provider's statement also reflects what it knew about its own infrastructure at the time.
This picture may change. Before attributing an unavailable site to these flaws, check its operator's status notice. Before claiming a breach or data leak, look for specific evidence. Recheck the technical advisories and vendor packages before publishing updated remediation advice.
The lasting lesson
PHP does not rely on a central service to run. Even so, a runtime flaw can require coordinated responses across many independent environments. In some of them, a short interruption may be part of the security response.
For people building and operating applications, the practical question is: do we know where PHP runs, who updates it, how to replace live workers, and how to verify that the fix reached production? That inventory and update path matter most when a critical advisory leaves little time to react.