Code signing for gh-aw binaries

When installing or running the gh-aw GitHub CLI extension on Windows, Microsoft Defender immediately blocks/quarantines gh-aw.exe.

This prevents using commands such as:

gh aw compile <workflow>

Detection

Microsoft Defender detection:

Trojan:Win32/Wacatac.B!ml

The alert appears immediately after installing the extension.

Affected file

C:\Users\<user>\AppData\Local\GitHub CLI\extensions\gh-aw\gh-aw.exe

Steps to reproduce

gh extension remove github/gh-aw
gh extension install github/gh-aw
gh aw compile <workflow>

Actual result

Windows Defender blocks the extension binary.

Example error:

failed to run extension: fork/exec C:\Users\<user>\AppData\Local\GitHub CLI\extensions\gh-aw\gh-aw.exe:
Operation did not complete successfully because the file contains a virus or potentially unwanted software.

Expected result

The extension installs and runs without being blocked by Microsoft Defender.

Environment

OS: Windows 11
GitHub CLI version: 2.93.0
gh-aw version: 0.76.1
Install command: gh extension install github/gh-aw
Defender detection: Trojan:Win32/Wacatac.B!ml

From agent analysis:

Root cause and fix

The fix is Windows Authenticode code signing of the gh-aw.exe binary. Signed binaries are trusted immediately by Defender regardless of ML scores. This is the standard resolution for Go-based tools with this issue (e.g., golangci-lint, goreleaser, and others have all gone through this).

Short term, users can:

Submit the binary to Microsoft via Security Intelligence submission portal as a false positive — Microsoft typically whitelists within 24–48h
Add an exclusion for C:\Users<user>\AppData\Local\GitHub CLI\extensions\gh-aw\ in Defender settings
Long term, the project should add Authenticode signing to the Windows binaries in the release pipeline in the push_tag job, after the Build binaries step.

also

Now I have enough context to give a thorough assessment. Let me summarize my findings:

Analysis: Trojan:Win32/Wacatac.B!ml Detection

Conclusion: This is a well-known false positive, not a real infection.

Why the detection is almost certainly a false positive

The critical indicator is the !ml suffix. Trojan:Win32/Wacatac.B!ml where !ml means this is a machine-learning heuristic detection, not a signature match against known malware. Windows Defender's ML engine is notoriously prone to flagging Go binaries for structural reasons.

Go binaries are the single most commonly false-positive-flagged executables by Defender ML because:

Static linking — Go bundles its entire runtime into one large PE file, which resembles self-packed malware to heuristic models

-s -w strip flags — The release build uses -ldflags="-s -w" which strips debug symbols and DWARF info, a compression pattern also used by packers like UPX

-trimpath — Combined with symbol stripping, this further reduces metadata that AV engines use to classify benign binaries

Unsigned binary — There is no Windows code-signing (Authenticode) certificate applied to the gh-aw.exe build; unsigned PE files receive higher ML scrutiny

Build process verification

I reviewed the full build chain:

Component Status

build-release.sh — cross-compilation script Clean: standard go build, no injected code

Makefile — build flags -s -w -X main.version=... Clean: expected flags only

go.mod — all direct dependencies Clean: all are well-known, maintained packages

release.md — release pipeline Clean: cache: false explicitly disabled to prevent cache poisoning attacks; SBOM generated post-build; id-token: write + attestations: write present for supply chain provenance

Go toolchain used Set via go-version-file: go.mod from actions/setup-go with pinned action hash

No UPX or external packing tools Correct: only wasm-opt is used, only on .wasm, not the PE binary

There is no evidence of tampering in the build process. No injected commands, no third-party build tools applied to Windows binaries, no suspicious dependencies.

Root cause and fix

The fix is Windows Authenticode code signing of the gh-aw.exe binary. Signed binaries are trusted immediately by Defender regardless of ML scores. This is the standard resolution for Go-based tools with this issue (e.g., golangci-lint, goreleaser, and others have all gone through this).

Short term, users can:

Submit the binary to Microsoft via Security Intelligence submission portal as a false positive — Microsoft typically whitelists within 24–48h

Add an exclusion for C:\Users\<user>\AppData\Local\GitHub CLI\extensions\gh-aw\ in Defender settings

