Mitigazione dell'Inclusione di File Locali nel Tema FindAll//Pubblicato il 2026-03-06//CVE-2026-22478

Nome del plugin	TrovaTutti
Tipo di vulnerabilità	Inclusione di File Locali
Numero CVE	CVE-2026-22478
Urgenza	Alto
Data di pubblicazione CVE	2026-03-06
URL di origine	CVE-2026-22478

Avviso urgente: Inclusione di file locali nel tema WordPress TrovaTutti (≤ 1.4) — Cosa devono fare ora i proprietari dei siti

Autore: WP‑Firewall Security Team
Data: 2026-03-10

Sintesi

Una vulnerabilità di Inclusione di File Locali (LFI) che colpisce il tema WordPress TrovaTutti (versioni ≤ 1.4) è stata divulgata pubblicamente e assegnata a CVE-2026-22478. Consente a attaccanti non autenticati di includere file locali dal sito target e visualizzarne i contenuti, il che può esporre segreti (credenziali del database, file di configurazione), portare a ulteriori esecuzioni di codice remoto o consentire un compromesso completo del sito a seconda della configurazione del server.

Come team di sicurezza di WordPress che protegge migliaia di siti web, consideriamo questa vulnerabilità ad alto rischio (CVSS 8.1). È necessaria una mitigazione immediata, specialmente dove gli aggiornamenti del tema o le patch del fornitore non sono ancora disponibili. Questo avviso spiega l'impatto della vulnerabilità, i segnali di rilevamento, i passaggi di mitigazione sicuri e le regole WAF/patch virtuali raccomandate che puoi applicare immediatamente per ridurre l'esposizione. Includiamo anche un elenco di controllo per la risposta agli incidenti operativi e linee guida per la prevenzione a lungo termine.

Nota: Questo avviso evita di fornire dettagli a livello di exploit. Il nostro obiettivo è aiutare gli amministratori a mettere in sicurezza i siti rapidamente e responsabilmente.

---

Informazioni su questo avviso

• Software interessato: tema WordPress TrovaTutti
• Versioni interessate: ≤ 1.4
• Tipo di vulnerabilità: Inclusione di File Locali (LFI)
• CVE: CVE-2026-22478
• Privilegi richiesti: Nessuno (non autenticato)
• Gravità: Alta (CVSS 8.1)
• Stato della patch: Nessuna patch ufficiale disponibile al momento della pubblicazione

---

Cos'è l'Inclusione di File Locali e perché è pericolosa

L'Inclusione di File Locali (LFI) si verifica quando un'applicazione accetta input controllato dall'utente per specificare un file da includere o leggere dal file system del server senza una corretta validazione o sanificazione. Quando un attaccante può controllare quell'input, può tentare di:

• Leggere file di configurazione sensibili (ad es., wp-config.php, .env) che contengono credenziali del database e chiavi segrete.
• Raccogliere credenziali che consentono l'accesso a database, servizi esterni o account amministrativi di WordPress.
• Combinare attacchi (ad esempio, leggere un file che rivela credenziali, quindi utilizzare quelle credenziali per modificare contenuti, iniettare un webshell o accedere al database).
• Ingannare il sistema per includere file di log o upload di utenti memorizzati nella cache che contengono codice PHP fornito dall'attaccante (se il server esegue PHP in directory scrivibili) — il che può portare a esecuzione di codice remoto (RCE).
• Rivelare informazioni sul percorso del server che aiutano ulteriori sfruttamenti.

Poiché questo particolare LFI è sfruttabile senza autenticazione e prende di mira un percorso di file di tema ampiamente utilizzato, i siti colpiti dovrebbero trattarlo come un problema urgente.

---

Scenari di sfruttamento realistici

Gli attaccanti tendono a sfruttare LFI nei seguenti modi nel mondo reale:

1. Elenca e leggi i file di configurazione:
   • Leggi wp-config.php per estrarre DB_USERNAME, DB_PASSWORD e SECRET_KEYS.
   • Leggi i file sotto la radice del sito come .env o altri file per sviluppatori.
