CodeQL 2.27.1: Windows Mapped Drives Need JDK Workaround

This matters because CodeQL is the static-analysis engine behind GitHub code scanning, the feature that flags security problems in pull requests and on repository dashboards. When CodeQL's view of your code changes, the alerts your developers see change too. In 2.27.1 most of the work improves how well CodeQL tracks data through popular libraries and frameworks, more than it adds rules. That can raise or lower alert volume even though you changed nothing.

CodeQL 2.27.1 adds cpp/ambiguous-assignment-of-comparison and new C++ library models​

The C/C++ query in the headline is cpp/ambiguous-assignment-of-comparison. The official CodeQL changelog says it detects "potentially ambiguous expressions where a comparison result is assigned to a variable and the assignment is used as a truth value." Here is an illustrative example of our own, not one from GitHub: a condition that stores the result of a == b in a flag and tests that assignment in the same if. A reader can easily mistake that for a typo of ==, or misread which operator binds first. GitHub calls these expressions potentially ambiguous. The query flags code that's hard to read and may hide a bug. It doesn't prove a vulnerability.

The C/C++ library work may matter more to many codebases. CodeQL 2.27.1 adds taint-flow models for boost::asio::ip::basic_resolver::resolve, the Boost.Asio call that resolves hostnames. It also adds flow summaries for BloombergLP::bdlbb::Blob, the segmented byte buffer in Bloomberg's BDE libraries, and for the Protocol Buffers C++ API google::protobuf::MessageLite.

A taint-flow model or flow summary tells CodeQL how data moves through a library function it can't or doesn't analyze directly. Without one, the analysis can lose track of untrusted input when it passes through a Protobuf message or a network-resolver call, and any query that depends on following that input can miss the path. The new models don't correspond to newly disclosed vulnerabilities. They let existing security queries follow data through code that makes heavy use of Boost.Asio, BDE, or Protobuf. If your project uses those libraries, you may see new findings after the upgrade. The likeliest cause is better data-flow coverage, not a regression in your code.

Kotlin 2.4.20 support and a K2 fix for Android PendingIntent alerts​

On the JVM side, CodeQL 2.27.1 adds support for Kotlin 2.4.20. Teams that upgrade their Kotlin toolchain can keep code scanning on the matching CodeQL release.

The more practical change is an extraction fix. CodeQL's changelog says Foo::class.java arguments "were dropped during extraction under the Kotlin K2 compiler." K2 is Kotlin's newer compiler frontend, and extraction is the step where CodeQL builds its database from your source code. If a class-reference argument goes missing from that database, the queries are reasoning about incomplete code. GitHub names java/android/implicit-pendingintents as one query that could produce false positives as a result. That query looks for Android PendingIntent objects built from implicit intents.

For Android teams on K2, some existing alerts from that query and similar ones may close after this release. GitHub hasn't said that every such alert was a false positive. The fix covers cases where the dropped argument changed the answer. Treat alerts that close as a sign the extractor now sees your code correctly. Don't dismiss the query's remaining results in bulk.

Fastify, Go 1.27 and Rust models change what code scanning can see​

Several changes won't show up under a new query name but can still move alert counts.

For JavaScript and TypeScript, CodeQL now treats Fastify servers configured through chainable methods such as fastify().withTypeProvider<T>() or fastify().setValidatorCompiler(...) as the same server instance. Previously, routes registered on a server built that way might not be linked to it at all. GitHub says the fix works in two directions. It can add results for queries such as js/missing-rate-limiting on routes CodeQL couldn't see before. It can also remove false positives where a globally registered plugin, such as a rate limiter, already protects those routes. A Fastify codebase could therefore see both new and closed alerts in the same scan.

For Go, the release adds or improves data-flow models for standard-library APIs introduced or updated in Go 1.27:

• The models cover bytes.CutLast, database/sql.ConvertAssign, database/sql/driver.RowsColumnScanner.ScanColumn, net/url.URL.Clone, net/url.Values.Clone and strings.CutLast.
• The new encoding/json/jsontext package now has models.
• Coverage of the strings package grows to include Clone, Cut, CutPrefix, CutSuffix, Fields, FieldsFunc and Join, plus Builder.String, Builder.WriteByte, Builder.WriteRune, Reader.ReadByte, Reader.ReadRune, Replacer.Replace and Replacer.WriteString.

These are model changes, not new Go queries. In practice, CodeQL can now follow tainted strings through everyday operations like splitting, cutting, joining, and building strings, where a trace could previously break.

Rust gets two accuracy fixes. The first fixes path resolution for m::{self} imports when m is a trait. The second adds data-flow models for core::fmt::Write. According to the CodeQL changelog, that one "may improve detection of vulnerabilities where tainted data is written to a formatted output buffer."

rust-analyzer 0.0.347 changes the Rust AST for custom CodeQL queries​

The Rust extractor now uses rust-analyzer 0.0.347. That upgrade changes the abstract syntax tree (AST) that CodeQL's Rust libraries expose. Teams that only run GitHub's built-in queries won't notice. Teams that maintain their own Rust queries or libraries should review the changes before upgrading.

The documented changes:

Our reading, which the changelog doesn't spell out: any custom query that uses FormatArgsArgName or calls getPath() directly on a Visibility will need editing, because those names are gone or have moved. Most of the other entries are additions and shouldn't break existing code. Check the removed class and the moved accessor against your query packs before you pin to 2.27.1.

C# and GitHub Actions queries get quieter, and NuGet feeds follow org policy​

