Windows Defender detects CodexBar 0.47.0 installer as Trojan:Win32/Wacatac.B!ml

[sandaun]

Hi,

Windows Defender is detecting the official CodexBar 0.47.0 installer as:

Trojan:Win32/Wacatac.B!ml

I installed it using Winget:

winget install Finesssee.Win-CodexBar

Winget successfully downloaded the installer and verified its hash, but Defender removed the file when the installation started.

Winget output:

Found Win-CodexBar [Finesssee.Win-CodexBar] Version 0.47.0
Downloading:
https://github.com/nesszer/Win-CodexBar/releases/download/v0.47.0/CodexBar-0.47.0-Setup.exe

Installer hash successfully verified.
Starting package install...

0x800704c7: The operation was canceled by the user.

Windows Security details:

Detected: Trojan:Win32/Wacatac.B!ml
Status: Removed
Affected file:
C:\Users\<username>\Downloads\CodexBar-0.47.0-Setup.exe

Environment:

Windows 11
Win-CodexBar version: 0.47.0
Installation method: Winget
Microsoft Defender enabled
Date detected: 2026-08-05

Could you please confirm whether this is a known false positive?

I have not allowed or executed the blocked file.

Thanks.

[Finesssee]

Thanks for raising issue, This issue occur because my app is not signed but I will try to fix this if possible.

[heitoormartins]

same here, the version before was functional

[Finesssee]

Thanks for the detailed report, @sandaun — this is a false positive, and you did exactly the right thing by not allowing the blocked file.

The file is genuine. The installer Defender removed is byte-identical to what our CI built and published:

SHA-256: a86564acf8ca95bcd8635893003136007863659a6f64617672d3e423857d2c76

This matches both the CodexBar-0.47.0-Setup.exe.sha256 checksum published in the v0.47.0 release and the InstallerSha256 pinned in the winget manifest. That's why winget printed Installer hash successfully verified before Defender stepped in: the file you downloaded is exactly what we released. The 0x800704c7 winget error is just the setup being cancelled after Defender quarantined the file mid-install — so this is purely Defender's heuristic on an unsigned binary, not a corrupted or tampered download.

Why Defender flags it: the installer is a standard Inno Setup build and is not code-signed. Trojan:Win32/Wacatac.B!ml is a machine-learning classification (the !ml suffix) that frequently fires on brand-new, unsigned installer files with no reputation history. Nothing about the app or its packaging changed in 0.47.0.

Workarounds right now:

1. Use the portable build instead — CodexBar-0.47.0-portable.exe from the same release (SHA-256 4d084c91ef8db687ceca4e269b7b15b5796b21f262df97ff12319620307cb6f6; the .sha256 file is published alongside it). No installer needed. If Defender also distrusts it on your machine, the same verify-and-restore steps below apply.
2. Or re-verify the hash yourself, then restore and exclude:

   Get-FileHash "$env:USERPROFILE\Downloads\CodexBar-0.47.0-Setup.exe" -Algorithm SHA256
   # Output (case-insensitive) must equal:
   # a86564acf8ca95bcd8635893003136007863659a6f64617672d3e423857d2c76

   Only if the hash matches: Windows Security → Virus & threat protection → Protection history → find the Wacatac.B!ml entry → Actions → Restore, then Windows Security → Virus & threat protection settings → Manage settings → Exclusions → add the file. Re-run winget install Finesssee.Win-CodexBar afterwards.

What we're doing about it:

• I'll submit the installer to Microsoft's Security Intelligence submission portal via the Software developer path as "incorrectly detected as malware" (referencing detection Trojan:Win32/Wacatac.B!ml) so it gets whitelisted. These ML detections are typically cleared in updated definitions within days once the file is processed. For other small maintainers hitting this: a free personal Microsoft account is sufficient for the developer path — no enterprise tenant or Software Assurance ID is required — though sign-in plus CAPTCHA are mandatory, and "Company Name" is just a free-text field (a project or publisher name is fine).
• Medium term, we're evaluating inexpensive OSS-compatible code signing (e.g. Azure Trusted Signing) so future releases stop starting life as "unknown unsigned publisher" binaries that trip Wacatac-class heuristics.

@heitoormartins — on "the version before was functional": that's expected, and it's reputation, not a code change. We've shipped the same unsigned Inno packaging since the 0.23.x releases. The 0.46.0 installer was an already-known file that had accumulated reputation (and wasn't drawn as a heuristic victim); 0.47.0 is a brand-new installer with a brand-new hash — i.e. an "unknown file" again — so the ML classifier fires on it until definitions/reputation catch up. Every release or definition update can roll these dice again until we get the binaries signed, which is what the signing work above is meant to fix. If you still have 0.46.0 installed and working, it's safe to stay on it until the 0.47.0 detection clears.

[Finesssee]

My suggestion is that u guys should wait for the next release.

[Finesssee]

