CodeQL 2.27.2 Adds C++ Regex Support and Improves Go, Rust, and JavaScript Analysis

Static analysis helps developers identify potential security vulnerabilities before code reaches production. However, the quality of the results depends on how well an analysis engine understands the programming language, frameworks, and libraries used by an application.

CodeQL 2.27.2 introduces improvements across C++, Go, Rust, and JavaScript/TypeScript. The release adds a parser for ECMAScript regular expressions used by C++ std::regex, expands data-flow analysis for several libraries, and improves framework-specific tracking.

The update also changes Go's control-flow graph implementation, which is important for developers maintaining custom CodeQL queries. Teams using CodeQL on macOS should also review the documented compatibility restrictions for compiled-language analysis.

What Is CodeQL?

CodeQL is a static analysis technology used by GitHub code scanning to identify potential security weaknesses in source code.

Instead of examining code only as text, CodeQL builds a representation of the program that can be queried. Security queries investigate patterns such as untrusted input reaching a sensitive operation, unsafe data handling, or missing security protections.

For example, a query might investigate whether user-controlled input reaches a SQL execution function without appropriate protection.

CodeQL 2.27.2 includes the following security query coverage:

Query suite	Security queries	CWE coverage
Default	498	170
Extended, additional coverage	131 additional	32 additional

CWE stands for Common Weakness Enumeration, a classification system for software security weaknesses. These figures describe query coverage, not the number of vulnerabilities a scan will discover or prevent.

What Changed in CodeQL 2.27.2?

The release focuses on improving how CodeQL understands language constructs, follows data through libraries, and analyzes framework behavior.

Language or component	Main improvement	Practical benefit
C/C++	ECMAScript regular-expression parser for `std::regex`	Better support for analyzing relevant regex expressions
C/C++	Comdb2 SQL-injection sink models and Bloomberg BDE flow summaries	Better tracking of potentially unsafe data flows
Go	Additional WebSocket import-path modeling	Supports projects using `github.com/coder/websocket`
Go	Reworked control-flow graph	More detailed control-flow representation, with breaking changes for custom queries
Rust	Improved async data flow and TLS library summaries	Better tracking through supported asynchronous and TLS-related code
JavaScript/TypeScript	Workflow SDK directive recognition and improved Hapi tracking	More accurate analysis of supported workflow and routing patterns
C#	Improved clickjacking and XSS query behavior	Better handling of certain ASP.NET Core security patterns

These improvements expand CodeQL's understanding of supported code. They do not automatically repair vulnerable applications.

C++ Analysis: Regular Expressions and SQL Injection

ECMAScript Regular Expressions in `std::regex`

C++ applications frequently use regular expressions to validate input, parse text, or extract information from strings.

The C++ std::regex library supports different regular-expression grammars. CodeQL 2.27.2 adds a parser for the ECMAScript grammar used by std::regex.

This gives the analysis engine a better foundation for understanding regular expressions written using that grammar. It is a parser improvement, not a guarantee that every regular-expression-related vulnerability will be detected.

Consider this example:

#include <regex>
#include <string>

bool isValidCode(const std::string& value)
{
    const std::regex pattern(R"([A-Z]{3}-[0-9]{4})");
    return std::regex_match(value, pattern);
}

The expression checks for three uppercase letters, a hyphen, and four digits.

CodeQL's ability to parse the relevant grammar improves its understanding of code using this API. Developers must still evaluate the expression's correctness, input limits, and runtime behavior independently.

Improved SQL-Injection Analysis for Comdb2

The release adds SQL-injection sink models for the Comdb2 C API functions cdb2_run_statement and cdb2_run_statement_typed.

A sink is a program operation where unsafe data may cause a security problem. For SQL injection, the concern is untrusted input reaching a database execution operation in a way that changes the intended SQL command.

For example, constructing SQL through string concatenation is risky:

std::string sql =
    "SELECT * FROM users WHERE username = '" +
    username + "'";

// Unsafe pattern: untrusted input is included in SQL text.
executeQuery(sql);

