PHP2Shell flaws hit CISA's October 29 deadline and 4 more

What people are saying

A Wiz post on PHP2Shell exploitation drew 191 points and 60 comments on Hacker News. Readers took its finding of no completed exploit chains in Wiz's honeypots as a counterweight to earlier talk of widespread exploitation. On Reddit's r/cybersecurity, commenters argued over what the Known Exploited Vulnerabilities (KEV) listing does and does not prove. Several commenters repeated the fixed upstream releases.

What holds up

Wiz says it has seen a limited number of exploitation attempts and has not found a public proof of concept that works end to end against an arbitrary target. It also says partners privately shared exploits that work against a variety of targets. Neither of the two exploit kit variants Wiz captured completed the chain.

Wiz's exposure data points the right way. It recorded an approximate 67% drop in vulnerable internet-exposed machines, and less than 53% of initially affected organizations remain vulnerable one week after disclosure.

The flaws are on the KEV list regardless. CISA's alert says it added CVE-2026-109618 and CVE-2026-109619 to the catalog on October 26. The KEV entry sets a due date of October 29. CISA tells organizations to update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35.

BleepingComputer reported that a Perplexity detection and response lead's honeypots recorded remote code execution against an Apache mod_php install running PHP 8.4.26. The outlet also said several security firms saw widespread attempts before disclosure but tagged them all as unsuccessful.

In our reading, Wiz's narrow claim stands. The broader inference that PHP2Shell is not being exploited does not.

Inside the threads

One Hacker News camp stressed that Wiz's result covers its honeypots only, noting the flaw was exploited in a public bounty challenge. Another commenter doubted earlier claims of months of exploitation, asking why logs would not show strange errors. Practitioners warned that unrestarted PHP workers and backported distribution packages with old-looking version numbers cause false confidence. One X post wrongly said CISA had not added the CVEs to the KEV list.

Our take

The argument over how many real servers fell matters for incident reporting, not for patch priority. A KEV listing with a federal deadline is enough to treat this as an emergency change, whatever a single honeypot network shows. What is underrated is the long tail. Old PHP branches, bundled vendor software and appliances are where exposure will linger after the headline patching is done. Expect a more reliable public exploit later and plan as if it is coming.

What to do

• Inventory every PHP runtime, including containers, hosting panels and PHP embedded in vendor products, and patch internet-facing systems first.
• Verify the runtime that actually serves requests: restart all PHP workers and check distribution changelogs for the CVE IDs rather than version numbers.
• On hosts exposed before patching, review web roots, upload directories and pre-patch access logs for signs of compromise.
• CISA says systems that cannot be updated, or that run PHP 8.1 or earlier, should go offline until patched.

What people are saying

Ars Technica reported a code-execution flaw in boot-time firmware used by most of the world's server vendors and data centers. Posts on X amplified it. One said the flaw lets hackers remotely take over servers, and another warned of millions of servers exposed. On Reddit's r/cybersecurity, the thread opened with jokes about the headline before turning to who actually boots from the network.

What holds up

The National Vulnerability Database record lists CVE-2026-97631 with a critical CVSS base score of 9.5 and a network attack vector. It was published on October 22. Ars Technica reports the flaw sits in TianoCore EDK II, the open source codebase hardware makers and cloud providers use to build UEFI firmware. It describes the flaw as a 16-year-old buffer overflow in the PXE Base Code driver that handles network boot.

Reach across suppliers is established. Ars reports that virtually all UEFI suppliers, including AMI, Insyde and Phoenix, use the reference code, and that Microsoft's Project Mu fork used the vulnerable component.

Exposure is narrower. Ars says the malicious message must arrive during the PXE boot sequence and that some control over a local network is a prerequisite. Tech Insider noted that the "most servers" wording describes reach across the supplier base and does not count vulnerable machines.

The disclosure went off schedule. Ars reports the researchers, at Anthropic and Google, had planned coordinated disclosure for January. AMI published a pull request with a fix last month, and TianoCore members issued a public advisory last week. HD Moore, chief research officer at Dragos, said the bug could be used to break disk encryption by an attacker with short-term network access. He also said it is likely a "forever" bug in end-of-support systems.

Verdict: partly confirmed. The "most servers" scale does not.

Inside the threads

Reddit split into two camps. One said the headline was alarmist because the flaw matters only for machines that boot from the network, and one commenter argued that excludes most servers. Others countered that mature environments use network boot for automated OS installs, and several asked whether virtual servers are affected. An IT operations commenter said enterprise desktops and laptops often have network boot enabled. One commenter cited a 9.2 score, while the CVE record says 9.5. On Lobsters, a commenter argued that "Secure Boot isn't a defense against firmware vulnerabilities."

Our take

We think the risk is real but concentrated. In our reading, the most exposed organizations are those with mature provisioning: bare-metal fleets that network boot for installs, compute clusters, and endpoints left with network boot on by default. The headline overstates the count. In our view, public fix code shortens the time before capable attackers understand the bug, while firmware patches move on vendor schedules. We think the underrated part is the TPM angle: code that runs before Secure Boot can undercut the disk encryption and attestation that boards were told protect the boot path. The local network requirement offers less comfort than it sounds, because insiders and intruders already inside are exactly who this bug helps. Our take is that the long tail on end-of-support hardware will be the lasting cost.

What to do

