32 Exploited CVEs in a Month: Prioritize With AI

October 2025 wasn’t “a busy patch month.” It was a stress test for every vulnerability management program that still relies on spreadsheets, static CVSS scores, and quarterly cleanup projects.

Recorded Future tracked 32 high-impact vulnerabilities that were actively exploited in October—double September’s 16. Twenty-six were rated Very Critical. If your team’s workflow still starts and ends with “sort by severity,” you’re already behind, because attackers aren’t sorting.

This post is part of our AI in Cybersecurity series, and I’m going to take a clear stance: AI-driven vulnerability prioritization is no longer optional for enterprises. Not because “AI is cool,” but because the volume, speed, and messiness of real-world exploitation have outgrown human-only triage.

What October 2025 proves about CVE risk (and why CVSS isn’t enough)

Answer first: October proves that exploitation activity is the only prioritization signal that consistently matches real breach risk.

CVSS is still useful. It tells you how bad a vulnerability could be. But October’s landscape highlights a more urgent truth: the moment a CVE becomes operationally useful to an attacker—especially with a public proof-of-concept (PoC)—your window to respond collapses.

Here’s what jumped out:

• 32 exploited vulnerabilities in one month is a workload problem, not a knowledge problem.
• Microsoft led with 8 exploited issues across Windows, WSUS, SMB, and even legacy Internet Explorer.
• Oracle E-Business Suite saw a zero-day exploited by CL0P for data theft and extortion.
• Five of the exploited RCE-enabling vulnerabilities were over a decade old. That’s not “legacy risk.” That’s “legacy certainty.”

A practical definition you can use internally:

Real CVE priority = exposure + exploitation + business impact + feasibility of mitigation.

AI helps because it can score and re-score those variables continuously, using live signals instead of last week’s ticket queue.

The three vulnerabilities that should change your playbook

Answer first: If you do nothing else, treat these as templates for how modern exploitation works: internet exposure, fast weaponization, and chaining.

CVE-2025-61882 (Oracle E-Business Suite): extortion-grade zero-day speed

CL0P’s use of CVE-2025-61882 is a reminder that “enterprise apps” aren’t safer because they’re boring. They’re lucrative because they’re full of sensitive workflows and privileged data.

What makes this case operationally important:

• Unauthenticated remote code execution in Oracle EBS versions 12.2.3 through 12.2.14.
• Added to the “known exploited” ecosystem quickly (a strong signal attackers will follow).
• Reported exposure included ~1,430 internet-visible EBS instances.

From an AI-in-cybersecurity perspective, this is where automation matters: an AI-driven attack surface program should be able to answer in minutes:

• Do we run Oracle EBS anywhere (including subsidiaries and acquired environments)?
• Is any instance internet-facing (intentionally or accidentally)?
• Are there suspicious requests to sensitive EBS endpoints in our logs?

If your answer requires three teams and a two-week discovery project, that’s the gap attackers exploit.

CVE-2025-59287 (Microsoft WSUS): compromise the thing that delivers trust

WSUS is a high-leverage target. If an attacker gets code execution there, they’re aiming at something bigger than one server.

This flaw is particularly nasty because it targets a common enterprise reality: administrative systems exposed “just enough” to keep operations running. Recorded Future notes confirmed exploitation of publicly exposed WSUS, and reporting elsewhere indicated only a relatively small number of exposed hosts remained—meaning attackers can afford to be selective.

Operational signals worth monitoring (and where AI helps triage):

• Unusual parent/child process behavior: wsusservice.exe or w3wp.exe spawning shells
• Bursts of suspicious POST traffic to WSUS web services
• Base64-heavy PowerShell patterns and atypical curl.exe use

AI-based detection helps here because it can correlate weak signals—process anomalies, rare command lines, network destinations—into one incident narrative, instead of leaving analysts to stitch it together at 2 a.m.

CVE-2025-59230 (Windows RasMan): privilege escalation is the missing middle

Security teams love focusing on initial access (phishing, exposed services) and “big impact” (ransomware). October’s data is a reminder that the middle step—privilege escalation—is where attackers turn footholds into takeovers.

CVE-2025-59230 enables escalation to SYSTEM. That means a single stolen credential or a phished endpoint can rapidly become:

• credential dumping
• persistence through services/tasks
• lateral movement
• ransomware deployment

AI-driven endpoint analytics can spot the pattern faster than humans can: low-privileged user activity followed by abnormal service interaction, token changes, or suspicious process trees that don’t match the machine’s baseline.

Why legacy CVEs keep winning (and how to stop it)

Answer first: Legacy vulnerabilities persist because organizations lose track of ownership and visibility, not because they don’t care about patching.

October included actively exploited CVEs dating back more than a decade (examples include older Microsoft, Mozilla, and GNU Bash issues). That’s not a trivia fact. It points to recurring failure modes I see in the field:

The “unknown asset” problem

You can’t patch what you can’t see. Legacy systems often live in:

• forgotten DMZs
• branch offices
• OT-adjacent networks
• “temporary” vendor-hosted environments
• discontinued app stacks that still run payroll, logistics, or manufacturing