The function executeQuery here is illustrative. It represents a database execution wrapper rather than a specific Comdb2 API signature.

The safer design is to use parameter binding supported by the database interface:

// Illustrative pseudocode: use the database driver's
// parameter-binding API for the actual implementation.
executeParameterizedQuery(
    "SELECT * FROM users WHERE username = ?",
    username);

The placeholder and function names must be adapted to the actual database driver.

The CodeQL improvement helps the analysis engine recognize the relevant Comdb2 execution operations. Developers should still verify that their application uses safe parameter binding and handles database errors appropriately.

Go Analysis: WebSocket Support and Control-Flow Changes

Updated WebSocket Library Modeling

CodeQL now models github.com/coder/websocket in addition to nhooyr.io/websocket.

This matters for Go applications that use the newer import path. Library modeling helps CodeQL understand how supported APIs participate in program behavior and data flow.

For example, a WebSocket application might receive messages from a client, validate their contents, and use the resulting data in database operations.

Security analysis needs to understand the movement of that data through the application. Improved library modeling can help, but developers should continue validating message sizes, authentication, authorization, and input formats.

A Breaking Change for Custom Go Queries

The Go control-flow graph (CFG) implementation has been rewritten to use a shared CFG library.

A control-flow graph represents possible execution paths through a program. Custom CodeQL queries may depend on its nodes, edges, source locations, or basic-block boundaries.

The updated graph includes additional nodes for constructs such as assignments, parameters, results, range statements, and deferred calls. It also excludes nodes that are unreachable from the entry point.

Some existing query APIs have changed:

BasicBlocks::Cfg has been removed.
ControlFlow::EntryNode and ControlFlow::ExitNode have been added.
IfStmt.getCond is deprecated in favor of IfStmt.getCondition.
Certain return types and intermediate representation classes have changed.

If your team maintains custom Go queries, review them before upgrading the CodeQL bundle used in development or CI.

A query that compiles successfully may still need semantic validation if it relies on the previous graph structure.

Rust Analysis: Async Code and TLS Libraries

Rust's ownership model helps prevent several classes of memory-safety problems, but applications can still contain security weaknesses involving untrusted input, network communication, and incorrect data handling.

CodeQL 2.27.2 improves data-flow analysis for asynchronous blocks used with await. It also adds flow summaries for native-tls, async-native-tls, and tokio-native-tls.

Flow summaries describe how data enters, passes through, or leaves supported library operations. They help an analysis engine follow relevant information across library boundaries.

For example, a service might receive data from a remote client, process it asynchronously, and pass it to a sensitive operation. Better async data-flow modeling can help CodeQL understand relationships that would otherwise be harder to track.

The Rust extractor also adds support for the AnyAttr and DocComment classes. These additions improve the syntax information available to CodeQL queries.

Developers should not interpret these changes as a general guarantee that all asynchronous or TLS-related vulnerabilities will be detected. Detection still depends on the query, the code path, and the supported library models.

JavaScript and TypeScript: Workflow SDK and Hapi Improvements

The JavaScript/TypeScript updates address workflow directives and Hapi request handling.

Workflow SDK Directives

CodeQL now recognizes the Workflow SDK directives "use workflow" and "use step" as known directives.

This prevents the js/unknown-directive query from incorrectly flagging these supported directives as unknown.

For teams using the relevant Workflow SDK patterns, this reduces an unnecessary diagnostic and helps keep security analysis focused on meaningful findings.

Improved Hapi Route and Input Tracking

CodeQL also improves Hapi route-handler and request-input tracking through custom route-registration helpers and higher-order functions.

Consider a Hapi application that registers routes through a wrapper rather than declaring every handler directly. Analysis becomes more complicated when the relationship between a route, its handler, and its request parameters is indirect.

Improved tracking helps CodeQL follow these relationships through supported abstractions.

Developers should still validate request parameters, enforce authorization, and encode output appropriately. Static analysis complements these controls rather than replacing them.

How to Integrate CodeQL into a Development Workflow

