CodeQL Is Starting to Treat Prompt Injection Like Code, Not Folklore

GitHub shipped CodeQL 2.26.0 with the usual grab bag of language support and query tuning. The interesting bit is smaller and sharper: JavaScript and TypeScript now get a js/system-prompt-injection query that detects untrusted user-controlled values flowing into an AI model’s system prompt.

That is not the end of prompt injection. It is not even the beginning of the end. But it is a useful marker: one class of LLM application bug is becoming boring enough to scan for. Boring is where security work starts paying rent.

What changed

According to GitHub’s changelog, CodeQL 2.26.0 adds:

• Kotlin support up to 2.4.0.
• More C#, Go, Swift, Python, and GitHub Actions analysis improvements.
• Additional JavaScript/TypeScript modeling for prompt-injection sinks across OpenAI, Anthropic, and Google GenAI SDK APIs.
• A new js/system-prompt-injection query for cases where untrusted user input can reach an AI model’s system prompt.

The fuller CodeQL 2.26.0 changelog is more explicit: the new query looks for untrusted, user-provided values flowing into the system prompt of an AI model, where that input could alter model behavior. It also calls out expanded sink modeling for OpenAI Sora prompt APIs, OpenAI Realtime session instructions, Anthropic legacy completion prompts, and Google GenAI cached content and system instructions.

GitHub also notes that new CodeQL versions are automatically deployed to GitHub code scanning users on github.com, with the functionality headed into a future GitHub Enterprise Server release. In other words, some teams will get this without scheduling a security tooling summit. A rare mercy.

Why builders should care

Most AI security advice still lives in two uncomfortable places:

1. Broad guidance documents that are directionally right but hard to operationalize.
2. Red-team demos where the model is tricked into doing something obviously cursed.

Those are useful, but they do not fit neatly into pull requests. CodeQL does.

GitHub’s move matters because it treats at least one LLM failure mode as a data-flow problem:

• What input is controlled by a user or attacker?
• Where does that value travel?
• Does it land in a privileged instruction channel such as a system prompt?

That is a familiar shape for engineers who already think about SQL injection, SSRF, command injection, and secrets exposure. The sink is newer, but the discipline is not. Follow the tainted value. See where it gets authority.

This is especially relevant for agentic applications, internal copilots, RAG systems, and customer-support bots where developers are tempted to build prompts from strings like this:

const system = `You are a helpful assistant for ${customerName}. ${customPolicy}`;

That code may look like configuration. It may actually be privilege assignment with a template literal mustache.

The practical implication

If your application calls LLM APIs from JavaScript or TypeScript, treat this as a prompt to inspect your prompt construction. Sorry. The pun was sitting in the road.

At minimum:

• Keep system prompts static where possible.
• Do not concatenate user-controlled values into system instructions.
• If tenant- or user-specific context must influence behavior, pass it as data with clear boundaries rather than rewriting the model’s operating instructions.
• Review wrappers around OpenAI, Anthropic, Google GenAI, LangChain-style abstractions, and internal SDKs. The dangerous flow may be hidden behind helper functions with friendly names like buildAssistantContext.
• Enable or review CodeQL code scanning results if your repository is eligible.
• Add tests or review rules for prompt builders, not just API handlers.

This also suggests a useful mental model: system prompts are not comments. They are closer to policy code. If attacker-controlled text can rewrite them, you have a boundary problem even if the application never calls eval, opens a socket, or drops a database table.

What this does not solve

Static analysis will not catch every prompt-injection issue. It is best at flows the analyzer can see: user input moving through code into known sinks. It is weaker when behavior depends on runtime configuration, indirect retrieval, opaque SDK wrappers, model-hosted tools, or prompt material assembled outside the repository.

OWASP’s LLM01: Prompt Injection guidance is also a reminder that RAG and fine-tuning do not magically remove the problem. Indirect prompt injection through retrieved documents, web pages, emails, tickets, or files remains a different and messier class of risk. CodeQL can help with code paths. It cannot bless every byte your agent reads from the world.

There is also a false-positive and false-negative question. New query modeling usually improves over time as real projects trip over it. That is normal. Static analysis is not a vending machine where you insert code and receive certainty.

The takeaway

The useful shift is not that GitHub has “solved” prompt injection. It has not. The useful shift is that prompt-injection risk is being pulled into the same machinery developers already use for code review, code scanning, and security triage.

That is where this category needs to go. Less mysticism. More boring red squiggles in pull requests.

The robots can keep their existential drama. The rest of us have CI to fix.