AI-assisted vulnerability research is accelerating code exploitation

At a glance

What this is: Intruder argues that AI-assisted vulnerability research is already capable of finding and exploiting real flaws, including a multi-stage SQL injection 0-day in a WordPress plugin.

Why it matters: This matters because AppSec teams now face faster targeted exploitation attempts, so detection, exposure reduction, and patch speed matter more than ever across code, plugins, and exposed services.

Context

AI-assisted vulnerability research uses models to triage code slices, rank findings, and help turn suspicious input paths into proof-of-concept exploitation. The governance problem is not the model alone, but the pipeline around it: once attack work becomes more targeted, organisations need faster exposure reduction, tighter review of public attack surface, and less reliance on broad manual inspection.

In this article, Intruder describes a workflow that starts with traditional code scanning and then uses LLMs to focus on likely vulnerability paths in large WordPress codebases. That makes the identity and access angle indirect rather than central, but the operational lesson is familiar to IAM and security teams: once automated analysis narrows the search, weak controls around exposed services and credentials become much easier to reach.

Key questions

Q: What breaks when AI-assisted code scanning is used without program slicing?

A: The model loses focus, burns context on irrelevant code, and misses the small set of functions that actually determine exploitability. In practice, that means poor triage, more false positives, and weaker coverage for bugs that depend on chained request paths or hidden state. Deterministic slicing is what keeps the model on task.

Q: Why do multi-step application flaws become easier to exploit with LLM triage?

A: Because the model can reason across stored state, later reuse, and chained requests once the relevant code is isolated. A vulnerability that looks harmless in one function may become dangerous only after a value is persisted and consumed elsewhere. AI-assisted triage is strongest when the exploit condition depends on that sequence.

Q: What are the signs that an exposed web path deserves immediate verification?

A: Public hooks, unauthenticated routes, nopriv AJAX handlers, and request parameters that eventually reach sensitive operations are the main warning signs. If user input can flow from an external request into SQL, command execution, or authorization checks, the path should be treated as high priority for manual validation and patching.

Q: How should teams respond when AI finds a credible exploit path in exposed software?

A: Contain the exposure first, then validate the chain with controlled testing and remove the reachable path if the service is internet-facing. Prioritise patching and isolation over waiting for perfect certainty, because public exploit development often moves faster than manual review. Where secrets may be exposed, rotate them as part of the response.

Technical breakdown

How code slicing narrows the search space for AI-assisted exploitation

Large language models are good at reasoning over a bounded code fragment, but they degrade when forced to ingest an entire repository. Code slicing solves that by extracting the function under test, its callees, and the relevant call graph paths around a finding. That lets the model focus on the specific data flow that matters instead of competing with unrelated source noise. In practice, the scanner does the discovery work and the model does the interpretation work, which is far more efficient than asking the model to search blindly through everything.

Practical implication: pair AI triage with deterministic slicing so the model receives a constrained, defensible scope.

Why multi-stage vulnerabilities are a natural fit for automated triage

Multi-step flaws are harder for classic scanners because the vulnerable path is often spread across request handling, session storage, and later reuse of the same value. AI helps because it can reason across those discrete steps once the surrounding slice preserves the chain. In the WordPress example, a value entered in one request was stored, retrieved later, and then injected into a SQL query. That kind of stateful sequence is exactly where focused analysis outperforms broad, surface-level pattern matching.

Practical implication: prioritise AI-assisted review where exploitation depends on chained requests, hidden state, or indirect data flow.

Why unauthenticated attack surface remains the highest-value target

The article focuses on unauthenticated plugin paths because public endpoints are easier to probe at scale and easier to weaponise once a bug is found. The technical risk is not only code weakness, but reachability: if a route, hook, or AJAX handler can be triggered without authentication, an attacker does not need an insider foothold to start exploitation. That makes exposure management part of the technical control stack, not a separate governance concern.

Practical implication: inventory and harden unauthenticated routes first, because they are the fastest path from discovery to compromise.

Threat narrative

Attacker objective: The attacker wants to turn a targeted code-analysis workflow into a reliable path to database access, secret extraction, and exploit-ready compromise.

1. Entry occurs through unauthenticated WordPress plugin attack surface, where user-controlled input can reach a vulnerable request path without prior login.
2. Credential and data access follow when a malicious value is stored, reused, and injected into SQL, allowing the attacker to read sensitive database content such as hashes and secret tokens.
3. Impact is realised through multi-stage exploitation that turns a scanner-discovered flaw into a working proof of concept and practical database compromise.

