Nome del plugin	Protezione contro l'iniezione
Tipo di vulnerabilità	Script tra siti (XSS)
Numero CVE	CVE-2026-3368
Urgenza	Medio
Data di pubblicazione CVE	2026-03-23
URL di origine	CVE-2026-3368

Urgente: CVE-2026-3368 — XSS memorizzato non autenticato nel plugin Injection Guard (<=1.2.9) — Cosa devono sapere e fare i proprietari di siti WordPress

Pubblicato: 23 marzo 2026
CVE: CVE-2026-3368
Gravità: CVSS 7.1 (Medio)
Versioni interessate: Plugin Injection Guard <= 1.2.9
Corretto in: 1.3.0
Crediti di ricerca: Itthidej Aramsri (Boeing777)

Come team di sicurezza di WordPress responsabile della protezione di migliaia di siti, prendiamo sul serio le nuove vulnerabilità dei plugin. Il 23 marzo 2026 è stata divulgata pubblicamente una vulnerabilità di Cross-Site Scripting (XSS) memorizzata che colpisce il plugin Injection Guard di WordPress (versioni fino e comprese 1.2.9) ed è stata assegnata CVE-2026-3368. La vulnerabilità consente a un attaccante non autenticato di iniettare HTML/JavaScript arbitrario tramite un parametro di query (nome) che può essere memorizzato ed eseguito successivamente in un contesto utente privilegiato.

Questo post spiega la vulnerabilità e la catena di attacco, valuta il rischio nel mondo reale, fornisce passaggi di remediation immediati e successivi, condivide tecniche di rilevamento e pulizia (sicure da utilizzare in produzione) e mostra come un WAF e la patching virtuale possano darti tempo se non puoi aggiornare immediatamente.

Continua a leggere per indicazioni pratiche e attuabili da un team di sicurezza WordPress esperto.

---

Sintesi (breve)

• Cosa: XSS memorizzato non autenticato tramite il nome parametro di query nelle versioni del plugin Injection Guard <= 1.2.9 (CVE-2026-3368).
• Impatto: XSS memorizzato che può essere eseguito in contesti amministrativi quando un utente privilegiato visualizza le pagine del plugin; potenziale takeover dell'account admin, installazione di backdoor nel sito, deturpazione dei contenuti o furto di dati.
• Urgenza: Alta priorità per i proprietari di siti con questo plugin installato. Patch disponibile in v1.3.0 — aggiorna immediatamente.
• Se non puoi aggiornare immediatamente: applica la patching virtuale WAF, blocca i payload di exploit o applica un mu-plugin sicuro per sanificare l'input.
• Utenti di WP-Firewall: regole di mitigazione protettive e patching virtuale sono disponibili per bloccare i tentativi di exploit mentre aggiorni.

---

1) La vulnerabilità e come funziona (panoramica tecnica)

Questa è una vulnerabilità di Cross-Site Scripting (XSS) memorizzata. L'XSS memorizzato si verifica quando l'input fornito dall'utente viene accettato dal server, memorizzato (ad esempio, in opzioni, meta post, commenti o un altro storage persistente) e successivamente reso in una pagina senza una corretta sanificazione/escaping. Quando quel contenuto memorizzato viene reso nel contesto di un utente privilegiato (amministratore, editore), qualsiasi JavaScript incorporato verrà eseguito con i privilegi di quell'utente.

Specifiche chiave di questa divulgazione:

• Plugin interessato: Injection Guard (versioni <= 1.2.9).
• Punto di iniezione: nome parametro di query. Le richieste non autenticate potrebbero essere in grado di iniettare contenuti che il plugin persiste.
• Contesto di esecuzione: Il contenuto memorizzato viene reso in una pagina che gli utenti privilegiati (amministratori del sito) visitano. Il payload memorizzato viene eseguito nel contesto del browser dell'amministratore, consentendo il furto di sessione, CSRF o compromissione completa del sito.
• Catena di sfruttamento: L'attaccante invia una richiesta non autenticata all'endpoint vulnerabile che memorizza contenuti controllati dall'attaccante. Successivamente, un amministratore visita il plugin (o la pagina di amministrazione correlata) e attiva l'XSS memorizzato, consentendo l'esecuzione di JavaScript fornito dall'attaccante in una sessione di amministrazione.

