A Vulnerability Is Not an Exposure

A vulnerable condition may remain unchanged for years. An exposure changes with the environment and with the attacker’s capabilities. 2,300 Found, 421 Fixed In November 2024 Google reported the first public case of an AI agent, Big Sleep, finding a previously unknown exploitable flaw in real software: a memory-safety bug in SQLite, reported in early October and fixed the same day, before it reached a release [1]. As of 26 August 2026, Anthropic reported 2,300 disclosed vulnerabilities in 392 open-source projects, all found since 1 November 2025. Of these, 421 had been fixed upstream, which is not the same as fixed in every installation [2]. The two programmes are not directly comparable, but the direction is plain enough. Automated discovery is becoming a mass process, but remediation is not. Attackers have the same tool. In May 2026 Google Threat Intelligence Group described, for the first time, a zero-day which it assessed with high confidence had been found and weaponised with the help of AI [3]. Code in which no vulnerability was known yesterday may contain a confirmed one today, and a working technique for exploiting it tomorrow, without changing by a single line. Finding a vulnerability does not necessarily create an exposure. The appearance of a working technique may. One Part of the Exposure Is Not Yours In the previous article (The Anatomy of Exposure: Why the Market Cannot Agree on What Counts as One) I defined an exposure as a combination of an attacker’s starting position, one or more existing conditions, a technique and the target — in short, origin → condition → technique → target. It exists when the target is reachable from that starting position and the technical prerequisites for the technique are satisfied. The condition and the target belong to your environment. The starting position is defined relative to it, although it can shift as an attack progresses: yesterday the internet, today a stolen VPN account. The technique is the element that moves directly with the attacker’s capabilities. That article left one question open: when should a technique be treated as applicable? My answer: when there is a working method of carrying it out, not merely a class of attack to which it belongs. Exposure is therefore a function of two changing systems, your environment and the attacker’s capabilities. Your environment moves too. An upgrade removes one condition and may introduce another; a new route makes reachable what was isolated yesterday; a changed firewall rule opens a path nobody designed. In a working organisation the environment is rarely settled for long. The practical difference is that one of these systems can at least be watched from inside the organisation, through change management, telemetry and configuration-drift monitoring. The other reaches you only through external signals, and usually late. None of this turns exposure into a probability. Its existence remains a matter of yes or no; priority is built from other fields, such as observed exploitation, likelihood and the value of the target. But any statement that an exposure exists holds only at the moment of observation. An entry in the ledger is an observation with a date attached. A change affecting the condition, path, starting position or target leaves the last known state of the exposure in place but removes the confirmation behind it: the record is marked needs_revalidation. The state of the object and the state of our knowledge about it are separate axes and belong in separate fields. The trigger may be a change-management event, a configuration-drift scan, which also catches whatever escaped the formal process, or the expiry of the observation itself. Until it is checked again, the record counts as active. The count errs on the high side by design: revalidation may confirm the exposure or close it. The expiry of a blocked status produces the same mark with different knowledge behind it: the condition is known to be in place, and only the control is in doubt. The Threshold Without a threshold, a “working method” becomes a matter of interpretation, and ledgers kept by different teams will diverge. The threshold I propose is a demonstrated method that carries the attack through to its result and is applicable to the version, configuration and prerequisites present in your environment. For a software flaw that means a functional exploit; a process crash in a test environment does not qualify. For a password-reset procedure it means a rehearsed social-engineering call that gets past the help desk. Publication is not required: a private exploit crosses the threshold as surely as a published one. The proof may be external, and there is no need to reproduce every public exploit yourself. Applicability, however, is a property of your environment. If a functional exploit has been published for the version you run, the instance is reachable and the prerequisites are met, the exposure exists. You need not attack your own production systems to acknowledge it. Until a working method exists, there is no exposure — only a vulnerable condition and some probability that a technique will appear, which is a matter for vulnerability prioritisation. CVSS 4.0 draws the same line in its own terms: the lowest level of its Exploit Maturity metric, Unreported, means only that no one has reported a method [4]. Where no assessment exists at all, the standard assumes the worst. Exists, Observed, Probable What usually ends up in one field is in fact three different things. A working technique appears, and that decides whether the exposure exists at all. Later it may turn up in real attacks, which is what a CVE’s entry into CISA’s Known Exploited Vulnerabilities catalogue records [5]; threat-intelligence reports and your own incidents say the same. Separately, EPSS may judge exploitation more likely: it estimates each day the probability that exploitation of a given CVE will be observed within 30 days [6]. The second and third change priority, not existence. In the ledger they are three fields, each with its own date: feasibility_known_since — when a working method was confirmed; observed_since, with source — when and where exploitation was seen; likelihood_30d — the current estimate and the date it was calculated. The first field records when you learned that the method existed. When it actually appeared, you do not know. A private method reaches your ledger by only three routes: threat intelligence, your own validation or an incident. With an incident, and often with an intelligence report, the first two fields acquire the same date, and both are late. An exposure may therefore exist before it can be recorded. To the ledger it is indistinguishable from absence; to the attacker it is perfectly real. An empty field means “unknown”, not “no”. This is a limitation of the model, and another scanner will not help. Controls Move Too A compensating control does not remove the underlying condition. A WAF does not repair SQL injection, an EDR agent does not alter a vulnerable binary, segmentation does not close a CVE and MFA does not abolish a password. A control changes only the ability to use the condition. That is why, in the previous article, I kept a blocked exposure in the ledger, only in a different column: its state changes, active → blocked, while the record stays. The state has a shelf life, and it can expire in three ways, each found by a different check. The first is bypass. The control sees the attack but reads it differently from the system it protects. In the WAFFLED study, researchers at Northeastern University and Dartmouth College confirmed 1,207 bypass requests against five widely used WAFs, which parsed HTTP bodies differently from the applications behind them [7]. A retest will find such a failure only with the right request. With the old set it will probably stay green. The second is surface mismatch. The control works as designed, but the attack passes outside the surface it covers. CVE-2023-4966, known as Citrix Bleed, let attackers steal valid NetScaler session tokens and open a session without a password or second factor [8]. MFA may have been working perfectly; the attack took the state created after it. The GTIG case is of the same kind. Google described a high-level logic flaw in the two-factor scheme itself: the developer had hard-coded an exception to a trust check, so that anyone with valid credentials could skip the second factor [3]. A test of whether the normal login path demands a second factor could well have stayed green while another path escaped the check. Repeating it will never find the failure; only reconsidering what the control is assumed to cover will. The third is false evidence, where what fails is the source of the green status. In January 2024 Ivanti issued mitigation guidance for its gateways, and attackers got round it. More serious was what CISA then found in its own laboratory: the accompanying Integrity Checker Tool was insufficient to detect compromise, and root-level persistence could survive a factory reset [9]. Such a failure can be found only through evidence independent of the control. Four Questions for a Blocked Exposure If an exposure stays in the ledger after a compensating control is applied, mitigated=true is not enough. For each of the three failures to be detectable, four questions need answers. Source. Who says the technique is blocked: a scanner, the control itself, an independent test, or a person closing a ticket? Date and artefact. When was it last checked, with which test or payload, and has that test been kept? Expiry. How long is the result valid, who is responsible for rechecking it, is the record counted as active once it expires, and how does that affect the count of active exposures? Surface. Which part of the technique does the control actually block, and when was that assumption last reviewed? The questions are not tests in themselves. Their purpose is to preserve the evidence, its provenance and its expiry, and to bring the coverage assumption into the open. The fourth is the most difficult. A control may work correctly and protect the wrong surface. The green status is then entirely honest, and entirely useless. AI Makes a Bad Definition More Expensive Once machines find vulnerabilities, build attack paths and test controls, it is natural to let them set priorities as well. The danger lies in doing so with a poor definition of what is being counted. Discovery is getting cheap, exploits are quicker to build than they were, and validation can be run far more often. A system that cannot tell these events apart merely replaces a slow error with a fast one. Anthropic’s dashboard shows where the defender’s bottleneck lies. Its models produced 26,153 candidates over the same period; external security firms reviewed 5,008 and confirmed 4,576. Anthropic names independent human triage as the rate-limiting step, and some confirmed flaws had not yet been reported for that reason [2]. On the attacker’s side the same bottleneck is narrower and cheaper. In a campaign Anthropic described in November 2025, AI performed 80–90 per cent of the tactical work against some 30 organisations, with humans intervening at four to six critical points [11]. In July 2026 Hugging Face disclosed an intrusion into its production infrastructure carried out end to end by an autonomous agentic system: two code-execution paths in the dataset-processing pipeline, harvested cloud credentials, movement across internal clusters [12]. It was nobody’s campaign: the agent was running an internal OpenAI cyber-capability evaluation, and covered the chain in thousands of small automated decisions with no malicious operator behind it [13]. The two sides do not pay the same price for being wrong. The model in the 2025 campaign also made mistakes, including invented credentials [11], but to an attacker a false hypothesis usually costs a failed attempt, at worst a burnt foothold or an alert. To a defender it may cost a production change, developer time or a false blocked status. So the sequence finding → confirmed condition → applicable technique → exposure can already be traversed almost entirely by AI on the attacker’s side, and in some observed cases end to end. On the defender’s side every step requires evidence, and the more the machine finds, the heavier the burden on those who must act. Human review remains the bottleneck because a defender’s action needs evidence that will stand up afterwards. Agents also create new conditions for attack. One that finds and fixes vulnerabilities needs data, tools and privileges, and OWASP lists identity and privilege abuse among the principal risks of agentic applications: delegated trust, inherited credentials and role chains used to obtain unauthorised access or actions [10]. The agent is not itself an exposure. It may be a target; its identity may be a condition and its privileges part of a path, all under the same model. What to Count A vulnerability tells you what is wrong with a system. An exposure tells you what an attacker can actually use: from which position, by which technique, against which target and in spite of which controls. The two have different lifetimes. A vulnerability exists while the condition remains. An exposure may: appear without any change to the code, because a technique appears; appear or disappear without any change to the code, because reachability, the starting position or the prerequisites change; become blocked without any change to the code, because an effective control is introduced; return, because the control is bypassed, covers the wrong surface or rests on false evidence; become far more important, because the technique spreads among attackers. This alters its priority and leaves its state alone. These are five different events. Reduce them to one severity score or one ticket status, and the history of the object disappears. The metric that matters is how long an attack was actually possible. In practice we measure only its observed part, from the first visible event — our own validation, a published exploit, an entry in KEV, an incident — until remediation. The ledger gives a lower bound. The time a ticket stays open, usually reported as MTTR, measures the process. Observed exposure time measures the part of the attacker’s window that we were able to see or reconstruct. The server, its IP address and its vulnerable binary may not have changed once in all that time. All reasoning, conclusions, and assessments presented in this article reflect my personal viewpoint. The material has been prepared exclusively based on publicly available sources (vendor materials, reports from analytical agencies, industry publications, and open news sources). These views do not reflect and cannot be interpreted as the official position of any organization with which I am currently or have previously been affiliated. The article is purely analytical and educational in nature and contains no internal or confidential information. References and sources are listed in the appendix. Data current as of September 2026. Appendix: A Possible Record Lifecycle A record is described along two independent axes: exposure_state — the state of the exposure according to the latest confirmed evidence: active, blocked or closed; verification_state — the state of our knowledge about it: verified or needs_revalidation. Exposure-state transitions A working method is confirmed for a reachable condition → create the record as active, verified. A compensating control is confirmed → active → blocked. A bypass, surface mismatch or false evidence is found → blocked → active. Revalidation establishes that the condition has been removed or the target is no longer reachable → closed, with closure_reason: condition_removed, unreachable, target_removed or prerequisites_removed. Verification-state transitions A change affects the condition, path, starting position or target, or the observation or control validation expires → needs_revalidation; exposure_state retains its last confirmed value. Revalidation → verified; exposure_state becomes active, blocked or closed according to the result. Sources [1] Google Project Zero, From Naptime to Big Sleep:https://projectzero.google/2024/10/from-naptime-to-big-sleep.html [2] Anthropic, Coordinated vulnerability disclosure dashboard, snapshot 26 August 2026, 11:55 PT, revision 32:https://red.anthropic.com/2026/cvd/Machine-readable payload.json can be used to verify the figures. On the bottleneck: “the process of independent human triage and review is the rate limiting step”. [3] Google Threat Intelligence Group, AI Threat Tracker: Adversaries Leverage AI for Vulnerability Exploitation, Augmented Operations, and Initial Access, 11 May 2026:https://cloud.google.com/blog/topics/threat-intelligence/ai-vulnerability-exploitation-initial-access [4] FIRST, CVSS v4.0 Specification Document, Exploit Maturity (E):https://www.first.org/cvss/specification-document [5] CISA, Known Exploited Vulnerabilities Catalog:https://www.cisa.gov/known-exploited-vulnerabilities-catalog [6] FIRST, EPSS:https://www.first.org/epss/ [7] WAFFLED, arXiv 2503.10846:https://arxiv.org/html/2503.10846v1 **[8]**CISA AA23-325A:https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-325a **[9]**CISA AA24-060B:https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-060b [10] OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications 2026, 9 December 2025, ASI03 Identity and Privilege Abuse:https://genai.owasp.org/resource/owasp-top-10-for-agentic-application [11] Anthropic, Disrupting the first reported AI-orchestrated cyber espionage campaign, 13 November 2025:https://www.anthropic.com/news/disrupting-AI-espionage [12] Hugging Face, Security incident disclosure — July 2026, 16 July 2026:https://huggingface.co/blog/security-incident-july-2026 [13] Hugging Face, Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident, 27 July 2026:https://huggingface.co/blog/agent-intrusion-technical-timeline