2. Leggi i file di sistema per informazioni sensibili:
   • /etc/passwd (aiuta con la ricognizione)
   • File nelle directory di backup o upload che possono contenere dump di database o credenziali
3. Sfrutta il log poisoning o file controllati da upload:
   • Scrivi payload PHP in una posizione che il server web includerà successivamente (ad esempio, tramite upload utente abilmente progettati o log di cache scrivibili), causando l'esecuzione di codice quando viene attivata un'operazione di inclusione.
4. Passa a un accesso persistente:
   • Usa credenziali trapelate per accedere al database, creare utenti admin o cambiare le opzioni del sito.
   • Carica backdoor e webshell nel sito che persistono oltre l'exploit iniziale.

Poiché la vulnerabilità non richiede autenticazione, scanner e bot automatizzati tenteranno un'esploitazione di massa rapidamente dopo la divulgazione. Pertanto, una rapida mitigazione è essenziale.

---

Indicatori di compromissione (IoCs) e cosa tenere d'occhio

Quando valuti se il tuo sito è stato preso di mira o sfruttato, rivedi i log e i contenuti del sito per i seguenti indicatori:

Log del server (log di accesso):

• Richieste HTTP contenenti parametri sospetti come file=, inc=, pagina=, modello=, path=, vista=, o altri campi combinati con ../ sequenze o modelli di traversata di directory codificati (%2e%2e%2f).
• Richieste che includono traversata doppio-codificata: %252e%252e%252f.
• Richieste che tentano di recuperare file comunemente mirati da LFI: /etc/passwd, il file wp-config.php, .ambiente, php://filter/convert.base64-encode/resource=, O data://.
• Picchi improvvisi nelle risposte 4xx/5xx per richieste con modelli di traversamento.

Corpi delle richieste:

• Parametri POST o GET contenenti .., ..%2f, php://, dati:, o grandi blob base64.

File di sistema e contenuto:

• Nuovi o modificati file PHP nelle cartelle uploads, cache o tema.
• Utenti admin inaspettati nell'elenco utenti di WordPress.
• Opzioni di WordPress modificate (URL del sito, modifiche all'email dell'amministratore).
• Attività programmate sospette (cron) o voci sconosciute in wp_options.

Database:

• Contenuto inaspettato nei post o nei campi delle opzioni che includono PHP offuscato o script sospetti.
• Nuovi utenti del database o privilegi concessi.

Se identifichi uno qualsiasi di quanto sopra, trattalo come un possibile compromesso e segui l'elenco di controllo per la risposta agli incidenti qui sotto.

---

Mitigazioni immediate (a breve termine, pre-patch)

Se utilizzi il tema FindAll (≤ 1.4), implementa i seguenti passaggi immediati ora — non aspettare una patch ufficiale.

1. Fai un backup (file + database)
   Esegui un backup completo offline prima di apportare modifiche. Tieni una copia al di fuori del server.
2. Metti il sito in modalità manutenzione (se appropriato)
   Prevenire ulteriori attacchi automatizzati mentre mitighi.
3. Rimuovi o disabilita il tema vulnerabile
   Se puoi passare a un tema attivo sicuro, fallo.
   Se il tema è la shell attiva del sito e non può essere facilmente scambiato, considera di mettere temporaneamente offline il sito e servire una pagina statica.
4. Limita l'accesso agli endpoint vulnerabili
   Se riesci a identificare il file tema specifico che accetta un parametro include, blocca l'accesso ad esso tramite regole del server web o nega le richieste pubbliche dirette a quel file.
   Disabilita qualsiasi esecuzione PHP scrivibile pubblicamente nelle directory upload/cache/temp.
5. Applica immediatamente WAF/patching virtuale.
   Se gestisci un Web Application Firewall (WAF) o un set di regole basato su host, applica regole che:
   • Blocca le richieste contenenti modelli di traversata delle directory: ../, %2e%2e%2f, ..%2f, %2e%2e%5c (traversata codificata in URL).
   • Blocca wrapper sospetti: php://, dati:, expect://, file://.
   • Blocca le richieste che tentano di accedere ai file di configurazione core: richieste che includono il file wp-config.php, .ambiente, config.php, ecc.
   • Blocca le richieste contenenti php://filter costrutti utilizzati per leggere il contenuto dei file.

   Applica una postura di negazione predefinita per qualsiasi parametro che sembra selezionare file (consenti solo una lista bianca rigorosa di nomi di file noti se possibile).

