Can AI Code Review Detect Injection Vulnerabilities?

The oldest bug class meets the newest reviewer

Injection has topped or hovered near the top of the OWASP Top Ten for two decades: SQL injection, cross-site scripting, command injection, path traversal, template injection. The pattern is always the same — untrusted input crosses a trust boundary and gets interpreted as code. Every security team owns a scanner that hunts for it. So when engineering leaders evaluate AI code review, the sharpest version of the security question is this one: will an LLM reviewer actually catch an injection bug in a pull request, or does it just paraphrase the linter?

The honest answer has three parts: yes for a meaningful and useful class of cases, no for a class that nothing diff-scoped can see, and the interesting part is knowing which is which before you bet your review process on it.

Why injection is a semantic problem, not a pattern problem

Classic static analyzers detect injection by taint tracking over known patterns: a source (request parameter), a sink (query executor, shell call, HTML output), and a path between them without a recognized sanitizer. Inside those patterns, SAST is exhaustive and tireless — it will check every file, every time, and never get bored.

The trouble is that real injection bugs are frequently pattern-breakers. The tainted value is renamed twice, passed through a helper, stored in an object field, and only then concatenated into a query. The sanitizer exists but is the wrong one for the sink — an HTML escaper in front of a shell call. The query builder is homegrown, so the scanner does not recognize the sink at all. Each of these defeats rule matching while remaining obvious to a reader who understands what the code means. Injection detection is, at its core, a reading comprehension problem — which is exactly the kind of problem LLM review changed.

What AI review reliably catches

• Concatenation reaching real sinks. User input flowing into SQL strings, shell commands, or file paths through ordinary code — including through intermediate variables and helpers inside the diff — gets flagged with an explanation and usually the correct fix: the parameterized API or escaping helper the codebase already uses elsewhere.
• The wrong defense in the right place. Escaping applied for one context and used in another — HTML-escaping before a SQL query, quoting that misses argument injection in a subprocess call. Rule engines see a sanitizer and stand down; a semantic reviewer checks whether it is the correct sanitizer for this sink.
• Sanitization that got lost in refactoring. The old call path validated input; the new one skips the validator. Nothing about the new code matches an unsafe pattern — the bug is the absence of a step, visible only by comparing the change against its surroundings, which is precisely what a reviewer with diff context does.
• Novel and framework-specific variants. Template injection in a server-side rendering helper, NoSQL operator injection in a Mongo filter built from user JSON, ORM escape hatches like raw query methods — cases where no signature exists because the pattern is too new or too local to the framework.

A well-configured reviewer also reports these findings differently: as a review comment on the exact line, in the language of the change, with the codebase's own conventions as the proposed fix. That materially raises the odds the author fixes it before merge instead of triaging it in a dashboard three sprints later — the fate of a large share of scanner findings. Our deeper dive on AI code review and security covers this reporting effect in detail.

What AI review will miss — by construction

A reviewer's evidence is the pull request plus retrieved context. Injection bugs whose evidence lives elsewhere are invisible no matter how capable the model is:

• Cross-boundary taint flows. Input enters service A, lands in a queue or database, and is interpolated into a query by service B in a different repository. No diff-scoped reviewer — human or AI — sees both halves.
• Configuration-dependent reachability. The vulnerable path only executes when a flag, environment variable, or deployment setting enables it. The code is in the diff; the reachability is not.
• Stored and second-order injection. The payload entered the system last month through a different endpoint; today's diff just reads a database field that was never trustworthy. The current change looks innocent because, locally, it is.
• Dependencies. Injection inside a third-party package is out of scope for review of your code. That remains the job of dependency scanning and advisories.

There is also the consistency caveat: LLM review is probabilistic. The same diff can get slightly different reviews on different runs, which is uncomfortable for compliance narratives that expect deterministic checks — and a real consideration we discuss in our false-positives deep dive.

The right architecture: layers, not a champion

The productive framing is not AI review versus SAST but AI review plus SAST, each covering the other's blind side. SAST provides the deterministic floor: every known pattern, every file, every commit, with results you can hand an auditor. AI review provides the semantic layer: the renamed-and-wrapped taint flow, the wrong sanitizer, the missing check, explained convincingly at the moment the author is most willing to fix it. Dependency scanning and dynamic testing cover the third rail neither can reach.

One more consideration for security-sensitive teams: where the review happens. Sending every diff to a third-party cloud service is itself a data-exposure decision. Running the reviewer inside your own infrastructure — the model PURA follows, detailed in our guide to self-hosted AI code review — keeps the code that is being checked for vulnerabilities from becoming a new vulnerability surface of its own.

So — can it?

Yes: AI code review detects a real, valuable class of injection vulnerabilities, including variants that slip past rule-based tools, and it reports them in a way that gets them fixed. No: it is not a complete injection defense, and anyone selling it as one should be asked about stored payloads and cross-service taint flows. Treat it as the semantic layer in a stack of defenses, and it will catch bugs this class of tooling has never caught before — on the pull request, before merge, where fixing them is cheapest.