The .php.php Pattern in mu-plugins: What We've Learned from 12 Recent Attacks

Aggregated anonymized pattern · March-May 2026

In the last 90 days, we've observed 12 WordPress attacks with the same technical signature: PHP files with double extensions uploaded to the wp-content/mu-plugins/ directory. The pattern is not documented by most commercial scanners. Here's what we've learned.

What is the pattern

Apache (and typical cPanel hosting) are configured with FcgidWrapper .php or AddHandler application/x-httpd-php .php. The matching rule uses the regex \.php$ (the final extension).

This means that:

• attack.php → executed as PHP ✓
• attack.php.php → executed as PHP ✓ (the final extension is .php)
• attack.php.bar.php → executed as PHP ✓
• attack.php.php.php.php.php → executed as PHP ✓

But many WordPress security scanners (even premium ones) use filters like:

• glob("*.php") — match only files with a single .php at the end
• LIKE '%.php' with incorrect escaping
• basename($file, '.php') to derive the name — fails if there are multiple .php

The result: the file is executed by Apache but is invisible to the security scanner.

Real examples (anonymized)

On 12 sites we've recovered in the last 90 days, we've found patterns like:

• 01-mu-AtlasDrift.php.php
• 01-mu-AuroraMesh.php.php
• 01-mu-BoundaryWeave.php.php
• 01-mu-SignalPlane.php.php
• wp-headre.php.php (intentional typo of "header")
• content.php.php
• radio.php.php
• deleteme.7c8f.php.php

Common characteristics of the files:

• Names that mimic standard WP plugins (prefix 01-mu- to ensure load order)
• Class names in CamelCase generated by an algorithm (likely AI)
• Functionality: backdoor with code-execution + base64 decoder + file upload endpoint
• Persistence: even if the file is deleted, it recreates itself at the next cron WP trigger

Why the pattern continues to work

Wordfence Free and MalCare Free do not scan mu-plugins/ recursively. Wordfence Premium does, but their .php pattern matcher does not correctly handle the double extension (verified on version 8.0.5 in May 2026).

Sucuri SiteCheck (remote scanning) can only detect the damage if the attacker has already injected visible redirects. If the backdoor is "silent" (only command-and-control), Sucuri sees HTTP 200 and says "all ok".

Patchstack only does CVE feed, not filesystem scanning.

What you can do now

If you manage a WordPress site:

1. Run this command via SSH (if you have access):

`` find /home/USER/public_html -name ".php." 2>/dev/null `` It should return 0 results. If you find something, you're already compromised.

1. If you don't have SSH, via cPanel File Manager:

- Navigate to wp-content/mu-plugins/ - Count the files: they should be 0-2 (only plugins you've installed as "must-use") - If you see files with random names like 01-mu-XxxYyy.php or double extensions, be suspicious

1. Audit the WP cron in wp-admin:

- Plugin "WP Crontrol" (free) → shows all scheduled hooks - Look for hooks with suspicious names: puc_cron_check_updates-, run_weekly_partner_ from themes you haven't installed

1. Check wp_options.cron via phpMyAdmin:

- Look for hooks that refer to plugins that aren't in wp-content/plugins/ - Known compromised examples: scheduling files in mu-plugins/ via wp_schedule_event

How WPSonar handles this

Our scanner explicitly checks for:

• Multi-dot extensions: patterns .php./.pht/.phps/.php5/7/.phtml/.phar. Files with more than one PHP-executable extension → automatic severity critical.
• Recursive mu-plugins scan: scan the content, not just the file list. Code-execution patterns + base64 decoder + obfuscated concatenation in mu-plugin → immediate quarantine.
• Cross-check of WP cron: hooks that refer to non-installed plugins/themes → flag as "orphan to remove".

In 12 incidents handled in the last 90 days, no client had to pay an external consultant or restore backups. The fix is automatic and arrives within 6 hours of detection.

Frequently asked questions

What is a mu-plugins attack in WordPress?

mu-plugins (must-use plugins) are PHP files in the wp-content/mu-plugins/ folder that WordPress loads automatically on every request, before normal plugins and without appearing in the active plugin list. An attacker who manages to write here gets persistent code execution and is hard to notice.

Why doesn't Wordfence find the .php.php files?

Many scanners derive the file name with functions like basename($file, '.php') or filter with glob('*.php'), which handle the double extension poorly. Apache, however, executes as PHP any file that ends with .php (regex \.php$), so attack.php.php is executed but skipped by the scanner.

How do I check if I have suspicious files in mu-plugins?

Via cPanel File Manager, navigate to wp-content/mu-plugins/ and count the files: they should be 0-2, only those you've installed as must-use. Any file with a random name like 01-mu-XxxYyy.php or double extension is suspicious. If you have SSH access: find /home/USER/public_html -name '.php.' should return zero results.

Are files with double extensions always malware?

Practically yes, in the context of a production WordPress site. No legitimate plugin or theme creates .php.php files. The double extension serves only to confuse scanners looking for the literal .php extension, while maintaining Apache execution.

Sources

• Patchstack database CVE WordPress — centralized vulnerability feed
• Wordfence threat intelligence — known backdoor patterns
• Sucuri blog · "What is a Multi-Stage Attack" — persistence techniques
• WordPress.org developer docs · mu-plugins — how must-use plugins work