Can Security LLMs Autonomously Discover and Exploit Vulnerabilities?

1. The Verdict Up Front: The Capability Threshold Has Been Crossed, but It Is Not Yet a “General Autonomous Hacker”

When a security model can automatically generate an executable exploit based on source code, a trigger input, and a runtime environment, calling it “capable of autonomously exploiting vulnerabilities” is not an exaggeration. But claiming that it can independently complete target discovery, vulnerability mining, exploitation, persistence, and lateral movement across the open internet clearly exceeds what current evidence supports.

A more accurate assessment:

1. In controlled environments with clear boundaries and sufficient feedback, models can already complete some exploitation tasks end to end.
2. When source code is visible and the trigger mechanism is known, models construct working exploits significantly faster.
3. As protections, environmental noise, and target uncertainty increase, success rates drop markedly.
4. Vulnerability discovery and vulnerability exploitation are distinct stages; results from the latter cannot directly prove the former.
5. Improved security-specific capability does not mean general programming, system understanding, and long-term autonomous planning have improved in tandem.

The real concern, therefore, is not whether models have become “omnipotent,” but that the technical barrier, time cost, and personnel requirements for exploitation are declining. Work that once took security researchers days or weeks can now potentially be compressed into a single stage of an automated pipeline.

2. First, Distinguish “Discovering Vulnerabilities” from “Exploiting Vulnerabilities”

The most common misconception in cybersecurity discussions is conflating vulnerability discovery, reproduction, and exploitation. In reality, these three stages have different input requirements, technical difficulty, and evaluation criteria.

1. Vulnerability Discovery

Discovery requires a system to identify anomalies across large volumes of code, binaries, or runtime behavior, and determine whether a security defect controllable by an attacker exists.

This stage typically requires:

• Understanding data flow and control flow in code;
• Identifying variables that external input can influence;
• Judging whether bounds checks, permission checks, or resource management are complete;
• Distinguishing ordinary defects from those with security impact;
• Constructing inputs that reliably trigger anomalies;
• Eliminating duplicate reports and false positives.

If a model receives complete source code, build instructions, and an input that already triggers the vulnerability, then the hardest part—locating a vulnerability in unknown code—has already been done in advance.

2. Vulnerability Reproduction

Reproduction confirms that a defect actually exists and analyzes the conditions under which it can be reliably triggered.

The model must handle:

• Differences in compiler options and dependencies;
• Runtime environment configuration;
• Input formats and trigger conditions;
• Crash logs, memory state, and exception paths;
• Non-determinism across multiple runs.

Being able to reproduce a vulnerability does not mean being able to exploit it. Many defects only cause a program to exit and cannot be further converted into out-of-bounds read/write, privilege escalation, or control-flow hijacking.

3. Vulnerability Exploitation

Exploitation requires converting a triggerable defect into an attack process with a defined security effect—such as reading protected data, bypassing permission checks, or gaining higher privileges.

This typically involves:

• Precisely controlling memory layout;
• Deriving address and object relationships;
• Bypassing protections such as address space randomization;
• Handling non-determinism from multithreading, garbage collection, or asynchronous execution;
• Constructing stable, repeatable input sequences;
• Verifying the exploitation result rather than merely observing whether the program crashes.

Therefore, when a benchmark already provides vulnerability source code, build steps, trigger samples, and a containerized environment, it primarily tests: whether the model can bridge the gap from “known defect” to “working exploit.”

This is an important capability, but it is not equivalent to autonomously discovering vulnerabilities in unknown real-world systems.

3. What Controlled Exploitation Benchmarks Actually Measure

A typical exploitation benchmark provides an agent with three types of information:

• Source code containing the vulnerability, plus build instructions;
• An input sample that triggers an anomaly;
• An isolated runtime environment that can be reset repeatedly.

The task goal is usually not simply to cause a crash, but to have the agent generate a complete exploit that ultimately reads protected information or obtains a pre-set target flag.

In this environment, the model can form the following loop:

Read source code and build information
        ↓
Run trigger sample
        ↓
Analyze crash and memory state
        ↓
Propose hypotheses about the vulnerability cause
        ↓
Modify exploit input or auxiliary program
        ↓
Rebuild and execute
        ↓
Iterate based on results

This loop suits agents well because the environment provides fast, clear feedback. After a failed attempt, the model can continue modifying based on error logs without bearing business disruption, evidence destruction, or access restrictions in real systems.

A publicly disclosed large benchmark contains nearly nine hundred real vulnerability samples, covering ordinary applications, browser execution engines, and operating system kernels. Even with protections such as address space randomization and sandbox isolation enabled, some tasks can still be completed automatically. This shows that modern protections can significantly increase exploitation difficulty but cannot guarantee a zero success rate.

Note, however, that benchmark success does not automatically mean real-world success. Benchmark environments typically have the following advantages:

