Two CISA deadlines expire today. PHP2Shell, the week’s loudest flaw, has none.

Seventy percent. That figure has been everywhere this week, Wiz's estimate of how many of the world's websites run PHP, repeated in every story about the two emergency flaws now called PHP2Shell. But the number that should actually shape your Monday is zero.

Zero is how many of the week's two defining vulnerabilities appear in the Known Exploited Vulnerabilities catalog. Not PHP2Shell, with its pre-auth remote code execution and its 70%. Not GitLab's CVE-2026–110264, a CVSS 10.0 that reaches every self-managed install since version 7.0. Neither carries a federal deadline. Meanwhile, the two entries that fall due today, a Nextcloud document server and an SD-WAN orchestrator, got almost no coverage.

It might look like the catalog is failing here, but it isn't. KEV tracks exploitation that has been observed and confirmed, a much higher bar than simply being attacked. As of Friday, Cloudflare was seeing millions of PHP2Shell attempts, but the PHP Foundation still had no evidence of a successful compromise. Attempts are not exploitation. A catalog that sticks to the facts will always lag behind the headlines, and sometimes, the entry never comes at all.

That distinction tells you what the catalog is, and what it is not. KEV is not a threat feed. It is a ledger of vulnerabilities that have already been proven to work against someone. That makes it useful and authoritative, but it will always be a step behind. If you start your Monday by prioritizing only what is in KEV, you are putting yesterday's confirmed problems ahead of today's active ones.

This is why you need two queues, not one. The first is your deadline queue: short, dated, auditable. Today, it holds two items that expire tonight. The second is your exposure queue, and no external source will build it for you. That list comes from your own inventory, from asking where PHP is running that you did not install, and from facing the uncomfortable reality that this week's worst incidents came from stolen tokens, not unpatched software. LiteLLM, OVHcloud's CLI, the GitHub Actions secrets harvest, none of these had a CVE, a countdown, or a patch. The queue most likely to hurt you is the one you have to create yourself.

Sources: The Hacker News on the KEV additions · Krebs on Security on the PHP flaw · The Hacker News on the Ruby regex bugs behind the GitLab flaws · CISA KEV catalog

What happened. CISA added two entries on Friday, both due today. CVE-2026–114625, CVSS 9.9, is SQL injection in on-premises Arista VeloCloud Orchestrator, reaching privileged internal functionality and the VCO host; it needs web access plus a session at Enterprise Read Only or above, and is fixed in 5.2.3.18, 6.1.3.10 and 6.4.2.12. It is the third VCO flaw exploited in the wild since July. CVE-2026–110447 CVSS 9.2, is OS command injection in Collabora Online's built-in CODE server, the richdocumentscode package most people meet as the Nextcloud office add-on, reachable via proxy.php. Attackers are dropping web shells with it. Fixed in September, in 26.4.303.

Why does this matter? Both vulnerabilities carry the forensic triage flag, which means your job is not just to patch, but to check whether you were already compromised. Notice the contrast: an SD-WAN orchestrator is the administrative plane-if someone owns it, they control everything beneath it. A Nextcloud add-on is the opposite: often installed for convenience, likely outside your inventory, and rarely on anyone's patch schedule. The Collabora fix has been available for a month.

Do this week. Today, not Wednesday. Confirm your VCO version against the three fixed branches, then audit the account list from Enterprise Read Only upward and disable anything without a named owner; exploitation needs a session, and dormant accounts supply them. Grep perimeter logs for Arista's two published indicator addresses. Then run occ app:list on every Nextcloud instance you operate, including the one that is somebody's team wiki, and get richdocumentscode to 26.4.303. If you have a CODE server that is present but not in use, remove the app instead of patching it. Since web shells were the payload, compare the web root for PHP files newer than your last release. Then document what you checked and what you found, even if the answer is "could not determine." That written record is your deliverable, not just the patch ticket.

