Nome del plugin	Tema WordPress Miller
Tipo di vulnerabilità	Inclusione di File Locali
Numero CVE	CVE-2026-28053
Urgenza	Alto
Data di pubblicazione CVE	2026-03-01
URL di origine	CVE-2026-28053

Urgente: Inclusione di File Locale (LFI) nel Tema WordPress Miller (≤ 1.3.3) — Cosa devono fare ora i proprietari dei siti

Riepilogo: È stata divulgata una vulnerabilità critica di Inclusione di File Locale (LFI) (CVE-2026-28053) per le versioni del tema WordPress Miller fino e compreso 1.3.3. Il problema consente a attaccanti non autenticati di includere file locali da un sito vulnerabile e visualizzarne i contenuti, il che può portare a esposizione di credenziali, compromissione completa del database o esecuzione di codice remoto a seconda dell'ambiente. Punteggio base CVSS 3.1: 8.1 (Alto). Se utilizzi il tema Miller (o gestisci siti che lo fanno), considera questo come una priorità immediata.

Questo avviso è scritto dalla prospettiva degli specialisti di sicurezza di WordPress di WP-Firewall. Di seguito spiegherò cos'è questa vulnerabilità, perché è pericolosa, come può essere rilevata e mitigata, e i passi pratici che devi intraprendere subito per proteggere i tuoi siti. Questo è scritto in un linguaggio tecnico semplice in modo che tu possa agire rapidamente — niente fronzoli di marketing, solo indicazioni concrete.

---

Sommario

• Cos'è l'Inclusione di File Locali (LFI)?
• Cosa sappiamo su CVE-2026-28053 nel tema Miller
• Perché questa vulnerabilità è importante per i siti WordPress
• Indicatori di compromissione (IoC) da cercare
• Passi di mitigazione immediata (rapidi, sicuri)
• Raccomandazioni per il rafforzamento e modifiche di configurazione
• Rilevamento e risposta a una compromissione
• Esempi di regole WAF / server che puoi implementare (modelli di blocco e suggerimenti)
• Come WP-Firewall può aiutare (piano gratuito e mitigazione rapida)
• Raccomandazioni a lungo termine e checklist post-incidente
• Appendice: Comandi utili, log di esempio e checklist

---

Cos'è l'Inclusione di File Locali (LFI)?

L'Inclusione di File Locale (LFI) è una classe di vulnerabilità in cui un'applicazione web include file dal filesystem locale del server in base a input controllato dall'utente. In uno scenario tipico di LFI, un attaccante manipola un parametro in un URL o in un modulo in modo che l'applicazione legga e restituisca il contenuto di file come:

• wp-config.php (contiene credenziali del database)
• .htaccess
• qualsiasi file PHP (potenzialmente esponendo il codice sorgente)
• file di sistema come /etc/passwd

Sebbene LFI di per sé non consenta necessariamente l'esecuzione di codice remoto (RCE), è spesso un trampolino di lancio. Ad esempio, un attaccante può:

• Leggere wp-config.php => ottenere credenziali DB => passare al takeover del DB o passare ad altre azioni.
• Leggere file di log che contengono codice PHP iniettato o caricare log per ottenere RCE.
• Utilizzare altre configurazioni errate (come directory di upload scrivibili) per posizionare file dannosi e poi includerli.

Le vulnerabilità LFI fanno parte dei rischi di “iniezione” ampi elencati in OWASP e, in WordPress, portano frequentemente a compromissioni complete del sito se non mitigate rapidamente.

---

Cosa sappiamo su CVE-2026-28053 (tema Miller ≤ 1.3.3)

• Tipo di vulnerabilità: Inclusione di File Locali (LFI)
• Versioni interessate: Versioni del tema Miller ≤ 1.3.3
• CVE: CVE-2026-28053
• Autenticazione: Nessuno richiesto (non autenticato)
• Punteggio base CVSS: 8.1 (Alto)
• Classificazione OWASP: Iniezione (A3)
• Segnalato: da un ricercatore di sicurezza (i dettagli della divulgazione pubblica variano)
• Patch ufficiale: Al momento della scrittura, non è disponibile alcuna patch ufficiale del tema dall'autore del tema (confermare con la pagina del fornitore del tema per aggiornamenti). Fino a quando non verrà rilasciata una patch ufficiale, i siti rimangono a rischio e devono fare affidamento sulle mitigazioni.

La vulnerabilità è sfruttabile da remoto fornendo richieste elaborate che manipolano un percorso di inclusione di file utilizzato dal tema. Poiché è non autenticata e influisce sul codice del tema (che viene eseguito nello spazio di richiesta pubblico), la superficie di sfruttamento è ampia. Un attaccante può tentare di includere direttamente file locali sul server web e visualizzarne il contenuto o altrimenti abusare della chiamata di inclusione.

