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/. La maggior parte degli scanner commerciali non lo riconosce. Sotto trovi come funziona e come difenderti.

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 elimini il file, si ricrea 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 suo matcher per .php non gestisce correttamente la doppia estensione (verificato su versione 8.0.5 a maggio 2026).

Sucuri SiteCheck (lato remoto) rileva 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:

  1. 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.

  1. 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

  1. 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

  1. 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 in automatico 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 solo a confondere gli scanner che cercano l'estensione .php letterale, e intanto tiene viva l'esecuzione lato Apache.

Fonti tecniche