Il pattern .php.php nei mu-plugins: cosa abbiamo visto in 12 attacchi recenti

Pattern aggregato anonimizzato · marzo-maggio 2026

Negli ultimi 90 giorni abbiamo osservato 12 attacchi WordPress con la stessa firma tecnica: file PHP con doppia estensione caricati nella directory wp-content/mu-plugins/. Il pattern non è documentato dalla maggior parte degli scanner commerciali. Ecco cosa abbiamo imparato.

Cos'è il pattern

Apache (e quindi cPanel hosting tipici) sono configurati con FcgidWrapper .php o AddHandler application/x-httpd-php .php. La regola di matching usa la regex \.php$ (l'estensione finale).

Questo significa che:

attack.php → eseguito come PHP ✓
attack.php.php → eseguito come PHP ✓ (l'estensione finale è .php)
attack.php.bar.php → eseguito come PHP ✓
attack.php.php.php.php.php → eseguito come PHP ✓

Ma molti scanner di sicurezza WordPress (anche quelli premium) usano filtri come:

glob("*.php") — match solo file con UN .php finale
LIKE '%.php' con escape sbagliato
basename($file, '.php') per derivare il nome — fallisce se ci sono multiple .php

Il risultato: il file viene eseguito da Apache ma è invisibile al security scanner.

Esempi reali (anonimizzati)

Su 12 siti che abbiamo recuperato negli ultimi 90 giorni, abbiamo trovato pattern come:

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

Caratteristiche comuni dei file:

Nomi che imitano plugin WP standard (prefix 01-mu- per garantire load order primo)
Class names CamelCase generati da algoritmo (probabilmente AI)
Funzionalità: backdoor con pattern code-execution + base64 decoder + file upload endpoint
Persistenza: anche se il file viene eliminato, ricrea sé stesso al prossimo trigger via cron WP corrotto

Perché il pattern continua a funzionare

Wordfence Free e MalCare Free non scansionano mu-plugins/ ricorsivamente. Wordfence Premium lo fa ma il loro pattern matcher per .php non gestisce correttamente la doppia estensione (verificato su versione 8.0.5 a maggio 2026).

Sucuri SiteCheck (lato remoto) può rilevare il danno solo se l'attaccante ha già injected redirect visibili pubblicamente. Se la backdoor è "silente" (solo command-and-control), Sucuri vede HTTP 200 e dice "tutto ok".

Patchstack non si occupa di scanning filesystem — fa solo CVE feed.

Cosa puoi fare ora

Se gestisci un sito WordPress:

Esegui questo comando via SSH (se hai accesso):

`` find /home/USER/public_html -name ".php." 2>/dev/null `` Deve ritornare 0 risultati. Se trovi qualcosa, sei già compromesso.

Se non hai SSH, via cPanel File Manager:

- Naviga a wp-content/mu-plugins/ - Conta i file: dovrebbero essere 0-2 (solo plugin che HAI installato come "must-use") - Se vedi file con nomi random tipo 01-mu-XxxYyy.php o doppia estensione, sospetto

Audit del cron WP in wp-admin:

- Plugin "WP Crontrol" (free) → mostra tutti gli hook scheduled - Cerca hook con nomi sospetti: puc_cron_check_updates-, run_weekly_partner_ da theme che non hai installato

Verifica wp_options.cron via phpMyAdmin:

- Cerca hook che riferiscono plugin che non sono in wp-content/plugins/ - Esempi noti compromessi: hook scheduling files in mu-plugins/ via wp_schedule_event

Come WPSonar gestisce questo

Il nostro scanner controlla esplicitamente:

Estensioni multi-dot: pattern .php./.pht/.phps/.php5/7/.phtml/.phar. File con count > 1 di estensione PHP-eseguibile → severity automatica critical.
mu-plugins ricorsivo: scan del contenuto, non solo elenco file. Pattern code-execution + decoder base64 + concatenazione obfuscata in mu-plugin → quarantena immediata.
Cross-check dei cron WP: hook che riferiscono plugin/theme non installati → flag come "orphan da rimuovere".

In 12 incident gestiti negli ultimi 90 giorni, nessun cliente ha dovuto pagare un consulente esterno o ripristinare backup. Il fix è automatico e arriva entro 6 ore dalla detection.

Domande frequenti

Cos'è un attacco mu-plugins in WordPress?

I mu-plugins (must-use plugins) sono file PHP nella cartella wp-content/mu-plugins/ che WordPress carica automaticamente a ogni richiesta, prima dei plugin normali e senza che compaiano nella lista plugin attivi. Un attaccante che riesce a scrivere qui ottiene esecuzione di codice persistente e difficile da notare.

Perché Wordfence non trova i file .php.php?

Molti scanner derivano il nome file con funzioni come basename($file, '.php') o filtrano con glob('*.php'), che gestiscono male la doppia estensione. Apache invece esegue come PHP qualunque file che termini in .php (regex \.php$), quindi attack.php.php viene eseguito ma saltato dallo scanner.

Come controllo se ho file sospetti nei mu-plugins?

Via cPanel File Manager naviga a wp-content/mu-plugins/ e conta i file: dovrebbero essere 0-2, solo quelli che hai installato come must-use. Qualsiasi file con nome random tipo 01-mu-XxxYyy.php o con doppia estensione è sospetto. Se hai accesso SSH: find /home/USER/public_html -name '.php.' deve restituire zero risultati.

I file con doppia estensione sono sempre malware?

Praticamente sì, nel contesto di un sito WordPress in produzione. Nessun plugin o tema legittimo crea file .php.php. La doppia estensione serve esclusivamente a confondere gli scanner che cercano l'estensione .php letterale, mantenendo l'esecuzione lato Apache.

Fonti tecniche

Patchstack database CVE WordPress — vulnerability feed centralizzato
Wordfence threat intelligence — pattern noti di backdoor
Sucuri blog · "What is a Multi-Stage Attack" — tecniche di persistenza
WordPress.org developer docs · mu-plugins — come funzionano i must-use plugin