Nota: L'iniezione iniziale è non autenticata, ma lo sfruttamento richiede che un amministratore (o un altro utente privilegiato) carichi la pagina contenente il payload memorizzato — il che può avvenire cliccando su un link, visualizzando le pagine del plugin o aprendo schermate di amministrazione specifiche.

---

2) Perché questo è pericoloso

L'XSS memorizzato che si esegue in un contesto amministrativo è una delle vulnerabilità web più pericolose per un sito WordPress perché:

• Viene eseguito con gli stessi privilegi dell'amministratore connesso nel proprio browser. Un attaccante può eseguire azioni per conto dell'amministratore (creare post, installare plugin/temi, aggiungere utenti, esportare dati).
• Può rubare cookie o token di sessione e usarli per dirottare le sessioni dell'amministratore.
• Può installare backdoor (shell PHP), creare utenti amministratori o attivare modifiche persistenti ai file del sito e alle voci del database.
• Poiché l'iniezione iniziale è non autenticata, l'automazione e le scansioni di massa possono trovare e infettare rapidamente molti siti.
• I payload memorizzati sopravvivono ai caricamenti di pagina — un amministratore potrebbe imbattersi nel contenuto malevolo giorni o settimane dopo.

Data la combinazione di iniezione non autenticata ed esecuzione in un contesto amministrativo, questa vulnerabilità dovrebbe essere considerata ad alto rischio per i siti interessati.

---

3) Scenario di attacco (passo dopo passo)

1. L'attaccante crea una richiesta che mira all'endpoint del plugin e passa il nome parametro di query contenente contenuto malevolo.
2. Il plugin memorizza questo nome valore nel database (ad esempio, nelle opzioni o nei meta post) senza una corretta sanitizzazione.
3. Successivamente, un amministratore visita la pagina di amministrazione del plugin dove il valore memorizzato nome viene reso nella pagina come HTML senza un'adeguata escape.
4. Lo script malevolo viene eseguito nel browser dell'amministratore. Lo script può:
   • Esfiltrare cookie, token di autenticazione o nonce CSRF.
   • Effettuare richieste autenticate agli URL di amministrazione di WordPress (creare un nuovo utente amministratore, installare un plugin, modificare file di temi o plugin, ecc.).
   • Inserire script dannosi o backdoor nel sito.
5. L'attaccante ottiene il pieno controllo amministrativo e può mantenere l'accesso, monetizzare il sito o passare ad altri sistemi.

Questo è un attacco XSS memorizzato tipico che è particolarmente impattante quando il contenuto iniettato viene mostrato a utenti privilegiati.

---

4) Azioni immediate per i proprietari del sito (cosa fare subito)

Se il tuo sito utilizza il plugin Injection Guard (<=1.2.9):

1. Aggiorna immediatamente
   • Aggiorna il plugin alla versione 1.3.0 o successiva. Questa è l'azione più importante.
2. Se non puoi aggiornare immediatamente
   • Applica un WAF/patch virtuale per bloccare i tentativi di sfruttamento (vedi le raccomandazioni WAF qui sotto).
   • Aggiungi un mu-plugin temporaneo che sanifica o rifiuta le richieste contenenti payload sospetti nel nome parametro di query.
3. Ruota le credenziali e i token di sessione
   • Forza il ripristino delle password per tutti gli account admin.
   • Invalidare le sessioni attive (puoi utilizzare la schermata admin Utenti o eseguire comandi WP-CLI).
4. Scansiona per contenuti dannosi e backdoor
   • Cerca nel database tag script memorizzati e attributi sospetti (vedi le query di rilevamento qui sotto).
   • Scansiona il filesystem per file recentemente modificati e schemi di backdoor noti.
5. Pulisci e audita
   • Rimuovi eventuali payload XSS memorizzati.
   • Audita tutti gli utenti di livello admin creati di recente.
   • Controlla gli editor di plugin e temi (Aspetto > Editor file tema, Plugin > Editor file plugin) per modifiche non autorizzate.
6. Monitora i log e il traffico
   • Abilita il monitoraggio per catturare tentativi di sfruttamento ripetuti e indirizzi IP sorgente.
   • Mantieni i log per analisi forensi.

Se gestisci più siti, fai un inventario e dai priorità all'aggiornamento e alla protezione di quelli che ospitano il plugin Injection Guard.