Status update — re-verification of the exact v0.47.0 artifacts with current Defender definitions

I re-verified the v0.47.0 release assets today using read-only checks only. Nothing was executed, no exclusions were added, and no protection settings were changed.

Environment & scan timestamp (UTC)

• Platform: Microsoft Windows 10 Pro (build 19045), x64
• Defender engine: 1.1.26070.7 · antimalware product: 4.18.26070.9
• AV signature version: 1.457.58.0 (updated 2026-08-07T22:03:23Z)
• Real-time protection: on
• Scan run: 2026-08-08T06:30:05Z → 2026-08-08T06:30:13Z (UTC)

Files verified (downloaded from the v0.47.0 release page)

• CodexBar-0.47.0-Setup.exe — SHA-256 a86564acf8ca95bcd8635893003136007863659a6f64617672d3e423857d2c76 (matches the published .sha256 sidecar and the winget InstallerSha256)
• CodexBar-0.47.0-portable.exe — SHA-256 4d084c91ef8db687ceca4e269b7b15b5796b21f262df97ff12319620307cb6f6 (matches the published sidecar)

Method (read-only only)

1. gh release download v0.47.0 --repo nesszer/Win-CodexBar — assets written to disk with real-time protection enabled; no detection fired on write (a live Wacatac verdict would have quarantined them at this point).
2. Get-FileHash <file> -Algorithm SHA256 — both hashes match the published sidecars exactly, so these bytes are byte-identical to the file Defender flagged on 2026-08-05.
3. (Get-AuthenticodeSignature <file>).Status → NotSigned for both files.
4. & "C:\Program Files\Windows Defender\MpCmdRun.exe" -Scan -ScanType 3 -File <file> (custom scan) → "found no threats", exit code 0 for both files.

Result
With definitions 1.457.58.0, the byte-identical installer that triggered Trojan:Win32/Wacatac.B!ml on 2026-08-05 no longer reproduces the detection on this machine: it persists on disk under active real-time protection and the on-demand custom scans of both artifacts are clean.

Caveats

• Wacatac.B!ml is a machine-learning/cloud-assisted verdict; results can vary per machine, definition version, and cloud state. One clean machine is strong evidence the definitions moved on — not a universal guarantee.
• The artifacts remain unsigned (NotSigned), and no code-signing workflow is implemented yet: docs/CODE_SIGNING.md currently describes the intended SignPath process ahead of reality (the release pipeline signs nothing today, and the README overstates this — a docs correction is pending). The only thing that has changed since the report is Defender's definitions.

Request to @sandaun and @heitoormartins
Please retest the same v0.47.0 installer hash (a86564ac…2c76) with current definitions and report back:

1. Update signatures first (Update-MpSignature in PowerShell, or Windows Security → Virus & threat protection → Check for updates).
2. Re-download from the release page (or retry winget install Finesssee.Win-CodexBar).
3. Report your Defender engine version, signature version, OS build, and whether the download/install still triggers a Wacatac detection.

Please do not add exclusions or disable protection for this — if it still trips, leave the file quarantined and just post the versions.

Closure criteria for this issue (keeping it open for now)

1. Microsoft confirms a false-positive determination via the WDSI submission and current definitions no longer detect the file for the original reporters, or
2. A newly signed/rebuilt installer ships and scans clean.

Two or more independent clean scans (mine + at least one reporter's) against the same hash on current definitions would support concluding the original detection was remediated definition-side — but that does not fix the underlying "unsigned publisher attracts ML heuristics" problem, which only real code signing solves.

Portal status (action item for maintainer)
There is no public status page for either portal; if/when available, please post here: (a) the WDSI submission outcome for this installer hash, and (b) the SignPath.io OSS application status, so this thread reflects the authoritative state.

[sandaun]

Worked like a charm! Fixed from my side.
Thanks a lot!

[Finesssee]

Closing this as remediated definition-side.

Current Microsoft Defender definitions no longer flag the byte-identical v0.47.0 installer: the maintainer re-verified the exact release hashes (CodexBar-0.47.0-Setup.exe SHA-256 a86564acf8ca95bcd8635893003136007863659a6f64617672d3e423857d2c76, plus the portable build) under signature 1.457.58.0 (engine 1.1.26070.7 / product 4.18.26070.9) with real-time protection on, and both on-demand scans came back clean. The original reporter @sandaun has also confirmed a successful install ("Worked like a charm! Fixed from my side.").

Note: the v0.47.0 binaries remain unsigned, and the underlying "unsigned publisher attracts ML heuristics" risk is unchanged — code-signing is separate follow-up work and is not resolved here. If you see a recurrence of this detection, please open a new issue and include: the artifact hash (e.g. Get-FileHash -Algorithm SHA256 output), your Defender engine and signature versions, and your OS build, so it can be re-submitted to Microsoft as a fresh false positive.

Thanks @sandaun for the report and retest, and @heitoormartins for confirming.