AI Security Triage for 0-Days, RCE, and OAuth Scams

Most companies still treat “patching and phishing” like two separate problems. This week’s incidents show why that’s a mistake.

We’ve got actively exploited Apple and Chrome zero-days, a WinRAR path traversal being used by multiple threat groups, a .NET RCE chain hiding in “expected” developer behavior, and OAuth consent-style scams that never touch the endpoint. On top of that, regulators are still handing out real penalties for security failures—LastPass’ U.K. fine is a blunt reminder that “we’ll improve” doesn’t help after the breach.

This post is part of our AI in Cybersecurity series, and I’m going to take a stance: if your detection and response can’t keep up with the pace of exploitation, you don’t have a tooling problem—you have a decision-automation problem. AI is how you close that gap, but only if you apply it to the right choke points.

What this week’s threats have in common (and why AI fits)

Answer first: These stories all share the same pattern: a short window between “bug exists” and “bug exploited,” plus attacker tradecraft that blends into normal behavior. AI helps because it’s good at spotting relationships and deviations across messy, high-volume data.

Here’s the common thread:

• Exploit speed beats human workflows. Opportunistic scanning and exploitation ramps up within hours of disclosure (and sometimes before).
• The “signal” looks like normal IT. WebKit rendering, archive extraction, SOAP calls, OAuth flows—these are all legitimate actions.
• Single-control security fails. MFA that isn’t phishing-resistant can be bypassed. AV doesn’t catch browser-only OAuth code theft. Patch SLAs fail without prioritization.

AI in cybersecurity earns its keep in three places:

1. Prioritization: turning “hundreds of vulns” into “patch these 12 systems in the next 24 hours.”
2. Detection: catching weak signals that only become obvious when correlated (identity + endpoint + network + SaaS audit logs).
3. Response: automating containment when the cost of waiting for a human is too high.

0-days in Apple/Chrome: treat browsers as Tier-0 assets

Answer first: When WebKit/Chrome 0-days are exploited in the wild, you should assume initial access via web content is on the table, and respond like it’s a Tier-0 event—even if you “only saw Safari crashes.”

This week’s Apple and Google fixes included two exploited zero-days (memory corruption and use-after-free) that can be triggered via maliciously crafted web content. One of them also affects Chrome through the ANGLE library.

Why this matters operationally: browser exploitation is often the “quiet” opener for commercial spyware and high-end targeted intrusion. You won’t always see ransomware-style noise. You’ll see a user browsing.

How AI helps with browser 0-days (practically)

AI won’t magically “find the 0-day” inside WebKit. What it can do is shorten the time from exposure to action:

• Patch impact prediction: Use models that learn your environment’s software-to-business mapping (device criticality, user roles, external exposure) to prioritize updates.
• Anomaly detection on browser-to-process chains: Look for unusual child processes, scripting engines spawning unexpected binaries, or suspicious persistence shortly after browsing sessions.
• Risk scoring for targeted populations: Executives, admins, finance, legal, and devs often have different threat profiles. AI-driven segmentation can tell you who needs emergency update enforcement.

Snippet-worthy rule: If a browser 0-day is exploited in the wild, your best “detection” is enforcing the fix faster than attackers can reach your users.

WinRAR CVE-2025-6218: the old-school entry point that still works

Answer first: Archive and file-handling exploits remain effective because they exploit human workflow, not just software bugs. AI can reduce risk by classifying file behavior and enforcing smarter controls at ingestion.

A WinRAR path traversal vulnerability (CVE-2025-6218, CVSS 7.8) is under active exploitation by multiple groups. This isn’t surprising—compression utilities are installed everywhere, and “open the file” is a habit attackers can reliably trigger.

What defenders often miss

Two issues come up again and again:

1. File trust is still mostly “sender-based.” If it came from a coworker or a vendor, people open it.
2. Controls focus on malware payloads, not suspicious file mechanics. Path traversal is about where files land after extraction.

Where AI strengthens the file pipeline

You can use AI to make file handling less naive:

• Content + context scoring: Combine sender reputation, domain age, prior communication patterns, file structure features, and sandbox extraction results.
• Behavioral baselining for endpoints: If a user typically doesn’t execute anything from Downloads or newly created temp directories, a sudden change is a strong signal.
• Automated quarantine decisions: For high-risk archives (password-protected, nested archives, strange path structures), route them into isolation automatically.

Opinion: If your organization still relies on “user training” to stop archive-based attacks, you’re choosing failure. Training helps. Controls stop compromises.

SOAPwn and .NET RCE: “developer surprise” is attacker opportunity

Answer first: The SOAPwn-style .NET behavior is dangerous because it turns a normal dev assumption into an exploit path: HTTP client proxies accepting non-HTTP URLs can enable arbitrary file writes, which can lead to RCE.

This week’s .NET issue (nicknamed SOAPwn) highlights a painful truth: platforms often have “features” that are secure only if every developer anticipates edge cases. Attackers count on developers not anticipating them.

In affected patterns, attackers can pass a crafted URL to a SOAP endpoint and push the proxy into interacting with the filesystem (not just HTTP). Best case, this enables NTLM challenge capture/relay. Worst case, it becomes webshell upload or PowerShell script drop leading to remote code execution.

How AI fits into AppSec for cases like SOAPwn

AI helps most when it’s used to reduce the review burden on humans:

