PHP2Shell Patch Lag: Millions of Scans a Day as Fixes Still Roll Out

In brief

• One week after PHP2Shell, mass scanning runs at millions of attempts a day while vendors still ship fixes and unpatched sites stay exposed.
• Cloudflare chief executive Matthew Prince said attempts on Cloudflare’s network rose from thousands before disclosure to millions afterward, according to Reuters coverage.
• Most observed activity so far is scanning for unpatched servers, not confirmed mass break-ins — a distinction that matters for how seriously, and how calmly, site owners should react.
• Palo Alto Networks confirmed on Oct 24 that PHP2Shell affects PAN-OS and Panorama management interfaces, with fixed PAN-OS hotfixes dated Oct 26-30.
• The FBI has urged organizations to update PHP installations, inventory where PHP runs, and — if an immediate update is not feasible — take the system offline until it can be fully mitigated.

What is new a week after the PHP2Shell disclosure?

One week after disclosure, the story has shifted from the flaws themselves to the gap between a fix existing and a fix being installed. CVE-2026-109618 and CVE-2026-109619 allow unauthenticated remote code execution in PHP, and patches were released on Oct 21. What is new on Oct 24-25 is the scale of the probing that followed, the vendors still working through their own product fixes, and the evidence that a large tail of sites has not yet patched.

That distinction — a patch released versus a patch applied — is the whole follow-up. PHP is one of the most widely used languages for building websites, powering everything from small business sites to large portals and content management systems. A flaw in PHP itself, rather than in one company’s product, can therefore touch a huge number of servers at once. When the fix lands, every one of those servers still needs updating individually, and that work does not happen overnight.

The numbers reported over Oct 24-25 show how quickly attackers moved into that gap. Cloudflare’s Matthew Prince described the surge in a post on X late on Wednesday, Oct 21, as reported by Reuters: in the 10 hours before public announcement, Cloudflare’s network saw thousands of exploitation attempts. That jumped to tens of thousands in the 45 minutes after announcement, hundreds of thousands within two hours, and millions after that. The follow-up reporting on Oct 24 confirms that elevated level of activity continued through Oct 23 and 24. The attackers, in other words, did not try once and move on. They kept knocking.

Readers who followed our original coverage can find the full explanation of the flaws there: PHP2Shell explained: the critical PHP vulnerability, the patches, and what to check first. This follow-up does not repeat that guide. It answers a different question: now that the patches have been out for several days, why is the risk still live, and what has changed in the last 48 hours?

Is this mass exploitation, or just mass scanning?

So far, most of what researchers observe is scanning, not confirmed mass break-ins. That is the most important qualifier in this story, and it should be stated plainly: millions of attempts does not mean millions of successful compromises. Scanning means attackers are probing servers to find which ones are still unpatched and reachable. It is the reconnaissance phase — loud, automated, and indiscriminate — and it precedes the break-ins that defenders are trying to prevent.

That does not make the scanning harmless. Scanning at this volume tells defenders two things. First, attackers have working probes for these flaws and are running them broadly, so any internet-facing, unpatched PHP installation is likely to be found rather than overlooked. Second, the window between scanning and exploitation can be short. Once a vulnerable system is identified, an attacker who already has a working exploit does not need to start from scratch. The scanning is, in effect, a census of the remaining exposure, conducted by the people least inclined to keep the results to themselves.

The reporting to date supports that measured reading. Palo Alto Networks said on Oct 24 that it was not aware of malicious exploitation against its own products, even as its Unit 42 researchers had seen proof-of-concept exploits for the wider PHP flaws. Precautionary shutdowns elsewhere tell a similar story: organizations are acting because they cannot yet confirm they are safe, not necessarily because they have confirmed a breach. South Africa’s Presidency website, for example, was taken offline as a precaution, with a spokesperson telling Reuters there was no indication of a breach. That is a defensive move in the face of uncertainty, and it is a rational one when the cost of being wrong is a compromised government site.

For site owners, the practical takeaway is therefore not panic but urgency without confusion. Scanning means you are probably already on someone’s list if you run an unpatched, internet-facing PHP installation. It does not mean you have already been breached. The time to patch is before the scanning turns into something worse for your specific server, and the FBI guidance covered later in this article is written with exactly that sequence in mind.

Why are so many sites still unpatched?

Because patching the web’s long tail is slow, uneven work — and Denmark’s Oct 24 snapshot shows it. More than 21,000 Danish websites still lacked PHP security updates, according to Danish industry reporting cited in Oct 24 coverage. That figure is attributed to that reporting; it is not AuTechWire’s own count, and it covers one country only. But as a snapshot it is revealing: days after patches were released, tens of thousands of sites in a single, well-connected country had still not applied them.