Long term, the project should add Authenticode signing to the Windows binaries in the release pipeline in the push_tag job, after the Build binaries step.

Thanks. Since it’s not my PC I am not gonna submit the binary to Microsoft, I’ll wait until it gets whitelisted or until gh aw provides a signed release. In the meantime, I’ll continue working with an older version (v0.75.4)

Link to internal guide on this: https://thehub.github.com/security/security-operations/code-signing/onboarding/

I can confirm Windows Defender is still blocking the executable because it isn't signed properly (as of today, 8/12/2026)

Status (2026-10-07; Needs progress check): A user reported on 2026-08-12 that Windows Defender was still blocking the gh-aw executable. The issue remains open; check whether current release binaries are signed and whether the detection persists before proposing a resolution.

Current-state refresher — 2026-10-16

Verdict: Partially addressed through scanning; code-signing and the current endpoint experience remain unverified. August 12 remains the latest user confirmation of blocking in this discussion.

Current main (0d15bd1649f6) has a Defender release gate verifying checksums, updating signatures, and scanning Windows binaries. #57768 added daily scanning and #58115 hardened it. These are substantive mitigations missing from the earlier refresher.

They are not Authenticode signing: the release builder cross-compiles the executables, and the build/upload path does not establish a signing step. The latest published release is v0.92.0; I have not inspected its PE signature or reproduced detection on Windows.

Remaining: establish signing status of published assets and validate installation on an affected machine. Signing does not guarantee Defender acceptance, and an ML detection alone proves neither malware nor a false positive. This review does not recommend disabling protection.

Still relevant (2026-10-22): scanning mitigations pass, but signing and affected-machine success remain unverified. The v0.93.0 release Defender job successfully scanned the Windows binaries, and the October 22 daily Defender scan job also succeeded. This is stronger evidence than the October 16 source-only assessment.

However, the current release builder and build/upload/Defender pipeline do not establish an Authenticode signing step. A successful runner scan is neither a Windows publisher signature nor proof that installation works under affected endpoint policies. August 12 remains the latest affected-user confirmation in this discussion; I did not inspect the released PE signatures or reproduce installation on Windows.

Next action: inspect both published Windows assets with Get-AuthenticodeSignature, record signer/status and asset hashes, implement release signing if absent, and validate gh extension install github/gh-aw plus gh aw compile on an affected Windows machine with protection enabled. Keep this open until code signing and the install/run outcome are demonstrated. Signing does not guarantee Defender acceptance; an ML detection alone proves neither malware nor a false positive.

Navigation Menu

Repository navigation

Code signing for gh-aw binaries #35467

Detection

Affected file

Steps to reproduce

Actual result

Expected result

Environment

Root cause and fix

Short term, users can:

Analysis: `Trojan:Win32/Wacatac.B!ml` Detection

Why the detection is almost certainly a false positive

Build process verification

Root cause and fix

Current-state refresher — 2026-10-16

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Component	Status
build-release.sh — cross-compilation script	Clean: standard `go build`, no injected code
Makefile — build flags `-s -w -X main.version=...`	Clean: expected flags only
go.mod — all direct dependencies	Clean: all are well-known, maintained packages
release.md — release pipeline	Clean: `cache: false` explicitly disabled to prevent cache poisoning attacks; SBOM generated post-build; `id-token: write` + `attestations: write` present for supply chain provenance
Go toolchain used	Set via `go-version-file: go.mod` from `actions/setup-go` with pinned action hash
No UPX or external packing tools	Correct: only `wasm-opt` is used, only on `.wasm`, not the PE binary

Code signing for gh-aw binaries #35467

Description

Detection

Affected file

Steps to reproduce

Actual result

Expected result

Environment

Activity

dsyme commented on May 28, 2026

Root cause and fix

Short term, users can:

Analysis: Trojan:Win32/Wacatac.B!ml Detection

Why the detection is almost certainly a false positive

Build process verification

Root cause and fix

arthurfvives commented on May 28, 2026

dsyme commented on May 28, 2026

jeenkhoorn commented on Aug 12, 2026

pelikhan commented on Oct 7, 2026

pelikhan commented on Oct 16, 2026

Current-state refresher — 2026-10-16

pelikhan commented on Oct 22, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Analysis: `Trojan:Win32/Wacatac.B!ml` Detection