Frequently asked questions

WPSniffer is a free, open-source command-line malware scanner for WordPress and PHP sites. It runs on your own server, checks every file against thousands of community YARA rules from YARA Forge using the YARA-X engine, and writes a report as CSV, TSV, plain text or an email summary.

Yes. WPSniffer is released under the GPLv3 license. There is no paid tier, no license key, no account and no usage limit. The rules it downloads from YARA Forge are also free and published by their authors.

A plugin runs inside WordPress and depends on PHP, the database and the site being healthy. WPSniffer is a standalone tool that scans files on disk from the shell, so it works on a site that is broken, offline or that you have not logged into. It can scan every site on a server in one run, and because it is not a plugin, malware cannot disable it from inside WordPress.

Both are GPLv3 Python command-line scanners for PHP malware with a similar command shape. Wordfence CLI depends on Wordfence's proprietary signature feed and a license key, and Wordfence has stopped issuing new Free and Premium licenses, with the Free version reaching end-of-life on October 14, 2026. WPSniffer uses open YARA rules from YARA Forge and your own rules, needs no key or account, and lets you read every rule it matches on. WPSniffer does not do vulnerability scanning of plugin versions. See the full comparison and migration notes.

No. The only network request it makes is downloading the YARA Forge rule package from GitHub, and you can skip even that with --yara-forge none and local rules. Your files never leave your server and no scan results are sent anywhere.

Python 3.8 or newer, shell access to the server (for example SSH), read access to the files you want to scan, and outbound HTTPS to GitHub for the first rule download. WordPress does not need to be running.

Create a virtualenv with python3 -m venv ~/wpsniffer, then run ~/wpsniffer/bin/pip install git+https://github.com/CommanderWaterford/wpbastion. The install guide walks through it step by step.

If your host gives you SSH access and Python 3.8 or newer, yes. Install into a virtualenv in your home directory; no root access is required. If your host only offers a web control panel without a shell, you cannot run WPSniffer there.

No. WPSniffer scans files on disk and never talks to PHP, the web server or the database. You can scan a backup, a site that is currently down, or a plain PHP application.

Yes. Point malware-scan at the parent directory, for example /var/www, and it walks every site underneath. Use wpsniffer count-sites /var/www to see how many WordPress installations it will cover.

It depends on the number and size of files and on how many worker processes you allow with -j. The scanner is multi-process and caches compiled rules, so the first run is the slowest. Restricting the scan to PHP files, or to recently changed files via find and stdin, makes it much faster on sites with large media libraries.

Yes. A single crontab line is enough; use the full path to the wpsniffer binary inside the virtualenv, and add the email options to get a summary. The docs include an example.

Yes. It needs only Python, prints machine-readable output, and exits cleanly, so a pipeline can install it, scan the checkout or build artifact, and fail the build if the report is non-empty. Pin a YARA Forge release or ship your own rules for reproducible results.

From YARA rules. By default WPSniffer downloads the YARA Forge core package, about 5,000 tested rules from many researchers including PHP webshell rules, and refreshes it daily. You can switch to the larger extended or full packages, or add your own .yar files with --rules.

Whatever the rules describe: PHP webshells and backdoors, obfuscated loaders such as eval(base64_decode(...)), SEO spam and redirect injectors, credential stealers and card skimmers, and known malware families documented by the rule authors. Detection is only as good as the rules, which is why you can add your own.

Some. Broad rules can fire on minified or obfuscated code in legitimate plugins. Start with the core package, exclude noisy rules with -e, and always read the matched_text and rule_reference columns before deleting anything.

Yes. Pass a .yar or .yara file or a directory with --rules. Each file gets its own namespace so names never collide, and you can combine your rules with a YARA Forge package or use --yara-forge none to run only yours. The rules page includes a worked example.

Because YARA rules often use filesize conditions and offsets, and a match that spans a chunk boundary would be missed. WPSniffer reads each file whole, up to 50 MiB by default, so rules behave exactly as their authors intended.

No. It finds suspicious files and reports them. Cleanup is up to you: confirm each match, restore or remove the files, update WordPress and its plugins, rotate credentials, and re-scan. The docs have a checklist for what to do after a scan finds matches.

One row per match, with the columns you choose: filename, signature_id, signature_description, rule_score, rule_author, rule_reference and matched_text. Output can be CSV, TSV, line- or null-delimited text, a human-readable listing, or an email summary with counts of suspicious files, scanned files, bytes processed and elapsed time.

A clean scan means none of the rules you used matched. It does not prove the absence of malware, especially for brand-new or custom-written backdoors. For a thorough check, re-scan with --yara-forge extended, review recently changed files, compare WordPress core files against the official release, and check for unknown admin users.

Open an issue on the GitHub repository. Include the command you ran, the WPSniffer and Python versions, and, for a suspected false positive, the rule name from signature_id.