---

5) Come rilevare payload memorizzati e artefatti sospetti (query e comandi sicuri)

Di seguito sono riportati controlli sicuri e non distruttivi che puoi eseguire per trovare potenziali payload XSS memorizzati. Esegui sempre il backup del tuo sito (database + file) prima di apportare modifiche in massa.

Controlli del database (WP-CLI)

• Cerca wp_options per script memorizzati:
  wp db query "SELECT option_id, option_name FROM wp_options WHERE option_value LIKE '%<script%';"
• Cercare nel contenuto del post:
  query wp db "SELEZIONA ID, post_title DA wp_posts DOVE post_content COME '%
• Cerca postmeta:
  wp db query "SELECT meta_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%<script%';"

Se hai una tabella personalizzata utilizzata dal plugin, adatta le query per controllare i valori con “<script”, “javascript:”, “onerror=”, “onload=”, “img src=javascript:” ecc.

Controlli di file e filesystem

• Elenca i file modificati negli ultimi 14 giorni:
  find /path/to/wp -type f -mtime -14 -print
• Cerca utilizzi sospetti di PHP eval o base64_decode (attenzione: potrebbe generare falsi positivi):
  grep -R --line-number -E "eval\(|base64_decode\(|gzinflate\(" /path/to/wp-content

Controlli dei log

• Rivedi i log del server web per richieste ripetute che colpiscono l'endpoint del plugin con nome= nella stringa di query.
• Blocca gli IP che inviano tentativi di sfruttamento ripetuti dopo un'indagine.

Rimozione sicura dei contenuti (esempi)

• Usa wp search-replace per rimuovere i tag script con attenzione:
  wp search-replace '<script' '<!--script-removed' --skip-columns=guid --all-tables
  NOTA: Usa cautela. Esegui prima il backup del DB. Testa in staging.

Se non sei sicuro, coinvolgi un professionista della sicurezza per eseguire una pulizia e una revisione forense.

---

6) Mitigazioni a breve termine quando l'aggiornamento non è immediatamente possibile

Se non puoi aggiornare a 1.3.0 immediatamente, applica una o più di queste mitigazioni:

1. WAF (Web Application Firewall) / Patch virtuale
   • Blocca le richieste in arrivo che includono caratteri sospetti nel nome parametro di query, come <, >, script, un errore, o attributi di evento.
   • Limita i metodi di richiesta a quelli previsti e scarta i modelli anomali.
   • Per gli utenti di WP-Firewall: è disponibile un insieme di regole di mitigazione specifiche per exploit per bloccare i modelli di attacco noti per questa vulnerabilità mentre aggiorni.
2. Mu-plugin temporaneo per sanificare l'input
   • Crea un mu-plugin (plugin da utilizzare obbligatoriamente) che sanifica o rimuove caratteri sospetti dal nome parametro GET prima che il codice vulnerabile possa memorizzarlo. Esempio (vedi sotto).
3. Limita l'accesso all'area admin
   • Usa l'allowlisting IP per wp-admin se possibile.
   • Metti l'autenticazione HTTP su wp-admin per un ulteriore livello.
4. Disabilita il plugin
   • Se il plugin non è critico per le operazioni quotidiane, disabilitalo temporaneamente fino a quando non puoi aggiornare in sicurezza.

Esempio di mu-plugin temporaneo (inserisci in wp-content/mu-plugins/temporary-sanitize-name.php):

<?php;

Note:

• Questa è una mitigazione temporanea, non un sostituto per l'aggiornamento.
• Testa su staging prima di distribuire in produzione.
• Usa un mu-plugin (sempre caricato) per garantire che venga eseguito prima dei plugin che potrebbero elaborare l'input.

---

7) Esempio di logica della regola WAF (livello alto)

Se gestisci un WAF o intendi definire regole personalizzate, quanto segue descrive un insieme di regole sicure e di alto livello per bloccare i tentativi di sfruttamento senza generare molti falsi positivi:

• Blocca se il nome parametro di query contiene:
  • <script O </script
  • javascript: (in qualsiasi attributo)
  • unerrore= O carico= O onclick= (attributi di evento comuni)
  • documento.cookie / document.location / window.location