There are mundane reasons for that lag, and they are worth naming because they explain why this story will run for weeks rather than days. Many sites are run by small businesses, agencies managing hundreds of clients, or owners who do not know which version of PHP their host runs. Some servers are forgotten entirely — old projects, staging systems left online, or sites nobody actively maintains. Others run unsupported PHP versions, such as 8.1 and older, which no longer receive updates from the PHP project itself, although some Linux distributions and long-term support vendors provide backported fixes. Those owners cannot simply click “update”; they need a migration plan, a vendor fix, or a decision to take the system offline.

Bundled PHP makes the problem harder still. PHP does not only run on servers that a team consciously chose to run PHP on. It is embedded in products — firewalls, appliances, and applications whose owners may not think of themselves as “PHP users” at all. That is why the FBI’s advice stresses inventorying where PHP runs, prioritizing internet-facing systems and bundled products, rather than only checking the servers a team already knows about. A site can be fully patched on its main server and still exposed through a forgotten appliance or a product that bundles an older PHP build.

The long tail is also why precautionary shutdowns keep appearing in the news. When an organization cannot quickly confirm whether it is affected — because its estate is large, its inventory is incomplete, or its vendor has not yet shipped a fix — taking a site offline is sometimes the only certain mitigation. South Africa’s Presidency site is the highest-profile example in this round of reporting, but the logic applies far more widely. The patch lag is not a story about lazy administrators. It is a story about a system in which the fix is centralized and the installation is distributed across millions of independent owners.

What did Palo Alto Networks confirm on Oct 24?

Palo Alto Networks confirmed on Oct 24 that PHP2Shell affects its PAN-OS and Panorama management interfaces, and its updated advisory gives customers a concrete but still-open timeline. The company rates the product impact at 8.7 out of 10 — high severity, though below the underlying PHP flaws’ CVSS 4.0 score of 9.2 — and its product-specific assessment identifies availability, rather than confirmed data theft or unauthorized changes, as the affected security property. The company said it was not aware of malicious exploitation against its products, while Unit 42 had seen proof-of-concept exploits for the wider PHP flaws.

The affected scope is specific and worth getting right. Affected branches include PAN-OS 10.2, 11.1, 11.2, 12.1, and 12.2 on PA-Series and VM-Series firewalls, and Panorama deployments, including virtual and M-Series systems, are also affected. Exposure is limited to the management web interface, covering the HTTPS administration console and the XML API; a dataplane interface is affected only when it has a management profile attached. GlobalProtect portals, gateways, Clientless VPN, and Captive Portal are not impacted, according to the corroborating advisory coverage. Two cloud services were previously affected but have already been fixed: Cortex XCORE SaaS received a fix on Oct 21 and WildFire Cloud on Oct 22.

The fix timeline is the part customers need most, and it stretches past the Oct 24 confirmation by several days. Fixed PAN-OS hotfixes are dated Oct 26-30, with 12.2.4-h1 on Oct 28 and 11.1.16-h4 on Oct 26 among them. Corroborating coverage adds that the earliest estimated releases are 10.2.18-h13, 11.1.16-h4, and 11.2.10-h16 on Oct 26, with other listed hotfixes planned through Oct 30, and that these dates remain estimates. Panorama versions were still to be confirmed at the time of the Oct 24 update. Until the hotfixes arrive, the company’s guidance is to limit management access to trusted internal IP addresses or a dedicated jump box, since internet-facing management interfaces present the highest risk.

That sequence — confirmation, then a multi-day wait for fixes, with interim access restrictions as the only mitigation — is the vendor version of the patch lag. It also shows why the story is not confined to website owners. When a flaw sits in a shared language layer, it surfaces inside security products themselves, and the teams responsible for defending networks become the teams waiting on a patch. The pattern is familiar from other recent critical flaws, and it is a useful comparison: our coverage of another critical remote code flaw explains a similar disclosure-to-patch scramble in GitLab CVE-2026-110264: the critical RCE flaw, explained. The details differ; the race between disclosure, scanning, and patching does not.

What is the FBI telling organizations to do now?

The FBI’s message is blunt, and its bluntness is the news: update now, know where PHP runs, watch for compromise, and take systems offline if you cannot patch yet. In a post on X on Wednesday, the FBI said organizations should update affected installations using guidance from PHP.net. It advised organizations to inventory where PHP runs, prioritizing systems accessible from the internet and products that bundle PHP. It urged monitoring for suspicious activity, including PHP processes unexpectedly launching command shells or downloading files. And it said that if an immediate update is not feasible, “it is recommended that organizations take the system offline until it can be fully mitigated.”

That last line deserves emphasis because it is stronger than the usual “patch as soon as possible” advice. Taking a system offline is a costly step, and agencies do not recommend it lightly. The recommendation signals how the FBI assesses the current risk: with mass scanning under way, an unpatched internet-facing system is not a theoretical exposure but a likely target, and the safe default when a fix cannot be applied is removal from reach. The FBI also said organizations that find signs of compromise should isolate affected systems, preserve server and PHP logs, and report the incident to an FBI field office or IC3, the FBI’s Internet Crime Complaint Center. Reports of compromise, the agency said, can help investigators identify cyber actors and alert other organizations.