AI-powered asset discovery (especially when combined with passive network signals and identity telemetry) can maintain a continuously updated view of what’s actually running.

The “can’t patch” reality

Sometimes you truly can’t patch quickly: vendor downtime windows, fragile dependencies, regulatory constraints. That’s where compensating controls are the difference between “accepted risk” and “managed risk.”

Compensating controls that work in practice:

• removing internet exposure (the single highest ROI move)
• strict ingress allowlists for admin services
• WAF/virtual patching for web-facing apps
• EDR policies that block common post-exploitation tooling
• segmentation that prevents one compromised server from becoming a domain-wide incident

AI helps by recommending controls based on observed attacker behavior in your environment, not generic hardening lists.

October’s CWE patterns show where defenses are still soft

Answer first: The most common weakness type, CWE-287 (Improper Authentication), is a loud signal: attackers keep finding ways around identity gates, and defenders still treat auth bugs as “app team problems.”

Top recurring weakness patterns included:

• CWE-287 Improper Authentication
• CWE-787 Out-of-bounds Write
• CWE-22 Path Traversal
• CWE-284 Improper Access Control
• CWE-502 Deserialization of Untrusted Data

Two practical ways to use this information beyond “interesting charting”:

1) Build a “CWE heat map” for your own portfolio

If your org disproportionately runs software classes where these CWEs show up (CMS platforms, Java app servers, legacy .NET services), you can predict where the next painful patch sprint will land.

AI can assist by:

• clustering your app inventory by technology stack
• mapping historical incidents to weakness patterns
• flagging systems that match the “shape” of recently exploited vulnerabilities

2) Turn weakness patterns into detection engineering

Some CWE families produce repeatable exploitation behavior:

• Deserialization bugs often lead to unusual object payloads, odd SOAP patterns, or abnormal process spawns.
• Path traversal often produces distinctive URL patterns and repeated file access attempts.
• Auth bypass frequently shows abnormal session creation, unexpected endpoints hit pre-auth, or anomalous user-agent/cookie behavior.

AI-based anomaly detection is particularly effective when you define the “normal” traffic and auth flows per application, then alert on deviations with context.

A practical AI-driven workflow to prioritize exploited CVEs fast

Answer first: The fastest reliable approach is a two-lane system: one lane for “exploited and exposed,” another for “high impact but not exposed.” AI keeps both lanes current.

Here’s a workflow that works for real teams (not just slide decks):

Lane 1: Exploited + exposed (same-day action)

Automate the decision as much as possible:

1. Ingest exploitation signals (threat intel, known-exploited feeds, telemetry hits).
2. Match to your asset inventory (including cloud, subsidiaries, and shadow IT).
3. Confirm exposure (internet-facing, partner-facing, or reachable from user subnets).
4. Auto-create a “24–72 hour” change plan with:
   • patch guidance
   • compensating controls
   • detection queries/playbooks

This lane is where AI saves the most time because it eliminates the “are we affected?” meetings.

Lane 2: High impact but not exposed (planned remediation)

Not everything needs a war room. This lane focuses on:

• systems that are internal-only but high-value
• vulnerabilities that enable privilege escalation (like RasMan)
• products that are widely deployed across endpoints/servers

AI helps by predicting which of these is likely to become exploited next based on:

• public PoC availability
• attacker chatter and tooling adoption patterns
• similarity to recently weaponized vulnerabilities

The metric that matters: time-to-triage, not tickets closed

If your team can’t confidently answer “Are we affected?” within a business day, your vulnerability program is operating on hope.

A strong target for enterprises:

• < 4 hours to identify affected assets for exploited CVEs
• < 24 hours to apply isolation/blocks if patching isn’t immediate
• < 72 hours to patch internet-facing exploited vulnerabilities

What to do this week (a short, opinionated checklist)

Answer first: Focus on exposure reduction and automated prioritization. You’ll get more risk reduction than another round of manual CVE grooming.

• Find and eliminate public exposure for admin/update services (WSUS is a perfect example). If it must be reachable, restrict it.
• Inventory “legacy-but-critical” systems and label owners. No owner, no security.
• Create an “exploited CVE” incident runbook that includes patch, isolation, and detection steps.
• Deploy AI-assisted triage in your vulnerability management pipeline so exploitation signals automatically bubble to the top.
• Tune detections around CWE families you see most in your environment (auth bypass, traversal, deserialization).

A simple rule: if a CVE is exploited in the wild and your asset is reachable, treat it like an incident—even if you haven’t seen compromise yet.

October 2025’s CVE landscape is a reminder that attackers don’t need novel techniques when organizations still have reachable, unpatched, and poorly monitored systems. AI in cybersecurity isn’t about replacing analysts; it’s about giving them a prioritization engine that keeps up with real exploitation.

If your backlog includes thousands of vulnerabilities, the next step isn’t “work harder.” It’s building a system where exploitation signals, asset context, and compensating controls come together automatically. What would your response look like if you had to handle 32 exploited CVEs again next month—without adding headcount?