| Nome del plugin | Jannah |
|---|---|
| Tipo di vulnerabilità | Inclusione di File Locali |
| Numero CVE | CVE-2026-25464 |
| Urgenza | Alto |
| Data di pubblicazione CVE | 2026-03-18 |
| URL di origine | CVE-2026-25464 |
Inclusione di File Locali nel Tema Jannah (<= 7.6.3) — Cosa Devono Fare Subito i Proprietari di Siti WordPress
Una vulnerabilità di Inclusione di File Locali (LFI) che colpisce il tema WordPress Jannah (versioni <= 7.6.3) — tracciata come CVE-2026-25464 — è stata pubblicata di recente. È una vulnerabilità di alta priorità (CVSS 8.1) che consente a attaccanti non autenticati di includere e visualizzare file locali dal server web. Ciò significa che gli attaccanti possono potenzialmente leggere file sensibili (ad esempio, wp-config.php), il che può portare all'esposizione delle credenziali del database e al completo controllo del sito.
Se utilizzi il tema Jannah su qualsiasi sito WordPress, leggi attentamente questa guida. Scrivo dalla prospettiva del team di sicurezza WP-Firewall: consigli pratici di mitigazione e recupero che puoi applicare immediatamente — anche prima che sia disponibile una patch ufficiale del fornitore.
Contenuti
- Cos'è un LFI e perché è pericoloso per i siti WordPress
- Riepilogo del problema LFI di Jannah (<= 7.6.3, CVE-2026-25464)
- Come gli attaccanti sfruttano l'LFI (schemi e payload comuni)
- Azioni immediate (0–24 ore)
- Mitigazioni a breve termine (24–72 ore)
- Indurimento e soluzioni a lungo termine
- Rilevamento e ricerca: indicatori di compromissione e schemi di log
- Piano di risposta agli incidenti se il tuo sito è compromesso
- Come WP-Firewall ti protegge e si integra nella tua risposta
- Raccomandazioni aggiuntive e domande frequenti
- Proteggi il tuo sito ora — Inizia con il piano gratuito di WP-Firewall
Cos'è un LFI e perché è pericoloso per i siti WordPress
L'Inclusione di File Locali (LFI) è una classe di vulnerabilità che si verifica quando un'applicazione include file basati su input controllato dall'utente senza una corretta validazione. In un CMS basato su PHP come WordPress, se un tema o un plugin utilizza include/require con una variabile non sanitizzata (ad esempio require_once($_GET[‘page’])), un attaccante può manipolare il percorso e causare l'inclusione di file locali da parte del server.
Perché è importante:
- Molti file sensibili risiedono sul server (wp-config.php, .env, file di backup, log).
- Leggere wp-config.php può rivelare il nome utente/password del database e i sali.
- Una volta che le credenziali o i segreti sono esposti, il movimento laterale e la compromissione totale sono banali.
- L'LFI è particolarmente pericoloso poiché spesso non richiede autenticazione e può essere automatizzato per colpire migliaia di siti.
Riepilogo del problema LFI di Jannah (<= 7.6.3, CVE-2026-25464)
- Software interessato: tema WordPress Jannah, versioni fino e comprese 7.6.3.
- Vulnerabilità: Inclusione di File Locali (LFI) tramite un input non autenticato che risulta in inclusione di file lato server.
- CVE: CVE-2026-25464
- Gravità: Alta (CVSS 8.1)
- Impatto: Un attaccante remoto può includere e visualizzare file locali dal server web; potenziale per rivelare credenziali del database e altri segreti.
- Privilegi richiesti: Nessuno (Non autenticato).
- Patch ufficiale: Al momento della scrittura, non è disponibile alcuna patch ufficiale per tutti i siti interessati. (Controlla i canali dell'autore del tema per aggiornamenti.)
- Rischio di sfruttamento di massa: Alto — Le vulnerabilità LFI sono obiettivi di routine per la scansione automatizzata e lo sfruttamento di massa.
Come gli attaccanti sfruttano l'LFI (schemi e payload comuni)
Gli attaccanti che cercano LFI tentano di chiamare endpoint con parametri che contengono sequenze di traversata delle directory (../) e nomi di file noti. Alcuni modelli di payload comuni:
- Traversata + file sensibile:
/?page=../../../../wp-config.php
- Trucchi del byte nullo (versioni PHP più vecchie):
/?page=../../../../wp-config.php
- Inclusione di file di log (log avvelenato):
/?page=../../../../wp-content/debug.log
- Tentativi di output filtrato e codifica:
/?page=../../../../wp-config.php&show=1
- Proxying di codice shell o lettura di file di backup:
/?page=../../../../backups/site-backup.sql
Gli scanner automatizzati proveranno migliaia di permutazioni; una volta trovata un'endpoint LFI attivo, tenteranno di estrarre wp-config.php, leggere .env o includere file caricati per eseguire codice PHP. Le catene di attacco variano, ma leggere wp-config.php è solitamente sufficiente per l'attaccante per escalare rapidamente.
Azioni immediate (0–24 ore)
Se sospetti o hai confermato che il tuo sito utilizza la versione vulnerabile di Jannah, dai priorità ai seguenti passaggi immediati:
- Metti il sito in modalità manutenzione se possibile
- Minimizza ulteriori sfruttamenti e impatti sugli utenti durante la rimediazione.
- Limita l'accesso pubblico ai file del tema
- Limitare temporaneamente l'accesso a
wp-content/themes/jannah/tramite l'autorizzazione IP nel pannello di controllo del tuo hosting o nella configurazione del server web.
- Limitare temporaneamente l'accesso a
- Rimuovi o sostituisci il tema vulnerabile se non puoi applicare una patch immediatamente
- Passa a un tema pulito e affidabile (temi WordPress predefiniti come Twenty Twenty-Three) fino a quando non è disponibile un aggiornamento sicuro.
- Se il cambio non è possibile, rimuovi il tema dal server e riattiva un tema sicuro.
- Blocca i vettori di sfruttamento all'esterno (Web Application Firewall / host)
- Implementa regole di blocco per modelli di traversata comuni:
../O%2e%2e%2f - Blocca/nega le richieste contenenti nomi di file sospetti:
il file wp-config.php,.ambiente, ecc. - Se utilizzi WP-Firewall, abilita regole di mitigazione immediate che mirano a modelli LFI e firme di attacco specifiche di Jannah.
- Implementa regole di blocco per modelli di traversata comuni:
- Ruota le credenziali (se ci sono prove di compromissione)
- Cambia le password dell'amministratore di WordPress, la password dell'utente del database e qualsiasi chiave/segreto se
il file wp-config.phppotrebbero essere stati esposti. - Aggiorna le chiavi API di terze parti se sono memorizzate sul server.
- Cambia le password dell'amministratore di WordPress, la password dell'utente del database e qualsiasi chiave/segreto se
- Esegui un backup completo (file + database)
- Cattura lo stato attuale per la forense prima di apportare modifiche distruttive.
- Cerca indicatori di compromissione
- Usa uno scanner di malware per rilevare file o webshells insoliti.
- Ispeziona i file modificati di recente in
wp-content/uploads/e le cartelle dei plugin/temi.
Mitigazioni a breve termine (24–72 ore)
Dopo la contenimento immediato, applica mitigazioni a strati per ridurre la superficie di attacco mentre si attende una patch ufficiale del fornitore:
- Applica regole .htaccess / nginx rigorose per bloccare l'accesso ai file
Apache (.htaccess) — Proteggi wp-config.php e blocca la traversata:
# Negare l'accesso a wp-config.php
Nginx — nega wp-config.php e blocca la traversata:
location = /wp-config.php {
- Indurire la configurazione PHP
- Disabilita
consenti_includere_urlEallow_url_fopense non necessario. - Limita
open_basediralla tua radice di WordPress per prevenire l'inclusione di file arbitrari:php_admin_value[open_basedir] = /var/www/example.com:/tmp
- Disabilita funzioni pericolose (se sicuro per il tuo sito):
disable_functions = exec,passthru,shell_exec,system,proc_open,popen
- Disabilita
- Permessi e proprietà dei file
- Assicurati di avere le corrette autorizzazioni sui file: file 644, dir 755,
il file wp-config.php600 o 640 dove supportato. - Assicurati che l'utente del server web possieda ciò di cui ha bisogno e nulla di più.
- Assicurati di avere le corrette autorizzazioni sui file: file 644, dir 755,
- Disabilita/limita le inclusioni di file del tema
- Chiedi agli sviluppatori di controllare il codice del tema e commentare o indurire eventuali dichiarazioni di inclusione/requisito che accettano input dell'utente.
- Blocca agenti utente sospetti e IP malevoli
- Usa i controlli di accesso del tuo host per bloccare noti botnet di scanner e indirizzi IP ripetuti con tentativi di exploit.
- Implementa patch virtuali
- Se non puoi aggiornare immediatamente, applica regole WAF mirate (patch virtuali) per bloccare i modelli di exploit LFI e qualsiasi endpoint vulnerabile scoperto fino a quando una patch del tema non è disponibile.
Indurimento e soluzioni a lungo termine
- Aggiorna il tema quando una patch del fornitore è disponibile
- Applica l'aggiornamento del tema non appena viene rilasciato e verificato.
- Esegui una revisione del codice di Jannah (e di altri temi/plugin di terze parti)
- Cerca modelli come include/require dinamici, uso di file_get_contents() con input non sanitizzati, o uso di input dell'utente per costruire percorsi di file.
- Adotta un processo centralizzato di gestione delle vulnerabilità
- Mantieni un inventario di temi e plugin, monitora le versioni e iscriviti ai feed di vulnerabilità pertinenti a WordPress.
- Limita la modifica dei file all'interno di WordPress
- In
il file wp-config.phpset:define('DISALLOW_FILE_EDIT', true);define('DISALLOW_FILE_MODS', true);
- Questo riduce il rischio che gli attaccanti modifichino il codice tramite la dashboard.
- In
- Applica il principio del minimo privilegio per gli utenti del database
- Evita di utilizzare l'utente del database con privilegi globali. Usa solo i permessi necessari a WordPress (SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER).
- Ambienti e backup separati
- Mantieni ambienti di staging separati; assicurati che i backup non siano memorizzati in directory web accessibili.
- Ruota regolarmente segreti e chiavi API
- Se qualche segreto è stato esposto, ruota e invalida i token.
- Integra la rilevazione in tempo reale
- Il monitoraggio dell'integrità dei file (FIM) e gli avvisi in tempo reale aiutano a rilevare cambiamenti sospetti prima.
Rilevamento e ricerca: indicatori di compromissione e schemi di log
Rilevare tempestivamente i tentativi di sfruttamento riduce i danni. Controlla i tuoi log di accesso, log di errore e log dell'applicazione per i seguenti modelli e indicatori:
Modelli di richiesta comuni:
- Richieste con sequenze di traversamento:
"../","..","". - Richieste che tentano di includere file noti:
il file wp-config.php,.ambiente,.bash_history,backup.sql,logs/debug.log. - Richieste con payload lunghi o parametri codificati in base64.
- Richieste POST che tentano di caricare o includere file nelle directory del tema.
Esempi di voci di log sospette:
- Risposte 200 o 403 a richieste con
../../../wp-config.phpnella stringa di query. - Errori 500 causati da tentativi di inclusione di file (avvisi inaspettati su include/require).
- Accessi anomali ai file del tema (ad es.,
/wp-content/themes/jannah/include.php?page=...).
File da ispezionare su disco:
il file wp-config.php— controlla il timestamp modificato di recente.- Qualsiasi file in
wp-content/uploads/o directory tmp con.phpestensione. - Voci cron inaspettate in WordPress o crontab del server.
- Nuovi utenti admin o livelli di capacità utente modificati.
Query di ricerca (grep):
- Cerca payload di traversale nei log di accesso:
grep -E "(\.\./|\\)" /var/log/apache2/access.log - Controlla la cronologia delle modifiche ai file:
trova /var/www/site -type f -mtime -7 -ls
Se trovi qualcosa di sospetto, metti il sito offline per un'indagine più approfondita e per la forense.
Piano di risposta agli incidenti se il tuo sito è compromesso
Se determini che un LFI è stato sfruttato con successo e i segreti sono stati divulgati, segui un piano di rimedio:
- Isolare
- Mettere il sito in modalità di manutenzione o metterlo offline per prevenire ulteriori danni.
- Istante
- Fai un'immagine del disco e uno snapshot del database per la forense.
- Copia i log web e di sistema in un luogo sicuro.
- Ruota la password del DB, le password dell'amministratore di WordPress e qualsiasi altra chiave (API, terze parti).
- Rimuovi le backdoor e i file sospetti
- Controlla manualmente e rimuovi webshell o file PHP sconosciuti dalle cartelle di upload e tema/plugin.
- Ripristina da un backup pulito (se disponibile)
- Se hai un backup pre-compromesso, ripristinalo e riapplica gli aggiornamenti di sicurezza corretti contro la vulnerabilità.
- Reinstalla i file core/theme/plugin da fonti affidabili
- Sostituisci i file di tema e plugin con copie fresche dai repository ufficiali.
- Migliora il monitoraggio
- Attiva i controlli di integrità dei file, le aggregazioni dei log e aumenta la frequenza degli avvisi.
- Rivaluta l'accesso e i permessi
- Assicurati il minimo privilegio e rimuovi gli account admin non utilizzati.
- Segnala e impara
- Riporta l'incidente al tuo fornitore di hosting e documenta i vettori di attacco per prevenzioni future.
- Supporto esterno
- Se l'incidente è complesso, coinvolgi un fornitore di risposta agli incidenti professionale esperto in WordPress.
Come WP-Firewall ti protegge e si integra nella tua risposta
Presso WP-Firewall consideriamo la sicurezza come una protezione a strati, rilevamento rapido e mitigazione veloce. I nostri prodotti e servizi aiutano in ogni fase:
- Regole WAF gestite (patching virtuale): Quando emerge una vulnerabilità zero-day o ad alto rischio come questo LFI, WP-Firewall può implementare regole mirate per bloccare i modelli di sfruttamento prima che sia disponibile una patch ufficiale. Questo è comunemente chiamato “patching virtuale” ed è una misura critica di emergenza.
- Blocco basato su firma e comportamento: Blocchiamo i modelli di traversata, i tentativi di leggere file sensibili e POST o upload sospetti.
- Scansione malware e integrità dei file: Rileva webshell, file PHP inaspettati negli upload e file core/theme modificati.
- Avvisi e registri in tempo reale: Ti offre la visibilità necessaria per indagare su eventi sospetti e agire rapidamente.
- Risposta guidata agli incidenti: Il nostro team di supporto aiuta a dare priorità ai passaggi, dall'isolamento del sito alla rotazione delle credenziali e alla pulizia degli artefatti.
Perché il patching virtuale è importante: Una patch del tema potrebbe essere ritardata, oppure il tema potrebbe essere installato su molti siti che non vengono mantenuti aggiornati. Un WAF correttamente configurato blocca i tentativi di sfruttamento al confine e ti dà tempo per applicare e convalidare gli aggiornamenti in modo sicuro.
Regole WAF pratiche ed esempi Nginx/Apache che puoi applicare immediatamente
Di seguito sono riportate regole difensive concrete che tu o il tuo host potete applicare per bloccare modelli di sfruttamento LFI comuni. Testa prima in staging.
ModSecurity (idea di regola generica):
# Bloccare la traversata ovvia nelle stringhe di query"
Frammento Nginx (aggiungi al blocco del server):
# negare i tentativi di accesso a wp-config.php direttamente tramite stringa di query
La regola Apache (.htaccess) già mostrata in precedenza è efficace per molti host.
Nota: Il blocco generico può produrre falsi positivi. Usa la whitelist e i test per evitare di interrompere la funzionalità legittima.
Guida per sviluppatori — come correggere il codice per prevenire LFI
Se mantieni un tema o un plugin personalizzato, segui queste migliori pratiche di codifica per evitare LFI:
- Non utilizzare mai input forniti dall'utente direttamente nelle istruzioni include/require.
- Usa whitelist piuttosto che blacklist: mappa i nomi delle pagine consentite ai percorsi dei file sicuri.
Esempio:
$pages = [
- Convalida e normalizza i percorsi dei file con
basename(),percorso reale(), e controlli contro una directory consentita. - Evita chiamate di inclusione dinamica che concatenano stringhe da input utente.
- Usa le API di WordPress dove possibile (
get_template_part,locate_template) che sono meno soggette a sfruttamento se utilizzate correttamente.
Domande frequenti (FAQ)
D: Un attaccante può eseguire codice arbitrario tramite LFI?
R: LFI tipicamente legge file locali, ma può portare all'esecuzione di codice remoto in attacchi concatenati — ad esempio, includendo un file che un attaccante può controllare (un file PHP caricato o un log compromesso). Una volta raggiunta l'esecuzione del codice, segue un compromesso totale.
D: Se cambio la password del database, il mio sito si romperà?
R: Dopo aver cambiato la password del DB, aggiorna wp-config.php con le nuove credenziali. Se l'attaccante aveva già ottenuto le vecchie credenziali e le ha utilizzate altrove, ruota i servizi dipendenti. Considera anche di creare un nuovo utente DB con privilegi limitati.
D: E se non riesco ad aggiornare il tema perché è personalizzato?
R: Usa la patching virtuale per bloccare lo sfruttamento, poi pianifica un aggiornamento controllato. Se il tema è personalizzato, unisci le correzioni del fornitore nella tua versione personalizzata o rifattorizza per rimuovere il codice problematico.
D: Quanto tempo dovrei tenere il sito offline se compromesso?
R: Finché necessario per rimuovere webshell, convalidare i backup, cambiare le credenziali e assicurarsi che non rimangano backdoor. Potrebbe richiedere ore o giorni a seconda della complessità.
Proteggi il tuo sito ora — Inizia con il piano gratuito di WP-Firewall
Se stai cercando un modo veloce e a bassa frizione per aggiungere protezione essenziale mentre valuti correzioni più profonde, il nostro piano Basic gratuito fornisce immediati strati di difesa:
- Protezione essenziale: firewall gestito, larghezza di banda illimitata, WAF, scanner antimalware e mitigazione dei 10 principali rischi OWASP.
- Mitigazione rapida: regole in tempo reale che bloccano i modelli LFI e altri vettori di sfruttamento comuni.
- Punto di ingresso senza costi per i proprietari di siti che desiderano una protezione automatizzata di base con l'opzione di aggiornare.
Inizia con il piano WP-Firewall Basic (Gratuito) qui: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
(Se hai bisogno di un livello più elevato di automazione e supporto, i nostri piani a pagamento aggiungono rimozione automatica di malware, gestione blacklist/whitelist IP, report mensili e patching virtuale automatico.)
Checklist: Elementi immediati e di follow-up
Immediato (entro poche ore)
- Metti il sito in modalità manutenzione o disconnettilo
- Sostituisci o rimuovi il tema Jannah se non puoi confermare che sia stato patchato
- Blocca i modelli di traversata sul server web/WAF
- Esegui backup e snapshot per la forense
- Scansiona alla ricerca di webshell e file sospetti
Follow-up (24–72 ore)
- Indurire PHP (open_basedir, disabilitare funzioni rischiose)
- Rigorosa gestione delle autorizzazioni dei file e disabilitare la modifica dei file
- Ruotare le credenziali del database e dell'amministratore se si sospetta una compromissione
- Applicare regole di patching virtuale (WAF) per bloccare i tentativi di sfruttamento
A lungo termine (in corso)
- Mantenere temi e plugin aggiornati
- Implementare FIM e scansione continua dei malware
- Rivedere periodicamente e indurire il codice del tema personalizzato
- Mantenere un inventario dei componenti installati e monitorare le vulnerabilità
Pensieri conclusivi
Le vulnerabilità di Local File Inclusion sono altamente attraenti per gli attaccanti perché possono essere automatizzate e spesso non richiedono autenticazione. Quando un tema popolare è colpito, migliaia di siti piccoli e medi possono essere presi di mira in pochi minuti. La migliore difesa è una combinazione di gestione proattiva (aggiornamenti e revisione del codice), controlli a strati (WAF, autorizzazioni dei file, indurimento di PHP) e rilevamento/risposta rapida.
Se gestisci siti utilizzando temi di terze parti, adotta una postura pronta per gli incidenti: backup, registrazione, piani di isolamento e un WAF affidabile che può fornire patch virtuali rapide. WP-Firewall è progettato per fornire ai proprietari di siti esattamente quelle capacità — dalle protezioni essenziali gratuite alla mitigazione automatizzata avanzata per le organizzazioni che ne hanno bisogno.
Rimani al sicuro, rimani aggiornato e se hai bisogno di aiuto per implementare patch virtuali o cercare segni di compromissione, il nostro team è pronto ad assisterti.
— Team di Sicurezza WP-Firewall
