AI-assisted vulnerability research is accelerating code exploitation

At a glance

What this is: This is a research post on using LLMs with code-scanning slices to find and exploit vulnerabilities, with a WordPress plugin SQL injection example proving the pipeline can work end to end.

Why it matters: It matters to AppSec and IAM-adjacent teams because AI can increase both attacker speed and defender throughput, making exposed services, secrets, and privileged data harder to leave ungoverned.

By the numbers:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

👉 Read Intruder's analysis of AI-assisted vulnerability discovery and CVE-2026-3985

Context

AI-assisted vulnerability research is changing AppSec by improving how scanners focus on relevant code, not by replacing the need for sound engineering controls. The core problem is signal dilution: large repositories create too much context for a model to reason about a specific weakness, while traditional slicing and taint analysis can narrow the search to the functions that actually matter.

For identity and access teams, the relevant issue is not just code quality but what a successful exploit can reach. When a vulnerability exposes database contents, password hashes, secret tokens, or session-backed authorisation state, the boundary between application security and identity governance disappears. That makes the article relevant to NHI governance, secrets management, and the handling of privileged data inside application flows.

The example here is atypical in automation depth but typical in what it reveals: attackers and defenders alike gain leverage when they can reduce the search space before the model reasons over it.

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-stage application flaws create higher security risk than single-request bugs?

A: Because they often defeat simple pattern matching and only become exploitable when state, sequencing, and stored input line up across more than one request. That makes them harder to spot, easier to underestimate, and more likely to reach sensitive data before defenders notice. The risk rises again when the data includes secrets or authentication artefacts.

Q: What do security teams get wrong about blind SQL injection?

A: They often assume the absence of visible data leakage means the application is safe. Blind SQL injection can still be confirmed through timing or behavioural changes, which means the query is being manipulated even when the page looks normal. Validation must account for invisible exploitation paths.

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 program slicing gives LLMs the right context

Large language models work best on bounded problems. Program slicing uses static analysis to extract only the functions, call paths, and data flows relevant to a candidate issue, which prevents the model from wasting attention on unrelated code. That matters because many real vulnerabilities depend on a narrow chain of functions rather than a single obvious bad line. Taint tracking then removes obviously safe paths, improving the quality of what reaches the model. The result is not AI magic, but a better division of labour between deterministic code analysis and probabilistic reasoning.

Practical implication: teams should pair LLM review with existing static-analysis and slicing tools instead of feeding whole repositories into the model.

Why multi-stage vulnerabilities are a better fit for AI triage

Multi-stage bugs are harder for conventional scanners because exploitability depends on ordering, state, and context across multiple requests or code paths. In this case, the issue required storing a payload in one step and triggering it later through a separate execution path. A model that can retain the relevant slice, understand state transitions, and reason about request sequencing can surface issues that rule-based detectors miss. But that same strength also means defenders need to treat AI findings as candidates, not proof. Human validation still matters when business impact depends on whether the chain truly holds.

Practical implication: prioritise AI-assisted triage for bugs that span state transitions, request chains, or separate application modules.

SQL injection still becomes identity risk when the payload reaches secrets

SQL injection is often discussed as data exposure, but the real security consequence depends on what the database contains. If the compromised table holds admin password hashes, API keys, session references, or backend tokens, the attacker may pivot from application access to privileged identity abuse. That is why secrets management and application security are inseparable here. The exploit path matters less than the blast radius once the database is readable. In identity terms, this is a failure to bound credential material inside an application layer that assumes the database is a trusted internal system.

Practical implication: classify database fields by credential sensitivity and treat leaked secrets as identity events, not only application defects.

Threat narrative

Attacker objective: The attacker aims to extract privileged data from the application database and use it to expand access beyond the original plugin flaw.

1. Entry occurs through a vulnerable unauthenticated WordPress plugin path that accepts attacker-controlled input across multiple requests.
2. Credential access follows when SQL injection reaches database records containing admin hashes, secret tokens, or other sensitive material.
3. Impact is achieved through read access to privileged data that can support follow-on account takeover or further exploitation.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI-assisted vulnerability research is becoming a force multiplier, but only when it is constrained by deterministic control points. The article shows that program slicing, taint filtering, and staged model use can turn a noisy codebase into a tractable security problem. That improves defensive and offensive efficiency at the same time, which is why AppSec teams need to govern where AI is allowed to reason and where deterministic tools must decide.

