948 Paths to Root: The Economics of AI Batch Vulnerability Mining

When vulnerability research shifts from a “researcher’s craft” to an “on-demand callable service,” the cost structures for both offense and defense will be repriced. A recently published security report has laid out the bill for everyone to see.

I. Event Review: Privilege Escalation Exploits Priced “Per Thousand”

In mid-October, an automated security research pipeline from a leading AI lab ran for 12 hours, delivering 2,308 candidate vulnerabilities. After 30 hours of dynamic validation, 1,724 of these stably reproduced crashes in isolated virtual machines. The final output: 948 distinct Local Privilege Escalation (LPE) exploits. Any attacker with a low-privilege shell could use any of these to escalate privileges to root.

Released on November 4, the report’s title translates to “A Thousand Fewer Paths to Root.” The total bill for the pipeline was $1.2134 million, averaging out to $1,279 per exploit.

This requires a shift in perspective. In the past, a usable kernel-level privilege escalation vulnerability often meant weeks or months of full-time work by a top researcher. It had no “unit price” because it couldn’t be mass-produced. Now that the “discovery-validation-exploitation” chain has become a repeatable pipeline, it finally has a calculable cost structure—which is far more significant than just “how many vulnerabilities were found.”

For comparison, three weeks prior, another report showed that an unreleased model wrote a two-stage exploit chain for a publicly disclosed kernel privilege escalation vulnerability in 53 minutes. That report highlighted “single-point depth”—how hard it is to patch one vulnerability. This new report highlights “batch capacity”—when this process can be ordered by the thousands, how much time does the defense have left?

II. The Five-Stage Pipeline: Where the Money Goes

The report breaks down the entire pipeline into five stages, each with independently calculable costs:

Stage	What It Did	Time	API Cost
Reconnaissance	Determine which code low-privilege users can reach	Not separately disclosed	$3,426
Discovery	Two agents divide labor: one selects targets, the other builds threat models	12 hours	$316,500
Dynamic Validation	Generate PoCs, run in KASAN-enabled isolated VMs	30 hours	$73,300
Exploitability Assessment	Write exploits in an environment with SMEP/SMAP/KASLR/HARDENED_USERCOPY fully enabled	Not separately disclosed	~$820,000
Patch Generation & Manual Review	Produce patches, rated by security researchers	Not separately disclosed	Included in the above

The most informative part of this table is the distribution of input versus output:

• Discovery accounts for only one-quarter. $316,500 sounds like a lot, but the real money sink is turning “suspected” into “working”: the exploitability assessment alone cost about $820,000, accounting for roughly two-thirds of the total.
• Unit prices double across different vulnerability categories. LPE development and validation totaled $691,000, averaging $558 per exploit; information leak exploits cost only $271. This twofold difference almost exactly represents the cost added to attackers by various mitigation mechanisms.
• Success is cheap; failure is expensive. Successfully written exploits averaged $360, while 59 failed attempts averaged $3,922 each—failure is ten times more expensive than success.

III. Why “Failure” is Ten Times More Expensive than “Success”

The answer boils down to two words: race conditions.

The nature of race condition vulnerabilities is that the vulnerability window only appears under specific scheduling orders, memory layouts, or concurrency pressures. The report describes failed attempts as “crashing once out of a hundred runs.” This means every determination of “whether this candidate can be exploited” requires massive repeated runs to approximate that low-probability window:

• Core pinning and scheduling control: Pinning processes to specific CPUs, adjusting priorities to create deterministic preemption timings.
• Memory and load perturbation: Altering allocation timing to amplify “sporadic” into “reproducible.”
• Massive repeated sampling: Every repetition is a real compute and inference cost.

A successful exploit only needs to work once; a failed determination often means dozens or hundreds of runs still cannot stably trigger the vulnerability, eventually marking it as “unexploitable” or “sporadic.” This is the source of the tenfold gap between $3,922 and $360.

This number is equally valuable for defenders: Before an attacker writes a stable exploit, they will inevitably leave traces of “failed attempts” in the target environment—repeatedly crashing processes, aggregated coredumps, and high-frequency triggering of the same family of system calls. This forms the basis for the detection section below.

IV. From Craft to Service: The Defender’s Time Budget is Repriced

Why now? Looking at the timeline makes it clear: since the middle of this year, multiple top model vendors have successively launched dedicated automated vulnerability research projects, all highly aligned in direction—servicing and batching vulnerability research. During this period, single-point cases also emerged: models quickly writing exploit chains for publicly numbered kernel vulnerabilities, researchers using general LLMs to discover man-in-the-middle vulnerabilities in mainstream distribution package managers, and so on.

When “sporadic cases” become “batch capacity,” at least three implications must be written into threat models:

1. Attack surface equals scan surface. Any kernel interface reachable by low-privilege users (system calls, ioctl, proc/sys interfaces, driver paths) should be assumed to be under “batch scanning.” In the report, the reconnaissance phase cost only $3,426 to complete the reachability assessment—attackers can do this, and defenders should do it first.
2. Fixing one hole does not eliminate a pattern. The 948 distinct paths indicate that similar defect patterns (reference count errors, use-after-free, race windows) exist in abundance in the kernel. Patching them one by one is necessary, but pattern-based code auditing and hardening address the root cause.
3. The time gap is compressed. In the past, the time from “vulnerability discovered” to “stable exploit appears” was measured in months; now it is measured in hours to days. The defender’s patch SLAs, canary rollout cadences, and rollback plans must all be recalibrated to this new time budget.

V. Defense Action List: Four Practical Steps

1. Patch Timeliness: Compress Month-Level SLAs to Day-Level

• Separately grade privilege escalation kernel vulnerabilities and set day-level remediation windows instead of using the month-level process for general vulnerabilities.
• Use rolling kernels or hotpatching mechanisms to shorten reboot windows, turning “patching” from a change event into a daily operation.
• Automate the pipeline from “intelligence subscription -> impact assessment -> canary validation -> full deployment,” removing manual approvals from the critical path.

2. Attack Surface Reduction: Leave the Reconnaissance Phase Empty-Handed

On the kernel side, first close entry points that low-privilege users don’t need. Below is a directly actionable baseline example:

# Kernel attack surface reduction baseline (enable after business evaluation)
kernel.kptr_restrict = 2            # Prevent leaking kernel pointers to unprivileged users
kernel.dmesg_restrict = 1           # Prevent unprivileged reading of kernel logs
kernel.perf_event_paranoid = 3      # Close unprivileged performance sampling entry
kernel.unprivileged_bpf_disabled = 1
vm.unprivileged_userfaultfd = 0     # Restrict userfaultfd to privileged use only
kernel.yama.ptrace_scope = 2        # Restrict cross-process debugging
fs.protected_hardlinks = 1
fs.protected_symlinks = 1

The same logic applies to the process side: run services with demoted privileges, clear excess capability sets, enable default-deny system call whitelist filtering, mount /proc and /sys as read-only, disable setuid and file capability escalation paths, and carefully assess whether opening user namespaces is necessary in unprivileged scenarios—historically, it has been the entry point for multiple privilege escalation chains.

3. Mitigation Normalization: Double the Attack Cost Again

The gap between $558 and $271 effectively prices mitigation mechanisms: SMEP/SMAP/KASLR/HARDENED_USERCOPY are not just “psychological comfort,” but engineering measures that directly raise attack costs. Actionable steps include: confirming KASLR is enabled on production kernels, ensuring hardware-side SMEP/SMAP is active by default, incorporating compile-time hardening like HARDENED_USERCOPY and Control Flow Integrity (CFI) into the kernel build baseline, and enforcing read-only root filesystems with dropped capabilities in container runtimes.

4. Detection: Turn “Failed Attempts” into Your Alerts

Race condition exploitation must be accompanied by a large number of failed runs before succeeding, which is observable in logs. An illustrative rule:

# Illustrative detection rule for race condition privilege escalation probing
IF coredump count on a single host > 20 within 10 minutes
   AND the crashing binary files are highly concentrated
THEN flag as "suspected privilege escalation exploit debugging" and trigger security response

The implementation approach is to route kernel logs, audit logs, and runtime observations into a unified logging service for cross-host aggregation and alerting. Cloud-based businesses can directly use managed forms of these capabilities—for example, leveraging general managed components from cloud providers like Baidu AI Cloud for host security, log services, and monitoring/alerting to implement these rules at the platform side, rather than building the entire collection and alerting pipeline from scratch.

One final note: this pipeline is equally available to defenders. In your own environment, use the same “discovery-validation-patch-regression” approach to batch-validate internal images, turning the attacker’s cost structure into your own remediation queue—provided there is strict isolation, authorization, and a responsible disclosure process.

VI. Conclusion: The Winning Move is Rhythm, Not Single Points

The story of single-point depth (writing a two-stage exploit chain in 53 minutes) was already shocking enough, but the real watershed is capacity: when discovery can be batch-ordered by the thousands, “the attacker doesn’t know about this vulnerability” is no longer a premise that any defensive plan can rely on.

948 paths being recorded means 948 patching tasks, and more importantly, it proves the ubiquity of a class of defect patterns. The defender’s moat has never been “the vulnerability wasn’t discovered,” but the distance between “the moment it is discovered” and “the moment it is patched.” Compressing this distance from months to days, changing the attack surface from “reachable” to “unreachable,” and turning every failed attacker attempt into an alert in your logs—this is the true offense-defense economics behind the $1,279 unit price.