Breaches seen in the wild

• United Nations breach 2021: Sakura Samurai used exposed Git credentials to reach 100,000+ UNEP staff records, then reported the flaw through the UN disclosure programme.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI-assisted vulnerability research is now an exploitation accelerator, not just a detection aid. The article shows that once a model receives tightly sliced code, it can reason about exploitability and help generate a working proof of concept. That changes the operating assumption for defenders: attackers do not need to brute-force entire repositories when a guided workflow can focus on reachable flaws. Practitioners should treat AI-assisted offensive analysis as a material increase in attacker throughput.

Multi-stage vulnerabilities are the ideal target for machine-assisted triage. A flaw that depends on request sequencing, session reuse, and indirect data flow is exactly the kind of problem where a human needs time to trace state, but a constrained model can rapidly test hypotheses. The named concept here is stateful exploit chaining: a vulnerability pattern where the harmful condition only appears after multiple ordinary application steps align. Teams need to assume that these chains will be found faster than single-point bugs.

Attack surface management is becoming the limiting control, not model sophistication. The article’s warning that exposed services cannot wait a week for patching is the real governance signal. Better models will not save an organisation if public routes, plugins, and internet-facing functions stay open long enough to be probed, triaged, and exploited. The decisive control is reducing reachable exposure before automated research can turn it into a live attack path.

Security tooling has to shift from broad review to prioritised verification. Traditional static analysis still matters, but the article shows its limits when suppression comments, plugin dependencies, or hidden request flows block obvious findings. The answer is not blind trust in AI, but a tighter governance loop around scan scope, exploit validation, and patch confirmation. Practitioners should use AI to speed verification, not to replace control ownership.

What this signals

Stateful exploit chaining: When a flaw only becomes dangerous after one request plants data and a later request consumes it, traditional pattern matching loses precision. Security teams should expect AI-assisted attackers to hunt these flows because they are easier to test once code slices expose the full sequence.

Automated exploit research is shifting the defender’s bottleneck toward exposure management and patch execution. The practical question is no longer whether a tool can spot suspicious code, but whether the surrounding programme can remove internet-facing risk fast enough to matter.

For practitioners

• Constrain AI to code slices, not full repositories Feed models only the minimal call graph and data flow needed to assess a suspected flaw so context stays focused and reviewable.
• Prioritise unauthenticated paths and public hooks Inventory REST routes, nopriv AJAX handlers, template hooks, and other externally reachable paths before applying AI-assisted triage.
• Test multi-step request chains explicitly Build validation around values that are stored in one request and consumed in another, because chained state is where blind injection often hides.
• Review suppressions in static analysis tooling Check line-level disable comments and similar suppressions to ensure they do not hide unsafe interpolation or raw query construction.

Key takeaways

• AI-assisted vulnerability research is moving beyond detection into exploit generation, which raises the value of targeted validation over broad manual review.
• The article’s WordPress example shows that multi-step request chains can hide serious SQL injection paths even when static tooling appears to have coverage.
• Teams reduce this risk by shrinking exposed surface, reviewing suppressions carefully, and prioritising verification of public paths that carry user input into sensitive operations.

Key terms

• Code Slicing: Code slicing is the process of extracting only the source paths related to a specific finding, input, or control flow. It reduces noise for analysis by preserving the functions, calls, and data dependencies that matter most to exploitability review and remediation.
• Stateful Exploit Chaining: Stateful exploit chaining is a vulnerability pattern where an attacker must complete multiple application steps before the dangerous condition appears. The risk is often hidden across requests, sessions, or stored values, which makes it harder for simple scanners to recognise and easier for targeted analysis to exploit.
• Unauthenticated Attack Surface: Unauthenticated attack surface is the set of externally reachable routes, hooks, or handlers that can be triggered without prior login. It matters because an attacker can probe and weaponise those paths at scale, turning a code weakness into a practical internet-facing compromise.
• Exploitability-Led Triage: Exploitability-led triage is a remediation method that prioritises weaknesses based on whether they are reachable and can be chained into real attack paths. It is more effective than raw backlog ranking because it ties effort to actual exposure, not just issue count.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners who need to connect identity controls to broader security operations. It is suitable for security teams that want a structured baseline for identity-led governance.