Sources: The Hacker News · SecurityWeek on the third VCO zero-day · BleepingComputer · Arista advisory 0199, via the KEV entry

What happened. On Wednesday, the PHP Foundation shipped emergency fixes for two unauthenticated RCE flaws, both CVSS 9.2, in every version of PHP: CVE-2026–109618 corrupts memory by timing a request to hit memory_limit, and CVE-2026–109619 abuses internal state that outlives the request memory it points at. Amazon saw honeypot attempts from October 17, four days before the patch; Cloudflare counts attempts in the millions; Mirai operators have joined, and an ASLR bypass has surfaced. Fix to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Two days later, PHP disclosed a third, still-unpatched RCE, CVE-2026–115560.

Why does this matter? Patching is the easy part, and most teams have already done it. The real challenge is that PHP is not just a website technology; it was the default web technology of the 2000s. That means every device from that era with a browser-based configuration page could be affected. Adrian Sanabria at SANS lists router firmware, Cisco virtual appliances, captive Wi-Fi portals, Roundcube, Cacti, phpMyAdmin, Moodle, and FreePBX. Criminals are still using the last major PHP RCE two years later. This is a long tail problem, not a quick patch cycle.

Do this week. Re-date the hunt: anyone who scoped log review from October 21 redoes it from the 17th, and since no indicators have been published, hunt behavior instead, your EDR watching for php, php-fpm or a web server spawning a shell, an interpreter, curl or wget. Then build the inventory that almost nobody has-not just which servers run PHP, but which appliances, containers, and vendor products have it embedded. Get a written fix date from each vendor. If a vendor has not published a date, treat that as your answer. session.upload_progress, the only mitigation for the unpatched third flaw.

Sources: Krebs on Security · BleepingComputer on the October 17 start · SecurityWeek on Mirai and the ASLR bypass · The Hacker News on the unpatched third flaw · Dark Reading · SANS NewsBites 28.79 for the Bischoping quotation and the Sanabria inventory list, cited as plain text because NewsBites links are click-tracked and useless to a reader.

What happened. Count them. A malicious LiteLLM 1.107.0 carrying an infostealer and a RAT sat on PyPI and Docker for under three hours on October 21; the attacker held three sets of developer GitHub CLI credentials, disabled branch protections, force-pushed, and signed the artifacts from a lookalike repository. OVHcloud CLI versions 0.11.0 to 0.15.0 were retroactively replaced with secret-stealing builds for ninety minutes on October 19, because release immutability was switched off. The campaign Wiz calls Gheist uses stolen GitHub tokens to push workflows that print repository secrets into Actions logs, then deletes the runs. And AOMEI Backupper's update channel was tampered with in five- to ten-minute bursts from April to July.

Why does this matter? It is the same attack, four times, and there is nothing to patch in any of them. The credentials were valid. The pipelines did exactly what they were built to do. The real failure was that a developer's token could change a published release, secrets were accessible to a workflow, and nobody noticed until a customer reported it-OVHcloud credits a customer for the discovery. Compare this to item 02: PHP2Shell generated millions of attempts and no confirmed compromise, while four attacks with no CVE quietly put real malware into production environments.

Do this week. unpinned or pulled a LiteLLM image on the 21st, treat every key that gateway held as compromised. That includes every model-provider credential you have. Pin to 1.106.2. OVHcloud CLI users should move to 0.16.0 and rotate every secret stored on disk, not just the API token. Then address the structural issues-these are an afternoon's work, not a week: turn on release immutability for your repositories and verify it, since OVHcloud's was off; inventory which tokens and OAuth apps can publish an artifact, and shorten their lifespans; move CI secrets into a manager that issues short-lived tokens, because Gheist's entire technique is printing secrets to a log; and pin dependencies with a lockfile.and pin dependencies with a lockfile.

