| Nome del plugin | Commenti non risposti DX |
|---|---|
| Tipo di vulnerabilità | CSRF |
| Numero CVE | CVE-2026-4138 |
| Urgenza | Basso |
| Data di pubblicazione CVE | 2026-04-22 |
| URL di origine | CVE-2026-4138 |
Cross‑Site Request Forgery (CSRF) nei commenti non risposti DX (<= 1.7) — Cosa devono sapere i proprietari di siti WordPress
Autore: Team di sicurezza WP-Firewall
Data: 2026-04-22
Breve riassunto: Una vulnerabilità CSRF (CVE‑2026‑4138) che colpisce il plugin “DX Unanswered Comments” (versioni <= 1.7) è stata pubblicata il 21 aprile 2026. La debolezza può consentire a un attaccante di ingannare un utente privilegiato per eseguire azioni indesiderate che modificano lo stato mentre è autenticato. Non è disponibile alcuna patch ufficiale al momento della pubblicazione. Questo avviso spiega i dettagli tecnici, gli scenari di sfruttamento, i metodi di rilevamento e le mitigazioni sia a breve che a lungo termine — dalla messa in sicurezza immediata alla patch virtuale con WP‑Firewall.
Sommario
- Contesto e sfondo
- Cos'è il CSRF e perché è importante per WordPress
- Riepilogo del problema dei commenti non risposti DX (CVE‑2026‑4138)
- Come un attaccante potrebbe sfruttare questa vulnerabilità (scenari)
- Chi è a rischio
- Azioni immediate che ogni proprietario di sito dovrebbe intraprendere (passo dopo passo)
- Segni di rilevamento e forensi da tenere d'occhio
- Raccomandazioni per la messa in sicurezza e correzioni per sviluppatori
- Come un WAF gestito / patch virtuale aiuta (cosa fornisce WP‑Firewall)
- Esempi di modelli di regole WAF e mitigazioni a livello di server
- Posizione di sicurezza a lungo termine: politiche, monitoraggio, backup e recupero
- Considerazioni speciali per fornitori di hosting e agenzie
- Proteggi il tuo sito con WP‑Firewall: dettagli del piano gratuito e come aiuta
- Riepilogo e prossimi passi raccomandati
Contesto e sfondo
Una vulnerabilità Cross‑Site Request Forgery (CSRF) recentemente pubblicata — tracciata come CVE‑2026‑4138 — colpisce il plugin WordPress “DX Unanswered Comments” nelle versioni fino e comprese 1.7. L'avviso pubblico nota che il plugin espone azioni che modificano lo stato senza una valida verifica della richiesta (controlli nonce/capacità), consentendo a un attaccante remoto di creare una pagina o un link malevolo che, quando visitato o cliccato da un utente privilegiato (ad esempio, un amministratore autenticato), attiva operazioni indesiderate sul sito.
È importante:
- Punteggio CVSS: 4.3 (basso).
- Privilegio richiesto: l'attacco può essere avviato da un attore non autenticato, ma lo sfruttamento riuscito richiede l'interazione di un utente privilegiato autenticato (ad esempio, cliccando su un link o caricando una pagina creata mentre è connesso).
- Versione patchata: nessuna annunciata al momento della scrittura.
- Pubblicato: 21 Apr 2026.
Sebbene la gravità sia classificata come bassa, i problemi di CSRF sono comunemente abusati come parte di attacchi a più fasi — possono essere combinati con ingegneria sociale o phishing per escalare in compromessi più ampi. Poiché non esiste una patch ufficiale al momento della divulgazione della vulnerabilità, i proprietari dei siti devono agire per ridurre immediatamente l'esposizione.
Cos'è il CSRF e perché è importante per WordPress
Il Cross-Site Request Forgery (CSRF) è una classe di attacco in cui un sito malevolo costringe il browser di una vittima a eseguire un'azione su un altro sito dove la vittima è autenticata. Le conseguenze tipiche includono la modifica delle impostazioni, l'eliminazione di contenuti o l'esecuzione di operazioni con un clic che richiedono implicitamente le credenziali della vittima (tramite cookie o sessione attiva).
WordPress mitiga il CSRF utilizzando nonce (numeri usati una sola volta), controlli delle capacità e una valida verifica lato server. Quando i plugin introducono endpoint (pagine di amministrazione, gestori AJAX, percorsi REST) che cambiano stato — e non verificano un nonce corretto o le capacità dell'utente che chiama — sono suscettibili al CSRF.
Perché i siti WordPress sono particolarmente esposti:
- Molti amministratori rimangono connessi per comodità.
- Gli utenti amministratori navigano comunemente in rete mentre sono connessi.
- I plugin aggiungono molti endpoint aggiuntivi; più codice gestisce le richieste, maggiore è il potenziale per controlli mancanti.
Il CSRF non è meramente teorico: gli attaccanti incorporano frequentemente richieste malevole in email, forum o altri siti. Se un utente amministrativo visita contenuti di questo tipo, le richieste elaborate vengono eseguite con l'autorità dell'amministratore.
Riepilogo del problema dei commenti non risposti DX (CVE‑2026‑4138)
- Plugin vulnerabile: DX Unanswered Comments
- Versioni interessate: <= 1.7
- Tipo di vulnerabilità: Cross‑Site Request Forgery (CSRF)
- ID pubblico: CVE-2026-4138
- CVSS: 4.3 (Basso)
- Pubblicato: 21 Apr 2026
- Privilegio richiesto: Un attore non autenticato può avviare l'attacco; tuttavia, lo sfruttamento richiede un utente privilegiato autenticato per eseguire la richiesta malevola (cioè, è necessaria l'interazione dell'utente).
- Stato della patch: Nessuna patch ufficiale disponibile al momento della divulgazione.
La causa tecnica, come riportato, è che il codice del plugin espone uno o più endpoint che cambiano stato (probabilmente gestori AJAX o POST di amministrazione) senza una corretta verifica dei nonce di WordPress e/o controlli delle capacità. Ciò consente a un attaccante di elaborare una richiesta che causa l'esecuzione di azioni nel contesto di un amministratore/editor autenticato che visita contenuti controllati dall'attaccante.
Poiché non esiste ancora una patch ufficiale, l'approccio raccomandato è una mitigazione stratificata: modifiche di configurazione immediate, monitoraggio e — in modo cruciale — patching virtuale al confine (WAF) per bloccare i tentativi di sfruttamento fino a quando non diventa disponibile un aggiornamento adeguato del plugin.
Come un attaccante potrebbe sfruttare questa vulnerabilità (scenari)
La catena di sfruttamento CSRF classica per un plugin WordPress segue generalmente questi passaggi. Descriviamo scenari plausibili senza rivendicare specifici dettagli interni del plugin oltre la debolezza pubblicata:
- L'attaccante identifica un sito target che esegue DX Unanswered Comments <= 1.7.
- L'attaccante elabora una pagina HTML malevola o un'email che esegue un POST o GET a un endpoint del plugin (ad esempio, un URL AJAX di amministrazione) con parametri che istruiscono il plugin a eseguire un'azione (eliminare, aggiornare la configurazione, attivare un flag, ecc.).
- L'attaccante induce un amministratore (o un utente con privilegi sufficienti) a fare clic sul link o visitare la pagina malevola mentre è ancora connesso al pannello di controllo di WordPress.
- Poiché l'endpoint del plugin manca di controlli nonce e/o di capacità, il browser include i cookie di autenticazione dell'amministratore e il server esegue l'azione richiesta come se fosse stata eseguita dall'amministratore.
- L'attaccante raggiunge il proprio obiettivo — che potrebbe essere:
- modificare le impostazioni del plugin,
- eliminare o nascondere commenti,
- cambiare la configurazione del sito che facilita ulteriori sfruttamenti,
- o creare condizioni che facilitano l'esfiltrazione dei dati o ulteriori iniezioni di codice.
Lo sfruttamento nel mondo reale è più probabile quando l'attaccante può combinare CSRF con ingegneria sociale (phishing), cross-site scripting (XSS) in un altro plugin/tema, o altre attività di ricognizione che rivelano le abitudini dell'amministratore.
Chi è a rischio
- Siti che eseguono DX Unanswered Comments versione 1.7 o precedente.
- Amministratori o qualsiasi utente con privilegi elevati che navigano regolarmente su siti esterni mentre sono connessi.
- Siti che consentono a molti utenti amministratori e non applicano controlli di accesso aggiuntivi per gli amministratori (restrizioni IP, MFA).
- Siti gestiti che non hanno ancora applicato protezioni di edge (WAF, patch virtuali).
Anche i siti piccoli o a basso traffico dovrebbero considerare la mitigazione perché gli exploit CSRF possono essere automatizzati e eseguiti su larga scala.
Azioni immediate che ogni proprietario di sito dovrebbe intraprendere (passo dopo passo)
Quando si tratta di una vulnerabilità non corretta, agire rapidamente e dare priorità al contenimento:
- Identificare i siti interessati
- Cerca nei tuoi siti il plugin installato e la versione. In WP-admin vai su Plugin → Plugin installati e controlla la versione di DX Unanswered Comments.
- Se gestisci molti siti, utilizza la tua console di gestione, WP-CLI o uno scanner di siti per enumerare le versioni del plugin in tutta la flotta.
- Se il plugin è installato e attivo:
- Se possibile, disattiva immediatamente il plugin fino a quando non è disponibile una versione sicura.
- Se il plugin è necessario, riduci il rischio con ulteriori mitigazioni (vedi sotto).
- Limitare l'accesso amministrativo
- Disconnetti le sessioni amministrative inattive.
- Richiedi agli amministratori di riautenticarsi (forzando la terminazione della sessione) e chiedi agli amministratori di evitare di navigare su siti non affidabili mentre sono connessi.
- Abilitare l'autenticazione a due fattori (2FA) per tutti gli account privilegiati.
- Applicare mitigazioni immediate del server/del bordo.
- Implementare patch virtuali tramite un WAF per bloccare modelli di sfruttamento probabili (esempi forniti in seguito).
- Utilizzare l'autenticazione di base HTTP o limitare l'accesso a /wp-admin se si adatta al proprio flusso di lavoro.
- Ispezionare i registri e gli indicatori.
- Controllare i registri di accesso per POST insoliti a admin-ajax.php, directory dei plugin o altre richieste sospette.
- Cercare cambiamenti inaspettati nelle impostazioni dei plugin, eliminazioni di commenti o azioni dell'amministratore.
- Esegui un backup
- Eseguire un nuovo backup completo (file + database) prima di applicare qualsiasi azione di rimedio che potrebbe cambiare lo stato.
- Comunicare con le parti interessate
- Informare altri amministratori e personale di hosting riguardo al problema e al comportamento richiesto (ad es., evitare di cliccare sui link mentre si è connessi).
- Pianificare un aggiornamento.
- Monitorare il fornitore del plugin per il rilascio di una patch. Non applicare una nuova versione del plugin a meno che non sia un rilascio ufficiale che dichiara esplicitamente che la vulnerabilità è stata risolta.
Segni di rilevamento e forensi da tenere d'occhio
- Richieste POST/GET insolite ai percorsi dei plugin o a admin-ajax.php da referenti esterni in un breve lasso di tempo.
- Richieste a URL che fanno riferimento alle directory dei plugin DX o a parametri specifici dei plugin; cercare corpi POST con nomi di parametri inaspettati.
- Attività dell'amministratore in momenti in cui l'amministratore legittimo non era attivo.
- Impostazioni del plugin modificate, commenti eliminati o altre modifiche che potrebbero essere eseguite tramite endpoint del plugin.
- User agent sospetti o alto volume di richieste provenienti da un insieme ristretto di IP.
- Eventi di accesso seguiti da rapidi cambiamenti amministrativi.
Per un'analisi forense più dettagliata:
- Abilitare e raccogliere registri WP-ingegnerizzati (plugin per la registrazione delle attività).
- Esportare i registri del server web per il periodo di tempo degli eventi sospetti e cercare richieste contenenti nomi di plugin, parametri di query sospetti o POST senza un'intestazione referer adeguata.
- Se disponibile, controlla i log del WAF per eventi bloccati/consentiti e correlali con i log del server.
Raccomandazioni per la messa in sicurezza e correzioni per sviluppatori
Per gli autori di plugin e gli sviluppatori, la soluzione corretta e a lungo termine è garantire che tutti gli endpoint che modificano lo stato implementino protezioni lato server:
- Convalida i nonce di WordPress per ogni richiesta che modifica lo stato (usa wp_verify_nonce).
- Verifica le capacità dell'utente (current_user_can) — non assumere che l'autenticazione sia sufficiente.
- Usa metodi HTTP appropriati (POST per le modifiche di stato) e tieni le azioni sensibili lontane da richieste GET facilmente chiamabili.
- Per gli endpoint REST, usa permission_callback con controlli robusti.
- Sanitizza e convalida tutti gli input sul server; non fare mai affidamento sui controlli lato client.
- Implementa il logging per le azioni amministrative in modo che le modifiche siano auditabili.
Per i proprietari di siti che non possono aggiornare immediatamente il plugin:
- Disattivare il plugin dove possibile.
- Sostituisci il plugin con un'alternativa che fornisca la stessa funzionalità ma segua pratiche di codifica sicure.
- Se il plugin è essenziale, richiedi all'autore del plugin di rilasciare una patch rapida e fornire una tempistica stimata.
Come un WAF gestito e la patching virtuale aiutano (prospettiva WP‑Firewall)
Quando una vulnerabilità viene divulgata pubblicamente ma non è disponibile alcuna patch ufficiale, la patching virtuale tramite un Web Application Firewall (WAF) gestito è una delle mitigazioni più rapide ed efficaci. Presso WP‑Firewall forniamo protezioni immediate che includono:
- Creazione di firme di vulnerabilità: Creiamo firme di richiesta che identificano i tentativi di sfruttamento mirati agli endpoint e ai parametri probabili del plugin.
- Patching virtuale: Invece di aspettare un aggiornamento del plugin, blocchiamo le richieste di sfruttamento all'edge in modo che il server non riceva mai il payload malevolo.
- Modellamento del traffico e controllo degli accessi: Possiamo limitare schemi di richiesta rischiosi, applicare vincoli di stessa origine per i POST amministrativi e applicare restrizioni IP/geo.
- Monitoraggio e allerta: Se si verifica un tentativo di sfruttamento, ricevi log e avvisi che mostrano i dettagli del tentativo, gli IP sorgente e i payload bloccati.
- Distribuzione e ottimizzazione: Le firme sono ottimizzate per ridurre i falsi positivi e possono essere distribuite a tutti i siti protetti in pochi minuti.
Perché il patching virtuale è importante:
- Velocità — Le regole del WAF possono essere distribuite immediatamente su tutti i tuoi siti.
- Sicurezza — Blocca i tentativi di sfruttamento prima che raggiungano WordPress o il plugin.
- Complementare — Le patch virtuali sono temporanei; dovrebbero essere utilizzati fino a quando il plugin non rilascia un aggiornamento sicuro.
Se utilizzi WP‑Firewall, le nostre protezioni standard (anche il piano gratuito) includono un firewall gestito e regole WAF comuni che riducono l'esposizione a molte vulnerabilità comuni dei plugin. I livelli a pagamento aggiungono patch virtuali automatiche, pulizia malware e supporto dedicato.
Esempi di modelli di regole WAF e mitigazioni a livello di server
Di seguito sono riportati esempi di modelli di mitigazione per bloccare i tentativi tipici di sfruttamento CSRF. Questi sono illustrativi; le regole esatte dovrebbero essere sviluppate e testate nel tuo ambiente.
Avviso: Testa sempre le regole in modalità monitoraggio (senza blocco) prima per garantire che nessun traffico legittimo venga interrotto.
- Blocca i POST agli endpoint del plugin senza un parametro WP nonce previsto:
- Logica: Se il percorso della richiesta corrisponde all'endpoint dell'amministratore del plugin (ad es., /wp‑admin/admin‑ajax.php con parametro di azione del plugin) E non è presente il parametro _wpnonce → blocca.
- Pseudocodice:
SE request_uri CONTIENE "admin-ajax.php" - Applica la stessa origine per i POST dell'amministratore:
- Rifiuta i POST a /wp‑admin/* o AJAX dell'amministratore che hanno un'intestazione Referer esterna o nessun referer quando l'origine è cross-site.
- Pseudocodice:
SE request_method = POST - Limita la velocità o blocca gli IP sospetti che eseguono azioni ripetute del plugin:
- Se un IP emette molti POST contenenti parametri di azione del plugin in un breve periodo, limita o blocca.
- Proteggi wp‑admin con autenticazione aggiuntiva:
- Limita l'accesso a /wp‑admin per IP, o richiedi un'intestazione extra verificata dal server/WAF.
- Esempio: Rifiuta le richieste a /wp‑admin a meno che non provengano da IP approvati o a meno che non sia presente un'intestazione proxy approvata.
- Applicazione dell'intestazione di sicurezza:
- Richiedi e valida l'intestazione X‑Requested‑With: XMLHttpRequest per le chiamate AJAX utilizzate dal plugin (se il plugin la utilizza), rifiutando le richieste che ne sono sprovviste per azioni specifiche.
- Esempio semplice di regola mod_security (concettuale):
SecRule REQUEST_URI "@contains admin-ajax.php"Nota: Le regole reali di mod_security devono essere scritte con attenzione e testate.
Se non ti senti a tuo agio a scrivere regole WAF, un fornitore gestito (come WP‑Firewall) può implementare e ottimizzare queste regole per te.
Posizione di sicurezza a lungo termine: politiche, monitoraggio, backup e recupero
Contenere una singola vulnerabilità del plugin è importante, ma dovresti utilizzare questo evento per rafforzare la tua postura di sicurezza complessiva.
- Minimo privilegio e igiene dell'account
- Limita il numero di amministratori.
- Crea account separati con capacità minime per le attività quotidiane.
- Rimuovi gli account admin non utilizzati e rivedi regolarmente i privilegi.
- Applica l'autenticazione a più fattori (MFA)
- Applica MFA per tutti gli account con diritti elevati.
- Gestione delle patch.
- Mantieni aggiornati il core, i temi e i plugin di WordPress.
- Mantieni un ambiente di test o staging per convalidare gli aggiornamenti prima della produzione.
- Monitoraggio e avvisi
- Usa plugin di registrazione delle attività e integra con SIEM dove possibile.
- Monitora l'integrità dei file, le modifiche degli admin e le escalation dei privilegi.
- Backup regolari e piano di recupero
- Mantieni backup automatizzati e versionati (fuori sede).
- Testa i ripristini periodicamente in modo da poter recuperare rapidamente.
- Verifica dei fornitori e dei plugin
- Preferisci plugin con chiara reattività alla sicurezza e aggiornamenti regolari.
- Evita di utilizzare plugin abbandonati o raramente aggiornati.
- Piano di risposta agli incidenti.
- Avere un piano documentato per scoperta, contenimento, eradicazione, recupero e revisione post-incidente.
Considerazioni speciali per fornitori di hosting e agenzie
- Gli host gestiti e le agenzie che mantengono molti siti WordPress dovrebbero:
- Scansionare immediatamente la loro flotta di hosting per la versione vulnerabile del plugin.
- Implementare regole di patch virtuali WAF al confine della piattaforma per proteggere tutti i siti fino a quando i fornitori di plugin non rilasciano una patch.
- Notificare i clienti dell'esposizione e dei passaggi raccomandati, inclusi le opzioni che l'host può applicare per loro conto.
- Offrire servizi di remediation gestiti, come patching, rimozione o sostituzione di plugin e supporto forense.
- Implementare registrazione e correlazione centralizzate per rilevare ampie campagne di sfruttamento mirate alla vulnerabilità.
Proteggi il tuo sito con WP‑Firewall — Dettagli del piano gratuito e come aiuta
Inizia a proteggere il tuo sito WordPress subito con il piano gratuito di WP‑Firewall
Se desideri una protezione immediata e gestita mentre valuti gli aggiornamenti dei plugin o coordini la remediation, il piano gratuito di WP‑Firewall fornisce difese essenziali per ridurre la tua superficie di attacco:
- Cosa è incluso nel piano gratuito (Base):
- Firewall gestito
- Larghezza di banda illimitata
- Firewall per applicazioni Web (WAF)
- Scanner di malware
- Mitigazione dei rischi OWASP Top 10
Queste protezioni sono progettate per fermare modelli di sfruttamento comuni, rilevare comportamenti sospetti e bloccare molti tentativi automatizzati di sfruttare le vulnerabilità dei plugin, inclusi i tentativi di sfruttamento CSRF che seguono modelli di richiesta identificabili. Iscriversi al piano gratuito è un modo veloce per aggiungere un ulteriore strato di protezione per il tuo sito mentre lavori sugli aggiornamenti dei plugin e sui passaggi di indurimento.
Inizia con il piano gratuito qui
Se preferisci livelli più elevati di automazione e supporto, i nostri piani a pagamento aggiungono funzionalità come rimozione automatica di malware, controlli blacklist/whitelist, report di sicurezza mensili e patching virtuale automatico. Ma per molti siti, il piano gratuito Base fornisce un miglioramento significativo e immediato nella postura di protezione.
Esempio di checklist per la risposta agli incidenti (concisa)
Se confermi lo sfruttamento o sospetti uno, segui questa checklist:
- Isolare: Limitare temporaneamente l'accesso admin e mettere il sito in modalità manutenzione se necessario.
- Conservare le prove: Esportare i log e fare uno snapshot del server e del database.
- Contenere: Applicare blocchi WAF, disattivare il plugin vulnerabile e ruotare le sessioni/password admin.
- Pulire: Rimuovere eventuali backdoor, utenti non autorizzati o codice iniettato.
- Ripristinare: Se necessario e disponibile, ripristinare da un backup pulito effettuato prima dell'incidente.
- Rivedere: Identificare la causa principale e aggiornare le politiche per prevenire ricorrenze.
- Notificare: Se necessario, notificare gli utenti o i partner interessati e documentare l'incidente.
Domande comuni (FAQ)
D: CSRF è lo stesso di XSS?
R: No. CSRF inganna un browser autenticato a eseguire azioni senza l'intento dell'utente. XSS inietta codice in un sito che viene eseguito nel browser della vittima; XSS può essere utilizzato per facilitare CSRF, ma sono vulnerabilità distinte.
D: Il mio sito ha poco traffico — dovrei preoccuparmi?
R: Sì. Gli attaccanti spesso eseguono scansioni ampie e campagne automatizzate. I siti a basso traffico sono comunemente presi di mira perché richiedono meno sforzo e l'attaccante ha bisogno solo di una singola interazione amministrativa riuscita.
D: Uso una password forte e 2FA — aiuta?
R: L'autenticazione forte aiuta a proteggere le credenziali dell'account, ma il CSRF sfrutta una sessione attiva, quindi un amministratore autenticato con cookie attivi potrebbe comunque essere ingannato. Combina MFA con le altre mitigazioni: disattivare il plugin, patching virtuale WAF, limitare l'accesso degli amministratori e applicare controlli di stessa origine.
D: Posso creare la mia patch per il plugin?
R: Solo se ti senti a tuo agio a modificare PHP in modo sicuro. La correzione corretta richiede controlli nonce e di capacità lato server per ogni azione che modifica lo stato. Se prevedi di applicare patch manualmente, testa in staging e mantieni un backup.
Parole finali — proteggere le persone e i siti
Le divulgazioni pubbliche come CVE‑2026‑4138 ci ricordano che gli ecosistemi WordPress dipendono da uno sviluppo sicuro dei plugin e da un approccio di difesa a strati. Le vulnerabilità CSRF sono prevenibili con misure ben note — nonce, controlli di capacità e pratiche di codifica sicura — ma si presentano ancora in reali codebase. Per i proprietari di siti, la combinazione di rilevamento tempestivo, contenimento immediato e protezioni al confine (WAF gestito / patching virtuale) fornisce il percorso più veloce per ridurre il rischio mentre si attende le patch del fornitore.
Se gestisci DX Unanswered Comments (<=1.7) sul tuo sito, tratta questo avviso come azionabile: valuta se puoi disattivare o sostituire il plugin; in caso contrario, stringi l'accesso degli amministratori, distribuisci patch virtuali al confine e monitora i log per eventuali attività sospette.
Presso WP‑Firewall ci concentriamo ad aiutare i proprietari di siti a fare esattamente questo: ridurre rapidamente l'esposizione e fornire il supporto operativo necessario per mantenere i siti al sicuro. Se desideri aggiungere immediatamente uno strato di difesa, inizia con il nostro piano gratuito che offre firewall gestito, WAF e scansione per ridurre la superficie di attacco mentre prendi le misure a lungo termine descritte sopra.
Se vuoi, WP‑Firewall può:
- scansiona il tuo sito ora per versioni vulnerabili del plugin,
- distribuisci regole di patching virtuale per bloccare i tentativi di sfruttamento,
- e fornisci indicazioni sugli incidenti se trovi prove di compromissione.
Contatta il nostro team di sicurezza tramite il tuo dashboard WP‑Firewall per assistenza accelerata.