6. Rinforza le autorizzazioni sui file
   Assicurati che wp-config.php non sia leggibile dal mondo.
   Imposta le directory di upload e cache su 0755 dove possibile e disabilita l'esecuzione tramite .htaccess / configurazione del server web.
7. Scansiona il sito per file dannosi e modifiche sospette.
   Usa uno scanner malware affidabile per localizzare webshell o file PHP insoliti.
   Rivedi manualmente i file recentemente modificati nelle directory tema, plugin e upload.
8. Ruotare i segreti se sospetti un'esposizione.
   Se trovi prove che wp-config.php è stato accesso, ruota immediatamente le credenziali del database e aggiorna wp-config.php con nuove password.
   Ruota eventuali chiavi API, token e account di servizio se potrebbero essere stati esposti.
9. Monitora i log da vicino
   Continua a monitorare i log di accesso del server web, i log degli errori e i log delle applicazioni per tentativi di sfruttamento.

---

Regole WAF raccomandate (esempi)

Di seguito sono riportati concetti di regole WAF sicure e difensive che possono essere utilizzati per bloccare modelli comuni di sfruttamento LFI. Questi sono intesi come modelli difensivi — non usarli per creare o rivelare payload di sfruttamento. Testa le regole in un ambiente di staging dove possibile prima di una distribuzione ampia.

Esempio: blocca tentativi evidenti di traversata di directory e wrapper (espressione concettuale — adatta alla sintassi del tuo WAF):

• Blocca se qualsiasi valore di parametro contiene \.\./ O %2e%2e%2f (non sensibile al maiuscolo/minuscolo).
• Blocca se qualsiasi valore di parametro contiene php://, dati:, file://, expect://.
• Blocca le richieste che includono il file wp-config.php nella stringa di query o nei dati POST.
• Blocca l'uso di php://filter wrapper utilizzati per leggere file.

ModSecurity (esempi di regole, adatta al tuo ambiente):

# Block common directory traversal attempts
SecRule ARGS|ARGS_NAMES|REQUEST_URI "(?:\.\./|\.\.\\|%2e%2e%2f|%2e%2e%5c)" "id:100001,phase:2,deny,log,msg:'Detect Directory Traversal LFI attempt'"

# Block access to wp-config.php or .env via query string or body
SecRule REQUEST_URI|ARGS|REQUEST_HEADERS "(wp-config\.php|\.env|config\.php)" "id:100002,phase:2,deny,log,msg:'Blocked attempt to access sensitive file'"

# Block php wrappers
SecRule ARGS|REQUEST_URI "(?:php://|data:|expect://|file://|phar://)" "id:100003,phase:2,deny,log,msg:'Blocked wrapper usage in input'"

# Optional: stricter rule to block inclusion parameters if their values are not in an allowed list
SecRule ARGS_NAMES "file|template|include|page|view|path" "id:100004,phase:2,pass,ctl:ruleRemoveById=999999"
# Then create a whitelist for known safe values if feasible.

Nginx (concettuale):

# Deny requests that contain traversal patterns
if ($request_uri ~* "\.\./|%2e%2e%2f") {
    return 403;
}

# Deny parameters that mention wp-config.php
if ($query_string ~* "wp-config\.php|\.env") {
    return 403;
}

Note:

• Quanto sopra è concettuale. Adattali alla tua tecnologia server/WAF e testa a fondo per evitare falsi positivi.
• Preferisci elenchi di autorizzazione positivi per parametri di selezione file dove puoi (consenti solo nomi di file noti).
• Evita regole eccessivamente ampie che potrebbero interrompere comportamenti legittimi — testa e monitora.

---

Regole di rilevamento sicure (non bloccanti; modalità di monitoraggio)