• Inventory which servers, appliances and endpoints have network boot enabled, and turn it off where it is not used.
• Keep provisioning and boot networks segmented so only trusted systems can reach hosts while they boot.
• Ask each server and firmware vendor for a written statement on CVE-2026-97631 with affected builds and a release date, then book a maintenance window.
• Track end-of-support hardware separately, and plan to isolate or retire anything that will not get a fix.

What people are saying

A post on Reddit's r/sysadmin about October Patch Tuesday drew a thread of administrators reacting to the 1,413 figure. The number also spread on X, where one post said Windows accounts for 1,102 of them, with 134 in Office. Other posts put the total at a record-breaking 1,411 flaws.

What holds up

A trade report said the update addressed a record number of common vulnerabilities and exposures (CVEs), with over 1,400 flaws listed, more than in the entirety of 2023. The same report said exact totals often vary and are hard to pin down because of third-party flaws and how they are counted.

Microsoft's October release notes say the release consists of 1468 Microsoft CVEs. The same page says Microsoft is republishing 616 non-Microsoft CVEs, with Chrome CVEs not listed. A separate report counted 1,413 vulnerabilities. A vulnerability vendor's review counted 1414, including 78 critical.

The year comparison does not survive. Tenable's Satnam Narang said more than 4,000 CVEs have been patched by Microsoft this year alone.

Microsoft lists CVE-2026-96951, a Windows Shell security feature bypass, as exploitation detected. The Cybersecurity and Infrastructure Security Agency (CISA) added it to its Known Exploited Vulnerabilities catalog, requiring federal agencies to apply the fixes by October 16, 2026. Microsoft marks CVE-2026-108398, a.NET Framework security feature bypass, as publicly disclosed. Dustin Childs of the Zero Day Initiative noted 55 unauthenticated, zero-click vulnerabilities across core network services.

Microsoft also introduced a method to prioritize updates by grouping related flaws into what it calls risk cohorts. In our reading, the record month holds up, but the exact count and the 'any year' framing do not, so we rate the claim partly confirmed.

Inside the threads

Commenters split over whether to scrap update rings and push everything on day 1. Others warned that a bad server update could be far worse than irritating. A middle camp said rings can shrink to hours: push to a small canary group first and then the rest the same day. One commenter pointed out that a single cumulative update remediates hundreds of vulnerabilities, which undercuts the '1,400 patches' framing. Complaints about broken Wi-Fi authentication drew replies that Microsoft intentionally turned off old crypto.

Our take

We think the headline total is a distraction, and the 'more than any year' line is the part that falls apart. The number that matters to a security leader is small: the exploited bug, the publicly disclosed ones and the zero-click network bugs. In our reading, the underrated story is operational, because monthly test cycles built for dozens of fixes are straining at this volume. We would not follow the thread's advice to drop rings entirely. Compressing them to hours keeps a safety check without giving attackers days.

What to do

• Confirm CVE-2026-96951 is patched across Windows endpoints, since it is on CISA's exploited list.
• Replace week-long ring gaps with a same-day canary stage and a clear rollback trigger.
• Report patch status to leadership by exploited and exposed bugs, not by raw CVE count.

What people are saying

Google's Project Zero published a comparison of two tools it runs against V8, Chrome's JavaScript engine: the Fuzzilli fuzzer and BigSleep, its AI bug-finding agent. The Project Zero front page dates the post 2026-Oct-27. A post on X shared the comparison. On Lobsters, readers took it as new data in the argument over how well AI finds vulnerabilities.

What holds up

The numbers come from the team that runs both tools, so the core claim is confirmed. Project Zero says both tools are used regularly to find vulnerabilities in V8.

Over the past six months, BigSleep found 45 vulnerabilities and Fuzzilli found 37, with a 25% overlap in the specific bugs. Project Zero says this method tends to underestimate overlap. It ran separate experiments on vulnerabilities reported since 2023, and those put overlap at roughly 60%.

Project Zero says that under either figure, a substantial portion of bugs were found only by large language models (LLMs) or only by fuzzing. The post limits itself to these two systems.

V8 bugs matter in practice. SOC Prime reported that Google confirmed in-the-wild exploitation of CVE-2026-3910, a V8 flaw patched in March.

Inside the threads

The Lobsters discussion was small and practical. One commenter said agent review alone worked well enough. In their experience, though, having agents build generative and deterministic test suites found more bugs, and more interesting ones.

That commenter works on a Go GraphQL server backed by Postgres. They said a plain bug-hunting prompt found about 40% as many issues as the test-suite approach. They recalled that about half of the prompt's findings overlapped with the other method.

Another commenter dismissed the post as "amazingly deep in the management sauce."

Our take

We think the useful finding is the overlap, not the ranking. A 45 to 37 lead is narrow and covers one heavily tested codebase. It tells you little about how an AI agent would perform on your own applications.

The overlap estimates matter more. Whether the true figure is 25% or 60%, each method misses a meaningful share of what the other catches. In our reading, that weakens any vendor pitch that an AI agent can replace existing testing.

We think the underrated point is that Google runs both tools on V8 and recommends vendors do the same. The Lobsters practitioner's experience points the same way: AI works best when paired with structured testing, not used alone. For budget decisions, our take is to treat AI analysis as an added layer of coverage and to fund it that way.

What to do

• Ask application security leads which components get fuzzing, which get AI-assisted review, and where neither runs.
• When evaluating AI bug-finding products, ask for results on your own code alongside your current tools, and measure overlap, not only raw counts.
• Ask software suppliers of critical components whether they use both fuzzing and agentic analysis, as Project Zero recommends.
• Keep browser patching fast across the fleet, since V8 flaws continue to be exploited in the wild.