CodeQL 2.26.0 Adds Prompt Injection Detection and Kotlin 2.4.0 Support
GitHub's static analysis engine now catches AI prompt injection flaws in JavaScript and TypeScript, while expanding language coverage to the latest Kotlin release — a signal that secure coding tooling is finally catching up to the AI-integrated codebase.
GitHub released CodeQL 2.26.0 on July 10, adding two capabilities that address very different but equally pressing concerns for development teams. First, Kotlin support now extends through version 2.4.0, keeping Android and server-side Kotlin developers inside CodeQL's security analysis umbrella. Second, and more notable for anyone building AI-powered features, the release introduces new prompt injection sinks for JavaScript and TypeScript that cover OpenAI, Anthropic, and Google GenAI SDK APIs. If your codebase talks to an LLM, CodeQL can now flag where untrusted input might reach it.
These aren't flashy features. They're plumbing. But they reflect a meaningful shift in how the industry is treating two realities: Kotlin is no longer a secondary language that tooling can lag behind on, and prompt injection is no longer a theoretical risk that security teams can defer.
What's Actually in the Release
CodeQL is the static analysis engine that powers GitHub's code scanning. It works by modeling your code as a queryable database, then running security queries against it to find vulnerabilities like SQL injection, cross-site scripting, or — now — prompt injection.
The 2.26.0 changelog details several language-specific improvements beyond the headline features. C# gains support for Razor Page handler method parameters as remote flow sources, meaning security queries like cs/sql-injection can now catch vulnerabilities in ASP.NET Core PageModel subclasses. Go picks up models for the log/slog package introduced in Go 1.21, extending log injection and clear-text logging detection to the newer structured logging API.
But the two standout additions are the Kotlin 2.4.0 support and the JavaScript/TypeScript prompt injection sinks. The latter specifically covers Sora prompts, OpenAI Realtime session instructions, Anthropic legacy completion prompts, and Google GenAI cached content and system instructions. That's a broad surface area across the three major commercial LLM providers.
The release deploys automatically to all users of GitHub code scanning on github.com, with inclusion in a future GitHub Enterprise Server release planned separately. (CodeQL 2.26.0 changelog)
Prompt Injection Detection: Why Static Analysis Catches What Model Defenses Miss
Prompt injection is the security problem that arrived with the LLM era and stubbornly refuses to be solved at the model layer alone. The basic idea: an attacker embeds instructions in data that an AI system processes, tricking it into performing unintended actions. It's conceptually similar to SQL injection — untrusted input reaches an interpreter without proper sanitization — but the "interpreter" is a language model whose behavior is probabilistically controlled rather than deterministically defined.
Google has been publicly documenting its approach to this threat. Google's post on estimating prompt injection risk describes building an automated red-teaming framework that simulates indirect prompt injection attacks, specifically testing scenarios where an AI agent with email access could be manipulated into exfiltrating sensitive user data like passport or social security numbers. The attack model involves hiding malicious instructions in emails that the agent retrieves and processes.
Google's separate post on Workspace defenses frames indirect prompt injection as a problem you don't solve once. Instead, Google describes a continuous cycle of human red-teaming, automated adversarial testing, and layered defenses. Google notes that increasingly agentic AI systems combined with diverse content sources create "an ultra-dynamic and evolving playground for adversarial attacks."
This is the context that makes CodeQL's new prompt injection sinks significant. Model-level defenses are necessary but insufficient. If your JavaScript code passes user-controlled strings directly into an OpenAI or Anthropic API call as a system prompt, no amount of model-side filtering will reliably save you. Static analysis catches this at the code level, before deployment, by identifying the data flow from untrusted source to dangerous sink.
The practical value for developers is straightforward: if you're integrating LLM APIs into a web application, CodeQL can now flag the paths where user input reaches prompt parameters. It won't catch every creative prompt injection vector, but it will catch the obvious ones — the equivalent of parameterized queries for the AI era.
Kotlin 2.4.0: Keeping Pace With a Moving Target
Kotlin's rapid release cadence has historically been a pain point for static analysis tools. When your analyzer lags behind the language version your team is using, you're either scanning with incomplete coverage or not scanning at all. Neither option is acceptable for security-conscious teams.
CodeQL's Kotlin 2.4.0 support means teams using the latest Kotlin features — including recent improvements to the K2 compiler and language enhancements — get the same security analysis coverage as teams on older versions. For Android development shops in particular, where Kotlin is the default language and Google's tooling often pushes developers toward newer versions, this matters. (Android Developers: Migrate to built-in Kotlin)
This update also builds on CodeQL's broader trajectory of treating Kotlin as a first-class citizen alongside Java. The models-as-data update from April 2026 listed Java/Kotlin as a single supported language pair for custom sanitizers and validators, allowing teams to define their own security-relevant functions declaratively in YAML rather than writing custom CodeQL queries. That feature, available since CodeQL 2.25.2, lets you tell CodeQL about your project's own HTML-escaping functions or input validation methods so it stops flagging sanitized data flows as vulnerabilities.
Together, these updates mean Kotlin teams can run current-version analysis with custom security models — a combination that was difficult to achieve even a year ago.
The Bigger Picture: Security Tooling for AI-Integrated Codebases
GitHub has been steadily expanding CodeQL's scope to match how modern applications are actually built. The AI-powered detections announcement described a strategy where CodeQL and AI-powered analysis work together, extending vulnerability detection across more languages and file types than either approach covers alone.
The prompt injection sinks in 2.26.0 are a concrete example of this strategy in action. Traditional static analysis excels at tracking data flow through well-defined APIs. LLM SDK calls are, structurally, just API calls — they have parameters, some of which are dangerous to populate with untrusted data. CodeQL's taint tracking is well-suited to this problem.
What static analysis alone can't fully address is the semantic dimension of prompt injection. A string that looks innocuous to a data flow analyzer might still manipulate an LLM's behavior in unexpected ways. This is why Google's approach, as described in its risk estimation framework, emphasizes runtime monitoring and continuous red-teaming alongside static defenses.
For development teams, the practical takeaway is layered. Use CodeQL to catch the structural vulnerabilities — untrusted input reaching prompt parameters. Use runtime defenses and output filtering to catch the semantic attacks that slip through. And treat prompt injection like any other injection vulnerability class: with input validation, least-privilege API access, and the assumption that your defenses will be tested.
What Comes Next
The 2.26.0 release points toward a future where security scanners understand AI integration patterns as well as they understand database queries or HTTP handlers. We're not there yet. The current prompt injection sinks cover the major commercial APIs, but the ecosystem of LLM tooling is expanding rapidly — LangChain, LlamaIndex, and custom orchestration layers — each new abstraction creates new potential sink points.
The models-as-data approach GitHub introduced in April offers a path forward here. Teams can define their own barriers and barrier guards for custom AI integration code without waiting for GitHub to ship built-in support. That's the right architecture for a fast-moving space.
For now, if you're building with Kotlin 2.4.0 or integrating OpenAI, Anthropic, or Google GenAI APIs in JavaScript or TypeScript, CodeQL 2.26.0 is worth enabling. It deploys automatically on github.com. The security coverage isn't exhaustive, but it's materially better than what existed last week — and in application security, incremental improvement compounds.
