# guide

Premium WordPress themes: choose carefully, scan before you activate

Updated October 2026

Premium themes are worth paying for, and worth checking. The same scanner that finds webshells on hacked sites will tell you in seconds whether a theme package contains a backdoor, before it ever runs on your site.

Why a theme deserves a malware scan

A theme is not a skin. It is PHP that runs on every page load with the same permissions as WordPress itself, so a theme that ships with a backdoor hands an attacker your whole site the moment you activate it. In cleanup work the theme is one of the most common places a persistent backdoor is found, usually in a file that looks like it belongs there: functions.php, a bundled plugin in inc/, or a stray class-wp-*.php that core never shipped.

Two situations account for most infected themes:

  • Nulled copies. "Free" downloads of paid themes from warez and "GPL club" sites. The license may technically allow redistribution, but the person redistributing it has every incentive to add a backdoor, an SEO spam injector or a crypto miner, and no incentive to tell you.
  • Abandoned themes. A legitimately bought theme whose developer stopped updating it. Bundled page builders, sliders and demo importers in old themes are a long-running source of exploited vulnerabilities, and once exploited the theme directory is where the attacker writes files.

Where to buy, and what to check first

  • Buy from the developer or a marketplace that pays them. The official theme shop, ThemeForest, or the vendor's own site. You get updates, support and a clean copy.
  • Check the update history. A premium theme that has not had a release in a year is a liability no matter how it looks. Look for a changelog with dates.
  • Prefer themes that keep features in plugins. A theme that bundles its own slider, form builder and page builder has three more attack surfaces that only the theme author can patch.
  • Check the child-theme story. If the vendor expects you to edit theme files directly, your customisations are lost on every update, which is how sites end up running a three-year-old version.
  • Never install a nulled copy "just to try it". Use the vendor's demo. If you need a free option, the WordPress.org directory reviews every theme it lists.

Scan the theme before you activate it

Upload the theme, but do not activate it yet. Then scan its directory with WPSniffer. The first run downloads the YARA Forge rule package and caches it; the scan itself takes seconds for a single theme. Install instructions are in the docs.

$ wpsniffer malware-scan -a --match-all --yara-forge extended /var/www/html/wp-content/themes/NEW-THEME

-a scans every file, not only the code-like extensions, so a PHP backdoor hiding behind a .jpg or .txt name is checked too. --yara-forge extended uses the wider rule package, which is the right choice for a one-off audit of a small directory. For a readable report with the matched bytes:

$ wpsniffer malware-scan -a --match-all --yara-forge extended \
    --output-columns filename,signature_id,signature_description,rule_reference,matched_text \
    /var/www/html/wp-content/themes/NEW-THEME

You can scan the zip's contents before uploading, too. Unpack it anywhere on a machine with WPSniffer installed and point the scanner at the folder:

$ unzip -q premium-theme.zip -d /tmp/theme-check
$ wpsniffer malware-scan -a --match-all /tmp/theme-check

How to read the result

A clean scan means no rule fired. That is good evidence but not proof, so pair it with a quick manual look:

  • Any PHP file outside the theme's documented structure. Themes do not need wp-login.php, xmlrpc.php, adminer.php or a file named like a core class.
  • base64_decode, eval, gzinflate or str_rot13 in functions.php. Legitimate themes almost never need them. Obfuscated "license check" code is the classic nulled-theme payload.
  • Calls to outside domains. grep -rn "http" --include='*.php' and look for anything that is not the vendor, WordPress.org or a known CDN.
  • Files with executable bits or recent change times that do not match the rest of the package.

If the scan does match, read the rule name and matched_text. A broad rule can fire on a minified JavaScript library, which is a false positive you can confirm by checking the rule_reference link. A hit on a PHP file with a webshell or backdoor rule name is not a false positive: delete the whole package and get a clean copy from the vendor.

Already running a theme you are not sure about?

Scan the live theme directory the same way, then compare it with a fresh copy from the vendor. Anything in your copy that is not in theirs is suspect. If the theme came from a nulled source, replace it with a licensed copy rather than trying to clean it: you cannot know what else was changed.

If the scan finds matches on a live site, follow the cleanup checklist. For a whole server, scan every site at once and put a nightly scan in place so a theme that goes bad later is caught within a day.

Install WPSniffer → All guides