Se non puoi bloccare immediatamente, imposta avvisi di rilevamento per i seguenti:

• Qualsiasi richiesta contenente token di traversata di directory nei parametri di query o nei corpi POST.
• Qualsiasi php://filter uso nelle richieste.
• Richieste che tentano di recuperare il file wp-config.php, .ambiente, O /etc/passwd tramite il livello applicativo.
• Qualsiasi agente utente o IP insolito che esegue molti tentativi simili a LFI.

Questi avvisi ti permettono di dare priorità agli IP da bloccare e fornire prove forensi se si verifica un incidente.

---

Lista di controllo per la risposta agli incidenti (passo dopo passo)

Se sospetti un'esploitazione, segui questi passaggi in ordine:

1. Contenere
   • Applica le regole WAF per bloccare ulteriori tentativi (blocca IP o modelli).
   • Metti il sito offline o abilita la modalità di manutenzione se necessario.
2. Preserva
   • Crea copie forensi di log, file e snapshot del database per un'analisi successiva.
   • Tieni una copia di eventuali file sospetti.
3. Rileva
   • Scansiona alla ricerca di webshell e file PHP inaspettati.
   • Controlla i log di accesso e di errore per parametri e richieste sospette.
4. Sradicare
   • Rimuovi le backdoor identificate e i file dannosi.
   • Sostituisci i file compromessi con versioni pulite da backup affidabili.
5. Recuperare
   • Ruota le credenziali (database, FTP, SSH, chiavi API).
   • Reinstalla temi/plugin da fonti affidabili (aggiorna a versioni corrette quando disponibili).
   • Ripristina il sito da un backup pulito se necessario.
6. Post-incidente
   • Esegui un audit di sicurezza completo, inclusa la revisione delle autorizzazioni dei file e dei plugin/temi.
   • Rivedi e rafforza le regole WAF e il monitoraggio.
   • Notifica le parti interessate e (se necessario) i clienti riguardo alla violazione e ai passaggi di rimedio.
7. Riporta
   • Se i dati dei clienti sono stati esposti, rispetta i requisiti di divulgazione e legali applicabili per la notifica.

---

Indurimento e mitigazione a lungo termine

Per ridurre il rischio di questa e simili vulnerabilità in futuro, applica queste migliori pratiche:

• Tieni aggiornati temi, plugin e il core di WordPress con un piano per patch di emergenza.
• Minimizzare i componenti installati: rimuovere temi o plugin non utilizzati.
• Utilizzare un WAF gestito che possa applicare patch virtuali per vulnerabilità note fino a quando le patch del fornitore non sono disponibili.
• Limitare i permessi dei file e disabilitare l'esecuzione di PHP nella directory degli upload:
  • Utilizzare .htaccess (Apache) o blocchi di posizione (Nginx) per negare l'esecuzione di PHP in /wp-content/uploads, /wp-content/cache e directory simili.
• Utilizzare il principio dei privilegi minimi per gli utenti del database.
• Utilizzare un utente del database separato per ogni sito con permessi limitati, se possibile.
• Implementa il monitoraggio dell'integrità dei file per rilevare cambiamenti imprevisti nei file.
• Mantenere backup regolari e testati archiviati off-site o offline.
• Scansionare il proprio codice sorgente e i componenti di terze parti (SCA — analisi della composizione del software) per identificare dipendenze vulnerabili.
• Condurre revisioni di sicurezza periodiche e test di penetrazione.

---

Come un firewall gestito/patch virtuale aiuta (una spiegazione pratica)

Quando una vulnerabilità viene divulgata pubblicamente e non è immediatamente disponibile una patch ufficiale, applicare una patch virtuale tramite un firewall gestito può guadagnare tempo mentre il fornitore del tema prepara e distribuisce una correzione sicura. Le patch virtuali:

