When I bundle my apps with PyInstaller, and in some cases Py2exe, antivirus software doesn't allow me to run the .exe files. CrowdStrike prevents it from being opened, and Windows Defender flags it as malicious unless I specifically allow it. This appears to be due to bad actors using PyInstaller to bundle malicious code. Is there any way to get around this, or another way to turn a Python program into an .exe that won't be flagged?
This is one of the most frustrating problems you'll encounter when packaging Python applications for distribution. You've spent time building your app, you bundle it into an executable, and then antivirus software tells your users—or even you—that it's malware. The good news is that this is a well-known issue, and while there's no single magic fix, there are several practical steps you can take to reduce or eliminate these false positives.
Why does this happen?
PyInstaller works by bundling your Python code together with the Python interpreter and all required libraries into a single executable (or a folder of files). When that executable runs, it extracts these components to a temporary directory and then executes your code from there.
This extraction-and-execution pattern is exactly what a lot of actual malware does. Malicious software often uses "packers" to compress and hide their payloads, extracting them at runtime to avoid detection. Because PyInstaller's behavior looks similar from the outside, antivirus heuristics — the pattern-matching rules that AV software uses to identify threats — can flag PyInstaller-built executables as suspicious.
To make matters worse, PyInstaller is genuinely used by some malware authors precisely because it's a convenient way to package Python scripts into executables. This means the PyInstaller bootloader (the small stub program that handles extraction and startup) has ended up on some AV threat lists. Your perfectly safe application inherits that guilt by association.
What you can do about it
There's no guaranteed way to make every antivirus product on the market happy with your executable. But the following approaches, used together, can significantly improve the situation.
Use the latest version of PyInstaller
The PyInstaller team is aware of this problem and periodically updates the bootloader to reduce false positives. Each new release may include a freshly compiled bootloader that hasn't yet been flagged by AV vendors. Always make sure you're using the latest stable release:
pip install --upgrade pyinstaller
Sometimes using the development version from GitHub can also help, since the bootloader may have been updated more recently than the last stable release:
pip install https://github.com/pyinstaller/pyinstaller/archive/develop.zip
Compile the bootloader yourself
When you install PyInstaller from PyPI, the bootloader binary is pre-compiled. Since this same binary is shared across every PyInstaller user worldwide, it's the exact binary that AV vendors have seen before and may have flagged.
If you compile the bootloader yourself on your own machine, the resulting binary will have a different hash. This alone can make a difference with some AV products. To do this:
-
Clone the PyInstaller repository:
sh git clone https://github.com/pyinstaller/pyinstaller.git cd pyinstaller -
Build the bootloader (you'll need a C compiler installed, such as Visual Studio Build Tools on Windows):
sh cd bootloader python ./waf all cd .. -
Install PyInstaller from your local copy:
sh pip install .
Your locally compiled bootloader will produce executables with different binary signatures, which can help avoid heuristic matches.
Code-sign your executable
Code signing is one of the most effective ways to reduce false positives. When you sign your executable with a valid code-signing certificate, you're attaching a verified identity to the file. Antivirus software and Windows SmartScreen both treat signed executables with much more trust than unsigned ones.
You can obtain a code-signing certificate from certificate authorities like:
- SignPath (offers free certificates for open-source projects)
- Sectigo (formerly Comodo)
- DigiCert
Standard code-signing certificates (OV, or Organization Validation) are typically sufficient, though Extended Validation (EV) certificates provide the highest level of trust with SmartScreen. EV certificates are more expensive and usually require a hardware token.
Once you have a certificate, you can sign your executable using Microsoft's signtool:
signtool sign /f your_certificate.pfx /p your_password /tr http://timestamp.sectigo.com /td sha256 /fd sha256 dist\your_app.exe
Code signing doesn't make false positives impossible, but it dramatically reduces them, especially with Windows Defender and SmartScreen.
Use one-folder mode instead of one-file mode
PyInstaller's --onefile mode creates a single executable that extracts everything to a temporary folder at runtime. This extraction behavior is one of the things that triggers AV heuristics.
Using --onedir mode (which is actually the default) produces a folder containing your executable alongside all its dependencies. Since nothing needs to be extracted at runtime, the behavior looks less suspicious to AV software:
pyinstaller --onedir your_app.py
The trade-off is that you'll need to distribute a folder instead of a single file. You can wrap the folder in an installer (using tools like Inno Setup or NSIS) to give your users a clean installation experience.
Submit false positive reports to AV vendors
This is tedious but effective. Most antivirus vendors have a process for reporting false positives. If your application is being flagged, you can submit the executable for review, and the vendor will typically whitelist it within a few days.
Here are submission links for some common AV products:
- Windows Defender / Microsoft: Microsoft Security Intelligence submission page
- CrowdStrike: Contact your CrowdStrike administrator or support representative
- Avast / AVG: Avast false positive form
- Kaspersky: Kaspersky false positive reporting
- ESET: ESET sample submission
Keep in mind that each time you rebuild your application, the hash changes, and you may need to re-submit. Code signing helps here because AV vendors can whitelist your certificate rather than individual file hashes.
Consider alternative packaging tools
While PyInstaller is the most popular packaging tool for Python, it's not the only option. Other tools use different approaches that may produce executables less likely to trigger AV software:
-
Nuitka compiles your Python code into C and then into a native executable. Because the result is a genuinely compiled binary rather than a bundled interpreter + script, it tends to trigger fewer AV false positives. Nuitka also offers commercial-grade features like code obfuscation and optimized compilation.
-
cx_Freeze is another packaging tool that works similarly to PyInstaller's one-folder mode. It doesn't have a one-file mode, so it avoids the extraction behavior that triggers heuristics.
-
Briefcase (part of the BeeWare project) creates platform-native application packages, including proper MSI installers on Windows. Native installer packages are generally treated with more trust by AV software.
Of these, Nuitka is probably the most promising alternative if AV false positives are a persistent problem for you. Because it produces actual compiled code, the resulting executable looks much more like a "normal" application to AV heuristics.
A practical strategy
For the best results, combine several of these approaches:
- Update PyInstaller to the latest version (or compile the bootloader yourself).
- Use one-folder mode and distribute with a proper installer.
- Code-sign your executable with a valid certificate.
- Submit false positive reports to the AV vendors your users are most likely to encounter.
- If problems persist, try Nuitka as an alternative packaging tool.
No single step will solve the problem for every AV product, but layering these approaches together will get you much closer to a smooth experience for your users.
A note for your users
If you're distributing applications to other people, it helps to set expectations. Include a note in your documentation or README explaining that some antivirus products may initially flag the application, and provide instructions for how to allow it. This is especially important for internal tools distributed within organizations where CrowdStrike or similar enterprise AV products are in use—in those cases, having your IT department whitelist the application (or your code-signing certificate) is usually the most reliable path forward.
PyQt6 Crash Course by Martin Fitzpatrick — The important parts of PyQt6 in bite-size chunks