| Nome del plugin | Tutor LMS |
|---|---|
| Tipo di vulnerabilità | Iniezione SQL |
| Numero CVE | CVE-2026-6080 |
| Urgenza | Alto |
| Data di pubblicazione CVE | 2026-04-17 |
| URL di origine | CVE-2026-6080 |
Comprendere e mitigare l'iniezione SQL di Tutor LMS <= 3.9.8 (CVE-2026-6080) — Una prospettiva di WP‑Firewall
Il 17 aprile 2026 è stata divulgata una vulnerabilità che colpisce Tutor LMS (versioni <= 3.9.8): un'iniezione SQL autenticata (amministratore) tramite il parametro parametro. Il problema è stato assegnato a CVE‑2026‑6080 ed è stato corretto in Tutor LMS 3.9.9. Gli autori della patch hanno valutato il problema con un CVSS di 7.6 — un punteggio serio guidato principalmente dal potenziale di manipolazione del database — ma il contesto è importante: lo sfruttamento richiede un account con privilegi di amministratore.
Come team dietro WP‑Firewall (un firewall per applicazioni web WordPress e servizio di sicurezza), esaminiamo questo tipo di problema attraverso due lenti: (1) come può essere sfruttato e quale è l'impatto reale per i proprietari dei siti, e (2) quali passi pratici puoi intraprendere immediatamente per mitigare il rischio e indurire il tuo sito. Di seguito forniamo una spiegazione tecnica, indicatori di rilevamento, un piano di risposta, indicazioni per la configurazione di WAF/patch virtuali (generali e indipendenti dal fornitore) e indicazioni per la prevenzione orientate sia ai proprietari dei siti che agli sviluppatori di plugin.
Questa guida è scritta per amministratori di siti, sviluppatori e professionisti della sicurezza che gestiscono siti WordPress. Evita il codice di sfruttamento e si concentra su rilevamento, mitigazione e pratiche operative sicure.
Sintesi
- Vulnerabilità: Iniezione SQL in Tutor LMS tramite un controllo admin autenticato
parametroparametro. - Versioni interessate: Tutor LMS <= 3.9.8.
- Versione corretta: Tutor LMS 3.9.9.
- CVE: CVE‑2026‑6080.
- Contesto di rischio: Richiede privilegi di amministratore per invocare la funzionalità vulnerabile. Questo limita lo sfruttamento remoto di massa, ma qualsiasi compromissione di un account admin aumenta drammaticamente la superficie di attacco.
- Azioni immediate: Aggiorna a 3.9.9 (o successivo). Se l'aggiornamento non può essere applicato immediatamente, applica controlli compensativi: patch virtuali (WAF), limita l'accesso admin, applica autenticazione forte e controlla i log per attività sospette.
Cos'è l'iniezione SQL e perché è importante
L'iniezione SQL (SQLi) si verifica quando un attaccante può manipolare l'input a una query di database in modo che vengano eseguiti comandi SQL non intenzionati. A seconda della query vulnerabile, un attaccante può leggere dati riservati, alterare dati o persino modificare oggetti di schema.
In questa vulnerabilità di Tutor LMS, un endpoint accessibile solo agli amministratori accettava un parametro parametro che veniva utilizzato in modo non sicuro in una query SQL. Poiché questa azione si verifica in un contesto amministrativo, gli attaccanti devono prima ottenere credenziali admin o sfruttare una sessione admin. Anche se questo requisito riduce la probabilità di sfruttamento opportunistico su larga scala, le conseguenze rimangono gravi se un account admin viene compromesso o se insider malevoli abusano dei loro privilegi.
Gli impatti includono (ma non sono limitati a):
- Estrazione di dati sensibili dal database di WordPress (utenti, indirizzi email, progresso dei corsi, metadati di pagamento).
- Iniezione di contenuti malevoli persistenti nelle tabelle del database (contenuto dei post, opzioni) che abilitano ulteriori abusi.
- Creazione di nuovi utenti amministrativi o modifica di account esistenti se le query modificano tabelle rilevanti.
- Movimento laterale e persistenza piantando backdoor (opzioni malevole, file di plugin/tema alterati) che sopravvivono agli aggiornamenti del plugin se non puliti.
Perché CVSS 7.6 — e cosa significa realmente
Il punteggio base CVSS riflette la gravità tecnica della vulnerabilità indipendentemente dalle specifiche mitigazioni ambientali. Un 7.6 indica alta gravità tecnica principalmente a causa del potenziale compromesso del database.
Punti contestuali importanti:
- Vettore di attacco: Locale alle interfacce amministrative (non anonimo remoto).
- Privilegi richiesti: Amministratore (richiesta di alto privilegio).
- Ambito: Lo sfruttamento può influenzare la riservatezza e l'integrità del database.
- Mondo reale: Poiché sono richiesti privilegi di amministratore, il modello di minaccia riguarda principalmente account amministrativi compromessi, amministratori malevoli o siti in cui le sessioni di amministratore possono essere rubate (ad esempio, tramite cookie rubati, phishing).
Quindi, sebbene la vulnerabilità sia tecnicamente seria, per molti siti è meno probabile che venga sfruttata su larga scala rispetto a un RCE realmente non autenticato. Tuttavia, qualsiasi vulnerabilità che consente interazioni SQL merita attenzione urgente.
Come gli attaccanti potrebbero sfruttare questo (livello alto, nessun codice di sfruttamento)
Flusso di attacco:
- L'attaccante ottiene credenziali di amministratore o hijacks una sessione di amministratore (phishing, credential stuffing, brute force, macchina locale compromessa).
- L'attaccante accede all'endpoint amministrativo che accetta il
parametroparametro (ad esempio, una routine di analisi, report o esportazione). - IL
parametroIl parametro viene inserito in un'istruzione SQL senza sufficiente parametrizzazione o sanitizzazione. L'input creato manipola l'esecuzione SQL per rivelare dati o modificare dati. - L'attaccante estrae dati, pianta meccanismi di persistenza, crea nuovi utenti amministratori o corrompe tabelle per coprire le tracce.
Poiché questo richiede un passaggio da amministratore, la vulnerabilità è spesso utilizzata in attacchi mirati contro siti specifici di alto valore — ad esempio, istituzioni che utilizzano Tutor LMS per corsi a pagamento, siti di abbonamento o siti che memorizzano PII.
Indicatori di compromissione (IoC) da cercare
Cerca questi segni nei log e nei database. Nessuno è definitivo da solo, ma insieme possono indicare attività malevole legata a SQLi.
- Registri del server web:
- Richieste POST/GET da utenti amministrativi a percorsi amministrativi di Tutor LMS dove
parametroo altri parametri contengono stringhe insolite o payload più lunghi del normale. - Richieste con tentativi ripetitivi o variazioni di parametro da un singolo IP.
- Richieste POST/GET da utenti amministrativi a percorsi amministrativi di Tutor LMS dove
- Log di WordPress:
- Cambiamenti improvvisi negli account utente (nuovi amministratori creati rapidamente).
- Ripristini o modifiche della password inaspettati, o creazione di account insoliti.
- Modifiche a
opzioni_wpche sembrano sospette (opzioni autoloaded sconosciute, voci di plugin/tema aggiunte).
- Anomalie nel database:
- Nuove righe in tabelle critiche (wp_users, wp_posts) dove i timestamp o i contenuti non erano attesi.
- Query SELECT inaspettate che riflettono UNION contro information_schema o query a lungo termine.
- Comportamento del sito:
- Pagine strane che appaiono, contenuti spam, visitatori reindirizzati.
- Notifiche dal tuo host o strumenti di scansione riguardo a modifiche sospette ai file.
- Strumenti di sicurezza/scansione:
- Scanner malware che segnalano file di plugin/tema modificati.
- Avvisi ripetuti legati al plugin Tutor LMS.
Se trovi uno di questi indicatori, tratta il sito come potenzialmente compromesso fino a prova contraria e avvia un processo di contenimento e ripristino.
Passi immediati di mitigazione (lista di controllo operativa)
Se gestisci uno o più siti WordPress con Tutor LMS, prendi questi passi immediati.
- Aggiorna il plugin
- Mitigazione primaria: aggiorna Tutor LMS alla versione 3.9.9 o successiva il prima possibile.
- Se non puoi aggiornare immediatamente: applica controlli compensativi
- Patch virtuale tramite WAF: implementa regole WAF per bloccare payload sospetti che mirano al
parametroparametro e ad altri endpoint di amministrazione (vedi le linee guida WAF qui sotto). - Limitare l'accesso: limita l'accesso degli amministratori per IP (se possibile) o tramite VPN per le pagine di amministrazione.
- Disabilita il plugin (temporaneamente): se la funzionalità vulnerabile non è necessaria, considera di disabilitare il plugin Tutor LMS fino a quando non viene applicata una patch.
- Riduci i privilegi: controlla gli account amministratori — rimuovi gli amministratori non utilizzati e ruota le credenziali per tutti gli amministratori attivi.
- Patch virtuale tramite WAF: implementa regole WAF per bloccare payload sospetti che mirano al
- Rafforzare l'autenticazione
- Imporre password forti e credenziali uniche.
- Implementare l'autenticazione a due fattori (2FA) per tutti gli account admin.
- Considerare l'accesso unico o altre forme di autenticazione a livello aziendale per grandi organizzazioni.
- Audit e monitoraggio
- Esaminare i log del server web e i log delle attività di WordPress per richieste admin sospette.
- Eseguire una scansione completa del sito per malware e integrità (file e database).
- Controllare le modifiche recenti ai file core, plugin e tema.
- Rotazione delle credenziali
- Se c'è qualche sospetto di compromissione, ruotare le credenziali del database (e ospitarle in modo sicuro), le chiavi API e le password admin.
- Aggiornare eventuali connessioni memorizzate (servizi esterni) che utilizzano le credenziali del sito.
- Backup
- Assicurarsi di avere backup recenti e puliti. Se si sospetta una compromissione, isolare i backup creati prima del presunto momento di compromissione.
- Notificare le parti interessate
- Informare il fornitore di hosting, il contatto per la sicurezza e gli stakeholder secondo necessità.
Raccomandazioni specifiche per la mitigazione di WP‑Firewall
Presso WP‑Firewall forniamo una protezione a più livelli che aiuta sia a prevenire che a mitigare problemi come questo. Se stai utilizzando un firewall gestito o un WAF (compreso il nostro), ecco i controlli pratici di WAF/patching virtuale da implementare:
- Patching virtuale (blocco per parametro)
- Bloccare o convalidare il
parametroparametro sugli endpoint admin di Tutor LMS. Consentire solo formati di data sicuri (ad es., YYYY-MM-DD) e rifiutare qualsiasi cosa che contenga parole chiave SQL o caratteri speciali oltre a cifre, trattini e barre. - Applicare un limite di lunghezza rigoroso (ad es., 10–20 caratteri) per gli input di data.
- Rifiutare input che contengono codifica percentuale di apostrofi singoli, punti e virgola o commenti tipici nei payload SQL.
- Bloccare o convalidare il
- Blocco basato su pattern
- Bloccare le richieste contenenti metacaratteri SQL o parole chiave nei parametri di query che non dovrebbero contenerli.
- Limitare il numero di tentativi di modifica dei parametri ripetuti dallo stesso IP.
- Controlli di autenticazione e capacità
- Forzare l'accesso agli endpoint amministrativi solo da sessioni admin verificate e intervalli di IP admin noti, dove possibile.
- Monitorare le sessioni admin utilizzate da nuove posizioni geografiche.
- Rilevamento delle anomalie
- Monitorare i picchi nel tempo di query del database o nuove query a lungo termine provenienti da endpoint di plugin.
- Modello di patch virtuale (regola pseudo)
- Quanto segue è una regola WAF concettuale e indipendente dal fornitore che puoi mappare nel tuo WAF:
-
- Obiettivo: Richieste a percorsi admin contenenti ‘/tutor/’ o noti endpoint admin di Tutor LMS.
- Condizione A: Parametro
parametropresente e non corrispondente a regex^\d{4}(-\d{2}(-\d{2})?)?$(consentire yyyy o yyyy-mm o yyyy-mm-dd). - Condizione B: Il parametro contiene caratteri diversi da 0-9, -, / (bloccare).
- Condizione C: Il parametro contiene parole chiave SQL (case-insensitive): SELECT, UNION, INFORMATION_SCHEMA, DROP (bloccare).
- Azione: Bloccare la richiesta e registrare intestazioni/payload completi per revisione forense.
- Nota: Non applicare blocchi di parole chiave SQL troppo ampi agli endpoint rivolti agli utenti dove l'input di testo legittimo può contenere queste parole. Limitare agli endpoint specifici per admin/plugin.
- Patch virtuale tramite filtraggio positivo (whitelisting)
- Dove possibile, preferire il whitelisting (consentire solo un formato di data rigoroso) rispetto alle liste di blocco. Le liste bianche sono più resistenti all'evasione.
- Raccomandazioni di indurimento che WP‑Firewall imporrà o assisterà:
- Applicare 2FA su tutti gli account admin.
- Proteggere wp-login e wp-admin utilizzando un ulteriore controllo degli accessi (restrizione IP o captcha).
- Abilita scans automatizzati frequenti e controlli di integrità dei file.
- Blocca automaticamente gli IP con attività sospette ripetute da amministratori.
Se sei un utente gratuito di WP‑Firewall, il nostro firewall gestito include regole WAF di base e scansioni malware che sono efficaci come primo strato di mitigazione mentre coordini gli aggiornamenti dei plugin.
Piano di risposta agli incidenti (passo dopo passo)
Se sospetti un'esploitazione o l'hai confermata, segui questa procedura escalata.
- Contenere
- Metti il sito offline o attivalo in modalità manutenzione se i dati sono sensibili.
- Disabilita temporaneamente il plugin vulnerabile (Tutor LMS) se fattibile e sicuro per i tuoi utenti.
- Blocca gli indirizzi IP degli attaccanti sospetti al firewall.
- Preservare le prove
- Conserva i log del server web e del database — fai copie sicure.
- Cattura uno snapshot della memoria se l'host lo supporta e l'incidente è grave.
- Indagare
- Cerca nei log accessi agli endpoint di amministrazione e anomalie intorno al momento della sospetta esploitazione.
- Cerca utenti amministratori creati/modificati, scritture nel database inaspettate o nuovi compiti programmati.
- Scansiona i file per file PHP recentemente modificati o nuovi, codice sospetto o web shell.
- Sradicare
- Rimuovi backdoor e file sospetti.
- Pulisci o ricostruisci componenti compromessi da fonti affidabili e riapplica aggiornamenti di sicurezza.
- Ruota tutte le credenziali per gli utenti amministratori, gli account del database e eventuali token.
- Recuperare
- Ripristina da backup noti e buoni se necessario.
- Riapplica aggiornamenti e riattiva i plugin solo dopo aver verificato la salute.
- Rivedi e riporta
- Conduci una revisione post-incidente per determinare la causa principale, la cronologia e l'impatto.
- Documenta le lezioni apprese e migliora i controlli di rilevamento e prevenzione.
- Informare le parti interessate
- A seconda degli obblighi legali o contrattuali, informare i clienti e le autorità di regolamentazione se i dati degli utenti sono stati esposti.
Rilevamento e monitoraggio — query e ricerche pratiche
Di seguito sono riportate ricerche sicure e pratiche per aiutarti a rilevare attività sospette. Questi sono suggerimenti di alto livello piuttosto che indicatori C2 specifici:
- Cerca nei log di accesso del server web richieste a percorsi admin con
data=o parametri simili. Ordina per frequenza e anomalie. - Nei log di attività di WordPress, controlla per:
- Creazioni di nuovi utenti con ruolo di amministratore in un breve intervallo di tempo.
- Richieste di reimpostazione della password e cambi di email per account admin.
- Monitora i log delle query del database (o abilita temporaneamente il logging delle query generali) e cerca:
- Query che includono parole chiave come INFORMATION_SCHEMA, UNION, o /* — sono spesso presenti nei tentativi di SQLi.
- Query a lungo termine e nuovi tipi di query contro tabelle contenenti dati sensibili.
- Utilizza il monitoraggio dell'integrità dei file per rilevare file di plugin o temi modificati (confronta con i checksum del pacchetto originale).
Se questi controlli indicano una potenziale compromissione, escalare al piano di risposta agli incidenti sopra.
Come gli sviluppatori di plugin avrebbero dovuto prevenire questo
Questa vulnerabilità evidenzia comuni omissioni nella codifica sicura. Se sei uno sviluppatore di plugin, segui queste pratiche:
- Sanitizzazione dei dati e parametrizzazione
- Utilizza sempre query parametrizzate (per WordPress, $wpdb->prepare o dichiarazioni preparate utilizzando l'astrazione del database).
- Evita di concatenare input grezzi in stringhe SQL.
- Validazione dell'input
- Utilizza una sanitizzazione e validazione rigorose sugli input, specialmente per i parametri che dovrebbero seguire un formato noto (ad esempio, utilizza regex o funzioni di sanitizzazione WP).
- Utilizzare lo schema dell'API REST di WordPress per definire e imporre i tipi di parametro.
- Controlli di capacità
- Verificare le capacità dell'utente utilizzando controlli delle capacità (ad es., current_user_can()) prima di eseguire query sensibili.
- Assicurarsi che le azioni eseguite nei contesti di amministrazione richiedano il minor privilegio necessario.
- Nonces e protezione CSRF
- Proteggere le azioni di amministrazione e gli endpoint AJAX con nonce e controlli delle capacità appropriati.
- Registrazione e monitoraggio
- Registrare tentativi di input sospetti o malformati per la revisione.
- Evitare di registrare eccessivamente dati sensibili (proteggere la privacy degli utenti).
- Revisione della sicurezza e fuzzing
- Includere test di sicurezza nella pipeline di rilascio (analisi statica, scansione dinamica, fuzzing degli input degli utenti).
Misure preventive a lungo termine per i proprietari del sito
- Mantenere un ciclo di vita dei plugin rigoroso: rimuovere i plugin non utilizzati e mantenere tutto aggiornato.
- Limitare il numero di amministratori: utilizzare ruoli con capacità minime necessarie per le attività quotidiane.
- Applicare politiche di 2FA e password forti per tutti gli account di livello amministrativo.
- Abilitare backup automatici archiviati off-site e testare regolarmente il ripristino.
- Utilizzare ambienti di staging per testare gli aggiornamenti dei plugin prima del deployment in produzione.
- Pianificare revisioni di sicurezza periodiche e modellazione delle minacce, soprattutto se il tuo sito gestisce pagamenti, dati degli studenti o PII.
- Mantenere un playbook per incidenti di sicurezza e contatti (supporto host, professionisti della sicurezza).
Perché la correzione rapida è importante anche quando un exploit richiede credenziali di amministratore
Una vulnerabilità che richiede credenziali di amministratore può comunque essere un rischio ad alto impatto. Gli account amministrativi possono essere ottenuti tramite phishing, riutilizzo delle credenziali, macchine di sviluppatori compromesse, integrazioni di terze parti vulnerabili e dirottamento di sessioni. Gli attaccanti spesso concatenano le vulnerabilità — ad esempio, possono compromettere un account a basso privilegio con un bug separato e poi escalare tramite una debolezza riservata agli amministratori. La correzione rimuove uno dei passaggi su cui gli attaccanti fanno affidamento in tali catene.
Inoltre, i difensori possono impedire agli attaccanti di stabilire persistenza in primo luogo chiudendo i vettori vulnerabili noti e applicando controlli compensativi.
Considerazioni sui campioni di regole WAF (pratiche, indipendenti dal fornitore)
- Limitare la regola solo agli endpoint di amministrazione di Tutor LMS (ridurre i falsi positivi).
- Whitelist valido
parametroformati da soli (ad es., yyyy, yyyy-mm, yyyy-mm-dd). - Rifiuta o sanitizza qualsiasi payload che include:
- Single quotes (‘), double dashes (–), semicolons (;), URL‑encoded single quotes (%27) — specifically when they appear in the
parametroparametro. - parole chiave SQL (INFORMATION_SCHEMA, UNION, SELECT, DROP) in parametri che non dovrebbero contenerli.
- Lunghezza eccessiva oltre la dimensione del token prevista.
- Single quotes (‘), double dashes (–), semicolons (;), URL‑encoded single quotes (%27) — specifically when they appear in the
- Registra le richieste bloccate e attiva un avviso all'amministratore del sito per la revisione.
- Aggiungi regole temporanee che aumentano la sensibilità durante le finestre ad alto rischio (ad es., lanci di alto profilo).
Ricorda: l'approccio più robusto è una whitelist di formati validi piuttosto che una blacklist.
Lista di controllo per la verifica post-mitigazione
- Tutor LMS è aggiornato alla versione 3.9.9 o successiva in tutti gli ambienti.
- Le regole WAF sono state implementate e testate (verifica che non blocchino attività legittime dell'amministratore).
- Gli account admin hanno 2FA abilitato e gli admin non utilizzati sono stati rimossi.
- Le credenziali del database sono state ruotate se si sospettava una compromissione.
- I controlli di integrità dei file non mostrano modifiche non autorizzate.
- I backup sono conosciuti come buoni e il ripristino è stato testato.
- Il monitoraggio/avviso per anomalie degli endpoint admin è operativo.
Scenari e indicazioni del mondo reale
- Siti piccoli (singolo admin, basso traffico): Aggiorna rapidamente il plugin, abilita 2FA e esegui una scansione malware/integrità dei file. Considera di utilizzare le protezioni del piano gratuito gestito di WP‑Firewall durante la patch.
- Siti di medie dimensioni (più amministratori, corsi a pagamento): Coordinare una finestra di manutenzione, aggiornare il plugin attraverso le istanze multisite se utilizzato, ruotare le credenziali e eseguire un audit approfondito del database e degli account utente.
- Impresa (integrazioni personalizzate, integratori LMS): Attivare la risposta agli incidenti, mettere il sito offline se necessario, preservare i log e applicare patch virtuali al perimetro mentre si distribuiscono correzioni per gli sviluppatori attraverso gli ambienti.
Una parola pratica e amichevole da WP‑Firewall
Sappiamo che la sicurezza non è un pensiero secondario — è un lavoro operativo che deve adattarsi alle tue finestre di aggiornamento, ai programmi aziendali e agli impegni con i clienti. Le vulnerabilità come il Tutor LMS SQLi sottolineano perché le difese a strati e la preparazione operativa siano importanti. Aggiorna frequentemente i tuoi plugin, limita l'accesso degli amministratori e utilizza forti protezioni perimetrali per guadagnare tempo quando sono necessarie patch urgenti.
Inizia a proteggere il tuo sito oggi — piano WP‑Firewall Basic (Gratuito)
Titolo: Proteggi rapidamente il tuo WordPress con WP‑Firewall Basic (Gratuito)
Se desideri una protezione immediata e senza costi mentre coordini aggiornamenti e indurimenti, il piano Basic (Gratuito) di WP‑Firewall ti offre capacità di sicurezza essenziali senza complessità. Il piano gratuito include un firewall gestito, copertura del firewall per applicazioni web (WAF), larghezza di banda illimitata, uno scanner malware e mitigazione dei rischi OWASP Top 10 — un primo strato pratico di difesa contro vulnerabilità come l'iniezione SQL di Tutor LMS. Iscriviti e inizia rapidamente a eseguire regole protettive e scansioni: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Se hai bisogno di più funzionalità, i nostri piani Standard e Pro aggiungono remediation automatizzata e servizi professionali su misura per siti e aziende in crescita.
Considerazioni finali
CVE‑2026‑6080 è un chiaro promemoria che anche le vulnerabilità riservate agli amministratori possono avere conseguenze significative. La correzione più rapida e pulita è aggiornare il plugin alla versione 3.9.9 o successiva. Se non puoi aggiornare immediatamente, applica patch virtuali, limita l'accesso degli amministratori, rafforza l'autenticazione e monitora i log per attività sospette. Combina queste pratiche con pratiche a lungo termine — igiene rigorosa dei plugin, ruoli amministrativi limitati e monitoraggio continuo — e ridurrai significativamente il rischio di compromissione.
Se desideri assistenza nell'implementazione di patch virtuali, nella messa a punto delle regole WAF o nell'esecuzione di un audit degli incidenti, il team di WP‑Firewall è disponibile per assisterti. La sicurezza è uno sport di squadra: la rilevazione tempestiva, il contenimento rapido e il successivo indurimento sono più importanti di qualsiasi correzione puntuale.
Appendice — riferimento rapido
- Colpito: Tutor LMS <= 3.9.8
- Corretto: Tutor LMS 3.9.9+
- CVE: CVE‑2026‑6080
- CVSS: 7.6
- Privilegio richiesto: Amministratore (autenticato)
- Azione immediata: Aggiorna il plugin a 3.9.9+, abilita 2FA, applica la regola WAF per la whitelist
parametroformati, rivedi gli account amministrativi e i log.
Se desideri, WP‑Firewall può fornire un breve elenco di controllo personalizzato per il tuo sito (suggerimenti per l'indurimento IP, esempi di regole WAF personalizzate per il tuo stack di hosting e un piano di aggiornamento a fasi). Facci sapere semplicemente quale ambiente utilizzi (WP singolo, multisite, host gestito) e prepareremo un piano d'azione conciso.
