CodeQL 2.27.2 is available with analysis updates for C/C++, Go, Rust, and JavaScript/TypeScript. The release also changes the Go control-flow graph (CFG), updates several security queries, and introduces a build-environment limitation for some compiled-language workflows on macOS.
Those changes matter beyond repositories that use the built-in queries. Teams with custom Go queries, CodeQL integrations, standalone CLI installations, or macOS-based build runners should review their workflows before treating the update as a routine version change.
What changed in CodeQL 2.27.2
The language updates are spread across both libraries and query behavior:
- C and C++: regular expressions used with
std::regexare now parsed using the ECMAScript grammar. The analysis also adds Comdb2 SQL-injection sink models and flow summaries for Bloomberg BDE codecs and byte-stream deserializers. - Go: CodeQL now models
github.com/coder/websocketin addition tonhooyr.io/websocket. - Rust: the library exposes
AnyAttrandDocComment, improves data flow for async blocks used withawait, and adds flow summaries fornative-tls,async-native-tls, andtokio-native-tls. - JavaScript and TypeScript: analysis recognizes the Workflow SDK directives
use workflowanduse step. Hapi route-handler and request-input tracking also improve through support for custom route-registration helpers and higher-order functions.
Several security queries have changed as well. The release updates recognition of clickjacking protections, adjusts Razor WriteLiteral XSS sink handling, and changes the trusted-owner syntax for the actions/unpinned-tag query. An entry such as !github can remove an owner from the trusted set.
These changes can affect results in individual repositories, but the supplied release information does not quantify whether findings, scan duration, or resource use will increase or decrease. Teams should compare results in representative projects rather than assume a universal outcome.
The Go CFG rewrite is the largest migration concern
CodeQL 2.27.2 rewrites Go control-flow analysis to use the shared CFG library. The new representation adds nodes for constructs such as assignments, parameters and results, range statements, and deferred calls. It also excludes unreachable nodes.
As a result, custom queries and tooling can see changes to CFG nodes, edges, locations, textual representations, and basic-block boundaries. The Go library removes BasicBlocks::Cfg, adds ControlFlow::EntryNode and ControlFlow::ExitNode, and deprecates IfStmt.getCond in favor of IfStmt.getCondition. Return types for IfStmt.getThen and LoopStmt.getBody are wider, and SwitchStmt.getExpr is new.
Several Go intermediate-representation instruction classes were also removed or consolidated. The available documentation does not provide a complete version-specific migration guide for every affected instruction or custom-query pattern, so teams should treat this as a compatibility review rather than assume that all existing queries will fail.
The maintained Go CFG documentation describes the shared implementation and notes that deeper semantic analysis generally belongs in the data-flow graph instead of depending on low-level CFG details. That is useful guidance for new or maintained queries, but it does not eliminate the need to inspect integrations that directly depend on the previous representation.
CLI behavior and runner requirements
The CLI now reports invalid qlpack: and from: values in query suites as user-facing errors. It also rejects YAML data-extension integers outside the signed 32-bit range, prefixes standard-error messages with ERROR: or WARNING:, and supports --dil-constants with --dump-dil. Data-extension loading now warns only when none of a pack’s listed patterns match files.
The standard-error prefix change may matter to integrations that parse CLI text. The research supplied for this release says structured logs and SARIF are unchanged, but text-based automation should be tested against the new output.
There is also a specific macOS limitation. For compiled-language autobuild and manual build modes, the release announcement says macOS 27 with any Xcode version and macOS 26 with Xcode 27 are unsupported. Affected workflows should use no newer than macOS 26 and Xcode 26. The general CodeQL system-requirements documentation lists supported macOS versions but does not independently establish every detail of this release-specific restriction.
This limitation applies to the affected compiled-language build modes, not necessarily every CodeQL workflow. The supplied build-options documentation confirms no-build support for C/C++ and Rust, but does not document the implementation details behind the release announcement’s improvement to build mode none on macOS.
Availability through CodeQL Action and the CLI
The CodeQL Action changelog records CodeQL 2.27.2 as the default bundle version in Action 4.38.3, dated October 8, 2026. The primary GitHub announcement is dated October 9, while the supporting CodeQL CLI changelog page is titled October 7. These dates appear to represent different publication or rollout events; the supplied documentation does not reconcile them further.
GitHub says new CodeQL versions are automatically deployed to code-scanning users on GitHub.com. The announcement also says a future GitHub Enterprise Server release will include CodeQL 2.27.2, but it does not identify that release or provide an availability date. The supplied GHES documentation lists CodeQL 2.25.6 for GHES 3.22, so administrators should not assume that a particular GHES version already includes 2.27.2.
For standalone use, GitHub’s CLI setup guidance recommends a per-platform CodeQL bundle from CodeQL Action releases. The documented packages include linux64, linux-arm64, osx64, and win64; the all-platform bundle is being phased out. The extracted bundle should be available on each CI server that runs analysis. On Apple Silicon macOS, the setup documentation requires Xcode command-line developer tools and Rosetta 2. Non-glibc Linux distributions such as Alpine Linux are unsupported.
What you should do
- Review custom Go analysis. Search queries and tooling for use of the previous CFG nodes, edges, locations, basic blocks, textual representations,
BasicBlocks::Cfg, deprecated APIs, and removed or consolidated IR instructions. - Prefer higher-level data-flow abstractions where appropriate. Avoid building new semantic analysis around low-level CFG details that may change between library versions.
- Audit macOS runners. For compiled-language autobuild or manual build workflows, identify macOS 27 and macOS 26 with Xcode 27, then move affected jobs to no newer than macOS 26 and Xcode 26.
- Test CLI integrations. If automation parses standard-error text, account for the new
ERROR:andWARNING:prefixes. - Use a matching standalone bundle. Keep the CLI, queries, libraries, and precompiled queries from the same bundle together, and validate the installation with commands such as
codeql resolve packsorcodeql resolve languages. - Compare scan results deliberately. Run the updated analysis against representative repositories and review changed findings instead of assuming that the release will always produce more or fewer alerts.
Scope of the update
CodeQL powers GitHub code scanning. The Default suite contains 498 security queries covering 170 CWEs, while the Extended suite adds 131 queries covering 32 additional CWEs. CodeQL 2.27.2 changes analysis within that broader system, but the supplied sources do not describe the release itself as a vulnerability, exploit, or security flaw.
For most GitHub.com users, the practical question is whether new analysis behavior changes results or whether local build environments and custom Go queries need adjustment. For organizations managing their own runners or standalone CodeQL deployments, the macOS and bundle requirements make the upgrade review more operationally significant.