• Blocca valori ad alta entropia o insolitamente lunghi nome (ad es., > 512 caratteri).
• Blocca le richieste che includono tag HTML o parentesi angolari nel nome parametro.
• Limita il numero di richieste all'endpoint per ridurre la scansione automatizzata.

Importante: Regola le regole per l'ambiente del tuo sito per evitare di interrompere la funzionalità legittima.

---

8) Come indurire il codice del plugin — guida per sviluppatori (correzioni da implementare)

Se sei uno sviluppatore che mantiene un plugin o lavora con il codice sorgente di Injection Guard, applica queste pratiche di codifica sicura:

1. Validazione e sanitizzazione dell'input
   • Sanitizza gli input in arrivo in base al tipo di dato previsto:
     • Campi solo testo: usa sanitize_text_field()
     • HTML consentito: usa wp_kses() con un elenco di tag e attributi consentiti
     • Numerico: (int) casting o absint()
2. Escape dell'output
   • Escape all'output in base al contesto:
     • Corpo HTML: echo wp_kses_post()
     • Valori degli attributi: echo esc_attr()
     • Contesti JS: echo esc_js()
3. Controlli delle capacità e dei nonce
   • Assicurati che solo gli utenti autorizzati possano invocare azioni che modificano i dati persistenti:
     • check_admin_referer() per invii di moduli
     • current_user_can('gestire_opzioni') o controlli di capacità appropriati
4. Evita il salvataggio non sanitizzato
   • Non memorizzare mai HTML controllato dall'utente in forma grezza a meno che non sia assolutamente necessario e sicuro.
5. Usa dichiarazioni preparate quando interagisci con il DB
   • $wpdb->prepare() per evitare problemi di SQL injection.
6. Evita di visualizzare valori memorizzati senza escape — anche i campi riservati agli amministratori possono essere pericolosi.

Esempio minimo di memorizzazione e rendering sicuri:

<?php;

Se l'HTML deve essere memorizzato (raramente), memorizzalo dopo aver filtrato con wp_kses() e fai escape all'output in base al contesto.

---

9) Lista di controllo per il recupero dopo una compromissione sospetta

Se sospetti che l'XSS memorizzato sia stato sfruttato e che azioni amministrative siano state eseguite da un attaccante, segui questa lista di controllo per il recupero:

1. Metti il sito offline o attivalo in modalità manutenzione (se pratico).
2. Eseguire il backup del filesystem e del database attuali per analisi forensi.
3. Revocare tutte le sessioni e ruotare le password e le chiavi di amministrazione (salti di WordPress in wp-config.php).
4. Scansiona per backdoor:
   • Cercare file recentemente modificati al di fuori dei tempi di aggiornamento previsti.
   • Controllare gli upload per file PHP.
5. Ispezionare gli utenti amministratori e rimuovere gli account non riconosciuti.
6. Controllare i compiti programmati (wp-cron o cron del server) per lavori sconosciuti.
7. Sostituisci i file core/plugin/tema modificati con copie pulite da fonti ufficiali.
8. Reinstallare il plugin interessato (aggiornare alla versione corretta) da una fonte ufficiale.
9. Riesaminare e indurire:
   • Applicare 2FA per tutti gli utenti amministratori.
   • Abilitare il logging e l'allerta per modifiche sospette.
10. Coinvolgere un professionista della risposta agli incidenti se il compromesso sembra grave.

---

10) Come WP-Firewall aiuta (cosa offriamo e perché è importante)

Presso WP-Firewall costruiamo protezioni che riducono la tua esposizione a vulnerabilità attive dei plugin come CVE-2026-3368. Quando viene divulgata una nuova vulnerabilità, adottiamo i seguenti passaggi:

• Regole di mitigazione immediate: Distribuiamo patch virtuali e firme WAF per bloccare i modelli di sfruttamento comuni per la vulnerabilità (ad esempio, richieste contenenti <script o gestori di eventi nel nome parametro di query).
• Scansione malware e avvisi forensi: Il nostro scanner cerca indicatori di XSS memorizzati e artefatti comuni post-sfruttamento.
• Registrazione degli attacchi e riproduzione: Catturare i tentativi di sfruttamento per informare le decisioni di rimedio e bloccare fonti persistenti.
• Opzioni di mitigazione automatiche o manuali: Se preferisci, possiamo applicare automaticamente le mitigazioni al tuo sito mentre pianifichi l'aggiornamento.
• Raccomandazioni e linee guida per la pulizia: Passi chiari per il rimedio e checklist personalizzate per il tuo ambiente.

