Nome del plugin	Ben fatto
Tipo di vulnerabilità	Inclusione di File Locali
Numero CVE	CVE-2026-28118
Urgenza	Alto
Data di pubblicazione CVE	2026-02-28
URL di origine	CVE-2026-28118

Urgente: Inclusione di File Locali nel Tema Welldone (<= 2.4) — Cosa Devono Fare Subito i Proprietari di Siti WordPress

È stata divulgata una vulnerabilità di inclusione di file locali (LFI) ad alta gravità che colpisce il tema WordPress Welldone (versioni <= 2.4). Tracciata come CVE-2026-28118 e assegnata un punteggio base CVSS di 8.1, questa debolezza consente a attaccanti non autenticati di includere file locali su un sito vulnerabile ed esporre i loro contenuti all'attaccante. Poiché le informazioni memorizzate in file locali (credenziali del database, chiavi API, dettagli di configurazione) possono portare a un compromesso totale, è necessaria una mitigazione immediata per qualsiasi sito che utilizzi il tema interessato.

Scrivo come parte del team di sicurezza WP‑Firewall con indicazioni pratiche e concrete: perché questo è pericoloso, come funziona a livello tecnico, come rilevare tentativi di sfruttamento e un elenco di controllo prioritario di azioni immediate e a medio termine che puoi intraprendere per proteggere il tuo sito WordPress. Se gestisci più siti o clienti di hosting gestito, condividi questo post con i tuoi team — i passaggi di seguito sono classificati per urgenza e facilità di implementazione.

Riepilogo della divulgazione

• Software interessato: tema WordPress Welldone
• Versioni vulnerabili: <= 2.4
• Tipo di vulnerabilità: Inclusione di File Locali (LFI)
• CVE: CVE-2026-28118
• CVSS: 8.1 (Alto)
• Privilegi richiesti: Nessuno (non autenticato)
• Impatto: Lettura arbitraria di file locali; possibile divulgazione di credenziali e file sensibili; può portare a un takeover completo a seconda della configurazione del server
• Segnalato da: Tran Nguyen Bao Khanh (segnalato il 19 agosto 2025; divulgazione pubblica il 26 febbraio 2026)

Perché LFI è così pericoloso per i siti WordPress

L'inclusione di file locali si verifica quando un'applicazione costruisce un percorso a un file locale utilizzando input fornito dall'utente, senza una corretta validazione o sanificazione, e poi include o legge quel percorso. In PHP, funzioni come include(), richiedere(), include_once(), E require_once() sono luoghi comuni in cui tali bug appaiono — particolarmente in temi e plugin che caricano parti di template o file esterni basati su parametri URL.

Per i siti WordPress, le conseguenze sono particolarmente gravi:

