CodeQL 2.26 Now Scans Your AI Code for Prompt Injection

GitHub shipped CodeQL 2.26.0 on July 10 with a static analysis query that detects prompt injection in AI applications by tracking untrusted user data into system prompts for OpenAI, Anthropic, and Google GenAI APIs. The update automatically enables for JavaScript and TypeScript repositories with GitHub Code Scanning, flagging the vulnerable pattern of mixing user input with system instructions as a high-severity vulnerability.

GitHub shipped CodeQL 2.26.0 on July 10 with the most practically significant security update for AI application developers in the last year: a static analysis query that detects prompt injection at the code level, the same way CodeQL has detected SQL injection for a decade. If you already have GitHub Code Scanning enabled on a JavaScript or TypeScript repository, you have it right now — no configuration required. What the New Query Does The js/system-prompt-injection query uses taint tracking — CodeQL’s core technique — to follow untrusted user-provided data from its entry point HTTP request parameters, form inputs, query strings to its exit point: an AI model’s system prompt. If your code routes that data into the system message of an OpenAI, Anthropic, or Google GenAI API call without proper separation, CodeQL flags it as a high-severity vulnerability. The analogy holds precisely. When CodeQL flags db.query "SELECT FROM users WHERE id=" + userId , it’s because untrusted data is controlling a privileged instruction — the SQL query. When it flags { role: "system", content: userInput } , the same logic applies: untrusted data is controlling the model’s behavior directives. The model cannot distinguish “developer instruction” from “injected attack instruction” when they share the same string. CodeQL can. The 2.26.0 release expands sink coverage beyond the basics. The query detects injections targeting OpenAI Realtime session instructions and Sora generation prompts, Anthropic’s messages API and legacy completion endpoints, and Google GenAI system instructions and cached content. That’s comprehensive coverage of every major AI SDK in active use today. The Vulnerable Pattern — and the Fix The vulnerable antipattern is common in production AI apps, especially those built quickly or refactored from prototypes: js // VULNERABLE — user input in system prompt const userInput = req.body.message; const response = await openai.chat.completions.create { model: "gpt-5.6-sol", messages: { role: "system", content: You are a helpful assistant. Context: ${userInput} }, { role: "user", content: "Help me." } } ; The system message is for developer-controlled instructions. Mixing user input into it hands the attacker partial control over those instructions. The fix is not complex: js // SAFE — user input goes in user message only const userInput = req.body.message; const response = await openai.chat.completions.create { model: "gpt-5.6-sol", messages: { role: "system", content: "You are a helpful assistant." }, { role: "user", content: userInput } } ; System prompt: static string, developer-controlled. User content: the user role. The model sees both — but the role boundary communicates intent and removes the vulnerability CodeQL is detecting. How to Enable Code Scanning For public repositories, GitHub Code Scanning is free and takes three clicks to enable: Settings → Advanced Security → CodeQL analysis → Set up → Default → Enable. GitHub auto-detects JavaScript and TypeScript; scans run on push, pull requests, and weekly. Every new CodeQL version is deployed automatically to github.com — if you already have Code Scanning enabled, you received 2.26.0 on July 10 without doing anything. Check your Security tab now for new system-prompt-injection alerts. For private repositories, GitHub Code Security is required part of GitHub Team or Enterprise . Full setup documentation is in GitHub’s code scanning docs https://docs.github.com/en/code-security/code-scanning/enabling-code-scanning/configuring-default-setup-for-code-scanning . The Rest of 2.26.0 The headline feature overshadows a release that closes several long-standing gaps. Kotlin support now extends to 2.4.0 — which ships Swift export and SwiftPM dependency support, meaning Kotlin Multiplatform projects finally get accurate analysis. Go’s log/slog package, widely adopted since Go 1.21, finally gets coverage for log injection and clear-text logging vulnerabilities. And C Razor Page handler parameters OnGet , OnPost , OnPostAsync are now treated as remote flow sources, meaning cs/sql-injection works correctly in ASP.NET Core PageModel apps — a gap that’s been open since Razor Pages replaced MVC as the default ASP.NET pattern. See the full CodeQL 2.26.0 changelog https://github.blog/changelog/2026-07-10-codeql-2-26-0-adds-kotlin-2-4-0-support-and-ai-prompt-injection-detection/ for the complete list. Where the Query Falls Short The js/system-prompt-injection query covers JavaScript and TypeScript only. The majority of LLM application code in production is Python — using the Anthropic Python SDK, the OpenAI Python SDK, or LangChain. Python coverage for this query is not in 2.26.0. If your AI backend is Python, you are not covered yet. The query also does not detect indirect prompt injection — the more dangerous variant where an attacker embeds instructions in external content a document, a web page, a tool response that flows back into the model’s context. That’s the attack vector behind the Comment and Control research https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-github-actions-security-20260503-csa-st/ and most real-world AI agent compromises in 2026. Static analysis cannot reason about what external content will contain at runtime. That problem still requires runtime mitigation — the OWASP Prompt Injection Prevention Cheat Sheet https://cheatsheetseries.owasp.org/cheatsheets/LLM Prompt Injection Prevention Cheat Sheet.html is a solid starting point. What This Marks Prompt injection has been treated as a model alignment problem — something for AI labs to solve, not something developers can prevent in code. CodeQL 2.26.0 disagrees with that framing. It treats the vulnerable pattern as a programming error, detectable and fixable at the code level. That’s correct. Direct prompt injection — where your own application routes user input into privileged model instructions — is not a model failure. It’s a code failure. Now your static analyzer knows that too. If you ship JavaScript or TypeScript AI applications, check your Code Scanning results today. The query is already deployed.