Notifications
Clear all
Topic starter
18/08/2026 2:25 pm
TL;DR: Combining traditional code-scanning slices with LLM triage can move from broad repo search to automated exploitation, culminating in a multi-stage SQL injection 0-day in a WordPress plugin, according to Intruder. The finding matters because AI now amplifies targeted vulnerability research, but remediation speed and attack-surface control still determine whether exposure becomes compromise.
NHIMG editorial — based on content published by Intruder: AI-assisted vulnerability research and the CVE-2026-3985 writeup
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Constrain LLMs with program slices Feed models only the functions, data flows, and call chains relevant to a candidate issue.
- Classify database fields by credential sensitivity Tag password hashes, API keys, tokens, and session-linked values as identity-bearing data.
- Shorten remediation for externally reachable flaws Treat internet-facing issues that can be exercised in multiple requests as urgent exposure events.
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
👉 Read Intruder's analysis of AI-assisted vulnerability discovery and CVE-2026-3985 →
AI-assisted code scanning for 0-days: what changes for AppSec teams?
Explore further
18/08/2026 3:15 pm
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.
A few things that frame the scale:
- 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.
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
A question worth separating out:
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.
👉 Read our full editorial: AI-assisted vulnerability research is accelerating code exploitation