---

Perché questo è pericoloso per i proprietari di siti WordPress

Ci sono tre principali conseguenze di LFI in un tema WordPress:

1. Esposizione delle credenziali — wp-config.php contiene spesso credenziali DB in testo semplice, sali e chiavi segrete. La divulgazione di queste può consentire l'accesso completo al database e il takeover amministrativo.
2. Esecuzione di codice remoto o controllo del sito — combinando LFI con directory scrivibili, o avvelenando i log che vengono poi inclusi, può portare a RCE. RCE consente a un attaccante di installare backdoor, deturpare il sito o ospitare malware.
3. Escalation dei privilegi e pivoting — con credenziali del database o esecuzione di shell, gli attaccanti possono creare utenti admin, esfiltrare dati degli utenti, utilizzare l'hosting del sito per attaccare altre reti o monetizzare l'accesso.

Poiché Miller è un tema che può essere presente e attivo su molti siti, e la vulnerabilità non richiede accesso, è un obiettivo attraente. Scanner automatici e codice di sfruttamento commerciale probabilmente appariranno rapidamente. La risposta raccomandata è una mitigazione immediata.

---

Indicatori di compromissione (cosa cercare in questo momento)

Scansionare i log e i file di sistema per segni che un attaccante ha tentato o ha avuto successo:

• Log di accesso HTTP con richieste contenenti sequenze di traversata delle directory (../ O ..\\) o tentativi di accedere a file del tema con parametri come ?file=, ?template=, ?inc=, ecc.
• Richieste GET sospette che fanno riferimento /wp-content/themes/miller/ o simili con traversamento codificato: %2e%2e%2f O %252e%252e%252f.
• Richieste che contengono stringhe come /etc/passwd, il file wp-config.php, O php://filter/ negli argomenti.
• Creazione o modifica di file imprevista in wp-content/uploads, wp-content/themes, o altre directory scrivibili dal mondo.
• Nuovi utenti amministratori creati in orari insoliti.
• Connessioni in uscita inaspettate dal server o lavori cron che eseguono script PHP sconosciuti.
• Avvisi dal tuo scanner di sicurezza per modifiche ai file, timestamp modificati, o checksum cambiati nei file del tema.

Se vedi registri o artefatti di questo tipo, procedi a una risposta all'incidente (vedi sotto).

---

Passi di mitigazione immediati — cosa fare nei prossimi 60–120 minuti

1. Se il sito utilizza il tema Miller (attivo o presente), disabilitalo immediatamente se possibile
   • Passa temporaneamente a un tema predefinito noto e buono (Twenty Twenty-Three o equivalente).
   • Se non puoi passare in modo sicuro su un sito con traffico pesante in produzione, applica mitigazioni basate su WAF (vedi i prossimi elementi).
2. Blocca i vettori di sfruttamento a livello web
   • Applica regole WAF per bloccare richieste contenenti sequenze di traversamento di file e tentativi di includere file locali.
   • Se hai un firewall per applicazioni web a livello di host o un firewall basato su plugin, aggiungi firme di mitigazione che si correlano ai modelli LFI (vedi regole di esempio in questo articolo).
   • Negare richieste a specifici endpoint di inclusione del tema se non sono richiesti pubblicamente.
3. Limita l'accesso diretto a file sensibili
   • Assicurati che wp-config.php non sia leggibile pubblicamente e che i permessi dei file siano restrittivi (ad es., 400/440 per i file che non necessitano di accesso in scrittura).
   • Aggiungi regole .htaccess/nginx per negare l'accesso diretto a *.php nelle sottocartelle del tema che non dovrebbero essere eseguite pubblicamente.
4. Indurire le impostazioni PHP
   • Assicurati che allow_url_include sia disabilitato (dovrebbe essere disattivato per impostazione predefinita).
   • Implementa restrizioni open_basedir per limitare l'accesso ai file PHP alle directory designate.
   • Disabilita funzioni pericolose (se possibile): exec, shell_exec, system, passthru, proc_open, popen.
5. Ruota le credenziali
   • Se i tuoi log indicano una lettura riuscita di wp-config.php o altri file sensibili, ruota immediatamente le credenziali del database e le chiavi API memorizzate nei file.
   • Reimposta i sali di WordPress e le password degli utenti — forzare un reset della password per tutti gli amministratori.
6. Isola l'host interessato se la compromissione è confermata.
   • Porta temporaneamente il sito offline o limitane l'accesso per IP fino a quando non viene ripristinato uno stato pulito.