• il file wp-config.php spesso include credenziali del database e sali; leggerlo può dare a un attaccante accesso completo al database.
• Altri file possono contenere chiavi API, credenziali SMTP o dati proprietari.
• Se i wrapper PHP (ad es., php://filter) o le posizioni di upload sono accessibili, un attaccante può passare dalla lettura di file all'esecuzione di codice (ad es., localizzando e prelevando un upload scrivibile che sarà successivamente utilizzato per memorizzare una backdoor).
• Poiché la vulnerabilità è accessibile senza autenticazione, è probabile che si verifichino tentativi di scansione automatizzati e sfruttamento di massa — e ci aspettiamo che attaccanti opportunistici prendano di mira rapidamente le installazioni esposte.

Come gli attaccanti sfruttano tipicamente LFI (livello alto)

Un attaccante scopre un parametro che viene utilizzato in una chiamata di inclusione di file (ad esempio, qualcosa come include( $template_path . $_GET['page'] . '.php' ); ). Se quel parametro non è convalidato, l'attaccante può inviare richieste che fanno riferimento ad altri file locali tramite traversata delle directory (../../../../wp-config.php) o tramite wrapper di stream PHP (php://filter, data://). Anche quando l'inclusione diretta è bloccata, molte catene LFI possono essere trasformate in esecuzione di codice remoto (RCE) esponendo prima file, log o includendo altre risorse accessibili.

Non condivideremo qui payload di exploit funzionanti, ma è importante che i difensori riconoscano i modelli e gli indicatori descritti nella sezione di rilevamento qui sotto.

Indicatori di attacco e compromissione — cosa cercare

Monitora i tuoi log (log di accesso del server web, log di errore PHP, log di WordPress) per questi segnali:

1. Richieste contenenti modelli di traversata delle directory nelle stringhe di query:
   • Non codificati o codificati "../" sequenze (ad es., ..%2F, %2e%2e%2f)
   • Tentativi di traversata ripetuti come ../../../../
2. Richieste che fanno riferimento a nomi di file sensibili:
   • il file wp-config.php, wp-config.php.bak, .ambiente, /etc/passwd, .htpasswd, ecc.
3. Richieste che utilizzano nomi di parametri LFI comuni:
   • Parametri di query denominati file, pagina, modello, inc, sentiero, modulo, o altri
   • Impennate improvvise di richieste agli endpoint del tema con payload di traversata variati
4. Utilizzo di modelli di wrapper di stream PHP:
   • php://filter, expect://, data:// che appaiono nei parametri di query
5. Voci di log anomale o nuovi file PHP/JS sotto wp-content/caricamenti, wp-content/themes//, o altre directory scrivibili:
   • File con nomi sospetti
   • Template o file di plugin recentemente modificati che non hai cambiato
6. Query di database improvvise e insolite, creazione inaspettata di utenti admin o modifiche ai file core di tema/plugin.

Se trovi uno dei punti sopra, trattali come alta priorità e segui i passaggi per l'incidente qui sotto.

Mitigazione immediata (ore) — azioni triagiate e pratiche

Se hai una delle versioni interessate o non sei sicuro, applica una o più di queste mitigazioni immediate. Sono ordinate per velocità e impatto:

1. Disabilita temporaneamente il tema vulnerabile:
   • Passa a un tema predefinito (ad es., un tema standard pulito e mantenuto). Questo è il modo più veloce per rimuovere la superficie di attacco se puoi permetterti un breve cambiamento visivo.
   • Se ciò non è possibile, metti il sito in modalità manutenzione mentre applichi altre mitigazioni.
2. Rimuovi o metti in quarantena il tema vulnerabile dal filesystem:
   • Se hai accesso al server (SFTP/SSH), rinomina o rimuovi la directory del tema vulnerabile da wp-content/themes/. Questo impedisce l'esecuzione del codice del tema.
   • Importante: Tieni una copia (fuori dal server) per analisi se stai indagando.
3. Blocca richieste sospette al server web o al firewall dell'applicazione web:
   • Blocca richieste con sequenze di traversamento delle directory e tentativi di accesso ai file core:
   • Esempio (nginx, semplificato): nega richieste con codificato .. sequenze o php://:

   if ($request_uri ~* "(%2e|%2f|\.\./|\.\.\\)") {
       return 403;
   }
   if ($request_uri ~* "php://|data://|expect://|file://") {
       return 403;
   }
   

   • Nota: Utilizzare test cauti prima di applicare regole a livello di server per evitare di interrompere URL legittimi; testare su un sito di staging quando possibile.
   • Esempio (Apache .htaccess) — negare l'accesso diretto a wp-config e bloccare le stringhe di query con modelli sospetti:

   <Files "wp-config.php">
     Order allow,deny
     Deny from all
   </Files>
   
   # Block attempts to access common sensitive files
   <IfModule mod_rewrite.c>
     RewriteEngine On
     # Block requests containing ../ or php:// or data:// (basic)
     RewriteCond %{QUERY_STRING} (\.\.|php://|data://) [NC,OR]
     RewriteCond %{REQUEST_URI} (\.\.|php://|data://) [NC]
     RewriteRule ^.* - [F,L]
   </IfModule>
   

4. Indurire le autorizzazioni e la proprietà dei file (controlli rapidi):
   • Assicurati il file wp-config.php non è leggibile dal mondo. Autorizzazioni consigliate:
     • il file wp-config.php → 400 o 440 a seconda della configurazione del server
     • Directory → 755
     • File → 644 (eccetto i file di configurazione sensibili che dovrebbero essere più rigorosi)
   • Assicurarsi che i file siano di proprietà dell'utente corretto (l'utente del server web non dovrebbe possedere file se il tuo host supporta una separazione più sicura).
5. Disabilitare wrapper e funzioni PHP pericolosi dove possibile:
   • In php.ini, assicurarsi allow_url_fopen = Spento E allow_url_include = Disattivato. Questo riduce il rischio di inclusione di file remoti o abuso di wrapper di stream.
   • Considerare di disabilitare funzioni rischiose (solo se la tua applicazione non ne ha bisogno): esecutivo, shell_exec, sistema, passare attraverso, proc_open, popen. Esempio:

   disable_functions = exec,shell_exec,system,passthru,proc_open,popen
   

6. Bloccare i parametri forniti dall'utente utilizzati per il caricamento dei file:
   • Se identifichi endpoint specifici del tema che accettano file O modello parametri, aggiungi regole di blocco rapide lato server per le richieste che includono quei nomi di parametro fino a quando il tema non è stato corretto.
7. Attivare un WAF/patch virtuale
   • Se gestisci un firewall per applicazioni web (WAF) o un plugin di sicurezza che può implementare patch virtuali, abilita o aggiungi regole che:
     • Rilevano sequenze di traversata delle directory
     • Rileva php:// E data:// involucri
     • Blocca le richieste che tentano di accedere il file wp-config.php o altri file sensibili
   • La patch virtuale previene lo sfruttamento anche se il codice sottostante rimane vulnerabile, guadagnandoti tempo fino a quando una patch ufficiale non è disponibile.

Rimedi e verifiche a medio termine (giorni)

1. Sostituisci o aggiorna il tema
   • Controlla se esiste una patch ufficiale o una nuova versione del tema che affronta CVE-2026-28118. Se diventa disponibile una versione patchata ufficiale, testala accuratamente in staging e poi aggiorna la produzione.
   • Se non esiste una patch ufficiale, considera di sostituire il tema con un'alternativa mantenuta o un tema figlio personalizzato di un tema base mantenuto.
2. Esegui un audit del tuo filesystem per webshell e file sospetti
   • Scansiona wp-content/caricamenti, directory dei temi e directory dei plugin per:
     • File con PHP eseguibile dove non dovrebbe esserci
     • File con timestamp recentemente modificati che non riconosci
     • Indicatori noti dai tuoi sistemi di rilevamento delle intrusioni
3. Ruota credenziali e segreti
   • Cambia tutte le password degli admin di WordPress, le password del database, le chiavi API e qualsiasi altra credenziale che potrebbe essere memorizzata sul server o esposta.
   • Se ripristini da un backup, ruota le credenziali successivamente.
4. Rivedi i log del server e dell'applicazione
   • Controlla i log per il periodo prima e dopo la data di divulgazione per attività sospette che indicano uno sfruttamento riuscito (ad esempio, codici di risposta che includono output di file sensibili o tentativi di sfruttamento ripetuti).
   • Esporta i log pertinenti in una posizione sicura per eventuali lavori forensi necessari.
5. Scansione completa del sito per malware e controllo dell'integrità
   • Esegui una scansione completa per malware; molti scanner rileveranno webshell, backdoor e file di core modificati.
   • Utilizza strumenti di integrità dei file per confrontare il tuo codice sorgente con fonti conosciute e valide.
6. Ripristina da backup puliti se la compromissione è confermata
   • Se trovi prove di compromissione che non puoi pulire completamente, ripristina da un backup effettuato prima dei primi segni di compromissione. Assicurati di eseguire gli altri passaggi di rimedio (permessi rigidi, rotazione delle credenziali) dopo il ripristino.

Prevenzione e indurimento a lungo termine (settimane / in corso)

1. Principio del privilegio minimo
   • Assicurati che gli utenti di file e database abbiano solo i permessi di cui hanno bisogno.
   • Evita di eseguire processi del server web come lo stesso utente che può modificare i file.
2. Isola gli ambienti
   • Mantieni isolati gli ambienti di staging e produzione.
   • Utilizza credenziali diverse per ambienti diversi.
3. Monitoraggio e allerta continui
   • Centralizza i log (accesso, errore, PHP) e aggiungi avvisi per:
     • Tentativi di traversata delle directory
     • Richieste di riferimento il file wp-config.php e altri file sensibili
     • Picchi insoliti nelle risposte 4xx/5xx
4. Scansione regolare delle vulnerabilità
   • Esegui scansioni automatiche e revisioni manuali programmate regolari del codice di temi e plugin.
   • Iscriviti a feed di intelligence sulle vulnerabilità e configura le tue procedure di gestione delle patch per essere reattive.
5. Backup regolari e ripristini testati
   • Mantieni backup versionati off-site e testa regolarmente le procedure di ripristino.
6. Indurimento di WordPress stesso
   • Tieni aggiornato il core di WordPress, i plugin e i temi.
   • Rimuovi i plugin e i temi non utilizzati.
   • Disabilita o proteggi gli editor di temi e plugin.
   • Implementa intestazioni di sicurezza e HTTPS ovunque.

Regole di rilevamento e prevenzione WAF suggerite (concettuali)

Di seguito sono riportati schemi difensivi che puoi adattare nel tuo WAF o set di regole del server. Queste sono firme regex concettuali e dovrebbero essere testate prima del deployment per evitare falsi positivi.

• Blocca le richieste con tentativi di traversamento delle directory (base):
  • Regex: (\.\./|\.\.\\|%2e%2e%2f|%2e%2e%5c)
• Blocca i wrapper php://, data://, expect://:
  • Regex: (php://|data://|expect://|zip://|phar://)
• Blocca i tentativi di riferimento a file sensibili nelle stringhe di query:
  • Regex: (wp-config\.php|/etc/passwd|/proc/self/environ|\.env|\.htpasswd)
• Blocca lunghe sequenze di caratteri codificati che indicano offuscamento:
  • Regex: (%[0-9A-Fa-f]{2}){6,}

Esempio di pseudo-regola (indipendente dal WAF):

• Se una stringa di query di richiesta corrisponde a uno dei seguenti:
  • (\.\./|\.\.\\|%2e%2e%2f|%2e%2e%5c) OR
  • (php://|data://|expect://) OR
  • (wp-config\.php|/etc/passwd|\.env)

  → allora blocca la richiesta (HTTP 403) e registra i dettagli per la revisione.

Note sui falsi positivi: Molti CMS e librerie legittime possono includere token che somigliano a modelli rischiosi. Testa attentamente qualsiasi modello, limita le regole ai punti finali probabili (file di tema, endpoint di inclusione) e stringi gradualmente la copertura.

Se il tuo sito è stato compromesso — lista di controllo per la risposta agli incidenti

Se confermi una compromissione, segui immediatamente questi passaggi:

1. Metti il sito offline (modalità manutenzione) o isola l'host.
2. Fai uno snapshot completo del sito e dei log per l'analisi forense.
3. Cambia tutte le password (utenti admin, database, FTP/SFTP, pannello di controllo).
4. Ruota tutte le chiavi e i token che potrebbero essere stati memorizzati sul server.
5. Scansiona e rimuovi file dannosi e webshell. Se non sei sicuro della pulizia manuale, ripristina da un backup pulito.
6. Verifica l'integrità del database e rimuovi utenti admin non autorizzati o iniezioni di contenuto.
7. Esegui un audit completo per identificare come l'attaccante ha ottenuto accesso e quale movimento laterale potrebbe aver eseguito.
8. Ricostruisci l'ambiente da fonti conosciute e buone se necessario; non fare affidamento su “soltanto pulire” se le backdoor sono complesse.

Come WP‑Firewall aiuta (cosa fa per te un WAF gestito)

Dalla prospettiva di un servizio di sicurezza WordPress gestito, induriamo e proteggiamo i siti combinando diversi strati:

• Patch virtuali (regole WAF): Quando appare una vulnerabilità come questo LFI, possiamo implementare regole mirate che rilevano e bloccano i modelli di sfruttamento sui tuoi siti fino a quando una patch del fornitore non è disponibile.
• Firewall gestito e ispezione delle richieste: Analisi in tempo reale dei parametri delle richieste per bloccare sequenze di traversamento, utilizzo di wrapper PHP e altre firme di sfruttamento.
• Scansione malware e pulizia automatizzata: Scansioni continue per trovare file dannosi e rimozione automatizzata per molte webshell e backdoor conosciute.
• Mitigazione OWASP Top 10: Protezioni sistemiche progettate per ridurre i rischi dalle classi di minacce più comuni (Iniezione, Autenticazione interrotta, LFI/RFI, ecc.).
• Monitoraggio, avvisi e reportistica: Monitoriamo anomalie nel traffico e emettiamo avvisi tempestivi se rileviamo tentativi di sfruttamento o prove di compromissione.

Raccomandiamo una strategia a strati: combina patch virtuali e protezione WAF con configurazione sicura, aggiornamenti rapidi e monitoraggio. Le patch virtuali offrono protezione immediata mentre esegui i test accurati richiesti per aggiornamenti ufficiali o sostituzioni di temi.

Una breve nota tecnica per sviluppatori e sysadmin

Questa classe di vulnerabilità origina quasi sempre da una concatenazione non sicura dell'input dell'utente nei percorsi del filesystem. La tua lista di controllo per file sicuri include:

• Non utilizzare mai direttamente l'input dell'utente per costruire nomi di file senza whitelistare i valori consentiti.
• Utilizza mappature sicure (ad es., mappa chiavi brevi e conosciute a nomi di file consentiti) piuttosto che accettare input di percorso completo.
• Normalizza e valida qualsiasi percorso prima di passarlo a include/require.
• Se il contenuto dell'utente determina la selezione del template, limita le scelte a un insieme fidato che esiste nel tuo codice sorgente.

Esempio di approccio più sicuro (pseudo-codice):

<?php;

Questo modello mappa l'input dell'utente a un elenco controllato e previene l'inclusione arbitraria di file.

Nuova risorsa per i proprietari di siti: Inizia con una protezione immediata e gratuita

Proteggi il tuo sito ora con il nostro piano Basic Free — firewall gestito, WAF, scansione malware e copertura per i rischi OWASP Top 10. È progettato per proteggere i siti immediatamente mentre pianifichi eventuali aggiornamenti o sostituzioni di temi.

Sicurezza del tuo sito adesso — Inizia con WP‑Firewall Basic (Gratuito)

• Cosa ottieni immediatamente:
  • Firewall gestito e WAF con capacità di patch virtuale
  • Larghezza di banda illimitata per il traffico di sicurezza
  • Scansione malware per trovare file e modifiche sospette
  • Protezioni contro le minacce OWASP Top 10 (inclusi i modelli LFI)
• Perché è utile:
  • Ottieni il blocco immediato di modelli di sfruttamento noti per vulnerabilità appena divulgate
  • La patch virtuale riduce la finestra di attacco mentre testi aggiornamenti ufficiali o migri
• Inizia: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Offriamo anche livelli a pagamento se hai bisogno di rimozione automatizzata di malware, controlli di blocco IP, report mensili o servizi di sicurezza gestiti.)

Esempi pratici — regole rapide che puoi incollare e testare (sommario)

• Proteggi wp-config.php (posiziona in .htaccess):

<files wp-config.php>
  order allow,deny
  deny from all
</files>

• Regola Nginx per bloccare tentativi con wrapper php:

if ($query_string ~* "php://|data://|%2e%2e|(\.\./)") {
  return 403;
}

• Indurimento PHP ini:

allow_url_fopen = Off

Importante: Testa queste regole in staging per assicurarti che non blocchino il traffico legittimo per il comportamento specifico del tuo tema o plugin.

Raccomandazioni finali — cosa fare nelle prossime 24–72 ore

1. Inventario: Identifica eventuali siti che eseguono il tema Welldone ≤ 2.4.
2. Applica almeno una mitigazione immediata:
   • Disabilita/rinomina la cartella del tema, oppure
   • Blocca i modelli di sfruttamento a livello server/WAF, e
   • Limita l'accesso a wp-config.php.
3. Abilita la scansione e il monitoraggio continui.
4. Se puoi, iscriviti a un piano di protezione gestito (disponibile un livello gratuito) per applicare patch virtuali immediatamente mentre pianifichi una soluzione permanente.
5. Comunica con le parti interessate se ospiti siti dei clienti — la trasparenza e la rapida mitigazione sono importanti.

Se hai bisogno di assistenza tecnica

Se gestisci più installazioni di WordPress o siti di clienti e desideri aiuto per la triage o l'applicazione delle mitigazioni, il nostro team di operazioni di sicurezza può aiutarti ad analizzare i log, distribuire patch virtuali su tutta la tua flotta e assisterti nella risposta agli incidenti e nella pulizia. Forniamo anche indicazioni passo-passo per aggiornamenti e sostituzioni sicure di temi vulnerabili.

Conclusione

Questa vulnerabilità Welldone LFI (CVE-2026-28118) è una grave vulnerabilità non autenticata che può esporre file locali e portare a divulgazione di credenziali e compromissione totale. Il percorso più veloce verso la sicurezza è rimuovere o mettere in quarantena il tema vulnerabile e applicare regole di patching virtuale al perimetro mentre pianifichi un aggiornamento o una sostituzione controllata. Indurire il server (disabilitando wrapper rischiosi, correggendo le autorizzazioni, restringendo l'accesso ai file) e monitorare i log per gli indicatori sopra ridurrà drasticamente l'esposizione.

Se desideri protezione immediata senza cambiamenti complessi al server, prova il nostro piano gratuito di protezione di base che fornisce regole di firewall gestite, protezioni WAF e scansione malware per bloccare modelli di sfruttamento come quelli utilizzati negli attacchi LFI. Inizia a proteggere il tuo sito ora: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

— Il team di sicurezza di WP-Firewall

Riferimenti e note

• Vulnerabilità tracciata come CVE-2026-28118 (Inclusione di file locali nel tema Welldone, segnalata il 19 agosto 2025; pubblicata il 26 febbraio 2026).
• Questo avviso è destinato ad aiutare i difensori. Non pubblichiamo codice di sfruttamento qui. Se sei un amministratore che sospetta una violazione e hai bisogno di assistenza diretta, contatta i tuoi rispondenti alla sicurezza o rivolgiti a un fornitore di sicurezza WordPress fidato.