SURIQ
A good week, if you take the cue from the security press, is measured by how many critical, exploited, patch-now advisories it can put in front of you. By that measure this was a heavy week. From inside our own desk it looked closer to the opposite: the work was not finding the dangerous flaws but deciding which of the week's thousands could safely be left alone.
That decision, made several thousand times across seven days, is the real shape of self-hosted defense, and it is the part no newsroom can show you. The flaws we chose to publish were genuine, and some were being exploited as we wrote them: an unauthenticated remote-code-execution bug in F5 BIG-IP APM, two pre-auth flaws in Check Point gateways already on CISA's exploited list, an unauthenticated file-inclusion hole in WordPress core reaching back to version 4.7. Each earned its post. But the story of the week is the far larger number you never saw.
The number that matters is the one we did not publish
Every desk that watches vulnerability feeds faces the same firehose, and almost none of it is actionable on any given server. Our ledger for the week breaks down cleanly: of the 4,609 items triaged, more than 4,300 went onto a watch list rather than into anyone's inbox. Around 51 carried some sign of active exploitation, by our tracking. Eight cleared the bar to publish.
Read the funnel the wrong way and it looks like negligence: thousands of vulnerabilities, and we acted on a handful. Read it the right way and it is the entire job. The watch list is not a pile of ignored risk. It is the output of thousands of small decisions that a given flaw cannot reach the reader's servers today, is not being exploited, or does not apply to software they run. Getting those decisions right is what keeps a security program from drowning.
What separated the eight from the rest
Three questions did almost all of the filtering, and none of them was the CVSS score.
The first was reachability. A flaw that requires an authenticated session, a local account, or a specific non-default setting is a different animal from one an anonymous request can trigger. The flaws we escalated this week were reachable before a login: the F5 bug sits in the OAuth authorization path, the Apache Roller flaw lives in an XML-RPC endpoint that answers before authentication, and a WooCommerce quote plugin accepted file uploads from anyone who found the handler. Pre-authentication reach is the single attribute that most reliably turns an advisory into an emergency.
The second was exploitation in the wild. A proof of concept in a researcher's repository and a flaw being sprayed across the internet are weeks and orders of magnitude apart. We weight a KEV listing, honeypot hits, or credible vendor telemetry far above a high severity number with no evidence anyone has used it. An access-control flaw in Cisco ISE was already being exploited when its advisory landed, which is exactly what moved it to the front. Most of the more than 4,300 on the watch list are there precisely because that evidence has not appeared yet, and the moment it does, an item moves.
The third was stack match. A critical bug in software you do not run is not your problem, and a moderate one in software exposed on every host might be. This is where raw counts mislead most. Cross-site scripting was again the single largest class we triaged, more than 260 flaws this week. Not one of the vulnerabilities exploited in the wild this week was cross-site scripting. The class that was being exploited, command injection and remote code execution, ranked second by volume, close to 250. A team that triaged by count would have spent the week on the wrong category.
The reverse decision matters just as much. A denial-of-service flaw in containerd crossed the desk this week, a genuine bug that can burn CPU and memory during an image pull. It is real, it has a CVE, and for almost every reader it belongs on the watch list, not in an alert: it needs a hostile image to be pulled, it degrades rather than compromises, and it competes for attention against flaws that hand an attacker code execution. Deciding quickly and correctly that a real vulnerability can wait is the same skill as deciding that another one cannot.
Volume is the attack on your attention
There is a quieter failure mode than missing a patch, and it is more common: burning a team's finite attention on the 4,300 that could wait while the eight that could not sit in the same undifferentiated feed. The security press does not help here. It amplifies by count and by drama, so a week reads as a wall of critical, exploited, act-now headlines with no denominator attached. The denominator is the point. Without it, every advisory looks equally urgent, and a defender who treats them that way is choosing at random.
We made a narrower version of this argument three weeks ago, when most of the flaws exploited that week already had a fix available. The pattern holds and generalizes. The scarce resource in self-hosted defense is not information about vulnerabilities. It is attention. Anything that spends attention without reducing risk is a cost, and an undifferentiated feed spends a great deal of it.
This is also why the count of what a team ignores is a better measure of its maturity than the count of what it catches. A program that escalates everything is not careful, it is unfiltered, and it will miss the one that matters inside the noise it made for itself. The skill on display in a normal week is suppression: the confidence to look at more than 4,300 real vulnerabilities and correctly decide they can wait.
Build the filter before the next 4,600 arrive
Turning that principle into practice does not need a bigger feed. It needs a filter, and the same three questions build it.
Keep a live inventory of what is actually exposed before authentication on each host: the login pages, API endpoints, upload handlers, and legacy interfaces like XML-RPC that answer an anonymous request. That list is short and finite, unlike the list of CVEs, and it is where nearly every flaw worth an emergency will land. When an advisory drops, the first question is whether it touches something on that inventory.
Subscribe to exploitation signal, not just severity. CISA's Known Exploited Vulnerabilities catalog, honeypot and telemetry feeds, and credible vendor confirmations tell you which flaws have crossed from theoretical to in use. Let that evidence, rather than a severity number, decide what jumps the queue. A 9.8 with no exploitation can often wait behind a 7.5 that is being used today.
Match every advisory to the versions you actually run before it costs you a minute of worry, because most critical vulnerabilities are critical for someone else's stack. And keep the watch list honest: it is not a graveyard but a queue you revisit when exploitation status changes, because the item you parked as theoretical on Monday is the one that shows up in KEV on Thursday. The eight we published this week were, a few days earlier, entries on exactly that kind of list.
Methodology: figures are drawn from the Suriq threat desk's own intelligence and news ledgers over the stated window. "Triaged" counts events we logged a decision on, not raw signal volume; exploitation figures are best-effort and labelled approximate.