Most Exploitation Now Lands Within 48 Hours of the Proof of Concept

AUSTIN, 17 AUG 2026 — In the first half of this year, 88 per cent of the vulnerability exploitation CrowdStrike observed against flaws with public proof-of-concept code happened within 48 hours of that code being released. Two China-linked groups moved inside 24 hours of disclosure.

That single figure settles an argument that patch-management policy has been having with itself for a decade. There is no maintenance window short enough to sit inside it.

The numbers

The report, published on 3 August and covering the first half of 2026, also records cloud-conscious criminal activity up 171 per cent, vishing intrusions doubling, device code phishing attempts rising fifteen-fold month on month, and 87 per cent of software registry threats involving malicious npm packages.

Adam Meyers, head of counter adversary operations at CrowdStrike, framed the theme as AI now being embedded in adversary operations: it changes how attacks are planned, executed and scaled, and it enlarges the surface that organisations have to defend.

Forty-eight hours is a policy number, not a technical one

Proof-of-concept code is published to help defenders understand and test a flaw. It also removes the hardest part of an attacker's work, and the interval between publication and use is now shorter than most organisations' change-approval process.

The report's findings should change behaviour, not just inform it. A monthly or fortnightly patch cycle was a reasonable policy when exploitation followed disclosure by weeks. It is no policy at all when 88 per cent of it lands in two days. The only workable response is to maintain a short, explicit list of internet-facing systems with an emergency patch process that bypasses the normal window — and to have the discipline to use it.

We wrote in July about CISA's remediation deadlines collapsing from 21 days to three. Against this data, three days is not aggressive. It is one day slower than the median adversary.

The 24-hour actors are a different problem

That VAULT PANDA and GENESIS PANDA operated inside a day of disclosure implies preparation, not just speed.

Weaponising a proof of concept, testing it against real targets and running an intrusion in under 24 hours is not opportunistic scanning. It requires a target list assembled in advance, tooling ready to adapt, and people on shift when the advisory lands. This suggests a standing capability aimed at a pre-selected set of organisations. For anyone on that list, patching speed alone will not be enough.

For this region the relevant history is that China-nexus activity against ASEAN government and defence targets is well documented — we have reported on it directly. An organisation that plausibly sits on such a list should be planning for compromise-detection rather than only for prevention.

The AI framework packages are the finding I would act on first

One hundred and thirty-one trusted AI framework packages poisoned by a North Korea-linked group is the most consequential line in the report, and it is getting the least attention. The mechanism was a malicious npm package inserted into Mastra AI frameworks.

Every organisation building anything with AI is installing these packages, usually with a single command, usually into an environment holding credentials for something that matters. The dependency tree of a typical machine-learning project is enormous, few teams read it, and a poisoned package inherits whatever access the process has.

Alongside that sits ALTERED SPIDER compromising more than 300 dependencies in a single day, and 87 per cent of registry threats arriving through npm. The supply chain is where the volume is, and AI tooling has added a fast-growing, loosely governed corner of it that most security programmes have not yet mapped.

The effective response is unglamorous. It means pinning versions, using a private registry mirror, generating a software bill of materials for AI projects, and treating any new model-adjacent dependency with suspicion.

AI as target as well as weapon

Most reporting on AI and security focuses on attackers using models as a weapon. The report offers a more useful framing: AI is also a high-value target because of the systems it connects to.

An inference endpoint with tool access, a coding agent with repository credentials, or an internal assistant indexed over a document store — each is a new, non-traditional route to sensitive data. The 171 per cent rise in cloud-conscious criminal activity, with credential theft, cryptomining and LLM abuse named together, is the same observation from the criminal side: model access is now worth stealing on its own.

The control that follows is an inventory rather than a product. Most organisations can list their servers and cannot list their model endpoints, their agent credentials or which repositories a coding assistant can write to. Until those appear on the same asset register as everything else, they are outside the scope of every control built on top of it.

That AI agent-triggered detection leads grew 2.5 times faster than human-triggered ones is significant for another reason. It says defensive automation is scaling too, which is the only honest counterweight in a report otherwise full of adversary acceleration.

What we could not establish

The denominator. An 88 per cent figure describes exploitation CrowdStrike observed, across the customer base and telemetry it has, and the report does not give the number of incidents behind the percentage. A high proportion of a small set and of a large set are different claims, and only one of them supports a general statement about attacker behaviour.

Also unestablished: how "AI-enabled" is defined and how consistently, which is the definitional question underneath most of the AI-related figures here; which vulnerabilities the 48-hour finding covers; whether the 24-hour attributions rest on one incident or many; whether the poisoned Mastra packages have been removed and how many installations they reached; and how much of the vishing and device-code phishing growth reflects better detection rather than more activity.

A vendor threat report is also a marketing document. This does not make the figures wrong, but it does mean the threats that grew the most are the ones the vendor sells a product to detect.

What to watch

The first thing to watch is whether any regional regulator moves its patching expectations to match this new timeline. India's CERT-In already requires reporting inside 12 hours, and no ASEAN authority has yet set anything comparable for private-sector remediation. This data is the argument someone will eventually use.

Then watch the registries. If npm remains the route for 87 per cent of registry threats, the pressure will move to provenance — signed packages, mandatory attestation, and eventually a curated default. That would be a large change in how developers install things.

Finally, watch whether the poisoned-AI-package pattern spreads from framework packages to model weights themselves. A poisoned dependency is a solved problem in principle; a compromised set of weights is not, because nothing in a typical pipeline verifies what a model file contains.