1. Clear targets: the model knows a vulnerability exists in the system.
2. Limited scope: source code, input, and runtime environment are already provided.
3. Fast feedback: failed attempts can be retried immediately.
4. Controllable cost: no risk of real business downtime.
5. Permissive access: debugging, building, and testing operations are allowed.
6. No social factors: no need to handle account management, organizational processes, or personnel response.

Real attacks may not even be able to determine the target’s tech stack, version, patch status, or reachable entry points—the two are not directly comparable in difficulty.

4. Why Hardened Environments Significantly Reduce Success Rates

In public testing, one benchmark achieved a success rate close to half in a standard environment; after stricter hardening was introduced, the success rate dropped to about one-third. Another external evaluation included nearly three hundred tasks, of which only about ninety were completed; fully hardened targets had no successful cases, and the most difficult task group failed entirely.

These results reveal at least three facts.

1. Models Are Highly Sensitive to Environmental Feedback

Current security agents often rely on an “execute–observe–correct” loop. When debugging information is hidden, exception output is trimmed, and execution attempts are limited, the model struggles to build accurate hypotheses about vulnerability mechanisms.

This yields an important insight for enterprises: production environments should not expose detailed stack traces, memory addresses, internal paths, and component versions to unnecessary parties. The richer the error information, the more feedback attackers and automated models can exploit.

2. Layered Protections Remain Effective

Address space randomization, non-executable memory, control-flow protection, privilege isolation, system call restrictions, and container boundaries are not absolute defenses, but they increase the complexity of the exploitation chain.

A single mechanism may be bypassed, but multiple mechanisms stacked together force the model to solve several constraints simultaneously:

• Find an information leak path;
• Derive randomized addresses;
• Construct stable memory writes;
• Avoid triggering runtime checks;
• Escape the restricted execution environment;
• Complete verification within a limited number of attempts.

This significantly lengthens the search chain and increases the probability of failure along the way.

3. The Hardest Tasks Still Require Deep System Knowledge

High-difficulty vulnerabilities are often not simple out-of-bounds read/write issues but involve object lifetimes, concurrency races, complex memory management, or cross-component state machines. A model may generate a seemingly reasonable plan but cannot guarantee that timing, layout, and environmental assumptions hold simultaneously.

Therefore, when evaluating models, do not look only at average success rates. Also consider:

• Whether high-difficulty tasks succeed;
• Whether success is repeatable;
• Whether human hints are required;
• Number of attempts and computational cost;
• Whether additional debugging information was used;
• Whether results still hold after the environment changes.

5. Automated Vulnerability Mining Pipelines Are More Concerning Than Individual Scores

Completing a single exploitation challenge only proves local capability. The more important shift is that models are being integrated into large-scale vulnerability mining workflows.

A typical automated pipeline might include:

Code and change collection
    ↓
Static analysis and model review
    ↓
Generate candidate defects
    ↓
Automatically construct test inputs
    ↓
Dynamic execution and anomaly detection
    ↓
Deduplication and root cause classification
    ↓
Verify security impact
    ↓
Generate fix recommendations and regression tests

Public research has disclosed that an automated workflow targeting operating system kernels dynamically reproduced a large number of defects from thousands of candidate issues and further constructed local privilege escalation exploits for a substantial portion of them. Compared with previous capabilities, output volume increased several-fold.

The significance of such data is not a particular percentage but three trends.

First, Vulnerability Research Is Becoming Scalable

Traditional research relies heavily on experts reading code one by one. Automated systems can scan large numbers of modules in parallel, rank candidate issues, and continuously run reproduction tasks.

Second, Marginal Costs Are Declining

Model inference, container execution, and automated verification still cost money, but compared with relying entirely on senior researchers, the cost of screening individual candidates may drop significantly. Even with a high false positive rate, as long as subsequent verification can be automated, the overall process may still be economically viable.

Third, Exploit Generation May Become a Standard Verification Step

In the past, confirming a program crash was sometimes sufficient to submit a vulnerability report. In the future, high-quality workflows may require further proof:

• What data an attacker can control;
• Whether privilege boundaries can be crossed;
• Whether the issue can be reliably reproduced;
• Whether protections can block exploitation;
• Whether a fix truly eliminates the root cause.

For defenders, this means vulnerability verification quality may improve; for attackers, it means high-severity vulnerabilities may be weaponized faster.

6. Why Current Models Still Cannot Be Called General Autonomous Attack Systems

A complete real-world attack chain includes at least the following stages:

1. Identify attackable targets;
2. Collect asset, version, and exposure information;
3. Find or discover security defects;
4. Determine whether a vulnerability is remotely reachable;
5. Construct a stable exploitation chain;
6. Bypass identity, network, and runtime protections;
7. Gain privileges and maintain access;
8. Adjust strategy in a dynamic environment;
9. Evade detection and response;
10. Understand business objectives and risk boundaries.

Current models perform strongly in some of these stages—particularly code analysis, script generation, log summarization, known vulnerability reproduction, and controlled-environment exploitation. But they still have clear shortcomings in long-term planning, stealthy operations, dynamic adversarial interaction, environment migration, and high reliability.