Program slice governance is the named control gap this research exposes. The real advantage comes from narrowing context before the model reasons, not from asking a model to inspect everything. Without that boundary, teams get poor triage quality, excessive token use, and missed exploit chains. Practitioners should treat context scoping as part of secure SDLC governance, not as an implementation detail.

SQL injection remains an identity problem when the database holds secrets and authentication artefacts. This post matters to IAM and NHI teams because database compromise can reveal password hashes, tokens, and session-linked state that reopens privileged access paths. The control failure is not just input validation. It is weak classification of credential-bearing data and poor separation between application data and identity material.

Automated exploitation changes the defender’s patching assumptions. If a pipeline can move from discovery to proof-of-concept generation quickly, the useful metric is not whether a flaw exists but how fast exposed services can be removed, patched, or isolated. That aligns with attack surface management, secrets governance, and incident response, and it pushes organisations toward shorter exposure windows rather than slower manual review cycles.

The market signal is clear: AI in vulnerability research will reward organisations that already have disciplined code, secrets, and asset governance. Teams that rely on ad hoc review or delayed remediation will feel the impact first. The likely outcome is greater pressure to connect application findings to identity controls, especially where leaked tokens or hashes can translate into immediate account abuse.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• From our research: Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• Forward-looking: Use Ultimate Guide to NHIs , Key Challenges and Risks to connect secrets sprawl, over-privilege, and lifecycle control into one governance model.

What this signals

Program slice governance: AI-assisted vulnerability research will keep improving, but the organisational advantage will sit with teams that can tightly scope model input before analysis begins. That shifts the control conversation toward analysis boundaries, evidence quality, and the speed at which findings become patchable work items.

When exposed software is internet-facing, exposure time becomes the real security variable. The practical lesson for AppSec and IAM teams is to connect vulnerability handling to secret rotation, access revocation, and service isolation so a code flaw does not become an identity compromise.

The presence of database credentials, hashes, and API keys inside application data means AppSec findings increasingly have identity consequences. That is why secrets governance, runtime exposure control, and application ownership should be managed together rather than as separate queues.

For practitioners

• Constrain LLMs with program slices Feed models only the functions, data flows, and call chains relevant to a candidate issue. Use static analysis and taint tracking first so the model reviews a bounded problem instead of a full repository. This reduces noise and improves exploitability assessment.
• Classify database fields by credential sensitivity Tag password hashes, API keys, tokens, and session-linked values as identity-bearing data. If a vulnerability exposes any of these fields, route it through the same escalation path you use for secrets compromise, not just application defect tracking.
• Shorten remediation for externally reachable flaws Treat internet-facing issues that can be exercised in multiple requests as urgent exposure events. Remove, patch, or isolate the vulnerable service before broad proof-of-concept development makes exploitation routine.
• Test exploitability in multi-step request flows Prioritise vulnerabilities that require stateful sequences, stored payloads, or delayed execution paths. These are the cases where conventional scanners often underperform and where AI-assisted triage can add the most value.

Key takeaways

• AI can accelerate vulnerability discovery, but it only works well when code is narrowed to the relevant slice before the model reasons over it.
• Multi-stage flaws matter because they can expose secrets, hashes, and tokens that convert an application bug into an identity compromise.
• Teams need shorter exposure windows, faster remediation, and tighter secrets classification if they want to stay ahead of AI-assisted exploit development.

Key terms

• Program Slicing: Program slicing is a static-analysis method that extracts only the code and data flows relevant to a specific variable, function, or vulnerability hypothesis. It helps security tools and analysts focus on the paths that matter, which is especially useful in large repositories with many unrelated components.
• Blind SQL Injection: Blind SQL injection is a variant where the application does not return obvious database output or errors, so the attacker infers information from timing or true-false response differences. It is harder to spot and often requires behaviour-based detection.
• Secrets-Bearing Data: Secrets-bearing data is application data that can be used to authenticate, authorise, or impersonate a system or user, such as tokens, hashes, API keys, and session material. When this data is exposed, the incident becomes an identity and access problem as much as a confidentiality issue.

What's in the full report

Intruder's full analysis covers the operational detail this post intentionally leaves at a higher level:

• The Joern rule set and slicing approach used to isolate unauthenticated attack surface in large WordPress codebases
• The exact exploit chain for CVE-2026-3985, including how session-stored input becomes injectable SQL
• The time-based proof-of-concept logic used to verify blind injection and extract hashes
• The disclosure sequence and plugin-specific remediation guidance for existing users

👉 The full Intruder post covers the exploit chain, program slicing method, and proof-of-concept details.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It is designed for practitioners who need to connect identity governance to real-world security operations.