• Code-aware detection: Scan repositories for risky proxy patterns, unvalidated URL inputs, and WSDL import flows that produce controllable client proxies.
• Semantic SAST triage: Instead of dumping 400 alerts into a backlog, AI can cluster findings into “this is the same sink repeated 63 times” and prioritize the reachable ones.
• Runtime correlation: If a SOAP endpoint suddenly starts causing file writes, that’s behavior you can flag—especially when correlated with unusual authentication artifacts or outbound requests.

Snippet-worthy rule: RCE doesn’t always start with “malware.” Sometimes it starts with a library doing exactly what it was coded to do.

OAuth “ConsentFix” scams: phishing that lives entirely in the browser

Answer first: OAuth code-stealing scams are effective because they hijack legitimate login flows and can bypass traditional endpoint detection. The defense is identity telemetry + AI correlation, plus phishing-resistant authentication.

A ConsentFix-style technique tricks users into copy-pasting OAuth material (like an authorization code embedded in a localhost URL) into an attacker-controlled page. The whole thing can occur inside the browser context.

Why that’s nasty:

• There may be no malicious file, no macro, no payload to detonate.
• MFA can still be bypassed if it’s not phishing-resistant.
• The attacker ends up with valid tokens or the ability to mint them.

AI-driven identity defense that actually helps

You want AI to answer one question quickly: “Is this OAuth flow normal for this user, on this device, from this network, for this app?”

High-signal detections include:

• First-seen OAuth apps requesting high-risk scopes
• OAuth grants immediately followed by unusual mailbox access, forwarding-rule creation, or mass downloads
• Token use from unusual ASN/geo/device fingerprint shortly after a successful login
• “Impossible travel” plus abnormal consent activity (correlation matters)

And yes, you still need policy:

• Prefer phishing-resistant MFA (FIDO2 / passkeys) for admins and high-risk roles
• Restrict OAuth app consent and require admin approval for sensitive scopes
• Shorten token lifetimes where possible; monitor refresh token abuse patterns

LastPass fine: the compliance angle is now an ops problem

Answer first: Regulatory penalties increasingly reflect operational security failures—especially around endpoint hardening, credential protection, and environment segmentation. AI helps by enforcing controls consistently and proving they’re working.

The U.K. ICO fined LastPass’ British subsidiary £1.2 million for failures tied to its 2022 breach chain. Whatever your view of that specific case, the message is clear: security programs are judged on outcomes and reasonable controls, not intentions.

If you’re selling into regulated industries—or you’re simply trying to avoid becoming the next headline—AI can support governance by:

• Continuously validating device posture (not once-a-quarter)
• Detecting identity anomalies that humans miss in log noise
• Producing audit-ready evidence: who had access, when it changed, what was enforced, and what alerts were acted on

A practical AI-driven “48-hour response” playbook

Answer first: When exploitation is active, you need a repeatable, AI-assisted workflow that prioritizes fixes and automates containment. Here’s a playbook you can run without rewriting your whole security stack.

1) Normalize your inputs (so AI isn’t guessing)

Feed the model and your analytics pipeline with clean signals:

• Asset inventory (owner, criticality, internet exposure)
• Patch telemetry (version, last update time, enforcement status)
• Identity logs (SSO, OAuth consents, token use)
• Endpoint events (process tree, file writes, script execution)

2) Prioritize like an attacker would

Rank by exploitability + reach + impact:

1. Actively exploited 0-days in browsers/OS
2. Known exploited vulnerabilities in widely deployed utilities (e.g., WinRAR)
3. RCE paths in business apps (e.g., .NET SOAP services)
4. Identity attacks that grant session tokens (OAuth/AitM)

3) Automate the safe actions

Good automation is boring and consistent:

• Force updates / block vulnerable versions where feasible
• Isolate endpoints exhibiting post-exploitation patterns
• Revoke tokens and force re-auth on suspicious OAuth grants
• Temporarily tighten conditional access for high-risk users

4) Measure the only metric that matters during active exploitation

Track time-to-mitigate (TTM) for exposed systems. If you can’t reduce TTM, your AI project isn’t helping yet.

A useful internal benchmark: If a vulnerability is confirmed exploited in the wild, your goal should be meaningful mitigation within 24–72 hours, not “next patch cycle.”

Where to start if you want AI in cybersecurity to drive leads (not slides)

If you’re evaluating AI security tooling right now, I’d start with use cases where you can show impact quickly:

• AI-powered vulnerability prioritization tied to your asset inventory
• Identity threat detection for OAuth, token abuse, and AitM patterns
• SOC alert clustering and root-cause summarization to cut investigation time
• Automated response guardrails (token revocation, isolation, policy tightening)

I’ve found the win isn’t “replace analysts.” It’s free analysts from repetitive triage so they can do the work that actually requires judgment.

What to do before the next weekly recap writes itself

This week’s mix—0-days, RCE paths, identity scams, and regulatory consequences—shows that modern defense is less about any single tool and more about speed and coordination.

If your organization can patch fast but can’t detect token theft, you’ll still get breached. If you can detect anomalies but can’t patch, you’ll still get breached. AI in cybersecurity is most valuable when it connects those worlds: predict exposure, detect abuse, and automate the first response.

What would change in your security outcomes if your team could cut time-to-mitigate from weeks to 48 hours—consistently—starting in Q1 2026?