Why Antivirus Flags FileGriffon, and What Our VirusTotal Report Actually Says

If you have seen a FileGriffon antivirus warning, you may reasonably be asking, “Is FileGriffon safe?” or wondering whether the detection is a genuine threat or a FileGriffon false positive. If you download FileGriffon and scan it, there is a fair chance that at least one antivirus engine will object—particularly because the installer is unsigned and built with Nuitka.

We are not asking you to simply trust that everything is fine. Instead, this post explains why antivirus software may flag FileGriffon, walks through the actual VirusTotal report for our first release, and examines every detection it contains. It also describes the one occasion when a real user’s antivirus quarantined part of the software and what happened after we reported it.

What our first release actually scored

On 21 August 2026, the day v1.0.0 went live, we uploaded the released installer to VirusTotal. We downloaded that copy directly from filegriffon.com in a private browser window and verified its SHA-256 before uploading it. In other words, the file in the report is demonstrably the same one offered on our download page.

Two engines out of 69 flagged it.

• DeepInstinct returned a flat “malicious” verdict with no further detail. DeepInstinct is a deep-learning classifier with a well-earned reputation for flagging essentially any unsigned, packed Python executable.
• ESET-NOD32 returned Python/Packed.Nuitka_AGen.KH Suspicious. Read that string literally, because it says exactly what happened: packed, built with Nuitka, matched by an auto-generated heuristic, considered suspicious. It is not a named malware family.

Microsoft Defender, the antivirus most Windows users actually have, reported no detection. The other engines either found nothing or returned no result because the file type falls outside their analysis.

VirusTotal’s own summary is particularly revealing. The installer’s “Popular threat label” is nuitka/python, while its family labels are nuitka and python. The combined verdict does not identify a threat; it identifies a build toolchain.

Detection scores drift as engines update their models, so the number above is a snapshot of that day rather than a permanent claim. The live report is always more current than this post.

Why software like this gets flagged

Three factors combine here, and none indicates that our code is harmful.

The installer is not code-signed. A code-signing certificate must be issued to a registered business entity rather than an individual, and that entity has not been established yet. Both antivirus scanners and Windows SmartScreen treat an unsigned binary from a publisher without an established history as unknown. Unknown software tends to score poorly by default. This is the largest single factor, and it is administrative rather than technical.

FileGriffon’s activity can statistically resemble ransomware. It reads and writes across entire drives, hashes large directory trees, creates parity data, and can encrypt its own database. These are legitimate product features, but they also resemble the activity ransomware performs before encrypting files. A behavioural engine sees the pattern, not the intent, so a file-integrity utility will naturally attract more scrutiny than something like a calculator.

Nuitka-compiled binaries have a reputation issue of their own. FileGriffon is written in Python and turned into a native executable using Nuitka. Legitimate developers and malware authors both use packed Python executables, which leads some engines to score the packaging separately from the code it contains. The Nuitka project publicly tracks this known issue; it is not unique to FileGriffon. ESET’s detection name effectively says the same thing.

How to read a VirusTotal report without scaring yourself

Several entries in the report can look alarming without being evidence of anything harmful. If you inspect the report yourself, here is the relevant context.

“Memory Pattern Domains” are strings, not connections. The report lists filegriffon.com, jrsoftware.org, innosetup.com, and remobjects.com. Only the first is ours. The other three are Inno Setup’s own embedded credits, because Inno Setup is the installer framework and RemObjects Pascal Script is its scripting engine. These are text found in memory, not evidence that anything was contacted.

Behavioural rules identify mechanisms, not motives. Five Sigma rules matched: four medium and one low. The autorun match is genuine but benign. It comes from FileGriffon’s documented “start with Windows” option, which writes an HKCU Run key and is disabled by default. A background monitoring service needs a way to launch automatically, while a rule can recognize only how that happens, not why. The Python DLL side-loading matches come from Nuitka’s compiled launcher loading python311.dll from its own directory, which is normal for a Nuitka build.

Sandbox behaviour is the part actually worth reading. VirusTotal ran the installer through three sandboxes, and one of them completed a full install and first launch rather than just unpacking it. Every file written was traced to a known cause: our own shipped payload, the runtime files FileGriffon creates on first launch, Windows Explorer’s own icon cache side effects, and Inno Setup’s standard extract-then-clean-up artifacts. The process tree ended where the documentation says it should, at the local dashboard on 127.0.0.1:8080.

All three sandboxes reported empty lists for contacted URLs and domains. For a product built around local operation and not uploading your files, that may be the most useful result in the entire report.

The Defender incident, told straight

There is one incident we do not want to omit.

After release, Windows Defender quarantined FileGriffonWatcher.exe on a real user’s computer following a normal installation. This was not a development machine or a build-time event. The file is a small component that watches the main service and restarts it if it crashes, while leaving a clean shutdown alone. Defender classified it as Win32/Wacatac.C!ml, which, unlike the VirusTotal results discussed above, is a named signature.

We submitted the case to Microsoft as a false positive, providing the file, its clean scan history, and the sandbox trace. After review, Microsoft’s analysts said the submitted files did not meet their criteria for malware or unwanted software and removed the detection.

That carries more weight than our simply insisting the file was safe because the conclusion came from Microsoft, not from us. This type of resolution is hash-specific, however, so a future build may need to go through the same process. FileGriffon also works normally without the watcher if you choose to leave that component quarantined.

What actually fixes this

The real fix is code signing. It is not a workaround: a signed installer from an established publisher avoids the underlying reputation problem. Obtaining that signature requires a registered business entity, which is planned but not yet in place.

Until then, the honest approach is the one taken here: publish the checksum and the report, explain each flag, and give you the information needed to verify the file instead of asking for blind trust.

Verifying it yourself

Every release on the downloads page is published with its exact SHA-256 checksum. After downloading, compare it before you run anything:

Get-FileHash .\FileGriffon-Setup-1.0.0.exe -Algorithm SHA256

Or from Command Prompt:

certutil -hashfile FileGriffon-Setup-1.0.0.exe SHA256

If it matches the published value, you have the file we built. If it does not, do not run it, and please tell us.

More detail on what to expect during install lives in the troubleshooting docs.