Security reporting regularly describes a vulnerability as “actively exploited in the wild.”
The phrase carries enormous practical weight. It can move a flaw from an ordinary patch queue into an emergency maintenance window. It can trigger government directives, executive briefings, incident-response retainers, credential rotation, emergency firewall changes, and retrospective compromise assessments.
But how does anyone actually know?
Researchers do not normally watch an attacker announce, in real time, that he is exploiting a particular CVE against a real victim. The determination is assembled from evidence: network traffic, endpoint telemetry, malware samples, server logs, forensic artifacts, honeypot observations, vendor data, customer incidents, exploit reconstruction, and the technical relationship between an observed request and the vulnerable code.
The quality of that evidence varies enormously.
A scanner touching a vulnerable endpoint is not the same as successful exploitation. A public proof of concept is not evidence that anyone has used it against a victim. A suspicious crash is not necessarily malicious. A honeypot receiving an exploit payload proves hostile delivery, but not necessarily compromise of a production system. A webshell found on an affected server is strong evidence of compromise, but investigators must still determine whether the relevant vulnerability placed it there.
Understanding these distinctions is essential because “active exploitation” is not merely a descriptive label. It is an evidentiary judgment.
What “In the Wild” Actually Means
In security research, “in the wild” distinguishes real-world malicious activity from controlled experimentation.
A vulnerability demonstrated by its discoverer in a laboratory is exploitable. A vulnerability incorporated into public proof-of-concept code is publicly reproducible. A vulnerability used without authorization against an actual target is being exploited in the wild.
The target does not necessarily need to be a conventional production organization. Malicious exploit delivery observed by a research sensor or honeypot may establish that an actor is attempting real-world exploitation, provided the activity is not attributable to authorized testing or ordinary security research.
The phrase therefore describes the context of use, not merely the technical maturity of the exploit.
A vulnerability may have:
- a detailed advisory but no public exploit;
- a working public proof of concept but no observed attacks;
- widespread scanning but no exploit payloads;
- exploit payloads delivered to honeypots;
- confirmed successful exploitation at one organization;
- multiple compromises across sectors;
- automated integration into botnets, ransomware operations, or mass-exploitation frameworks.
All of these conditions represent different stages of threat development.
Collapsing them into a single phrase deprives defenders of information they need for prioritization.
CISA’s Standard: Reliable Evidence, Not Theoretical Exploitability
The best-known formal designation is the U.S. Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities Catalog.
CISA requires three conditions before adding a vulnerability:
- The vulnerability must have an assigned CVE identifier.
- Reliable evidence must show that it has been actively exploited.
- A clear remediation action must exist.
CISA explicitly distinguishes active exploitation from the mere existence of research, scanning activity, or proof-of-concept code. A vulnerability does not qualify for KEV simply because someone has shown that exploitation is possible.
That distinction is one reason KEV is operationally valuable. CVSS estimates technical severity. EPSS attempts to estimate the probability of near-term exploitation. KEV records a different fact: CISA has accepted evidence that exploitation has already occurred.
The public rarely sees all of that evidence.
CISA may receive information from vendors, federal agencies, incident-response firms, intelligence partners, affected organizations, researchers, managed-security providers, or classified and law-enforcement channels. Victim confidentiality and intelligence sensitivities may prevent it from publishing the underlying logs, samples, or case details.
A KEV listing therefore communicates that CISA considers the evidence sufficient, but it does not necessarily allow an outside reader to independently reconstruct the case.
That is an important limitation, but it is not a reason to dismiss the designation. It means KEV is an authoritative operational signal rather than a complete public evidentiary record.
The Evidence Ladder
It is useful to think about exploitation evidence as a ladder. Each step supports a stronger claim than the one below it.
1. Vulnerability Discovery
A researcher identifies a security defect and demonstrates it under controlled conditions.
This proves that the vulnerability exists. It does not prove that a malicious actor knows about it or has used it.
The researcher may have a complete exploit, a partial primitive, a crash, a code path, or a theoretical analysis. The technical quality of the finding can be excellent while still providing no evidence of hostile activity.
2. Public Technical Disclosure or Proof of Concept
Detailed analysis, patch diffing, exploit code, detection artifacts, or a Metasploit module becomes available.
This establishes that exploitation knowledge is accessible. It may reduce the skill and time required for an attacker to weaponize the flaw.
It still does not establish active exploitation.
This is one of the most common errors in vulnerability reporting. A headline may move from “public PoC released” to “hackers can now exploit” and then be repeated elsewhere as “hackers are exploiting.” The grammatical shift quietly converts possibility into observed fact.
3. Scanning or Reconnaissance
Internet sensors observe actors searching for the affected product or endpoint.
Examples include:
- requests for a distinctive login page;
- banner collection;
- version checks;
- probes for a vulnerable path;
- attempts to identify exposed management interfaces;
- harmless requests used to determine whether a feature is enabled.
This proves attacker or researcher interest. It does not prove that an exploit was delivered.
Scanning can begin within minutes of disclosure because automated systems continuously ingest CVEs, GitHub repositories, social-media posts, and vendor advisories. Some activity comes from security companies, academics, internet-measurement projects, bug-bounty researchers, or administrators assessing their own exposure.
Source reputation, payload structure, follow-on behavior, and infrastructure history all matter.
4. Exploit-Payload Delivery
A sensor captures traffic that exercises the actual vulnerable condition.
This is substantially stronger evidence.
The request may contain:
- a malformed serialized object;
- a command-injection string;
- a path-traversal sequence;
- a crafted SAML assertion;
- an overflowing field;
- a malicious template expression;
- a file-write action;
- a distinctive exploit chain reproduced from public research.
Researchers then compare the payload with the vulnerable code, the patch, known proof-of-concept material, or their own reproduction.
If the payload is technically valid and was sent without authorization, it supports the statement that exploitation was attempted in the wild.
It may not prove success.
The target may be patched. A prerequisite may be absent. A WAF may block the request. The payload may contain an error. The attacker may be testing an exploit against every visible host without knowing which are vulnerable.
This is why careful researchers say “exploitation attempts observed” rather than “systems compromised.”
5. Observable Exploit Success
The receiving system exhibits the security effect predicted by the vulnerability.
Examples include:
- a command executes;
- a file is written;
- a new administrator account appears;
- process memory is returned;
- authentication is bypassed;
- an attacker-controlled session is created;
- a callback reaches the actor’s server;
- a child process is spawned by the vulnerable application;
- data becomes accessible across a trust boundary.
At this point, the evidence supports successful exploitation rather than mere delivery.
A honeypot can sometimes establish this stage. A deliberately vulnerable instrumented system may record the request, the resulting process creation, the filesystem change, and the outbound callback.
But even then, terminology should be precise. Successful exploitation against a research decoy proves that attackers possess and are deploying a working exploit. It does not prove that a production victim has been compromised.
6. Confirmed Victim Compromise
An incident-response investigation finds that the vulnerability was used to compromise a real organization.
This is among the strongest forms of evidence.
Investigators may reconstruct a chain such as:
- an external request reaches the vulnerable server;
- the application writes a webshell;
- the webshell executes a discovery command;
- the attacker delivers a payload (exploit string, malware);
- credentials are stolen;
- lateral movement follows;
- data is exfiltrated or ransomware is deployed.
The strength comes from correlation across multiple telemetry sources:
- reverse-proxy or web-server logs;
- application logs;
- endpoint detection;
- process telemetry;
- filesystem timestamps;
- authentication records;
- network flow;
- DNS;
- cloud audit logs;
- malware samples;
- memory images;
- attacker infrastructure.
No single artifact must carry the entire conclusion. The chain becomes persuasive because independent evidence sources agree.
7. Repeated or Widespread Exploitation
Multiple independent victims, telemetry providers, or research teams observe the same exploit pattern.
At this stage, researchers can begin to assess scale, targeting, and actor behavior.
They may determine whether exploitation is:
- opportunistic or targeted;
- manual or automated;
- confined to one sector;
- associated with espionage;
- used by an initial-access broker;
- incorporated into ransomware operations;
- added to a botnet;
- spreading through a static target list;
- occurring before or after public disclosure.
Unit 42’s analysis of the 2025 SharePoint ToolShell campaign provides a good example of progressively accumulated evidence. Its telemetry distinguished pre-exploitation testing from later exploit attempts, tracked timestamps and source infrastructure, and connected activity with follow-on webshells, key theft, persistence, data loss, and ransomware.
That level of detail supports far more than the generic claim that “hackers are scanning for SharePoint.”
Where the Evidence Comes From
No single organization sees the entire internet. Exploitation determinations emerge from different visibility points.
Vendor Telemetry
Large software and cloud vendors may have enormous observational advantages.
Depending on the product and customer configuration, vendors may receive:
- crash reports;
- endpoint detections;
- cloud-service logs;
- malware submissions;
- authentication anomalies;
- security-product alerts;
- update telemetry;
- exploit-prevention events;
- customer-support cases.
A vendor may recognize that multiple customers are experiencing the same unusual failure or attack sequence before the vulnerability has been publicly identified.
Microsoft, for example, combines MSRC vulnerability handling with threat-intelligence and security-product telemetry. When Microsoft reports observed exploitation, the conclusion may reflect Defender detections, cloud signals, incident-response work, or direct victim evidence. Its public advisory may reveal only a small part of that basis.
The strength of vendor telemetry is scale.
Its weakness is opacity. Outsiders may be unable to inspect the evidence, understand collection biases, or determine how many customers were affected.
Incident-Response Investigations
Incident responders often produce the clearest exploitation evidence because they can examine the victim environment directly.
They can establish:
- the first malicious request;
- the vulnerable version;
- the exploit prerequisite;
- the resulting process or file;
- the attacker’s subsequent actions;
- the absence of an alternative initial-access path.
The central challenge is attribution of cause.
Suppose investigators find a webshell on an unpatched server. That does not automatically prove that the newest headline vulnerability installed it. The server may also have exposed credentials, an older unpatched vulnerability, a compromised administrator account, or another reachable application.
The strongest investigations reconstruct the sequence rather than assuming it.
Timestamps must align. The exploit request must be technically valid. The vulnerable component must have processed it. The resulting artifact must match the vulnerability’s capabilities. Competing explanations must be considered.
EDR, MDR, and Security-Product Telemetry
Endpoint and network-security companies may observe exploitation across many customers.
They can search for patterns such as:
- a web server spawning a command shell;
- an appliance writing an unexpected file;
- a Java process launching a downloader;
- a new service following a distinctive request;
- an authentication event lacking a normal identity-provider record;
- repeated callback domains after exploitation.
Rapid7’s reporting during the 2021 Microsoft Exchange crisis, for example, cited multiple related compromises observed through managed detection and response, including attackers uploading webshells. That is much stronger than observing port scans or Exchange fingerprinting.
The risk is product-selection bias. A provider sees customers using its tools, in environments where telemetry is enabled and retained. Absence from its dataset does not establish absence from the wider world.
Honeypots and Deception Infrastructure
Honeypots are systems designed to attract and record hostile activity.
They may imitate:
- SSH servers;
- web applications;
- VPN gateways;
- databases;
- industrial systems;
- cloud metadata services;
- vulnerable appliances;
- exposed administrative interfaces.
A basic honeypot records requests. A high-interaction honeypot may run the real vulnerable product in an isolated environment, allowing researchers to observe the exploit’s effects.
Honeypots are particularly useful for answering:
- How soon did exploit traffic begin?
- What endpoints are attackers targeting?
- Are payloads copied from a public proof of concept?
- Are actors validating vulnerability before sending the exploit?
- What commands or malware follow successful exploitation?
- Which source addresses and autonomous systems are involved?
But honeypot evidence must be interpreted carefully.
Attackers know honeypots exist. Researchers scan them. Some payloads are broken. Some actors spray exploits indiscriminately. A successful result against a deliberately vulnerable decoy does not reveal how many real organizations were compromised.
The strongest honeypot reports clearly separate payload received, exploit succeeded on sensor, and production victims confirmed.
Network Sensors, WAFs, and Internet Telescopes
Organizations with broad network visibility can identify sudden bursts of requests matching an exploit pattern.
WAF providers may detect:
- traversal strings;
- injection patterns;
- malicious serialized data;
- exploit-specific headers;
- requests to newly disclosed endpoints.
Internet telescopes and distributed sensors can measure scanning volume and geographical spread.
This can provide early warning, but signature quality is decisive.
A loose signature may count benign requests or ordinary scans as exploits. A signature copied from public proof-of-concept code may detect only exact replicas while missing modified payloads. An encrypted protocol may leave only metadata unless the sensor terminates the session.
Researchers should explain what their signature detects and what it cannot establish.
Malware Samples and Exploit Artifacts
Sometimes the exploit is recovered from:
- a malware sample;
- an attacker toolkit;
- a server-side script;
- a leaked exploit framework;
- a compromised command-and-control server;
- a victim’s filesystem;
- memory captured during an incident.
Reverse engineers can inspect the code and determine which vulnerability it targets.
This may reveal exploitation that was not obvious from logs, particularly when the attacker deletes artifacts or uses encrypted traffic.
However, possession of exploit code does not prove deployment. Investigators still need execution evidence, victim telemetry, or operational infrastructure connecting the code to real attacks.
Sinkholes and Command-and-Control Infrastructure
Researchers sometimes seize, redirect, or sinkhole attacker-controlled domains and servers.
A sinkhole may receive callbacks from compromised systems, showing that implants or post-exploitation payloads are active.
This can help estimate infection volume and identify victim sectors.
But a callback usually proves that malware executed, not necessarily which vulnerability delivered it. Mapping the infection to a particular CVE requires additional evidence from the payload, campaign timeline, affected product, or victim investigation.
Public Reports From Victims and Hosting Providers
An affected organization may disclose that attackers used a specific vulnerability.
Managed-service providers and hosting companies may observe identical compromise patterns across many customer systems.
These reports can be highly valuable because they come from direct operational experience. They can also be incomplete, hurried, or based on preliminary attribution.
A careful intelligence analyst asks:
- Did the organization publish technical evidence?
- Was the conclusion confirmed by the vendor?
- Did an incident-response company reproduce the timeline?
- Is the vulnerability the only plausible entry point?
- Has the claim changed in later updates?
The Importance of Reproduction
One of the most important steps is reproducing the exploit in a controlled environment.
Suppose a sensor records a suspicious request. Researchers can:
- obtain the affected software version;
- configure the required feature;
- replay the request;
- observe whether it reaches the vulnerable function;
- compare the result with the captured attack;
- test the patched version;
- derive reliable indicators.
This process answers crucial questions.
Was the payload valid? Did it require authentication? Did it work only under a non-default configuration? Did the public description misstate the effect? Was the actor exploiting the new CVE or an older flaw in the same endpoint?
Reproduction converts correlation into technical understanding.
It also protects against mistaken CVE assignment. Multiple vulnerabilities may affect the same product, URL, parser, or request type. Without reproduction or source-level analysis, researchers may attach observed activity to the wrong identifier.
How Researchers Distinguish Scanning From Exploitation
The difference usually comes down to what the request is capable of doing.
A reconnaissance request may ask whether a file exists or retrieve a version string.
An exploitation request contains the input needed to trigger the flaw.
Consider a simplified command-injection vulnerability.
A scanner might request:
/status
An exploit attempt might request a vulnerable parameter containing shell metacharacters and an encoded command.
A stronger observation would show the target process launching a shell.
Stronger still would be an outbound callback or a file written by that shell.
The determination therefore proceeds through layers:
Intent suggested by request → exploit condition triggered → security effect observed → post-exploitation confirmed.
Researchers should resist inferring later layers from earlier ones.
Failed Exploitation Is Still Active Exploitation Activity
A terminological complication arises when attackers deliver a valid exploit to a patched or non-vulnerable target.
Was the vulnerability “actively exploited”?
From a campaign perspective, the actor is actively using the exploit in the wild.
From the target’s perspective, exploitation failed.
This is why phrases such as these are more informative:
- active exploit attempts observed;
- exploit payload delivered;
- successful exploitation confirmed;
- post-exploitation activity observed;
- victim compromise confirmed;
- widespread exploitation assessed.
The binary language of “exploited” versus “not exploited” often hides the actual state of the evidence.
Zero-Day Determinations
Calling a vulnerability a zero-day requires another timeline judgment.
Investigators must establish that exploitation occurred before a patch became available—or, under some usages, before public disclosure.
Evidence may include:
- victim logs predating the advisory;
- malware compilation timestamps;
- infrastructure registration dates;
- crash reports;
- command-and-control traffic;
- forensic timestamps;
- historical telemetry searched after the vulnerability is understood.
Retrospective hunting is especially important.
Once researchers know the exploit’s shape, they can search months of stored telemetry for earlier occurrences. An attack initially thought to begin after disclosure may turn out to have been active much earlier.
Google Project Zero’s work on in-the-wild zero-days repeatedly emphasizes how detection depends on the visibility and telemetry available to researchers. The number of observed zero-days is therefore partly a measure of detection capability, not simply attacker activity.
This creates a persistent detection deficit: vulnerabilities may be exploited without anyone recognizing the exploit, preserving the relevant logs, or connecting the behavior to a specific flaw.
Why Public Confirmation Often Arrives Late
Defenders sometimes wonder why CISA or a vendor adds a vulnerability to an exploited list days or weeks after researchers first claim activity.
Verification takes time.
Organizations may need to:
- validate the CVE assignment;
- distinguish research scans from malicious exploitation;
- reproduce the payload;
- contact affected customers;
- confirm the product version;
- rule out alternative entry points;
- coordinate disclosure;
- prepare a patch;
- develop detection guidance;
- protect victim confidentiality;
- determine whether public notice would compromise an investigation.
CISA also requires a clear remediation action before KEV inclusion. Evidence of exploitation may therefore exist before the catalog can provide defenders with a specific required action.
Absence from KEV must never be interpreted as proof that exploitation is not occurring.
It may mean:
- evidence has not reached CISA;
- the evidence is still being validated;
- no CVE has been assigned;
- remediation guidance is incomplete;
- the activity remains confidential;
- exploitation has escaped detection entirely.
KEV is a high-confidence floor, not a complete map of active exploitation.
Common Reporting Errors
Several mistakes repeatedly distort public understanding.
“A PoC Exists, Therefore Exploitation Is Active”
False.
A PoC establishes accessibility of exploit knowledge, not malicious use.
“Scanning Equals Exploitation”
False.
Scanning may precede exploitation, but many scanners never deliver a working payload.
“The Sensor Returned HTTP 200, Therefore the Exploit Worked”
Not necessarily.
HTTP status alone may show only that the endpoint accepted or processed the request. The exploit’s security effect must be confirmed.
“A Webshell Was Found, Therefore the Newest CVE Installed It”
Not necessarily.
Investigators must correlate the webshell with the relevant request and exclude other access paths.
“The Vendor Said ‘Limited Attacks,’ Therefore the Risk Is Small”
Not necessarily.
“Limited” describes observed scope, often at a particular moment. A small number of successful attacks against high-value systems may justify emergency action.
“KEV Absence Means No Exploitation”
False.
It means the vulnerability has not met or completed CISA’s public inclusion process.
“Active Exploitation Means Mass Exploitation”
False.
One confirmed victim is sufficient to establish in-the-wild exploitation. Scale is a separate question.
A Better Vocabulary for Threat Reporting
Security reporting would improve substantially by using a more exact ladder:
Exploitable: Researchers have demonstrated the vulnerability.
Public PoC available: Reproduction code or detailed exploitation guidance is public.
Scanning observed: Actors are identifying exposed targets or vulnerable features.
Exploit attempts observed: Technically relevant payloads are being delivered without authorization.
Successful exploitation observed on sensors: The payload produced the expected security effect in monitored infrastructure.
Victim exploitation confirmed: A real organization was compromised through the vulnerability.
Post-exploitation confirmed: Attackers performed actions after gaining access.
Widespread exploitation: Multiple independent sources or victims indicate significant scale.
Zero-day exploitation confirmed: Exploitation predates patch availability or public disclosure, according to the stated definition.
This vocabulary tells defenders what is actually known.
What Defenders Should Do With an Active-Exploitation Claim
The response should depend on both evidence strength and system importance.
First, identify whether the organization actually runs the affected product and whether the exploitation prerequisites are present.
Second, determine whether the system was exposed during the relevant window.
Third, preserve logs before patching or rebooting destroys useful evidence.
Fourth, patch or mitigate the vulnerability.
Fifth, assess compromise separately.
For an edge appliance, RMM server, identity provider, backup platform, CI/CD system, or source repository, patching may close the entry point without removing:
- stolen credentials;
- forged sessions;
- webshells;
- malicious accounts;
- SSH keys;
- scheduled tasks;
- modified pipelines;
- downstream endpoint compromise;
- persistence in connected cloud services.
The correct question is not simply, “Are we patched?”
It is, “What could this system authorize, access, or control while it was vulnerable?”
Conclusion
Organizations determine that a vulnerability is being actively exploited by assembling a chain of evidence.
At the weakest end are theoretical exploitability, proof-of-concept code, scanning, and suspicious traffic. At the strongest end are technically valid exploit payloads, observed security effects, correlated endpoint and network telemetry, forensic reconstruction, victim confirmation, and repeated findings across independent sources.
The phrase “actively exploited in the wild” should therefore never be treated as a magical binary label.
The important questions are:
What was observed?
Was the payload technically valid?
Did the exploit succeed?
Was a real victim compromised?
What happened afterward?
How many independent sources confirm it?
What remains uncertain?
A mature threat-intelligence product answers those questions explicitly. It separates payload delivery from exploit success, exploit success from compromise, and one confirmed incident from widespread activity.
That precision is not pedantry.
It determines whether defenders merely install a patch—or recognize that they may already be investigating an intrusion.
Jonathan Lockhart is a cybersecurity researcher and investigative journalist at bordercybergroup.com.
If you would like to support our work — useful, well-researched, ad-free cybersecurity intelligence — subscribe, comment, or buy us a coffee! Thanks.
Member discussion: