GitHub Actions pipelines have become one of the quieter attack surfaces in software development. They pull in third-party actions, cache dependencies, and pass secrets between jobs, often without anyone reviewing the workflow file as closely as they’d review application code. That gap is exactly where cache-poisoning and output-clobbering attacks live, and it’s why GitHub keeps tuning CodeQL’s ability to spot them.

CodeQL 2.26.3, released August 12 and detailed in GitHub’s changelog on August 19, focuses squarely on that problem. The update refines several GitHub Actions security queries and expands JavaScript and TypeScript modeling, with a particular focus on Vue applications.

The release keeps CodeQL’s default security suite at 497 queries covering 170 CWE categories, with an extended suite adding another 131 queries across 32 more CWEs. That scope matters less than the accuracy of individual queries, though, which is where most of this release’s effort went.

The Actions-focused changes are practical rather than flashy. The output-clobbering query now delivers messages tailored to the specific output channel it flags, and it no longer flags simple jq path filters when their output remains JSON-encoded, which should reduce noisy false positives. GitHub also fixed a performance issue in that query caused by unescaped source-code input in a regular expression.

Cache-poisoning and untrusted-checkout queries got a workflow improvement of their own: alert paths now start at the expressions that control untrusted checkouts, so the alert message links directly to the code responsible instead of pointing upstream and leaving the reader to trace it back. The cache-poisoning queries now also account for read-only cache access in low-trust triggers, which should reduce alerts for workflows that can’t actually poison a cache even if they touch one.

“Workflow files are production code that nobody reviews like production code,” said Mitch Ashley, an analyst with Futurum Group. “Platform teams inherit the fallout when a poisoned cache reaches a build. Sharper alerts matter more than query count, because triage runs out first.”

Two other fixes matter for teams securing their CI/CD pipelines. CodeQL now correctly classifies the schedule event when it determines whether a workflow is externally triggerable, and the environment-variable injection query requires that an untrusted source and a privileged context originate from the same trigger event before it flags a risk. Both changes are aimed at the same goal: fewer alerts that don’t reflect real exposure, so security teams spend less time triaging noise.

There’s also a breaking change worth flagging. GitHub removed the codeql.actions.security.SelfHostedQuery module because it couldn’t reliably distinguish self-hosted runners from GitHub-hosted ones based on labels alone. Teams that built custom queries on top of that module will need to adjust.

The JavaScript and TypeScript updates lean into how modern front-end frameworks actually move data. Vue Router’s useRoute() is now recognized as a client-side remote flow source, and CodeQL added flow models for Vue’s Composition API helpers, including ref, shallowRef, toRef, reactive, and computed. For teams running Vue at scale, that closes a real gap. A lot of routing and state logic in modern Vue apps runs through those exact functions, and previous CodeQL versions couldn’t always trace tainted data as it moved through them.

CodeQL also added support for Sails Action2 controllers, treating declared input properties as remote flow sources, and now recognizes the @fastify/rate-limit package when checking for missing rate limiting. On the modeling side, custom queries can now reference specific files using the file:<path> syntax, making it easier to define sources and sinks tied to a particular exported API rather than to an entire package.

One more JavaScript change is worth calling out for anyone running security queries against API-heavy applications: promise-wrapped client response data is now tracked into promise fulfillment values. That means CodeQL can follow tainted data through a .then() chain instead of losing track of it once it’s wrapped in a promise, which is common in modern fetch and axios-based code.

None of these changes are dramatic on their own. That’s kind of the point. CodeQL’s value in a CI/CD pipeline comes from steadily closing small gaps between how code actually behaves and what a static analysis tool can see. A missed taint path through a promise chain, a mislabeled trigger event, an alert that doesn’t point at the right line of a workflow file — each one is small until it’s the reason a real issue slips through or a team stops trusting the tool’s output.

Ashley sees a bigger shift behind these incremental fixes. “Scanning on a schedule was built for code written at human speed,” he said. “AI writes faster than reviewers can absorb, which pushes security to the moment of creation. Security leaders have to make that shift this cycle.”

For DevOps and platform teams running CodeQL against GitHub Actions workflows, this release is worth a routine update rather than a fire drill. The exception is anyone using the removed SelfHostedQuery module, who should check their custom query suites before the next scan. Everyone else gets quieter, more accurate alerts on their next run, which is arguably the more valuable outcome. Static analysis tools earn trust by being right often enough that teams stop double-checking them, and this release is another step in that direction.

The update deploys automatically for GitHub.com. A corresponding release for GitHub Enterprise Server is expected to follow.