Every other month, a critical infrastructure breach makes the news. An enterprise edge product receives another CISA emergency directive. A boundary security appliance line is found to again permit pre-authentication code execution. A consumer connectivity device family is quietly conscripted into a botnet, again. The cadence has become so regular that it has stopped being shocking, which is the problem itself.
The dominant narrative in the security industry in 2025 and 2026 has been the artificial-intelligence vulnerability-discovery mythos. Agentic large language models are alleged to identify zero-day vulnerabilities at superhuman speed. Autonomous pentesting systems are described as imminent replacements for human operators. So-called reasoning models are presented as capable of analyzing source code like trained researchers. Several reports circulated of artificial intelligence identifying real-world defects during this period. The sector rebranded itself, and vendors raised tens of millions of dollars based on slide decks promising to industrialize bug discovery.
The position that proponents of this mythos are reluctant to articulate is the following.
Defects are not hidden; the industry’s main challenge is not defect discovery. The same vendors repeatedly ship the same defect classes, many of which are documented in CVEs over a decade old. While prevailing narratives claim the bottleneck is discovery, evidence points to accountability as the actual bottleneck: specifically, vendor politics, bug-bounty incentives, silent patching, under-resourced security teams, and a culture that penalizes defect reporters as much as it ignores defects.
What follows is a field report based on approximately ten weeks of pipeline operations conducted by the present author and the CyberDagger team. None of the primitives described is novel. Most of the high-severity findings map cleanly to defect classes that were treated as textbook material by 2003.
What “discovery” looked like, in summary
This post is intentionally light on specifics. Most of the work referenced below is inside an active coordinated-disclosure window under the Responsible Disclosure Policy at https://cyberdagger.com/responsible-disclosure/. Naming a vendor, product, technology stack, protocol, operating system surface, component, or finding identifier before disclosure completes could risk the engagement, the timeline, or the safe-harbor posture guiding the work. Technical details for each finding, named by vendor, will follow at the end of each ninety-day window.
What can be stated at this stage is the work’s shape.
Since the pipeline began operation in February 2026, approximately ten weeks ago, it has produced approximately one hundred high-confidence findings spanning several product categories, with tens of CVE assignments currently pending across active disclosure batches. The findings span the full severity range, with a meaningful subset rated at the CVSS 9-class level. Some findings form end-to-end exploit chains; others remain standalone primitives. Some are confirmed in dynamic harnesses against the live product; others are confirmed against a faithfully reconstructed component but do not reach operational impact on the actual product surface, a category that the prevailing slide decks do not have a column for, which is itself germane to the argument advanced here.
The point of the preceding paragraph is not the count. The point is that the count exists at all.
None of these primitives are novel
If the specifics are blurred and only the defect classes are examined, the picture becomes striking.
- Cleartext-fallback updates triggered when an authenticated transport is unreachable, a class of defect documented for over a decade.
- Authenticated transport with peer verification disabled in stock configuration, identified in baseline hardening guides since at least the mid-2010s.
- Hardcoded fleet-wide credentials and licensing material embedded in shipped images, a class made notorious during the Mirai era of eight years ago.
- Unsigned auto-update payloads, a defect class that has its own Wikipedia entry.
- Permission misconfiguration on operating-system-level shared objects, set programmatically by the vendor’s own code during the default install, is a class of issue covered in introductory secure-coding training going back 20 years.
- Confused-deputy patterns in which a privileged service acts on a less-privileged caller’s behalf without dropping privilege, a pattern documented in the relevant API specifications themselves.
- Memory-safety primitives in high-frequency code paths that have not been refactored in 10 years, observed to remain unchanged in binaries tested across multiple major releases.
- Length-handling underflows in parser code that has reportedly been audited many times across the industry but that does not appear to have been audited in the build shipped to customers.
These are not new defect classes. These are old defect classes still being shipped in 2026, in flagship products that retail at four-figure prices and carry support contracts that retail at five-figure prices.
The notion that artificial intelligence discovers zero-day vulnerabilities is misplaced. The real question is: why do fundamental defect classes still appear in 2026 in products repeatedly listed in the CISA Known Exploited Vulnerabilities catalog?
What “thousands of findings” actually means
The marketing side of this market favors large numbers on slides. Our agent generated 12,000 findings last quarter. Our pipeline triages a CVE in nine seconds. We have automated the work of forty pentesters.
Set against those numbers, the 100 high-confidence findings and the tens of pending CVE assignments described in the previous section may at first appear small. They are not. These results represent the bottom of a funnel. That funnel begins, in any honest pipeline, with thousands of raw candidate signals. Almost everything in between is an artifact. Every credible vendor in this market is operating on a similar funnel. What differs is which number on that funnel the vendor chooses to put on the slide. The number that the present pipeline is willing to defend in a coordinated-disclosure email to a CVE Numbering Authority is the bottom one, not the top one.
What follows is the honest accounting beneath the headline, which is the question every vendor in this market should be asked about its own pipeline.
The raw candidate set here numbers in the thousands. It includes static-analysis hits, dynamic-scanner flags, dangerous-function call sites tagged in disassembly, fuzzer crashes, sanitizer reports, and large-language-model “this looks suspicious” signals. The ratio of raw candidates to actual disclosable findings, with a working proof of concept and a reachable code path in the real product, is severe. Three patterns recur.
- Fuzz-harness false positives. A campaign produces hundreds or thousands of crashes. After deduplication and replay against the actual binary rather than the harness, the surviving set collapses to a handful, and a non-trivial share of the early “criticals” turn out to be artifacts of the harness’s initialization not matching production behavior. Single-digit-percentage survival rates are common among published open-source targets, where the source code is fully available; closed-source targets are harsher still.
- Static-analyzer rediscoveries and dead code. A scan produces thousands of CVE flags from the tool’s internal database. After filtering for version-pinned false positives, dead-code paths, compiled-out components, and code only reachable from already-authenticated configuration paths, the surviving set collapses to dozens. Many survivors are already-published CVEs re-flagged by the tool’s database. Single-digit percent novelty rates from large scans are normal, not embarrassing.
- Real defect, non-exploitable on this product. A widely embedded component carries an unpatched CVE that reproduces with full instruction-pointer control under sanitizer instrumentation in a faithful harness. The crash is real, and the bug is genuine. However, the defect is not exploitable in the product that statically links the component. The product’s path through the component never reaches the vulnerable routine, or reaches it only when the exploitation precondition is not satisfied. The result is a working remote code execution primitive against the component, but with no path to operational impact on the product. This category is common. Slide decks that count “found a CVE-2025-XXXX” without that distinction are misleading.
The funnel that translates the top number into the bottom number has stages, and almost every stage eliminates between 50 and 95 percent of the surviving candidates.
flowchart TD
A["Candidate signal<br/>~thousands<br/><i>static hit, fuzz crash, 'looks bad'</i>"]
F1["<i>filter</i><br/>deduplicate, version-pin,<br/>exclude already-CVE'd"]
B["Crashing input<br/>~hundreds<br/><i>replays against the actual binary</i>"]
F2["<i>filter</i><br/>confirm not a<br/>harness-init artifact"]
C["Real defect<br/>~tens<br/><i>reproducible, sanitizer-clean, mapped to CWE</i>"]
F3["<i>filter</i><br/>is the code path reachable<br/>from product attack surface?"]
D["Reachable defect<br/>~tens<br/><i>gated by build flags, runtime config, auth</i>"]
F4["<i>filter</i><br/>does it compose into<br/>operational impact?"]
E["Exploitable chain<br/>~tens<br/><i>proof of concept works end-to-end on default config</i>"]
F5["<i>filter</i><br/>will the vendor credit, fix,<br/>or publish?"]
G["Disclosable CVE<br/>~tens (pending)"]
A --> F1 --> B --> F2 --> C --> F3 --> D --> F4 --> E --> F5 --> G
classDef stage fill:#2468A2,stroke:#194367,color:#FFFFFF
classDef filter fill:#b4c5cf,stroke:#194367,color:#333333
class A,B,C,D,E,G stage
class F1,F2,F3,F4,F5 filter
Each transition in the diagram represents weeks of human labor. Is the function reachable from any pre-authentication input? requires reading the dispatch code. Does the harness initialization match the real initialization? requires diffing the allocations. Does the chain survive the default configuration? requires deploying the product, attaching a debugger, and driving the path. Is the defect actually present in the build that the customer runs? requires pulling the binary and inspecting the build flags. None of this is what an agentic large language model is depicted doing in the demonstration video.
The mythos counts the top of the funnel. Defenders, vendors, and CVE Numbering Authorities count at the bottom. When a vendor pitches “12,000 findings per quarter,” the appropriate question is how many of those findings the vendor would attach a researcher’s name to in a coordinated-disclosure email to a CNA. The answer separates the slide deck from the work.
This is also why the claim that artificial intelligence will replace human pentesters lands as marketing rather than as a credible threat. The pentester’s value is not at the top of the funnel, since identifying obvious unsafe primitives, such as calls to strcpy, is trivially automated. The value is located in the seven filter stages below it, and at present those stages remain irreducibly dependent on human judgment.
The actual bottleneck: accountability, not detection
The reason the headlines repeat is not that defects are unfindable. The disclosure-to-fix-to-credit pipeline is structurally broken in ways that discovery-side tooling will not address. The following patterns have been documented across multiple programs over the past several months and are presented in the abstract.
Vendors game severity. A worked example, anonymized: a permission misconfiguration on a sensitive operating-system-level resource, set programmatically by the vendor’s own code with no administrator-controllable toggle, present on every default installation, was closed by the vendor’s triager as “informational, requires insecure system configuration.” The CVSS score, calculated using the FIRST.org calculator, placed the issue in the 9th class. The severity assigned at closure was informational. The full chain that used that primitive to escalate from a low-privilege account to the highest privilege available on the platform was also closed as informational, despite a working end-to-end proof of concept and platform-side audit-log evidence of the elevation. Closing both the primitive and the chain produces a result in which every constituent finding is dismissed despite a working proof of concept on file.
Platforms reassign engagements mid-flight. A vendor program that switches from one bug-bounty contract type to another after submissions are already in queue is a contract change against which the researcher has no leverage. The platform is the vendor’s intermediary, not the researcher’s. This is a structural fact rather than an accusation.
Silent patches with no CVE and no release-note credit. The present records include written closure threads from triagers who admit, in plain language, to a workflow in which the vendor patches the vulnerability and then closes the submission as “duplicate,” “out of scope,” or “not applicable” without issuing a CVE or crediting the researcher. This is a documented pattern, not a one-off interpretation. The pattern directly hides defect history from defenders who are trying to triage their own fleets.
Sealed disclosures. Bug-bounty programs operating in “Nondisclosure” mode, under which the standard disclosure terms prohibit public disclosure even after the submission is closed, produce findings that the downstream defender community will never see. Findings of this shape are presently held in sealed status indefinitely.
Understaffed PSIRTs. Findings that have been triaged and rewarded sometimes drift eight or more weeks past the reward without a CVE assignment, an advisory date, or a release-note ETA, with platform-mediated replies remaining stuck on “no estimated time yet.” This is not a question of malice; it is a question of resourcing. The result for defenders is identical regardless of the cause.
The strongest available artificial-intelligence discovery pipeline could be layered on top of the structures described above, and the headlines would still repeat, because they are not driven by what is undiscoverable. The headlines are driven by what is undisclosed, miscategorized, silently patched, or never fixed.
Technical debt, corporate politics, and budget allocation produce predictable headlines
The same vendor names rotate through the news because the same internal structures keep reproducing the same defects.
Technical debt. Architectures designed for product lines that are a decade old continue to ship in current flagship hardware, retaining the same configuration knobs, fallback behaviors, and upstream identifiers, and in some cases, are distributed across multiple SKUs and multiple branded vendors via OEM relationships. A single fix on the upstream side benefits all downstream products. The corollary is that one architectural mistake propagates across all of them. The work being described is not the exploitation of cleverness; it is the exploitation of the consequences of code reuse without security review.
Corporate politics. Product lines that receive marketing budget for “next-generation artificial-intelligence threat intelligence” do not receive budget for the engineer who would have detected that peer verification disabled shipped in the same configuration file twice. Marketing reliably wins this internal contest because marketing produces the slides that go to the board.
Budget. The reward column in the bug-bounty spreadsheet reflects what the program states a defect class is worth, not what downstream defenders would pay to have the defect patched. A modest reward for a high-CVSS primitive in a product currently listed in CISA KEV is the math the program is using. The math is incorrect, but it is the math.
The mythos asserts that scale will resolve these problems: more agents, more pipelines, more findings per quarter. The available evidence indicates that scale does not resolve accountability gaps. Scale only generates more findings to be silently patched.
Tooling and disclosure practice
Tooling is real, and tooling is useful. The pipeline referenced throughout this post ingests vulnerability-intelligence feeds, generates static-analysis rules from patch diffs, runs LLM-generated harnesses, triages crashes with sanitizer-aware deduplication, and orchestrates dynamic validation against deployed targets. It is used daily. Without it, the volume described above would be reduced by approximately eighty percent.
The pipeline, however, does not find the bugs. The pipeline narrows the surface and presents candidates. The actual judgment, regarding whether a primitive is exploitable in the real binary rather than only in the harness, whether the primitive composes into a chain, whether the vendor will game the closure, and what the protocol actually looks like under a debugger, is human work, and it requires weeks per finding rather than seconds.
The changes adopted in 2026 are the following.
- Direct-to-vendor disclosure with documented timelines, after the platform-mediated bug-bounty channel was concluded to cost more credibility than it produced.
- Published Responsible Disclosure Policy at https://cyberdagger.com/responsible-disclosure/, with a default ninety-day window and Day 0, 7, 14, 30, 60, and 90 milestones recorded per batch.
- Public receipts on Day 90. Where a vendor silently patches and refuses CVE assignment, the current practice is to file via VulnCheck (CNA-LR) or MITRE Root and publish the technical details regardless.
- Cross-vendor coordination notes are baked into every disclosure packet. Where a defect lives in a shared component reused by multiple downstream vendors, every packet includes explicit please notify the other affected parties language up front.
What is described above is not a transformational program. It represents the unglamorous central segment of the discovery-to-disclosure funnel, the segment that the prevailing mythos elides.
What would actually move the needle?
For defenders, three observations follow from the analysis above. Silent-patch advisories should not be trusted; git logs and binary diffs should be examined directly, because vendor accounts of what has been fixed and when have, in the present sample, repeatedly proven unreliable. Embedded components should be treated as part of the defender’s supply chain; the component CVE is, for practical purposes, the defender’s CVE, even when the product vendor takes a different position. The defects that will appear in the headlines next quarter are already present in the products that defenders deployed last year.
For researchers weighing whether to invest in another artificial-intelligence discovery agent or in the labor of writing sixty vendor disclosure emails, the answer follows from the foregoing analysis. The defects are not hidden. The disclosure work is what is missing.
See the full research record → · Live pipeline dashboard →
CyberDagger LLC publishes coordinated disclosure under the policy at https://cyberdagger.com/responsible-disclosure/. Vendor inquiries: [email protected]. Per-finding technical detail, named by the vendor, will be published only after each batch’s disclosure window closes.