Sources: SecurityWeek on LiteLLM · BleepingComputer · The Hacker News on Gheist · Dark Reading on the OVHcloud CLI compromise · The AOMEI Backupper timeline and the Google Threat Intelligence Group guidance come only from SANS NewsBites 28.79, cited as plain text; no wire source carried it this week.

On Tuesday, Accenture, Dragos and the SANS Institute launched the Community Cyber Resilience Foundation with roughly $10 million to start. Phase one covers up to 500 US water, wastewater, electric and natural gas utilities turning over under $100 million a year, a threshold that, by the founders' own arithmetic, describes more than 50,000 organizations, over 97 percent of American utilities. Participants get the Dragos Platform, help deploying it, funded hardware, ICS/OT training and a peer network. It builds on a program that works: Juneau's water utility, staffed by three people, went from roughly 85 percent critical-system up. Now compare that to the start of this edition. Two KEV entries are due today and require triage; three more are due November 3, including a Siemens flaw being exploited through a ClickFix campaign that relies on someone pasting a command. Each one needs a human to look, decide, and sign off on the outcome. Tools are capital; triage is payroll. A grant can buy the first, but not the second. The real question is not whether the platform gets deployed, but who is watching it on day 400-and what happens when the one person you trained takes a better offer. Visibility without capacity turns "we did not know" into "we knew and did nothing."did not know" into "we knew and did nothing."

So if you run one of these utilities, apply, then fight for the headcount before the hardware arrives, because the requisition is far easier to justify while the gift is in the news. And if you are trying to get into this field, municipal systems and rural co-ops are the least crowded entry point in security right now; they are about to acquire tooling they cannot staff, and three-person teams hire for aptitude rather than twelve years of it.

Sources: SecurityWeek on the Community Cyber Resilience Foundation · This item rests on SecurityWeek's report, corroborated independently in SANS NewsBites 28.79, which is also the source of the Juneau uptime figures and is cited as plain text. SANS is a founding partner of the program, which is worth keeping in mind when reading its own coverage.

BOD 26–04, Prioritizing Security Updates Based on Risk, issued June 10, 2026, replaced BOD 22–01 outright. Where 22–01 gave every KEV entry a flat deadline, 26–04 scores four yes-or-no questions, publicly exposed, automatable, total or partial control, in KEV, and assigns a window accordingly, from three days with forensic triage at the top down to fix-on-upgrade. Agencies have until December to be meeting those timelines.

Here is something the catalog shows that no outlet has reported. Across all 272 entries CISA added in 2026, every entry carrying forensicTriage = Yes has a three-day window: all 91 of them, without one exception. The flag first appears on June 25, two weeks after the directive took force. The due date alone isn't a signal: 53 entries got three days with no triage requirement at all. So the field to watch in your tooling is not the deadline; it is forensicTriage, the one place CISA states, machine-readably, that patching is not sufficient evidence of remediation. Four of this week's five three-day entries carry it; none of the three fourteen-day entries does.

Two things to document before Friday. Correct any policy language claiming the fourteen-day tier has fallen out of use; this brief said so last week, and the catalog has since proved otherwise. Then produce two lists: asset classes you can actually triage within three days, and those you cannot. The second list is the finding.

Sources: Tenable's FAQ on BOD 26–04, for the tier structure and compliance dates · CISA KEV catalog, for the computed forensicTriage finding · The directive itself is at cisa.gov, unreachable from this working environment; the tier structure is sourced to Tenable's summary and cross-checked against the requiredAction text CISA writes into every KEV entry. This edition computes the 91-of-91 finding and reports it nowhere else.

No sponsors. Never any sponsors. Everything here is free, and this one is Apache-2.0.

Item 02 asks for an inventory of embedded PHP, which sounds like a quarter of work and is closer to an afternoon. Grype scans container images, directories, and SBOMs for known vulnerabilities, and, for this week, it ingests CISA KEV and EPSS data and sorts findings by them.