7. Distribuisci una patch virtuale temporanea.
   • Se gestisci un WAF o puoi distribuire regole al reverse-proxy/balancer di carico, aggiungi una regola per bloccare le richieste che tentano l'inclusione di file locali (esempi di seguito).
   • La patch virtuale riduce il rischio immediato in attesa di una patch ufficiale del fornitore.

---

Raccomandazioni per il rafforzamento e modifiche di configurazione (a lungo termine).

• Tieni aggiornati temi, plugin e il core di WordPress. Ma ricorda: gli aggiornamenti a volte ritardano e potrebbero non essere sempre immediatamente disponibili; la patch virtuale basata su WAF è una soluzione utile temporanea.
• Rimuovi temi e plugin non utilizzati. Anche il codice di temi inattivi può a volte essere scoperto e abusato.
• Limita i permessi dei file:
  • Directory: 755 (o 750 dove appropriato)
  • File: 644 per la maggior parte dei file; 440 o 400 per wp-config.php se l'utente del server lo consente.
• Usa open_basedir per limitare PHP solo alle directory necessarie.
• Implementa il monitoraggio dell'integrità dei file: monitora i checksum dei file di temi/plugin e invia un avviso su qualsiasi cambiamento.
• Disabilita l'esecuzione di PHP nelle directory di upload:

  # Previeni l'esecuzione di PHP negli upload
  

  location ~* ^/wp-content/uploads/.*\.(php|phtml|php3)$ {
  

• Assicurati che il tuo ambiente di hosting utilizzi il principio del minimo privilegio per l'utente del database — l'account DB dovrebbe avere solo i privilegi necessari (ad esempio, evita i privilegi GRANT).
• Mantieni backup sicuri con versioning, archiviati off-server. In caso di compromissione, devi essere in grado di ripristinare a uno snapshot noto e pulito.

---

Rilevamento di tentativi di sfruttamento — query e controlli pratici

1. Cerca nei log HTTP modelli:

   grep -i -E "(\.\./|\%2e\%2e|\%2e\%2e\%2f|php://filter|wp-config.php|/etc/passwd)" /var/log/apache2/access.log

2. Controlla i log degli errori per errori o avvisi di file inclusi:

   grep -i "impossibile aprire lo stream" /var/log/apache2/error.log

3. Cerca file che sono stati modificati di recente nelle directory di plugin/tema:

   trova /var/www/html/wp-content -type f -mtime -7

4. Cerca la creazione sospetta di utenti admin nel database:

   Interroga la tabella wp_users per account con date di creazione inaspettate.

5. Confronta i checksum attuali dei file del tema con copie conosciute e buone. Se non hai una baseline, scarica una copia fresca del tema e confronta.

Se trovi prove di upload malevoli o backdoor, non limitarti a eliminare i file e assumere che tutto vada bene — esegui una risposta completa all'incidente (vedi sezione successiva).

---

Procedura di risposta all'incidente (se sospetti una compromissione)

1. Contenere
   • Blocca tutti gli attacchi al firewall/WAF.
   • Metti il sito in modalità manutenzione o limita per IP durante l'indagine.
2. Preservare le prove
   • Fai una copia forense dei log e del filesystem prima di apportare modifiche distruttive.
   • Fai uno snapshot del server dove possibile.
3. Sradicare
   • Rimuovere backdoor e file dannosi.
   • Reinstalla il core di WordPress, il tema e i plugin da fonti conosciute e sicure.
   • Sostituisci le credenziali compromesse (DB, WP admin, FTP, SSH).
   • Ruota eventuali chiavi API trovate nei file di configurazione.
4. Ripristinare e convalidare
   • Ripristina da un backup conosciuto e pulito.
   • Valida l'integrità dei file e scansiona alla ricerca di malware.
   • Assicurati che tutte le patch e le misure di indurimento siano applicate.
5. Comunicare
   • Notifica le parti interessate, i clienti o gli utenti come richiesto dalla politica o dalla legge, in particolare se i dati personali potrebbero essere stati esposti.
6. Analisi post-incidente
   • Documenta la causa principale (ad es., sfruttamento di un tema vulnerabile incluso).
   • Rivedi i processi di monitoraggio e patching per prevenire ricorrenze.

Se non ti senti a tuo agio a farlo da solo, ingaggia un professionista della sicurezza esperto nella gestione degli incidenti di WordPress.

---

Esempio di regole WAF / server per bloccare tentativi comuni di LFI

Di seguito sono riportati modelli che puoi utilizzare in un Web Application Firewall (WAF), o come regole server per Apache mod_security o Nginx. Questi non sono esaustivi; adattali al tuo ambiente per evitare falsi positivi. Se gestisci molti percorsi personalizzati, testa prima in modalità non bloccante/logging.

Principio guida importante: non fare affidamento esclusivamente su stringhe di blocco — combina WAF con il principio del minimo privilegio, indurimento della configurazione e monitoraggio.

Modelli generici per rilevare tentativi di traversata e inclusione

• Blocca le richieste contenenti:
  • ../ O ..\\ (non codificato o codificato)
  • %2e%2e%2f O %252e%252e%252f
  • php://filter
  • il file wp-config.php
  • /etc/passwd
  • input: file=, includere=, inc=, modello=, pagina=, path= quando utilizzato nei contesti di inclusione del tema

Esempio di regola mod_security (concettuale):

SecRule REQUEST_URI|ARGS|ARGS_NAMES "@rx (\.\./|\%2e\%2e|\%252e\%252e|php://filter|wp-config\.php|/etc/passwd)" \
 "id:100001,phase:2,deny,status:403,log,msg:'Potential LFI attempt blocked'"

Esempio di frammento di configurazione Nginx:

# block suspicious traversal sequences
if ($request_uri ~* "\.\./|\%2e\%2e|\%252e\%252e") {
    return 403;
}

# block php://filter usages in query string
if ($arg_file ~* "php://filter|wp-config\.php|/etc/passwd") {
    return 403;
}

Regola mirata: blocca l'accesso a specifici file di tema inclusi

Se identifichi un file di tema specifico che espone un parametro include (ad esempio inc.php?file=), limita l'accesso a quel endpoint:

• Negare per impostazione predefinita, consentire per referrer/IP, o bloccare tutto l'accesso esterno se non necessario.

Esempio di .htaccess Apache:

<Files "inc.php">
  Require ip 192.0.2.0/24       # Only allow your IP range or internal systems
  Require all denied
</Files>

Utilizza queste protezioni lato server insieme a un WAF per una copertura migliore.

---

Esempio di modifiche PHP sicure che gli sviluppatori di temi dovrebbero implementare (livello alto)

Se sei uno sviluppatore che mantiene un tema o lo corregge, non utilizzare ingenuamente l'input dell'utente nelle dichiarazioni include. Implementa quanto segue:

• Mantieni un elenco di controllo degli obiettivi di inclusione consentiti (mappa chiavi come intestazione1, piè di pagina2 ai percorsi dei file effettivi).
• Convalida e normalizza i nomi dei file — non accettare mai ../.
• Evita inclusioni dinamiche dall'input dell'utente. Se devi, mappa solo token brevi a percorsi predefiniti.
• Usa funzioni PHP per canonizzare i percorsi (realpath) e verifica che il file risieda nella directory prevista.

Pseudo-codice modello sicuro:

<?php

Non accettare mai un percorso completo del filesystem o consentire sequenze di traversata delle directory.

---

Come dare priorità alla mitigazione in tutta la tua flotta di siti

1. Crea un inventario dei siti e identifica quali utilizzano il tema Miller (attivo o installato).
2. Dai priorità ai siti attivi esposti al pubblico o con alto traffico per un'azione immediata.
3. Applica le regole WAF a livello di rete per bloccare i modelli di exploit noti mentre correggi o rimuovi il tema.
4. Per i siti non critici, considera di rimuovere il tema o disabilitare l'esecuzione di PHP nelle sue directory fino a quando non è stato corretto.
5. Dopo la correzione o la rimozione, continua a monitorare per almeno 30 giorni per catturare attività post-exploit ritardate.

---

Come WP-Firewall ti aiuta in questo momento

WP-Firewall si specializza in patching virtuale rapido e protezione runtime continua per i siti WordPress. Se gestisci una flotta di siti o una singola proprietà importante, WP-Firewall offre:

• Regole WAF gestite che possono essere implementate immediatamente per bloccare i modelli LFI e le firme di exploit noti.
• Scansione malware e monitoraggio dell'integrità dei file per rilevare se un attaccante ha già accesso a file sensibili.
• Mitigazione per i rischi OWASP Top 10 out of the box (inclusi tentativi di iniezione e inclusione di file).
• Un modo semplice per patchare virtualmente temi vulnerabili fino a quando non è disponibile un aggiornamento ufficiale dall'autore del tema.

Proteggi il tuo sito ora — protezione veloce e gratuita disponibile

Raccomandiamo a ogni proprietario di sito WordPress di iscriversi al piano Basic (Gratuito) di WP-Firewall per ottenere rapidamente le protezioni essenziali: firewall gestito, larghezza di banda illimitata, WAF, scansione malware e mitigazione per i rischi OWASP Top 10. Questo livello gratuito ti offre un blocco immediato per modelli comuni di LFI e iniezione in modo da poter ridurre il rischio mentre esegui una completa rimediazione. Iscriviti al piano gratuito qui: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Se preferisci più automazione: i piani Standard e Pro includono rimozione automatica del malware, blacklist/whitelist IP, patching virtuale automatico, report di sicurezza mensili e componenti aggiuntivi di sicurezza dedicati che semplificano notevolmente la rimediazione e la gestione continua.)