Teams using GitHub code scanning on GitHub.com receive new CodeQL versions through GitHub's automatic deployment process. Teams using a self-managed CodeQL CLI or GitHub Enterprise Server should review their installed version and supported upgrade path.

A typical GitHub Actions workflow for CodeQL scanning can look like this:

name: CodeQL Security Analysis

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
  schedule:
    - cron: "30 2 * * 1"

jobs:
  analyze:
    name: Analyze Code
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
      packages: read

    strategy:
      fail-fast: false
      matrix:
        language: [javascript-typescript]

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Initialize CodeQL
        uses: github/codeql-action/init@v4
        with:
          languages: ${{ matrix.language }}

      - name: Autobuild
        uses: github/codeql-action/autobuild@v4

      - name: Perform analysis
        uses: github/codeql-action/analyze@v4

This example illustrates the workflow structure for a JavaScript/TypeScript repository. The language selection, build steps, action versions, and permissions must be adapted to the project. Compiled languages such as C++ and Go may require different build configuration, and production workflows should pin third-party actions to verified commit SHAs where appropriate.

For repositories already using code scanning, review the existing workflow rather than replacing it blindly. Confirm that the selected language, build mode, query suite, permissions, and runner environment match the application.

macOS Compatibility: An Important Upgrade Consideration

CodeQL 2.27.2 documents a limitation for compiled-language analysis on newer Apple toolchains.

According to the release notes, autobuild and manual build modes for compiled languages are unsupported on macOS 27 with any Xcode version, and on macOS 26 when Xcode 27 is selected. The issue relates to the removal of the multi-architecture x86-64/arm64 binaries required for traced analysis.

Teams using these combinations should review the supported environment before changing their CI runners. The documented guidance is to use macOS 26 or earlier with Xcode 26 or earlier for the affected build modes, while CodeQL support for alternative build configurations continues to evolve.

Do not assume that a successful local compilation guarantees that CodeQL can perform the required analysis in the same environment.

Best Practices and Common Mistakes

Best Practices

Upgrade deliberately. Test CodeQL changes in a non-production branch before rolling them out to critical repositories.
Validate custom queries. Pay particular attention to Go queries that depend on control-flow graph structure.
Keep build environments supported. Check the operating system and compiler versions used by compiled-language scans.
Use secure coding patterns. Prefer parameterized SQL, validate external input, and enforce authorization independently of static analysis.
Review alerts in context. Confirm the source, data flow, and sensitive operation before deciding whether a finding is exploitable.
Track scan failures. Distinguish build failures, query compilation errors, authentication problems, and actual security findings.

Common Mistakes

Assuming that additional language support guarantees complete vulnerability detection.
Ignoring breaking changes in custom CodeQL queries.
Treating every alert as a confirmed exploitable vulnerability.
Disabling security checks to work around a configuration problem.
Upgrading a CI runner without checking CodeQL build-mode compatibility.
Relying exclusively on static analysis instead of combining it with tests, dependency scanning, and code review.

Advantages and Disadvantages

Advantages	Disadvantages or limitations
Better parsing and library modeling across several languages	Improvements apply to supported patterns, not every possible code path
Expanded tracking for selected SQL and data-flow operations	Developers must still validate findings and application behavior
More accurate recognition of supported workflow and routing patterns	Custom queries may require maintenance after structural changes
Broader query coverage through the Extended suite	Additional queries may require more analysis time and review effort
Improved understanding of Go control flow	Existing queries that depend on the previous CFG can break

Summary

CodeQL 2.27.2 expands static-analysis capabilities across C++, Go, Rust, and JavaScript/TypeScript. Its most notable changes include ECMAScript regular-expression parsing for C++ std::regex, additional SQL-injection and data-flow models, improved asynchronous Rust analysis, and better tracking of selected JavaScript frameworks.

For security teams, these changes can improve the analysis of applications that use the affected languages and libraries. For developers maintaining custom queries, the Go control-flow graph rewrite deserves particular attention. Teams running compiled-language scans on macOS should also verify their build environment before upgrading.

The practical approach is to update deliberately, validate custom queries, keep CI environments compatible, and treat CodeQL as one part of a broader application-security process.