La protezione a strati di WP-Firewall (WAF + scanner + monitoraggio) è progettata per prevenire l'iniezione da essere memorizzata e bloccare i tentativi di sfruttamento che raggiungono utenti privilegiati, dandoti tempo per aggiornare i plugin in modo sicuro e eseguire pulizie con fiducia.

---

11) Esempi pratici di rimedio per sysadmin e sviluppatori

A. Come rimuovere in modo sicuro i tag script memorizzati dalle opzioni (WP-CLI):

1. Backup DB:
   • wp db export prima di apportare modifiche.
2. Cerca:
   • wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%';"
3. Per ogni risultato, aggiorna in modo sicuro:
   • Utilizzo wp option get NOME_OPZIONE per rivedere.
   • Se non sicuro, sanitizza e aggiorna:
     • wp option update NOME_OPZIONE "$(wp option get NOME_OPZIONE | php -r '$s=fgets(STDIN); echo strip_tags($s);')"

B. Come invalidare le sessioni e ruotare i sali:

• Ruota i sali in il file wp-config.php: genera nuove chiavi tramite https://api.wordpress.org/secret-key/1.1/salt/ e aggiorna il file wp-config.php.
• Forza il ripristino delle password: Per ogni utente, imposta password utente tramite wp-cli o istruisci gli utenti a ripristinare tramite email.
• Cancella le sessioni: Se utilizzi un plugin per le sessioni, segui la documentazione del plugin. Altrimenti, utilizza WP-CLI o aggiornamenti del database per cancellare i token di sessione nella tabella usermeta.

C. Ricerca nel filesystem per JavaScript iniettato:

• grep -R --line-number -i "<script" wp-content/uploads
• Controlla qualsiasi file restituito per legittimità.

---

12) Linee guida per la comunicazione: cosa dire ai tuoi clienti o stakeholder

Se gestisci siti dei clienti, la trasparenza è importante. Ecco un testo di esempio che puoi utilizzare:

• Per notifica immediata:
  • “Abbiamo identificato che un plugin installato sul tuo sito (Injection Guard, precedente alla v1.3.0) è affetto da una vulnerabilità XSS memorizzata (CVE-2026-3368). Stiamo applicando misure protettive e aggiorneremo il plugin alla versione corretta. Non sono state trovate prove di sfruttamento (ancora). Ti consigliamo di cambiare le password di amministrazione dopo l'aggiornamento come ulteriore precauzione.”
• Per follow-up dopo la mitigazione:
  • “Abbiamo aggiornato il plugin alla versione corretta e implementato regole WAF per bloccare i tentativi di sfruttamento. Abbiamo scansionato il sito per artefatti malevoli e trovato [nessuno/trovato X]. Se è stato trovato qualcosa di sospetto, abbiamo effettuato una pulizia e ruotato le credenziali.”

---

13) Difese a lungo termine per ridurre il rischio dei plugin

• Principio del minimo privilegio: Limita gli account utente e restringi la capacità di gestione dei plugin a un piccolo gruppo di amministratori fidati.
• Rafforza l'accesso admin: Implementa l'IP allowlisting, l'autenticazione HTTP per /wp-admin e la 2FA.
• Tieni un inventario: Mantieni un elenco di tutti i plugin installati e monitora le divulgazioni.
• Staging e testing: Testa gli aggiornamenti dei plugin in staging prima di passarli in produzione.
• Politica di patching automatizzato: Dove accettabile, abilita gli aggiornamenti automatici per patch non distruttive o programma finestre di aggiornamento gestibili.
• Verifica di terze parti: Usa la reputazione del plugin e le revisioni del codice per i plugin che installi.
• Monitoraggio continuo: Monitoraggio dell'integrità dei file (FIM) e rilevamento delle anomalie nel traffico.

---

14) Esempio di sostituzione sicura per sviluppatori per codice vulnerabile (concettuale)

Se il plugin memorizza un parametro GET senza sanitizzazione, sostituisci la memorizzazione non sicura con un flusso di lavoro convalidato e sanitizzato — e richiedi nonce CSRF e controlli delle capacità per le modifiche di amministrazione. Esempio di pseudo-fix concettuale:

<?php

Consenti solo la memorizzazione tramite invii di moduli autenticati e autorizzati, e fuga sempre l'output al momento del rendering.

---

15) Cronologia e attribuzione

• Scoperta / divulgazione pubblica: 23 marzo 2026
• CVE: CVE-2026-3368
• Corretto in: Injection Guard v1.3.0
• Ricercatore accreditato: Itthidej Aramsri (Boeing777)

---

16) FAQ

Q: Un attaccante non autenticato può compromettere completamente il mio sito utilizzando questa vulnerabilità?
UN: L'iniezione iniziale non richiede autenticazione, ma lo sfruttamento richiede tipicamente che un amministratore o un utente privilegiato visualizzi il payload memorizzato. Se un admin lo visualizza, l'attaccante può eseguire azioni amministrative tramite lo script iniettato, portando potenzialmente a una compromissione totale.

Q: Ho aggiornato, devo ancora preoccuparmi?
UN: Aggiorna a 1.3.0 o successivo il prima possibile. Dopo l'aggiornamento, esegui la scansione per i payload memorizzati e verifica che non siano state eseguite azioni amministrative. Se il tuo aggiornamento è stato ritardato, assumi una potenziale esposizione e segui la checklist di recupero.

Q: E se non ho un backup?
UN: Crea un backup immediatamente prima di qualsiasi intervento di ripristino. Se non esiste alcun backup, sii cauto e contatta un professionista della risposta agli incidenti: le azioni di ripristino possono essere distruttive senza backup.

---

17) Proteggi te stesso oggi con il nostro piano di protezione del sito gratuito

Se sei responsabile della sicurezza di WordPress, il rischio derivante da vulnerabilità dei plugin come questa è reale e immediato. Per aiutare i proprietari di siti a muoversi rapidamente e con fiducia, offriamo un piano Base gratuito che fornisce protezioni essenziali senza costi: un firewall gestito, regole WAF, larghezza di banda illimitata, scansione malware e mitigazione contro i rischi OWASP Top 10. Se desideri patching virtuale immediato e scansione per bloccare i tentativi di sfruttamento mentre aggiorni i plugin e esegui la pulizia, iscriviti al piano WP-Firewall Base (Gratuito) su: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Il nostro piano Base è progettato per fermare molti attacchi automatizzati e per dare agli amministratori il tempo di aggiornare e pulire i siti. L'upgrade ai piani a pagamento aggiunge rimozione automatica del malware, blacklist IP, report di sicurezza mensili e patching virtuale automatico per minacce emergenti.

---

18) Raccomandazioni finali — checklist prioritaria

1. Se Injection Guard è installato: aggiorna a v1.3.0 immediatamente.
2. Se non è possibile aggiornare immediatamente:
   • Applica regole WAF/patching virtuale per bloccare sospetti nome richieste di parametri.
   • Distribuisci la sanitizzazione temporanea del mu-plugin (vedi esempio).
3. Esegui il backup del sito e del database prima di qualsiasi modifica.
4. Scansiona il database e i file per tag di script memorizzati e rimuovili in modo sicuro.
5. Ruota le password di amministrazione e invalida le sessioni.
6. Audita gli utenti admin, i plugin installati e le modifiche recenti ai file.
7. Applica 2FA e altre misure di sicurezza per gli amministratori.
8. Considera di passare a una soluzione di sicurezza gestita con WAF + mitigazioni automatiche.

---

Nota conclusiva da WP-Firewall

Sappiamo quanto possano essere stressanti le divulgazioni di sicurezza. La nostra filosofia è semplice: la velocità è importante. Proteggi prima (patch virtuale + WAF), poi aggiorna, poi pulisci e verifica a fondo. Questo approccio riduce il tempo di esposizione e minimizza la possibilità di compromissione.

Se gestisci più siti WordPress, dai priorità a quelli che espongono gli utenti amministratori a traffico esterno, a quelli che ospitano e-commerce o dati sensibili, e a quelli con finestre di manutenzione a bassa frequenza. Se desideri una guida personalizzata per il tuo ambiente, i team di supporto e servizi gestiti di WP-Firewall sono pronti ad aiutarti.

Rimani al sicuro e agisci prontamente: aggiorna, scansiona e proteggi.

— Team di Sicurezza WP-Firewall