---

Miglioramenti della postura di sicurezza a lungo termine

L'LFI in Miller è un promemoria che la sicurezza di WordPress richiede strati:

• Gestione delle patch: mantieni aggiornati core, temi e plugin.
• Shielding dell'applicazione: utilizza un WAF e indurisci PHP.
• Minimo privilegio: limita i permessi del DB e dei file.
• Monitoraggio + registrazione: monitoraggio dell'integrità dei file, conservazione dei log e avvisi.
• Backup + ripristino: backup versionati regolari off-host e ripristino testato.
• Sviluppo sicuro: gli sviluppatori di temi e plugin dovrebbero adottare le migliori pratiche di codifica sicura (liste bianche per gli include, convalida dell'input, codifica dell'output).

Tutti questi strati insieme riducono drasticamente la possibilità di compromissione totale anche quando viene scoperta una vulnerabilità.

---

Lista di controllo pratica — Passo dopo passo per i proprietari di siti (copia questa lista)

1. Identificare se il sito ha installato il tema Miller (attivo o inattivo).
2. Se Miller è attivo:
   • Passa a un tema sicuro se possibile OPPURE
   • Implementa immediatamente le regole WAF per bloccare i modelli LFI se non puoi cambiare.
3. Aggiungi regole del server per bloccare la traversata del percorso e php:// le richieste di stile.
4. Imposta i permessi dei file: wp-config.php 400/440, file 644, directory 755.
5. Disabilita l'esecuzione di PHP negli upload e in altre directory non di codice.
6. Assicurati che allow_url_include = Off; implementa restrizioni open_basedir.
7. Scansiona i file per modifiche ed esegui una scansione approfondita del malware.
8. Controlla i log per tentativi di LFI e attività sospette dell'amministratore.
9. Se si sospetta una compromissione: conserva i log, metti il sito offline, ruota le credenziali, ripristina da un backup pulito e esegui una revisione post-incidente.
10. Iscriviti per WAF gestito/patching virtuale per ridurre il rischio mentre aspetti una patch ufficiale.