The C# changes lean toward code quality and reducing noise. The new cs/linq/missed-firstordefault query flags foreach loops that could be written more clearly with LINQ's FirstOrDefault method. This is a readability suggestion, not a security finding.

The related cs/linq/missed-* queries no longer suggest lambda rewrites that would capture in, out or ref parameters. C# doesn't allow lambdas to capture those, so the old suggestions pointed developers toward code that wouldn't compile.

On the security side, cs/web/missing-token-validation now recognizes ASP.NET Core's AutoValidateAntiforgeryTokenAttribute when it's registered as a global MVC filter through AddControllersWithViews and related methods. Many ASP.NET Core apps enforce anti-forgery validation globally this way instead of decorating each action. Until now, CodeQL could report actions protected by that global filter as missing CSRF token validation. Those false positives should now close.

Two GitHub Actions fixes target actions/unpinned-tag, the query that warns when a workflow references an action by a movable tag instead of a fixed commit:

• The query no longer reports action references pinned by a structurally valid .github/workflows/actions.lock entry for the enclosing workflow.
• The query no longer reports $/ self-repository references such as uses: $/path/to/action. The CodeQL changelog says these resolve to the same repository at the running commit and are therefore inherently pinned, the same as ./ local workspace references.

The phrase "structurally valid" matters. GitHub hasn't said a malformed lock entry gets the same exemption, so a lock file with errors could still leave warnings in place.

One change sits outside the query packs. Some organizations set up private NuGet registries at the organization level with the "Replaces base" option turned on. Those registries now replace the default NuGet feeds whenever CodeQL downloads dependencies, including for projects that list the default feeds explicitly. For teams that want CodeQL's dependency fetching to use only an internal feed, this closes a gap: a project-level feed setting no longer overrides the organization's policy. The change applies to CodeQL's own dependency downloads, not to NuGet behavior in general.

Windows CodeQL CLI users meet Temurin OpenJDK 25.0.4.1​

The GitHub blog announcement leaves out one detail that matters most to Windows readers running the CLI themselves. The release notes for the CodeQL CLI binaries state that the build of Eclipse Temurin OpenJDK that is used to run the CodeQL CLI has been updated to version 25.0.4.1. GitHub warns that Java 25 has a known issue that affects symlink resolution on mapped drives on Windows (JDK-8355342).

GitHub doesn't provide a fix inside CodeQL. It offers a workaround: users impacted by such regressions can run CodeQL with an alternative JDK using the CODEQL_JAVA_HOME environment variable. The setups most at risk are Windows build agents or developer machines that check out source code or keep CodeQL databases on a mapped network drive, especially where the path includes symbolic links. If CodeQL starts failing to resolve paths there after the upgrade, point CODEQL_JAVA_HOME at a different JDK installation. GitHub doesn't recommend a particular JDK version, so test whatever you choose before rolling it out.

Packaging is also changing. The 2.27.1 CLI binaries come as a platform-specific codeql-PLATFORM.zip or the generic codeql.zip which covers Linux x64, Windows x64 and macOS (including Apple Silicon). The full bundle release, which includes the query packs, follows the same pattern. Linux arm64 is available as the per-platform codeql-bundle-linux-arm64.tar.gz only. GitHub posted a deprecation notice for the all-platform CodeQL bundle on September 22, the same day 2.27.1 shipped. Scripts that download the combined archive should move to the win64 or other platform-specific package now, while both are still published.

What this means for you​

Your choice here is about monitoring and timing, not whether to upgrade. On GitHub.com, GitHub deploys each new CodeQL version to code scanning automatically, so the real work is spotting alert changes and explaining them to developers. GHES customers have a real choice. GitHub says GHES 3.24 will include CodeQL 2.27.1, but it hasn't given a release date for 3.24. Older GHES instances can upgrade CodeQL manually if they want the Kotlin, ASP.NET Core, or Fastify fixes sooner.

• Android teams building with the Kotlin K2 compiler should expect some java/android/implicit-pendingintents alerts to close. They should review the remaining alerts from that query one by one, not in bulk.
• Fastify codebases may see new js/missing-rate-limiting alerts on routes CodeQL couldn't see before, alongside closures where global plugins protect routes. Triage both before assuming a regression.
• Rust teams with custom CodeQL queries should look for FormatArgsArgName and direct Visibility.getPath() calls before adopting 2.27.1, because those names are gone or have moved.
• ASP.NET Core apps that register AutoValidateAntiforgeryTokenAttribute globally should see false cs/web/missing-token-validation alerts close without any code changes.
• Organizations that use "Replaces base" on private NuGet registries should confirm that CodeQL's C# dependency resolution now uses only their internal feeds, as intended.
• Windows CLI users with source code or databases on mapped drives should watch for symlink problems under Temurin OpenJDK 25.0.4.1 and keep CODEQL_JAVA_HOME ready as a fallback.

CodeQL 2.27.1 is a typical point release: two small new queries and a long list of accuracy fixes. Its real effect is on which alerts developers see. Better models for Boost.Asio, Protobuf, Go 1.27, Fastify and core::fmt::Write let existing security queries follow data further, while the Kotlin, ASP.NET Core and Actions fixes remove noise. GitHub's repository is already preparing version 2.27.2. The upcoming dates to plan around are the GHES 3.24 release, which has no date yet, and the retirement of the all-platform bundle. Windows automation that downloads CodeQL should switch to platform-specific packages before that retirement.