From the CrowdStrike edition of November 10, 2026
CrowdStrike Counter Adversary Operations: public proof-of-concept exploits are weaponized in under a day on median, with AI widening the pool of attackers
CrowdStrike Counter Adversary Operations · Threat intelligence (cross-sector, including government) · Global
- Publisher
- CrowdStrike blog
- Original publication
- November 5, 2026
- Source retrieved
- 2026-11-11
- Event date
- 2026-11-05
What happened
CrowdStrike says that across in-the-wild exploitation it observed from January to July 2026, the median time from a public proof-of-concept (POC) exploit to exploitation was under one day, the fastest was 35 minutes, and 91 percent of exploited vulnerabilities with a public POC were used within 48 hours. Case studies include cPanel CVE-2026-41940, the CopyFail Linux flaw used by a Belarus-nexus actor against a Ukrainian government entity, and a modified FortiOS exploit held by an Iran-nexus actor. It assesses that AI-assisted vulnerability research is speeding discovery and weaponization, while admitting direct AI use is hard to detect. It is newly relevant because Microsoft's Nov 10 Patch Tuesday was a second straight month above 1,000 fixes, which puts the patch-window argument in front of public IT teams this week.
Why it matters
State, local and school IT teams commonly patch on monthly or longer cycles and run internet-facing cPanel, Fortinet and Linux web hosts. If exploitation follows public POCs within hours, those cycles leave exposed systems open. The government-entity case is Ukrainian, so U.S. transferability is by analogy.
Evidence and measured results
Opened the full blog (Nov 5, two named authors). Timing figures come from CrowdStrike's own telemetry; the sample size, how 'exploited' is defined and the share of all vulnerabilities covered are not stated. AI attribution is explicitly described as hard to confirm.
Limitations and uncertainty
Vendor research using proprietary telemetry; no methodology, sample size or baseline; AI's role is assessed, not measured; one case concerns a non-U.S. government.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-11-11; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Public IT teams patch on monthly or slower cycles while public exploits are reportedly used within hours.
- Stakeholders
- State or district CISO
- Infrastructure and server lead
- Change advisory board
- Shared-services or cyber navigator program
- Discovery questions
- How do you learn that a public exploit exists for something you run?
- What triggers an emergency patch outside your normal window?
- Which internet-facing systems would you struggle to patch within 48 hours?
- Value hypothesis
- Exposure inventory plus managed detection may reduce the time exposed systems sit unprotected after a public POC; no SLED outcome data is offered.
- Potential engagement
- A two-week internet-facing exposure and emergency-patch process review for one agency or district.
- Unsupported claims
- Industry-wide exploitation timing
- That AI caused the observed speed-up
- Guaranteed prevention of exploitation
Pre-sales engineering
Role takeaway
- Fit
- Agencies and districts with internet-facing web hosting, VPN or control-panel systems.
- Architecture and integration
- Combine asset inventory, vulnerability scanning, threat intelligence on POC releases and endpoint detection into one prioritized exposure view.
- Prerequisites
- Accurate internet-facing asset inventory
- Sensor coverage on exposed hosts
- Feed or service tracking public exploits
- Constraints
- Legacy systems that cannot be patched quickly
- Vendor appliances with slow fixes
- Change freezes during school terms or elections
- Security
- Treat public detection scripts as potential exploits and test them only in isolated environments.
- Proof of value
- Measure current median time from POC publication to mitigation on exposed hosts
- Confirm detection fires on a simulated post-exploitation privilege escalation
- Count exposed hosts lacking sensor coverage
Delivery
Role takeaway
- Work
- Define an exploit-driven emergency patch path and compensating-control playbook.
- Dependencies
- Change advisory board approval
- Asset inventory
- Threat intelligence source
- Ownership
- Agency or district CISO with infrastructure operations.
- Skills and adoption
- Operations staff trained to assess POC releases and apply isolation steps.
- Governance checkpoints
- Emergency trigger approved
- Quarterly review of exploit-to-mitigation times
- Exceptions logged for unpatchable systems
- Acceptance criteria
- Proposed: exposed systems mitigated within 48 hours of a public POC
- Proposed: every exposed host has a named owner and sensor
- Risks
- Emergency changes causing outages
- Alert fatigue from POC volume
- Overstating vendor statistics to leadership
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Internet-facing control panels, VPN appliances and Linux web servers need exposure inventory and compensating controls (isolation, detection) that do not wait for the next maintenance window.
Governance
Who approves, reviews and stays accountable for outcomes?
Patch policies keyed only to CVSS severity and fixed monthly windows may need an exploit-availability trigger that allows emergency change.
Security and privacy
What data, permissions and controls need testing?
Public detection scripts and POCs can be trivially turned into exploits, so publishing or reusing them inside an agency needs care.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Small SLED teams cannot monitor POC releases around the clock; this argues for shared state services or managed detection rather than more individual effort.
Procurement
What should contracts, pricing and exit terms secure?
Supports funding cases for exposure management and threat intelligence, but the figures are vendor telemetry and should not be the sole justification.
Operating model
Which teams own the service once it runs?
Shifts the question from 'how fast do we patch' to 'what do we isolate or watch while we cannot patch yet'.
Publication history
- 2026-11-10CrowdStrike · Issue 134 resources
Stable resource ID: crowdstrike-vulnerability-ecosystem-weaponization-timelines-2026-11-05