October 22, 2026
Yesterday, the internet had a rather unusual problem. Websites belonging to governments, universities, hospitals and major businesses were being taken offline because of two critical vulnerabilities in PHP, one of the foundational technologies of the web.
The list included Dutch government services, French prefecture websites, Finnish government infrastructure, parts of the BBC’s web presence, services operated by major Japanese companies, and systems maintained by the Wikimedia Foundation and the Internet Archive.
These were precautionary shutdowns, not evidence that all those organizations had been hacked. Nevertheless, the scale of the disruption is remarkable. A community-maintained outage tracker recorded 50 affected websites and services, with seven still listed as down when checked on October 22 at 08:12 UTC. The tracker is not a complete or independently audited census, but it illustrates the breadth of the response.
Sources: Reuters — Governments and companies take websites offline over PHP flaws · PHP2Shell outage tracker
The vulnerability is known as PHP2Shell, and PHP released fixes on October 21 for CVE-2026-109618 and CVE-2026-109619. Both received a CVSS 4.0 score of 9.2 out of 10.
The immediate technical crisis is real. My bigger concern is what this episode reveals about the infrastructure we depend on: the gap between a vendor announcing a security fix and that fix actually reaching every server, and the strange way this release unfolded.
Is PHP2Shell a real vulnerability, or are we being sold a story?
This is worth establishing before getting carried away by headlines.
Yes, the vulnerabilities are real. Researchers at Wiz published technical details and demonstrated unauthenticated remote code execution against WordPress, Drupal and Joomla running vulnerable PHP versions. Datadog Security Labs separately reported reproducing the memory-corruption issue. The PHP Foundation’s own explanation confirms the underlying flaws and the successful demonstrations.
The distinction matters because this is a vulnerability in PHP itself. It does not require a vulnerable WordPress plugin or a clever application-specific exploit. The PHP interpreter can mishandle memory while processing a request, potentially allowing an attacker to execute code with the privileges of the PHP worker.
The two flaws involve related memory-management problems. One concerns corrupted or partially initialized state after an out-of-memory condition. The other concerns references to memory that has already been released. Both can create opportunities for an attacker to corrupt internal state and gain control of execution.
The risk is particularly serious for Apache installations using mod_php, where a demonstrated attack can reach the vulnerable code before application-level code runs. PHP-FPM deployments are also affected, although the demonstrated exploitation paths can depend on application behaviour and configuration.
This is why an application login, WordPress security plugin or ordinary application-level validation cannot be assumed to protect an affected PHP runtime.
Sources: Wiz Research’s technical analysis · Datadog Security Labs’ independent reproduction · PHP Foundation’s technical explanation
The strange part: PHP announced a critical security release in advance
On October 8, the official PHP website published an advance notice announcing a security release scheduled for October 21 at 14:00 UTC. It stated that two critical vulnerabilities were being addressed, each with a CVSS score of 9.2.
The notice deliberately withheld the technical details and affected versions.
A public announcement almost two weeks before a critical security release is unusual enough to attract attention. Why announce a date so far in advance while withholding the information administrators need to identify their exposure?
There is a legitimate explanation. Coordinated vulnerability disclosure gives maintainers, Linux distributions, hosting panels, cloud platforms and security providers time to prepare fixes before attackers have full technical details. A coordinated release can be much safer than publishing an exploitable bug and leaving every downstream vendor to start from scratch.
However, the plan became messy.
On October 20, information about the vulnerabilities began circulating before the scheduled release. Reporting described leaked vulnerability identifiers and an accidentally published demonstration video from the research effort. The PHP team reiterated its release schedule, and the fixes followed on October 21.
Cloudflare reported preparing and deploying protective rules in advance of public disclosure, while also observing attack traffic associated with the vulnerabilities. Amazon Web Services later reported an attempted exploitation observed in its honeypot telemetry on October 17, four days before the public release. AWS said it could not establish whether that attempt would have succeeded against a real vulnerable system or how the actor had obtained the necessary information.
This is the part worth examining. The intended advantage of coordinated disclosure was to give defenders time to prepare. In practice, information leaked, demonstrations circulated and attackers were reportedly testing the vulnerability before most administrators even knew what they needed to patch.
The advance notice itself is not evidence of wrongdoing. Coordinated releases are a normal security practice. The legitimate questions concern how the embargo was maintained, how early the information escaped, and whether the people responsible for distributing fixes were ready when the deadline arrived.
Sources: PHP’s advance security notice · WIRED’s reporting on pre-release exploitation · Cloudflare’s account of its protections
The patch exists. Why am I still typing commands?
Here is where the problem becomes very practical.
I manage PHP websites, including sites running on Plesk. During this incident, I had to log into a server over SSH and perform a PHP upgrade manually because the patched version was not available to me through the normal graphical update workflow at the time I checked.
That experience is not proof that every Plesk installation failed to update. It is evidence that having a commercial hosting control panel does not guarantee that an emergency fix is immediately available and installed.
Plesk’s own advisory illustrates the changing situation. Its initial October 20 notice said patches for its bundled PHP versions were pending the upstream PHP release. The advisory was updated on October 22 with patched versions, including PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, as well as fixes for components of the Plesk control panel itself.
The discussion on that same advisory included administrators reporting that their package repositories did not yet show the expected updates or that APT repository signature errors prevented normal updates. Those reports are individual experiences, not proof of a universal Plesk defect, but they show the practical difficulties that can arise during an emergency rollout.
This is not limited to Plesk. Every layer has its own release and deployment process: the PHP project, the operating-system distribution, the hosting panel, third-party repositories, the actual PHP handler and the administrator who must make sure the fixed code is running.
A fix announced upstream is only the first step.
Source: Plesk’s PHP2Shell advisory and update history
Linux distributions: fixed upstream does not mean identical package versions everywhere
There is another complication. Different distributions package PHP differently, and security fixes may be backported into a package without changing its upstream PHP version number to match the latest release.
Ubuntu published its PHP security notice on October 21, listing fixed package revisions for supported Ubuntu releases. Debian’s security tracker also lists fixed versions for Bookworm and Trixie. This means it would be inaccurate to claim that Ubuntu or Debian generally remained without a fix on October 22.
The more important issue is that availability varies by distribution, release, repository and supported lifecycle. An administrator running an older PHP branch may depend on a distribution or commercial vendor to provide a backport. PHP 8.1 and earlier no longer receive ordinary upstream security releases; the PHP project has published limited source backports for selected older branches, while some distributions and extended-support vendors provide their own packages.
Consequently, simply running php -v and comparing the number with the latest upstream release is not always enough. Administrators need to check the security status of the exact package they are running.
For an incident affecting PHP itself, that is an uncomfortable amount of complexity for something many site owners assume their operating system or control panel will take care of.
Sources: Ubuntu Security Notice USN-8948-1 · Debian’s CVE-2026-109618 tracker
What about N0C and other hosting providers?
I could not locate a public, verifiable N0C advisory that establishes its patch status for this particular incident. That does not prove N0C failed to patch its systems; updates may have been deployed without a public notice, or information may be communicated privately to customers.
However, customers should not have to guess.
For an incident of this severity, a hosting provider should be able to state which PHP versions and products are affected, when a fix became available, whether it has been deployed, which customer systems need action, and how customers can verify their status. Silence is not proof of a vulnerability, but a lack of clear public guidance makes it harder for customers to make informed decisions.
The same standard should apply to hosting panels, managed platforms and third-party repositories. If an update is delayed, administrators need to know that. If a version is end-of-life, they need an explicit remediation path.
Containers create another update gap
The same problem applies to Docker. A container using wordpress:latest does not automatically acquire a new PHP version merely because a newer image has been published. The image must be pulled, the container recreated and the resulting installation verified.
That is a perfectly reasonable deployment model when administrators understand it. It becomes risky when people assume that the word latest means the running application is continuously updated.
A machine can have automatic Ubuntu updates enabled while a vulnerable PHP runtime remains inside an old container. Likewise, a server may have multiple PHP versions installed for different sites, with only some of them updated.
A meaningful security update process must account for every runtime and every application, rather than treating the server as a single package inventory.
So, is this a genuine emergency or overblown security marketing?
The technical evidence supports the vulnerability. Wiz and Datadog documented successful exploitation, the PHP Foundation acknowledged the underlying memory-management flaws, and Cloudflare reported protective activity and attack traffic. This is not a convincing case for dismissing PHP2Shell as fabricated.
At the same time, commercial security vendors and AI companies have understandably highlighted their role in discovering or mitigating the problem. Their marketing claims deserve the same scrutiny as any other corporate claims. The existence of a genuine vulnerability does not mean every description of its impact, every estimate of affected websites or every claim about AI’s role should be accepted without examination.
The PHP Foundation’s own post is particularly revealing. It acknowledged that the initial concern about one of the flaws had been identified in 2024, but that the lack of a known exploitation path, limited specialist capacity and disagreement over the proper fix caused work to stall and restart over several months. The Foundation explicitly described the delay as a structural failure and said it was changing its decision-making process.
That admission is more useful than the sensational headlines. It points to the underlying problem: critical infrastructure depends on open-source projects that may have limited people, funding and time to deal with complex engine-level defects.
The vulnerability is real. The public countdown and disclosure complications are unusual, and the operational response deserves scrutiny. The failure to make every patch immediately available through every distribution, panel and deployment workflow is a separate problem that cannot be solved by announcing an urgent update.
The question hosting providers should answer
When a critical vulnerability is announced, a provider should be able to tell its customers:
- Which installed PHP runtimes were vulnerable?
- When was a patched package or image made available?
- Was the update installed automatically, or was customer action required?
- Were all PHP handlers and application containers restarted or recreated?
- How can customers verify that the patched runtime is actually serving requests?
- What should customers do if they are running an end-of-life PHP branch?
- If a vulnerable service was exposed before patching, what investigation is recommended?
Those are straightforward questions. They should have straightforward answers.
The PHP2Shell incident is a reminder that security advisories, package repositories, hosting panels and actual running services are separate parts of the same chain. A patch is valuable only when it reaches the system that needs it.
And for those of us managing production websites, the recurring lesson is frustratingly familiar: even when the update is marked critical, you still need to check the versions, find the package, run the commands, restart the service and verify that the fix took effect.
That is what a reliable security process should make easier, not leave to chance.