The FBI’s message directed organizations to PHP’s announcement, CERT-EU Security Advisory 2026-018, and CISA’s Known Exploited Vulnerabilities catalog for further information. The UK’s National Cyber Security Centre has given similar guidance: identify systems running PHP, prioritize those exposed to the internet, and monitor them for malicious activity. The convergence matters. When the FBI, the NSA, and the UK’s NCSC are all pushing the same three steps — inventory, prioritize internet-facing systems, monitor — the advice is no longer a matter of opinion. It is the consensus response to a flaw whose exploitation attempts are already measured in millions.

For readers who run a website rather than a corporate network, the translation is straightforward. Check your PHP version with your host, confirm you are on a patched release for your branch (PHP’s security advisory lists updates for versions 8.2, 8.3, 8.4, and 8.5), and ask your host or vendor about any product that bundles PHP. If your host cannot confirm a patched version and cannot give you a date, the FBI’s offline advice applies in miniature: a temporarily unavailable site is better than a compromised one. Our original PHP2Shell post remains the place for the step-by-step checks, and this follow-up deliberately does not duplicate it — the new information is the urgency, the vendor timelines, and the official guidance, not a second copy of the same checklist.

What should readers watch for next?

Three dates and one count will tell us whether the patch lag is closing. The first is the Palo Alto hotfix window itself: Oct 26-30. As each PAN-OS hotfix lands, customers on that release train can close their own exposure, and the Panorama versions still to be confirmed should narrow the remaining gap. Watch for Palo Alto’s advisory updates rather than assuming a single release fixes every branch; the hotfixes are staggered by version, and installing the wrong train’s fix is not a fix at all.

The second is the scanning volume. Cloudflare’s trajectory — thousands before disclosure, tens of thousands within 45 minutes, hundreds of thousands within two hours, millions after that — is the baseline against which the coming days should be judged. If attempt counts fall as patching spreads, the lag is closing. If they stay at millions per day, the long tail is still large enough to be worth attackers’ time. Either way, the count is a public signal worth revisiting, and it is a better indicator than any single vendor statement.

The third is the next vendor advisory. Palo Alto is unlikely to be the last product vendor to confirm PHP2Shell exposure, because PHP is bundled so widely. Cisco published its own advisory on the PHP flaws on Oct 21 and updated it the next morning, listing a long set of products still under investigation. Other vendors with PHP-based management consoles will keep surfacing over the coming weeks, and each one will need the same question asked of it: where does PHP sit in your product, which versions are affected, and when does the fix ship? Readers who manage appliances should ask their vendors that question now rather than waiting for the advisory to find them.

The broader context is worth one paragraph, not a detour. This disclosure arrived in a week of unusually concentrated critical vulnerability news, and supply-chain risk is part of the same picture: a recent trojanized package incident shows how a trusted component can become an attack route, as covered in LiteLLM 1.107: the trojanized supply-chain attack, explained. PHP2Shell is different — a flaw in the language itself, not a poisoned package — but the defensive lesson overlaps: know what your systems are built from, including the parts you did not choose directly. The patch lag ends not when the last advisory is published, but when the last forgotten installation is found, updated, or taken offline.

Until then, the follow-up story is simple to state and hard to execute: millions of scans a day, fixes still rolling out through Oct 30, and unpatched sites still exposed. The flaws were patched on Oct 21. The internet is still catching up.

Sources

• https://aiagentupdate.com/post/php2shell-mass-exploitation-2026-10-24
• https://www.europesays.com/3330994/
• https://www.reuters.com/world/asia-pacific/cloudflare-sees-millions-exploit-attempts-after-php-disclosure-2026-10-22/
• https://cybersecuritynews.com/palo-alto-confirms-php-rce-vulnerabilities/

Update — October 27, 2026: Unit 42 retracts its exploitation claim

On October 25, Palo Alto Networks’ Unit 42 retracted its October 23 update that had linked an intrusion at a European government agency to PHP2Shell. Unit 42 now says it cannot confirm the attackers’ initial access was through CVE-2026-109618 or CVE-2026-109619. This article never claimed a confirmed PHP2Shell exploitation — its framing throughout has been mass scanning, not confirmed mass break-ins — and the retraction reinforces that distinction. Neither CVE is in CISA’s Known Exploited Vulnerabilities catalog as of this update. Separately, the PHP team announced a further flaw, CVE-2026-115560, on October 23; no patch is available yet, and the interim mitigation is the same as before. Sources: Unit 42 threat brief (October 25 update); SOCRadar PHP2Shell tracker (October 26 update).