---

Appendice: Comandi utili e ricerche di esempio

• Trova file modificati di recente all'interno dei temi:

  trova /var/www/html/wp-content/themes/miller -type f -mtime -7 -ls

• Cerca nei log web sequenze di traversamento:

  grep -iE "(\.\./|\%2e\%2e|php://filter|wp-config\.php|/etc/passwd)" /var/log/nginx/access.log

• Elenca gli utenti di WordPress aggiunti negli ultimi 7 giorni (MySQL):

  SELEZIONA ID, user_login, user_email, user_registered DA wp_users DOVE user_registered >= ORA() - INTERVALLO 7 GIORNI;

• Controlla la configurazione PHP per impostazioni pericolose:

  php -i | grep -E "allow_url_include|open_basedir|disable_functions"

---

Note finali da un esperto di sicurezza WP

Questo LFI nel tema Miller è un esempio reale di come un singolo include vulnerabile o un modello di accesso a file nel codice del tema possa esporre l'intero sito. I punti chiave:

• Tratta qualsiasi vulnerabilità di inclusione di file non autenticata come alta priorità.
• Non fare affidamento solo su “aspetta una patch”. Usa la patch virtuale (WAF) e i controlli del server per ridurre immediatamente la superficie di attacco.
• Ruota le credenziali e svolgi un'indagine accurata se sospetti l'esposizione di wp-config.php o altri segreti.
• Usa difese a strati: WAF, indurimento dell'host, codifica sicura, monitoraggio e backup.

Se gestisci più siti WordPress, una mitigazione urgente e centralizzata (regole WAF su tutta la flotta + un inventario per identificare i siti interessati) è il modo più veloce per ridurre il rischio mentre applichi correzioni mirate.

Rimani calmo, agisci rapidamente e usa la difesa in profondità. Se hai bisogno di aiuto per implementare le regole o per svolgere un'indagine post-compromesso, il nostro team di WP-Firewall può assisterti con una risposta su misura e protezione continua.