• Intercettano e bloccano schemi di attacco noti prima che raggiungano il codice dell'applicazione vulnerabile.
• Vengono aggiornate in tempo reale dai team di sicurezza quando vengono osservati nuovi schemi di sfruttamento.
• Possono essere personalizzate per la vulnerabilità per ridurre i falsi positivi (ad esempio, bloccando solo le richieste che mostrano traversata di directory o utilizzo di wrapper).
• Forniscono protezione immediata per vulnerabilità non autenticate e riducono lo sfruttamento automatizzato da parte di bot.
• Sono particolarmente utili per le organizzazioni che non possono aggiornare temi/plugin immediatamente a causa di vincoli di compatibilità o test.

Ricorda: la patch virtuale è una mitigazione, non una soluzione permanente. Dovrebbe essere utilizzata mentre pianifichi e distribuisci una patch permanente fornita dal fornitore o sostituendo il componente vulnerabile.

---

Esempi pratici: Cosa cercare nei log (campioni)

Di seguito sono riportati esempi sicuri di righe di log che sono sospette (potresti vedere versioni codificate in URL):

• GET /?file=../../../../wp-config.php HTTP/1.1
• GET /?page=../../../../etc/passwd HTTP/1.1
• POST /theme-handler.php con corpo contenente php://filter/convert.base64-encode/resource=wp-config.php
• Richieste ripetute da un singolo IP che tentano diverse codifiche di traversamento.

Se trovi tali voci, blocca l'IP, conserva i log e indaga.

---

Se il sito è stato compromesso — priorità di rimedio

1. Revoca le credenziali esposte (ruota la password del DB, le chiavi API).
2. Forza il ripristino delle password per gli amministratori e per eventuali account privilegiati.
3. Reinstalla il core di WordPress, i temi e i plugin da fonti pulite.
4. Sostituisci eventuali file compromessi con versioni conosciute come buone.
5. Cerca e rimuovi le backdoor — i webshell spesso usano nomi innocui; ispeziona i file modificati di recente.
6. Indurire la configurazione e aggiungere regole WAF per prevenire la riesploitazione.

---

Indicazioni per la comunicazione per agenzie e host

Se gestisci più siti client o ospiti molte installazioni di WordPress:

• Identifica rapidamente i siti che utilizzano il tema colpito (≤ 1.4).
• Dai priorità alla mitigazione sui siti commerciali esposti e sui siti che gestiscono dati sensibili.
• Applica patch virtuali a livello di rete/WAF su più siti per ridurre il carico di gestione.
• Coordina con i clienti: fornisci aggiornamenti chiari sullo stato, cosa hai cambiato e i prossimi passi, inclusi backup e rotazione delle credenziali.

---

Perché la sicurezza proattiva è importante (contesto del mondo reale)

Vulnerabilità come LFI in temi ampiamente distribuiti sono obiettivi attraenti per gli attaccanti perché possono essere automatizzati e scalati su molti siti. Una postura reattiva che aspetta una patch del fornitore del tema rischia l'esposizione dei dati e l'interruzione del servizio. Misure proattive come il patching virtuale, il monitoraggio continuo e aggiornamenti tempestivi ridurranno significativamente il rischio e il tempo di recupero.

---

Mitigazione WP‑Firewall: come aiutiamo

Presso WP‑Firewall, il nostro firewall gestito e la capacità di patching virtuale sono progettati per proteggere i siti WordPress da vulnerabilità come questo LFI mentre esegui la rimedio. Il nostro approccio include:

• Distribuzione rapida delle firme per bloccare i modelli di sfruttamento associati a vulnerabilità recentemente divulgate.
• Regole di monitoraggio e rilevamento sintonizzate su contesti specifici di WordPress per ridurre i falsi positivi.
• Guida e supporto per incidenti per la rotazione delle credenziali, la scansione e la pulizia.

Se utilizzi WP‑Firewall, possiamo attivare una regola di mitigazione per questo specifico modello LFI sui siti protetti per prevenire tentativi di sfruttamento automatico mentre pianifichi una soluzione permanente.

---

Nota speciale sulla divulgazione responsabile e sui prossimi passi

Se sei uno sviluppatore di temi, segui questi passaggi:

