PyInstaller EXE Flagged as a Virus? Why It Happens and How to Fix It

A PyInstaller one-file .exe isn't just your script. It's a small bootloader plus a compressed archive of everything your program needs — the Python interpreter, the standard library, and your code. When the user runs it, the bootloader extracts that whole archive to a temporary folder (a _MEI###### directory in %TEMP%) and executes from there.

That "unpack myself to a temp folder and run" behavior is exactly what a lot of real malware does, so heuristic and machine-learning scanners treat it as suspicious. On top of that, the PyInstaller bootloader is identical across every app built with it — including any malware someone has ever packaged with PyInstaller — so scanners have learned to distrust that shared signature. Add an unsigned binary that's brand new (no reputation yet) and you get a false positive that has nothing to do with what your code does.

Two different things get lumped together, and they have different fixes:

• "Windows protected your PC" (SmartScreen) is a *reputation* prompt — it appears for any new, unsigned, downloaded .exe until it's been downloaded enough to earn trust. It's not calling your file a virus. You click *More info -> Run anyway*, or remove the internet tag (right-click -> Properties -> Unblock).
• Defender flags / quarantines the file is *malware detection* — a heuristic or ML verdict. This is the "flagged as a virus" case, and it needs the packaging fixes below (or code signing).

Code signing helps *both* — it establishes a real publisher identity — which is why it's the permanent fix. Everything before it just lowers the odds.

The single most effective free fix is to drop --onefile and build --onedir. A one-folder build doesn't self-extract — the launcher .exe just loads the files sitting next to it — so it avoids the exact behavior scanners flag. I built the same app both ways to show the difference.

$ file myapp.exe
myapp.exe: PE32+ executable (console) x86-64, for MS Windows, 6 sections
$ ls -l myapp.exe
-rwxr-xr-x  5997536 myapp.exe          # 5.72 MB, everything bundled inside

myapp/
  myapp.exe              # the launcher — no embedded archive to unpack
  _internal/
    python312.dll        # the interpreter, in the open
    base_library.zip     # the standard library
    VCRUNTIME140.dll
    libcrypto-3.dll
    _hashlib.pyd  _bz2.pyd  _lzma.pyd  _socket.pyd  _decimal.pyd
    select.pyd  unicodedata.pyd

Same program, same size (~5.6 MB), but the one-folder launcher never writes and executes a payload from %TEMP%, so it trips far fewer scanners. The trade-off is you distribute a folder (usually zipped) instead of a single file — fine for an installer or a download, less tidy for "email someone one .exe."

An .exe with no product name, company, or version looks more like throwaway malware than legitimate software, and some heuristics weigh that. PyInstaller can embed a Windows version resource (--version-file) so the file has real Properties -> Details. I built the app with metadata and checked that it actually lands in the binary:

with-metadata build:
   MyApp            embedded=True
   Acme Ltd         embedded=True
   1.0.0            embedded=True
   MyApp CLI tool   embedded=True
plain build (no --version-file):
   MyApp            embedded=False
   Acme Ltd         embedded=False

Now the file shows a product name, company and version in Windows' Properties dialog. This makes it look like real software and can reduce some false positives — but on its own it does not clear SmartScreen or a determined AV verdict. Treat it as a cheap, always-do-it step, not the fix.

Signing your executable with a code-signing certificate attaches a verified publisher identity to it. This is the only thing that reliably clears antivirus false positives and starts building SmartScreen reputation. You get a certificate from a CA (or use Microsoft's Trusted Signing, formerly Azure Code Signing, which is low-cost), then sign with signtool on Windows or osslsigncode on Linux/CI.

signtool sign /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 ^
  /a myapp.exe

Two more steps that matter, especially before you sign:

1. Build in a clean, reproducible environment — GitHub Actions on a fresh Windows runner, not your day-to-day machine. This guarantees no local infection or stray file gets bundled, and gives you a build log you can point to. The command-and-workflow generator on our Python-to-EXE tool produces a ready-to-commit Actions workflow that builds on GitHub's own Windows runner.
2. Submit the false positive to the vendor. If Defender flags a genuinely clean build, report it at Microsoft's submission portal (microsoft.com/wdsi/filesubmission); most other vendors have an equivalent. A confirmed false positive gets the detection removed in a future definition update, which helps every user of your app.

If Defender quarantined an .exe you built yourself and you trust it, you can restore it: open Windows Security -> Virus & threat protection -> Protection history, find the item, and choose Restore. You can also add a folder exclusion for your build output directory while developing. Only do this for your own builds — never restore or exclude a file you didn't create and can't verify.

It's tempting to reach for tricks that make the flag "go away" — packing the exe, stripping the bootloader signature, or obfuscating specifically to dodge detection. Don't. Those techniques are exactly what malware uses to evade scanners, so they tend to *increase* detections, they can get your publisher identity flagged, and they cross the line from "ship legitimate software" to "evade security tools." The durable path is the boring one: one-folder or signed builds, real metadata, reproducible CI, and vendor submission. That's how you make trustworthy software that scanners stop flagging — not how you sneak past them.

You can produce all of the above without a local toolchain. Our free Python-to-EXE builder builds a real PyInstaller .exe in the browser with a one-folder option (the lower-false-positive build), embedded version metadata, and a matching GitHub Actions workflow for reproducible signed releases — the exact fixes from this article, ready to use.