Moreover, a single failure in a real system may trigger alerts, ban accounts, or cause the target service to restart. Models cannot retry indefinitely as they can in experimental containers. The lack of low-cost feedback is one of the most important differences between real-world scenarios and benchmarks.

7. How Enterprises Should Evaluate Security LLM Capabilities

Enterprises should not ask only “can the model discover vulnerabilities” but should build a tiered evaluation system.

1. Evaluate Four Categories of Capability Separately

At minimum, split evaluation into:

• Candidate discovery capability: can it identify potential defects from code;
• Dynamic reproduction capability: can it generate stable trigger samples;
• Security impact analysis capability: can it judge exploitability and scope of impact;
• Fix verification capability: can it generate patch recommendations and regression tests.

Combining all four into a single score obscures where the model actually creates value or risk.

2. Record Real Resource Consumption

Evaluation reports should record:

• Maximum attempts per task;
• Total inference and execution time;
• Whether source code access is allowed;
• Whether trigger samples are provided;
• Whether debugging information is exposed;
• Whether human experts intervene;
• Whether successful results can be reproduced in a fresh environment.

Without disclosing these conditions, a raw success rate is nearly incomparable.

3. Validate in Isolated Environments

Security models should not connect directly to production systems. A more robust architecture is:

Task submission
  ↓
Permission and compliance review
  ↓
Disposable isolated container or virtual environment
  ↓
Restrict network, file, and system call permissions
  ↓
Fully log model inputs, operations, and outputs
  ↓
Human review of security conclusions
  ↓
Destroy the test environment

Isolated environments should also set resource quotas, timeout limits, and outbound network controls to prevent model-generated test programs from accidentally affecting other systems.

8. What Defenders Should Do Now

1. Reduce Feedback Available to Attackers

Production systems should avoid returning detailed exception stack traces, internal paths, address information, and dependency versions externally. Keep external responses concise and route full diagnostic information to controlled logging services.

2. Advance Layered Hardening

Do not rely on a single protection mechanism. Combine:

• Memory-safe programming and bounds checking;
• Least-privilege execution;
• Process and container isolation;
• Address and memory execution protection;
• Network segmentation and access control;
• Sensitive system call restrictions;
• Anomalous behavior monitoring;
• Rapid patching and rollback mechanisms.

3. Shorten the Vulnerability Remediation Cycle

As vulnerability weaponization accelerates, handling high-severity issues monthly or quarterly may no longer be sufficient. Enterprises need to connect asset identification, risk ranking, patch testing, canary releases, and rollback plans into an automated loop.

4. Use Models to Strengthen Defense, Not Just to Worry About Attack Risk

The same capabilities can also be used to:

• Review high-risk code changes;
• Automatically generate security test cases;
• Analyze crash logs and memory errors;
• Deduplicate candidate vulnerabilities;
• Generate fix recommendations;
• Verify whether patches introduce regressions;
• Summarize monitoring alerts and incident evidence.

The key is to retain human approval, operation auditing, and privilege isolation—models must not directly modify production code or execute high-risk commands without constraints.

9. How to Interpret “Autonomously Discovering and Exploiting Vulnerabilities” Rationally

To judge whether such claims are reliable, ask six questions in sequence:

1. Was the vulnerability discovered by the model, or provided in advance by the test set?
2. Was the trigger input generated by the model, or provided directly?
3. Does the runtime environment allow unlimited trial and error?
4. Are the main real-world protections enabled?
5. Have the results been independently reproduced?
6. Can successful cases transfer to different versions and configurations?

If the vulnerability, trigger sample, source code, and environment are all provided, the more accurate description is “automatically constructing exploits,” not “autonomously discovering vulnerabilities.”

If a system can screen candidates from large volumes of real code, dynamically reproduce them, assess security impact, and form stable exploits, then it can be considered to have preliminary automated vulnerability discovery and verification capability. Even at that stage, it does not mean it possesses general attack capability in open environments.

10. Conclusion

Security LLMs have demonstrated vulnerability analysis and exploitation capabilities that deserve attention. Given source code, trigger samples, and isolated environments, they can complete some work that previously relied heavily on expert experience; in large-scale pipelines, they may also participate in candidate discovery, dynamic verification, and security impact assessment simultaneously.

But existing evidence proves more about “automated exploitation and vulnerability verification under controlled conditions” than about “general autonomous attacks in open environments.” Hardening, information restrictions, privilege isolation, and environmental changes can still significantly reduce success rates, and high-difficulty vulnerabilities still require deep system knowledge and reliable long-term planning.

For enterprises, the most reasonable attitude is neither to ignore nor to panic. Incorporate model capabilities into threat modeling, strengthen layered defenses and vulnerability response, and use models for code review, vulnerability reproduction, patch verification, and security operations—all under strict isolation, full auditing, and human review. The real competitive differentiator is not who first labels a model an “autonomous hacker,” but who can more quickly build a verifiable, controllable, and sustainable intelligent security engineering system.