1. Riconosci prontamente il rapporto.
2. Identifica il percorso del codice vulnerabile e implementa una corretta convalida dell'input e una lista bianca.
3. Rilascia una versione corretta e fornisci indicazioni per l'aggiornamento agli utenti.
4. Coordina con i fornitori di sicurezza in modo che le patch virtuali e le regole di mitigazione possano essere aggiornate e successivamente rimosse quando è disponibile una patch sicura.

Se sei un proprietario di un sito:

• Monitora il fornitore del tema per patch ufficiali.
• Applica la patch del fornitore non appena viene rilasciata e convalidata.
• Tieni registri delle modifiche e backup per ripristinare se necessario.

---

Nuovo Piano: Proteggi il tuo sito immediatamente — Protezione di base gratuita da WP‑Firewall

Ci rendiamo conto che non tutti i proprietari di siti possono reagire immediatamente a un'emergenza. Per aiutare i proprietari di siti a ottenere protezione immediata senza costi, offriamo un piano di base (gratuito) su misura per una difesa rapida ed essenziale:

• Titolo: Protezione immediata e senza costi — Prova WP‑Firewall Basic (gratuito)
• Cosa ottieni in Basic (gratuito):
  • Protezione firewall gestita
  • Larghezza di banda illimitata
  • Regole del Web Application Firewall (WAF) contro l'OWASP Top 10
  • Scanner di malware
  • Mitigazione rapida per minacce critiche (patch virtuali dove applicabile)
• Perché iscriversi:
  • Ottieni uno strato di protezione gestito che blocca i modelli di sfruttamento comuni mentre correggi o sostituisci componenti vulnerabili.
  • Ideale per proprietari di siti singoli, agenzie con piccoli clienti e chiunque abbia bisogno di una riduzione immediata del rischio.

Inizia la tua protezione di base gratuita ora: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Se hai bisogno di funzionalità extra, i nostri piani Standard e Pro aggiungono rimozione automatica del malware, capacità di blacklist/whitelist IP, report di sicurezza mensili e servizi gestiti avanzati.)

---

Domande frequenti (FAQ)

Q: Il mio tema è aggiornato a una versione corretta — ho ancora bisogno di un WAF?
UN: Sì. Un WAF offre difesa in profondità. Aiuta a bloccare i tentativi di sfruttamento mentre testi e distribuisci aggiornamenti, e può proteggere contro attacchi zero-day e altre vulnerabilità in plugin/temi che potresti non aver ancora aggiornato.

Q: Queste regole WAF romperanno funzionalità legittime?
UN: Regole ben progettate sono pensate per minimizzare i falsi positivi. Raccomandiamo di testare in modalità di rilevamento, quindi passare al blocco una volta convalidato che nessun traffico legittimo è colpito. Un approccio di whitelisting per parametri di selezione di file legittimi è la strategia di produzione più sicura.

Q: Ho trovato richieste sospette nei log — da dove inizio?
UN: Blocca gli IP offensivi al perimetro, conserva i log, fai un backup, quindi segui la checklist di risposta all'incidente sopra.

---

Raccomandazioni finali

• Tratta CVE‑2026‑22478 (tema FindAll ≤ 1.4 LFI) come una minaccia immediata se utilizzi il tema interessato.
• Se puoi, disabilita o sostituisci il tema subito. Se non è possibile, applica WAF/patching virtuale e indurisci immediatamente i permessi dei file.
• Monitora i log e cerca indicatori di compromissione. Ruota le credenziali se sospetti una divulgazione.
• Usa strumenti gestiti per applicare patch virtuali rapidamente e ridurre la finestra di attacco mentre le patch del fornitore vengono preparate.
• Mantieni backup e un piano di risposta agli incidenti testato in modo da poter reagire rapidamente in future divulgazioni.

---

Se desideri assistenza nell'applicare le regole WAF, nel cercare indicatori di compromissione o nell'implementare un piano di mitigazione, il team WP‑Firewall può aiutarti. Il nostro firewall gestito protegge i siti WordPress con regole contestuali e patch virtuali rapide su misura per WordPress, temi e plugin.

Rimani al sicuro e dai priorità a una risposta rapida e metodica — più velocemente agisci, minore sarà il rischio di danni a lungo termine.

Team di sicurezza WP-Firewall