| Nome del plugin | Learnify |
|---|---|
| Tipo di vulnerabilità | Inclusione di File Locali |
| Numero CVE | CVE-2025-60085 |
| Urgenza | Alto |
| Data di pubblicazione CVE | 2026-04-25 |
| URL di origine | CVE-2025-60085 |
Inclusione di File Locale Critica nel Tema Learnify (≤ 1.15.0) — Passi Immediati per i Proprietari di Siti WordPress
2026-04-25 | WP‑Firewall Security Team
Riepilogo
È stata divulgata una vulnerabilità critica di Inclusione di File Locale (LFI) nel tema WordPress Learnify che colpisce le versioni ≤ 1.15.0 (CVE-2025-60085). Il problema consente a attaccanti non autenticati di includere e visualizzare file locali dal server web. La vulnerabilità segnalata ha un'alta gravità (CVSS 8.1) e può essere sfruttata su larga scala — consentendo agli attaccanti di divulgare file sensibili come il file wp-config.php, file di ambiente, o qualsiasi file leggibile lato server. Questo può portare a divulgazione di credenziali, compromissione del database e takeover completo del sito a seconda dell'ambiente.
Se gestisci Learnify o siti che lo utilizzano, leggi attentamente questo post. Spieghiamo cosa significa la vulnerabilità, come gli attaccanti la abusano, come rilevare segni di sfruttamento e il processo di mitigazione e risposta agli incidenti passo dopo passo che raccomandiamo. Mostriamo anche regole pratiche per WAF e linee guida per il rafforzamento del server per ridurre immediatamente la superficie di attacco.
Cos'è l'Inclusione di File Locali (LFI)?
L'Inclusione di File Locale (LFI) è una classe di vulnerabilità nelle applicazioni web che si verifica quando l'input controllato dall'utente viene utilizzato per selezionare e includere file sul server senza una corretta validazione. In un sito basato su PHP, ad esempio, questo potrebbe apparire come:
include($_GET['template']);require_once($_REQUEST['page']);
Se un attaccante può controllare l'input che determina quale file viene incluso, può puntare l'applicazione a file locali arbitrari e costringere il server a leggere e visualizzare i loro contenuti. Conseguenze comuni:
- Divulgazione di segreti (credenziali del database, chiavi API).
- Raccolta di informazioni per preparare ulteriori attacchi.
- In ambienti che consentono wrapper pericolosi (php://input, php://filter) o dove l'inclusione di file remoti è abilitata, l'esecuzione di codice remoto (RCE) potrebbe essere possibile.
LFI può essere sfruttato utilizzando semplici stringhe di traversamento (../../../../) e tecniche di wrapper (php://filter) per leggere file in modo sicuro in contesti in cui l'inclusione diretta non stamperà il contenuto del file.
Perché questo LFI di Learnify è pericoloso
Fatti chiave su questo incidente:
- Colpisce le versioni del tema Learnify ≤ 1.15.0.
- CVE: CVE-2025-60085.
- Privilegi richiesti: nessuno (non autenticato).
- CVSS: 8.1 (Alto).
- Al momento non è disponibile alcuna patch ufficiale del fornitore (i proprietari dei siti devono applicare mitigazioni).
Perché questo particolare LFI è un problema ad alta priorità:
- Non autenticato: un attaccante non ha bisogno di credenziali per tentare di sfruttare.
- Facile da automatizzare: i controlli LFI possono essere eseguiti da scanner automatizzati su migliaia di siti.
- File di destinazione sensibili: WordPress memorizza le credenziali del database e i sali in
il file wp-config.php, rendendo questo file un obiettivo primario. - Catena: LFI può essere concatenato con altre configurazioni errate (permissivi di file deboli, directory di plugin/temi scrivibili, wrapper PHP pericolosi) per escalare a RCE o installazione di backdoor persistenti.
A causa di questi fattori, i siti che eseguono le versioni vulnerabili di Learnify dovrebbero agire immediatamente.
Dettagli tecnici (come gli attaccanti tipicamente sfruttano LFI)
Sebbene il nome esatto del parametro vulnerabile possa variare tra le versioni del tema, il modello di sfruttamento per LFI segue passaggi comuni. Di seguito spieghiamo il metodo generale che un attaccante utilizzerebbe — così puoi riconoscerlo e difenderti.
- Trovare il punto di ingresso
– L'attaccante cerca file di tema che chiamanoincludere,richiedono,file_get_contents, o funzioni simili con variabili influenzate da valori GET/POST/cookie.
– Esempio di modello rischioso:include( $theme_dir . '/' . $_GET['tpl'] ); - Traversata del percorso
– L'attaccante invia payload contenenti sequenze di traversata:
–../../../../etc/passwd
–../../../../wp-config.php
– Molti server impediscono la lettura di file restituendo errori quando si includono file binari. Gli attaccanti quindi usano wrapper. - Utilizzare wrapper per leggere file (tecnica comune)
–php://filter/convert.base64-encode/resource=path/to/file— applica un filtro per codificare in base64 un file quando incluso, rendendolo stampabile nelle risposte.
– Esempio di payload:
–?tpl=php://filter/convert.base64-encode/resource=../../../../wp-config.php - Byte nullo e trucchi di codifica
– Su versioni più vecchie di PHP e configurazioni del server, gli attaccanti possono utilizzare il byte nullo (%00) per troncare e bypassare i controlli dei suffissi. Molte versioni moderne mitigano questo, ma è ancora un payload comune nelle scansioni automatizzate:
–?tpl=../../../../wp-config.php - Passi post-sfruttamento
– Se vengono trovate le credenziali di wp-config, l'attaccante le utilizza per accedere al database o per creare un utente admin, caricare backdoor o esfiltrare ulteriori segreti.
– Se i caricamenti di file sono accessibili e non sanitizzati, l'attaccante può caricare shell PHP e ottenere RCE.
Una divulgazione responsabile ha notato che la logica di inclusione del tema Learnify non riusciva a sanitizzare correttamente i percorsi forniti dall'utente, abilitando le tecniche sopra.
Indicatori di esempio e modelli di richieste malevole da cercare
Controlla i log del tuo server web e i log del WAF per richieste contenenti questi modelli:
php://filter/convert.base64-encode/resource=....O../ripetuti (attraversamento del percorso)%00o tentativi codificati in byte nullo- Richieste a file PHP del tema con stringhe di query insolite come
?tpl=...O?pagina=...(controlla qualsiasi parametro che sembra selezionare un template) - Lunghe stringhe base64 nelle risposte (indica che i contenuti del file sono codificati e restituiti)
Esempio di riga di richiesta sospetta:
GET /wp-content/themes/learnify/somefile.php?template=php://filter/convert.base64-encode/resource=../../../../wp-config.php HTTP/1.1
Se vedi questo modello, trattalo come alta priorità — isola e indaga immediatamente.
Lista di controllo per azioni immediate (cosa fare nelle prime ore)
Se gestisci un sito che utilizza Learnify ≤1.15.0, esegui immediatamente le seguenti azioni:
- Metti il sito in modalità manutenzione (se possibile) o applica controlli di accesso temporanei (liste di autorizzazione IP) per ridurre l'esposizione.
- Passa a un tema pulito (predefinito di WordPress) o rimuovi il tema vulnerabile dalle directory pubbliche. Non lasciare attivo il tema vulnerabile.
- Se viene pubblicata una versione del tema corretta, applica immediatamente l'aggiornamento. Se non esiste ancora una patch ufficiale, procedi con le mitigazioni di seguito.
- Metti in atto una regola WAF (patching virtuale) per bloccare le richieste che contengono sequenze di traversamento o utilizzi di wrapper (vedi esempi di regole nella sezione “Regole WAF”).
- Cambia la password del database di WordPress e qualsiasi credenziale di servizio che potrebbe essere memorizzata in
il file wp-config.phpe altri file di configurazione — ma solo dopo aver assicurato backup e controlli di integrità, poiché il compromesso potrebbe persistere. - Ruota le chiavi segrete e i sali in
il file wp-config.phpdopo la remediazione. - Scansiona il sito per webshell, file sospetti e timestamp modificati.
- Ripristina da un backup pulito verificato se rilevi un compromesso.
- Aumenta il monitoraggio: abilita il monitoraggio dell'integrità dei file, i registri di audit e gli avvisi.
Se non hai la capacità tecnica di eseguire tutti i passaggi, contatta il tuo fornitore di hosting o un team di sicurezza e fornisci loro gli indicatori che hai trovato.
Come rilevare se il tuo sito è stato sfruttato
Anche se chiudi la vulnerabilità, devi verificare se è stata sfruttata in precedenza.
Controllare per:
- Nuovi o file modificati in
wp-content/caricamenti,wp-content/temi,wp-content/plugin, o altre posizioni inaspettate. - Nuovi utenti admin in WordPress (controlla
utenti wptabella). - Attività pianificate sospette (cron jobs) o voci cron non autorizzate nel database.
- Connessioni in uscita dal server verso IP sconosciuti (controlla i log del firewall/host).
- Utilizzo imprevisto elevato della CPU/IO o picchi nel traffico.
- Query di database insolite nei log delle query lente o query che utilizzano account mai visti prima.
- File PHP sconosciuti o script codificati contenenti
valutare,base64_decode, Ogzinflate.
Strumenti consigliati:
- Controlli di integrità dei file a livello di server (stile tripwire).
- Scanner di sicurezza per WordPress (preferire quelli che forniscono scansioni a livello di codice e euristiche).
- Scansione completa del malware di file e contenuti del database.
- Revisione manuale dei file critici (wp-config, .htaccess, index.php nelle cartelle di plugin/temi).
Se trovi prove di compromissione, segui i passaggi di risposta all'incidente nella sezione successiva.
Risposta agli incidenti: playbook passo dopo passo
Se confermi lo sfruttamento, procedi come segue:
- Contenere
– Metti il sito offline o blocca il traffico per prevenire ulteriori danni.
– Revoca le credenziali compromesse e le chiavi API.
– Isola il server dalla rete se possibile. - Preservare le prove
– Esegui il backup dei log (web server, database, log delle applicazioni) e delle immagini del disco.
– Non sovrascrivere i log — preserva i timestamp per l'analisi forense. - Sradicare
– Rimuovi tutte le backdoor, le shell e gli script dannosi scoperti.
– Reinstalla il core di WordPress, i plugin e i temi da fonti pulite.
– Ricostruisci i server da immagini se si sospetta una persistenza a livello di server. - Recuperare
– Ripristina da un backup pulito (effettuato prima della compromissione).
– Applica tutte le patch di sicurezza disponibili e le misure di indurimento.
– Cambia tutte le password e ruota le chiavi e i sali. - Post-recupero
– Rafforza il monitoraggio e la registrazione.
– Esegui un'analisi post-mortem: come è avvenuta la compromissione? Quali controlli hanno fallito?
– Educa il team e aggiorna il tuo piano di risposta agli incidenti. - Notificare
– Notifica le parti interessate, il fornitore di hosting e, se richiesto nella tua giurisdizione, i clienti o i regolatori.
Raccomandazioni per l'indurimento per ridurre il rischio di LFI
Anche dopo una mitigazione immediata, adotta queste difese a lungo termine:
- Principio del privilegio minimo
– Assicurati che i permessi di file e directory siano minimi. La maggior parte dei file di WordPress dovrebbe essere leggibile dal server web ma non scrivibile, eccettowp-content/caricamentiche necessita di accesso in scrittura solo per i caricamenti.
– Gli account del database utilizzati da WordPress dovrebbero avere solo i privilegi necessari. - Configurazione PHP
– Disabilitaconsenti_includere_url.
– Disabilita i wrapper non utilizzati se possibile.
3. Per gli endpoint REST API:open_basedirper limitare l'accesso di PHP alle directory.
– Disabilitaesecutivo,shell_exec,passare attraverso,sistemase non necessario. - Disabilita l'editor di plugin e temi integrato
– Aggiungi ail file wp-config.php:
define('DISALLOW_FILE_EDIT', true);
define('DISALLOW_FILE_MODS', true);// limita le installazioni/aggiornamenti di plugin/temi dall'amministratore WP - Caricamenti sicuri
– Prevenire l'esecuzione diretta di file PHP inwp-content/caricamentiaggiungendo regole del server (vedi esempio di blocco .htaccess/nginx qui sotto). - Utilizzare sali e chiavi forti e unici (ruotare in caso di remediation)
– Cambiare le chiavi invaliderà i cookie di autenticazione attivi — utile dopo un incidente. - Backup regolari e test di ripristino
– Mantenere backup frequenti offsite e testare regolarmente i ripristini. - Utilizzare aggiornamenti a fasi e revisione del codice
– Per temi/plugin in sviluppo attivo, rivedere il codice di terze parti o limitare l'uso fino a quando la postura di sicurezza non è verificata.
Regole WAF pratiche e mitigazioni a livello di server
La patch virtuale (WAF) può guadagnare tempo quando una patch ufficiale non è ancora disponibile. Di seguito sono riportate regole di esempio che puoi utilizzare nei comuni sistemi WAF o come controlli a livello di server web. Adatta e testa con attenzione — regole errate possono bloccare il traffico legittimo.
Rilevamento di modelli importanti da bloccare:
- Qualsiasi valore di parametro contenente
php://filter - Qualsiasi parametro contenente più
../sequenze - Tentativi di byte nullo
%00 - Tentativi di includere file con nomi di file sensibili (
il file wp-config.php,.ambiente,/etc/passwd)
Esempio di regola in stile ModSecurity/Core Rule Language (CRS):
# Blocca le firme di attacco LFI comuni"
Regola basata sulla posizione Nginx per negare php://filter o tentativi di traversal:
if ($request_uri ~* "(php://filter||\.\./){1,}") {
6. Apache .htaccess frammento efficace per bloccare l'esecuzione di PHP nei caricamenti:
# Proteggi i caricamenti - prevenire l'esecuzione di PHP
Un approccio più sfumato: bloccare solo le richieste sospette, consentire quelle sicure. Testare le regole in staging prima di applicarle in produzione.
Come noi di WP‑Firewall aiutiamo (firewall gestito + mitigazione)
Presso WP‑Firewall operiamo con un'assunzione: le vulnerabilità verranno scoperte in temi/plugin. La protezione più veloce e meno dirompente è la patch virtuale tramite un WAF gestito che blocca i tentativi di sfruttamento in tempo reale mentre pianifichi e applichi correzioni permanenti.
Protezioni principali che forniamo e raccomandiamo:
- Regole WAF gestite aggiornate automaticamente in risposta a nuove divulgazioni — bloccare i payload di sfruttamento (php://filter, sequenze di traversamento, tentativi di recupero
il file wp-config.php) prima che colpiscano PHP. - Scansione malware e rilevamento delle firme per rilevare webshell e modifiche sospette subito dopo un tentativo di sfruttamento.
- Monitoraggio dell'integrità dei file e scansioni giornaliere per rilevare cambiamenti imprevisti nei file.
- Allerta sugli incidenti e supporto per aiutare a classificare i risultati e implementare mitigazioni.
- Capacità di patch virtuale in modo che anche se un tema non ha una patch ufficiale, puoi continuare le operazioni mentre il rischio è ridotto.
Raccomandiamo di abbinare la patch virtuale immediata con i passaggi di indurimento del server descritti sopra, ruotando le credenziali e implementando un monitoraggio continuo.
Esempi di regex di rilevamento e suggerimenti per l'analisi dei log
Tieni d'occhio i log del server web e implementa avvisi su questi modelli:
Regex (non sensibile al maiuscolo/minuscolo) per rilevare probabili probe LFI:
(?i)(phpfilter|php://filter|(\.\./){2,}|(\.\.\\){2,}||wp-config\.php|/etc/passwd)
Voci di log che attivano avvisi:
- GET /wp-content/themes/learnify/… ?…=php://filter/convert.base64-encode/resource=../../../../wp-config.php
- Qualsiasi richiesta che utilizza
php://involucri - Richieste che restituiscono 200 con stringhe codificate in base64 — base64 nelle pagine HTML è spesso un indicatore di letture di contenuto dei file.
Imposta un lavoro automatizzato per scansionare i log quotidianamente per questi modelli e notificare gli amministratori.
Esempio di test sicuro per controllare la vulnerabilità (solo per i proprietari del sito)
Se sei il proprietario del sito e hai bisogno di testare se la tua installazione di Learnify è vulnerabile, segui questa procedura di controllo sicura e in sola lettura. Non tentare di sfruttare i siti di altre persone.
- Usa una richiesta non distruttiva
php://filterche tenta semplicemente di codificare in base64 un file riconosciuto (ad es.,readme.htmlnella directory del tema). - Costruisci una richiesta simile a:
GET /wp-content/themes/learnify/index.php?tpl=php://filter/convert.base64-encode/resource=inc/readme.html
- Se la risposta contiene una stringa base64 che si decodifica nel contenuto del file, la funzione in quel tema è vulnerabile all'abuso del modello di inclusione. Smetti di testare e procedi con la mitigazione.
Importante: Testa solo sui siti che possiedi o gestisci. Non eseguire test su siti di terze parti.
Albero decisionale per la rimediabilità: Aggiorna vs Mitigazione temporanea vs Rimuovi
- Se è disponibile un tema ufficiale corretto: aggiorna immediatamente, quindi segui la checklist di verifica (scansione dell'integrità del file, rotazioni delle password).
- Se non esiste una patch ufficiale:
- Rimuovi il tema dall'uso attivo (passa a un tema predefinito).
- Applica regole WAF e restrizioni del server per bloccare i tentativi di sfruttamento.
- Collabora con il fornitore del tema per la tempistica o considera di sostituire il tema con un'alternativa mantenuta.
- Se non puoi rimuovere il tema per motivi aziendali:
- Metti il sito dietro controlli di accesso rigorosi (whitelist IP) per l'accesso amministrativo.
- Applica regole WAF rigorose e consenti solo funzionalità minime.
- Pianifica monitoraggio dedicato e frequenti scansioni di integrità.
Dopo la rimediazione: convalida e monitora
Dopo aver applicato le correzioni, convalida il tuo ambiente:
- Riesegui gli scanner automatici.
- Verifica che non siano presenti account admin o attività pianificate inaspettati.
- Controlla eventuali connessioni di rete inaspettate o modifiche DNS.
- Rivedi i backup per indicatori precoci di compromissione (assicurati che i backup siano puliti).
- Continua il monitoraggio intensificato per almeno 30 giorni dopo la rimediazione.
Domande frequenti (FAQ)
- D: LFI può portare all'esecuzione di codice remoto?
- R: LFI stesso è una vulnerabilità di inclusione/lettura di file. L'esecuzione di codice remoto può essere possibile se l'attaccante può includere un file che può controllare (ad es., un file PHP caricato) o concatenare l'LFI con altre configurazioni errate (directory scrivibili, wrapper pericolosi o plugin dannosi).
- D: Il mio sito utilizza un tema child di Learnify — sono colpito?
- R: Possibilmente. I temi child ereditano il codice core dai temi genitori. Se la logica vulnerabile esiste nel codice del tema genitore e il tema genitore è Learnify ≤1.15.0, è probabile che tu sia colpito. Controlla la versione del tema genitore e applica le mitigazioni.
- D: Ho corretto il tema — devo ancora ruotare le credenziali?
- R: Sì. Se c'è qualche possibilità che il sito sia stato esposto, ruota le chiavi, le password del database e i token API utilizzati sul sito. La correzione previene future sfruttamenti ma non rimuove le compromissioni avvenute in precedenza.
- D: Come posso essere avvisato di vulnerabilità simili in futuro?
- R: Iscriviti a un feed di sicurezza affidabile e mantieni aggiornati i tuoi segni WAF e scanner malware. Implementa il monitoraggio automatico delle vulnerabilità per i temi e i plugin installati.
Inizia a proteggere il tuo sito oggi — Piano gratuito disponibile
Se desideri uno strato di protezione immediato e diretto mentre esegui i passaggi di rimediazione tecnica sopra, il nostro piano gratuito gestito fornisce difese essenziali per i siti WordPress. Il piano gratuito include un firewall gestito con patch virtuali, un firewall per applicazioni web (WAF), scansione malware, protezione della larghezza di banda illimitata e mitigazione per i rischi OWASP Top 10. Iscriversi è semplice e veloce: puoi iniziare a bloccare i tentativi di sfruttamento in pochi minuti.
Scopri di più o registrati per il piano gratuito qui
Opzioni di upgrade: offriamo anche piani a pagamento accessibili che aggiungono rimozione automatica di malware, blacklist/whitelist IP, report di sicurezza mensili e servizi gestiti avanzati per aziende e agenzie. Se gestisci più siti o richiedi supporto attivo per la rimediazione, i nostri piani di livello superiore offrono un approccio completo e gestito alla sicurezza.
Considerazioni finali dagli esperti di sicurezza di WP‑Firewall
Questa divulgazione LFI di Learnify è un promemoria che qualsiasi tema o plugin può introdurre debolezze critiche. Gli aspetti più importanti per rispondere a incidenti come questo sono la velocità e la completezza:
- Velocità nell'applicare le mitigazioni (patch virtuali e rimozione temporanea).
- Completezza nell'indagine (l'attaccante ha ottenuto qualcosa? cosa è stato accesso?).
- Miglioramenti a lungo termine (indurimento, monitoraggio, minimo privilegio).
Se hai bisogno di un partner che possa gestire le patch virtuali e fornire rilevamento e risposta continui per la tua flotta di WordPress, i servizi gestiti di WP‑Firewall sono progettati per fare esattamente questo: proteggere il traffico in tempo reale, cercare indicatori post-sfruttamento e aiutarti a recuperare con il minimo disturbo per l'attività.
Se gestisci più siti WordPress, ora è il momento di rivedere il tuo inventario di temi, confermare le versioni e applicare i passaggi sopra. Se hai bisogno di aiuto per triage di indicatori specifici, pubblichiamo guide dettagliate per la remediation e forniamo supporto ai clienti che richiedono assistenza accelerata. Rimani vigile e tratta qualsiasi probe LFI come potenzialmente serio: gli attaccanti automatizzano questi controlli e un sito sfruttabile è a reale rischio.
Appendice A: Lista di controllo rapida (copia/incolla)
- Identifica se Learnify ≤ 1.15.0 è installato.
- Passa a un tema diverso o disattiva Learnify.
- Applica regola(e) WAF per bloccare tentativi di php://filter e traversata di percorso.
- Scansiona per webshell e modifiche non autorizzate ai file.
- Ruota le credenziali del DB e i sali di WP.
- Ripristina da un backup pulito se viene rilevata una compromissione.
- Implementa l'indurimento delle autorizzazioni dei file.
- Abilita il monitoraggio e l'allerta dell'integrità dei file.
- Monitora i log per 30 giorni dopo la remediation.
Appendice B: Risorse e riferimenti aggiuntivi
- CVE-2025-60085 (riferimento avviso pubblico)
- Migliori pratiche di indurimento PHP
- Manuale di sicurezza di WordPress (guida per amministratori di sito)
- Guida all'ottimizzazione WAF e al testing delle regole
(Se desideri aiuto nell'implementare regole WAF specifiche o nell'eseguire una scansione di vulnerabilità sicura nel tuo ambiente, il nostro team di sicurezza di WP‑Firewall può assisterti. Offriamo opzioni sia self-service che gestite su misura per siti di tutte le dimensioni.)
Grazie per prendere sul serio la sicurezza. Se hai domande sui passaggi sopra o desideri indicazioni specifiche per il tuo sito, contatta il supporto di WP‑Firewall o iscriviti al piano gratuito per ottenere una protezione immediata e gestita: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