Homebrew users can run brew install grype; on Windows, winget install Anchore.Grype.

Step 1: Scan one thing and read the columns

You get package, installed version, fixed version, vulnerability ID and severity — more than most asset databases will tell you about what is on the box.

Step 2: Sort by the thing that carries a deadline

This is the flag worth memorizing. — sort-by accepts kev, lifting entries in CISA's catalog to the top of the output instead of whatever scores highest on CVSS. Pair it with — only-fixed so you see only what you can act on today:

Valid values are package, severity, epss, risk, kev and vulnerability; the default is risk. Notice what that flag does: it reorders your queue by observed exploitation rather than theoretical severity — the argument of BOD 26–04 expressed as a command-line option.

Step 3: Find PHP where you did not put it

Pair it with Syft, from the same project, which produces the bill of materials Grype can read. Generate once, query many times:

Run that against the vendor appliance images in your registry, and you will find PHP you did not know you owned. Then wire it into CI, where — fail-on sets the exit code to 2 at or above a chosen severity:

Why this one

For a practitioner, it turns "where is PHP running?" from a question you ask people into one you answer with a command, and it reads images, hosts, and SBOMs with the same syntax.

For a GRC function, it produces timestamped evidence. An SBOM written to a file on a dated run, plus a Grype report generated from that same file, is a reproducible statement about what was installed and what was known about it that morning, materially stronger than a scanner summary nobody can regenerate.

And if you are breaking into the field, scan three public container images, sort by KEV, and write a one-page note on what carries a federal deadline and what does not. This interview proves three things at once: you can operate the tool, you know the difference between a severity score and observed exploitation, and you treat an SBOM as evidence rather than a checkbox. Most candidates can name a scanner. Very few can explain why they sorted the output the way they did.

Sources: Grype repository · Grype CLI reference, for the flags quoted above · Grype getting-started guide · Syft repository

• Oct 26: TODAY. KEV deadlines for Arista CVE-2026–114625 and Collabora CVE-2026–110447, both carrying the forensic triage requirement.
• Oct 27: SANS executive roundtable on coordinated critical-infrastructure disruption, with Tim Conway, Robert M. Lee, Mark Bristow and Brian Harrell.
• Nov 3: KEV deadlines for Siemens Software Center CVE-2026–110936 and Plex Media Server CVE-2026–96652 and CVE-2026–96655 — the only three clocks in the catalog still running.
• Nov 3: SANS webinar: AI Summit Fall Solutions Track.
• Nov 5: SANS webinar: Agentic AI Threats and SOC Autonomy, with new survey data on detecting prompt injection and non-human identity compromise.
• Nov 10: Microsoft Patch Tuesday, the first since the record 1,413-fix October release.
• Nov 16–17: SANS CyberThreat 2026, London.
• Dec 7: BOD 26–04 180-day mark: federal civilian agencies must be meeting the directive's remediation timelines, not merely planning to.
• Jan 2027: Windows Server 2016 reaches end of support and stops receiving security updates.

If a developer's laptop in your organization were compromised tonight, which of your published software releases could that person's token silently rewrite?

Most teams cannot answer this because they never framed the permission as a risk-they framed it as being able to ship. That is exactly the position OVHcloud was in: release immutability was available, switched off, and nobody had decided to switch it off, because nobody had been asked. Four separate poisonings this week ran through the same door, and in three of them the valid credential of a trusted person was the entire exploit chain. So the honest answer points somewhere unglamorous and cheap. List, by name, every human and machine identity that can publish or alter an artifact your customers install, and put an expiry date beside each one. It will take an hour, it will embarrass somebody, and it is a better use of this week than any patch on your list, because the patch has a deadline that will remind you, and this does not.

Researched and produced by Devore J. McIntosh · CyberDev · BCT North. The Friday Cyber Recap covers what the week meant; this covers what to do about it. Keeping you safe, one click at a time.

Originally published at https://www.linkedin.com.