Skip to content

Virus detected in ui version #89

Closed

Description

@Maton-Nenoso

When downloading version 0.5.4 of codebase-memory-mcp-ui-windows-amd64.zip, Windows Defender detects a virus.
This doesn't happen with version 0.5.3.

Detected: Trojan:Script/Wacatac.B!ml

Pinned by DeusData

Activity

  1. DeusData commented on Mar 21, 2026

    @DeusData
    Owner

    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.

  2. DeusData commented on Mar 21, 2026

    @DeusData
    Owner

    @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

  3. DeusData commented on Mar 21, 2026

    @DeusData
    Owner

    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/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.

  4. DeusData commented on Mar 21, 2026

    @DeusData
    Owner

    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

  5. DeusData commented on Mar 21, 2026

    @DeusData
    Owner

    Have added now the virus total scan step in the release pipeline. The next build will include for every binary the report

  6. DeusData commented on Mar 21, 2026

    @DeusData
    Owner

    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.

  7. added a commit that references this issue on Mar 21, 2026
    281a760
  8. DeusData commented on Mar 21, 2026

    @DeusData
    Owner

    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
    • 8-layer security audit — static allow-list for dangerous calls, binary string audit, network egress monitoring, install output validation, smoke hardening, UI audit, MCP robustness testing, vendored dependency integrity
    • 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
    • 11 snprintf buffer overflow fixes — offset clamping prevents unsigned underflow on truncation
    • TOCTOU race condition fixes — atomic file permissions, open-then-fstat pattern
    • 31 security defense tests — covering shell injection, SQLite authorizer, SQL injection via Cypher, path containment, and shell-free execution

    Verification

    Users can independently verify any release binary:

    # SLSA provenance
    gh attestation verify <file> --repo DeusData/codebase-memory-mcp
    
    # Sigstore cosign
    cosign verify-blob --bundle <file>.bundle <file>
    
    # SHA-256 checksum
    sha256sum -c checksums.txt

    Thank you @Maton-Nenoso for reporting this — it directly led to building this entire security infrastructure.

  9. added 2 commits that reference this issue on Apr 8, 2026
    2c3736a
    9e7b4ea
  10. added 2 commits that reference this issue on May 20, 2026
    f511c6e
    29542f5
  11. added 2 commits that reference this issue on May 23, 2026
    b6ed50d
    6049acd
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    false positive: windows defenderWindows Defender ML heuristic false positive — investigated and resolved

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions