You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for reporting — we've identified the cause.
The Trojan:Script/Wacatac.B!ml detection is a false positive from Windows Defender's machine-learning heuristic (the !ml suffix means it's an ML-based detection, not a signature match against known malware).
The trigger is the DLL resolve tracking feature introduced in commit f92fd66. This feature scans C/C++ source code for GetProcAddress, dlsym, and LoadLibrary patterns to build call graph edges across DLL boundaries. The binary now contains these API names as literal strings (for regex matching and strcmp comparison), which is exactly what Windows Defender's ML model flags as suspicious — because real malware uses these same APIs for d…
Thanks for reporting — we've identified the cause.
The Trojan:Script/Wacatac.B!ml detection is a false positive from Windows Defender's machine-learning heuristic (the !ml suffix means it's an ML-based detection, not a signature match against known malware).
The trigger is the DLL resolve tracking feature introduced in commit f92fd66. This feature scans C/C++ source code for GetProcAddress, dlsym, and LoadLibrary patterns to build call graph edges across DLL boundaries. The binary now contains these API names as literal strings (for regex matching and strcmp comparison), which is exactly what Windows Defender's ML model flags as suspicious — because real malware uses these same APIs for dynamic API resolution to evade static analysis.
Ironically, our code detects these patterns in other codebases for code analysis purposes, but Defender's heuristic can't distinguish that from malware that uses them.
We're working on a fix — will update here shortly.
@Maton-Nenoso generally sorry for this confusion. I test this usually on my macOS and have currently no way to also test it explicitly for evey version on Windows. I am going to remove this feature immediately and will push it for v0.5.5 so that you can use it without this confusion. This was anyway a smaller feature which was giving only value in niche cases. We will have to see how we maybe can implement it differently such that it is not flagging as a virus. Will give you a short heads up once it is delivered in v0.5.5. and then please test it again
The DLL resolve tracking feature has been removed entirely (281a760). The binary will no longer contain GetProcAddress/dlsym/LoadLibrary string literals that triggered the Wacatac.B!ml detection.
Once v0.5.5 is published, you can update with:
codebase-memory-mcp update
Thanks for reporting — this was caught quickly because of your report.
I can understand that this was a scary moment, but I can gurantee to you there was never a bad intent. But I learned my lesson here to also include virus scanner into the builds to you give more confidence with this
It was secure, it just was a false positive. I am still working on hardening the release pipeline with security checks including also a step where windows defender will run against the release binary before it gets released such that this kind of issues will be flagged already before release. We will also add many other steps including virus total scans etc to make this type of things very unlikely to appear again. Security for all users is for me the most important thing and I will give my best that nobody will get problems from this project. I will update once the new release pipeline is in place.
v0.5.5 Security Hardening — Full Mitigation Summary
v0.5.5 has been released with comprehensive mitigations to prevent this class of issue from recurring. Here's everything that was done:
Root cause fix
Removed DLL resolve tracking — the literal strings (GetProcAddress, dlsym, LoadLibrary) that triggered Windows Defender's Wacatac.B!ml ML heuristic have been completely removed from the codebase.
Build-time scanning (every commit)
Native antivirus on all 3 platforms: Windows Defender (with ML heuristics), ClamAV on Linux, ClamAV on macOS — any detection fails the build
CodeQL SAST — static analysis with full build coverage, zero open alerts required
Fuzz testing — random/mutated JSON-RPC + Cypher inputs on every build
Release-time scanning (before publish)
VirusTotal zero-tolerance gate — all release binaries are uploaded to VirusTotal and scanned by 70+ antivirus engines. The release stays as an invisible draft until every engine reports clean. Any single detection blocks publication.
SLSA build provenance — cryptographic proof each binary was built by GitHub Actions from this repo
Sigstore cosign signing — keyless digital signatures verifiable by anyone
SBOM — Software Bill of Materials (SPDX 2.3) listing all vendored dependencies
SHA-256 checksums — published with every release
Code-level security hardening
Shell injection eliminated — replaced system() calls with cbm_exec_no_shell() (fork+execvp), no user input reaches a shell
Activity
DeusData commentedon Mar 21, 2026
Thanks for reporting — we've identified the cause.
The
Trojan:Script/Wacatac.B!mldetection is a false positive from Windows Defender's machine-learning heuristic (the!mlsuffix means it's an ML-based detection, not a signature match against known malware).The trigger is the DLL resolve tracking feature introduced in commit f92fd66. This feature scans C/C++ source code for
GetProcAddress,dlsym, andLoadLibrarypatterns to build call graph edges across DLL boundaries. The binary now contains these API names as literal strings (for regex matching andstrcmpcomparison), which is exactly what Windows Defender's ML model flags as suspicious — because real malware uses these same APIs for dynamic API resolution to evade static analysis.Ironically, our code detects these patterns in other codebases for code analysis purposes, but Defender's heuristic can't distinguish that from malware that uses them.
We're working on a fix — will update here shortly.
DeusData commentedon Mar 21, 2026
@Maton-Nenoso generally sorry for this confusion. I test this usually on my macOS and have currently no way to also test it explicitly for evey version on Windows. I am going to remove this feature immediately and will push it for v0.5.5 so that you can use it without this confusion. This was anyway a smaller feature which was giving only value in niche cases. We will have to see how we maybe can implement it differently such that it is not flagging as a virus. Will give you a short heads up once it is delivered in v0.5.5. and then please test it again
DeusData commentedon Mar 21, 2026
Fixed in v0.5.5 (building now): https://github.com/DeusData/codebase-memory-mcp/actions/runs/23380017784
The DLL resolve tracking feature has been removed entirely (281a760). The binary will no longer contain
GetProcAddress/dlsym/LoadLibrarystring literals that triggered the Wacatac.B!ml detection.Once v0.5.5 is published, you can update with:
Thanks for reporting — this was caught quickly because of your report.
DeusData commentedon Mar 21, 2026
will be removing 0.5.4 now and will add a virus-total scan as last release step to give more confidence. Please also for your to feel secure: Upload the binary in https://www.virustotal.com/ it did not flag anything on my side.
I can understand that this was a scary moment, but I can gurantee to you there was never a bad intent. But I learned my lesson here to also include virus scanner into the builds to you give more confidence with this
DeusData commentedon Mar 21, 2026
Have added now the virus total scan step in the release pipeline. The next build will include for every binary the report
DeusData commentedon Mar 21, 2026
Here btw is the report from the 0.5.4 release that had this issue: https://www.virustotal.com/gui/file/a55f9e87fc524be1934ed44fee5ab2b95bf2fcff32c1c00093fc161b7bec68a8
It was secure, it just was a false positive. I am still working on hardening the release pipeline with security checks including also a step where windows defender will run against the release binary before it gets released such that this kind of issues will be flagged already before release. We will also add many other steps including virus total scans etc to make this type of things very unlikely to appear again. Security for all users is for me the most important thing and I will give my best that nobody will get problems from this project. I will update once the new release pipeline is in place.
Release security hardening: VirusTotal + attestations + cosign + SBOM…
Remove DLL resolve tracking (Windows Defender false positive)
DeusData commentedon Mar 21, 2026
v0.5.5 Security Hardening — Full Mitigation Summary
v0.5.5 has been released with comprehensive mitigations to prevent this class of issue from recurring. Here's everything that was done:
Root cause fix
GetProcAddress,dlsym,LoadLibrary) that triggered Windows Defender'sWacatac.B!mlML heuristic have been completely removed from the codebase.Build-time scanning (every commit)
Release-time scanning (before publish)
Code-level security hardening
system()calls withcbm_exec_no_shell()(fork+execvp), no user input reaches a shellVerification
Users can independently verify any release binary:
Thank you @Maton-Nenoso for reporting this — it directly led to building this entire security infrastructure.
Remove DLL resolve tracking (Windows Defender false positive)
Release security hardening: VirusTotal + attestations + cosign + SBOM…
Remove DLL resolve tracking (Windows Defender false positive)
Release security hardening: VirusTotal + attestations + cosign + SBOM…
Remove DLL resolve tracking (Windows Defender false positive)
Release security hardening: VirusTotal + attestations + cosign + SBOM…
docs(upstream-sync): record 13M-1/13M-2/13N receipts and Jenkins qual…