Nome del plugin	The7
Tipo di vulnerabilità	Script tra siti (XSS)
Numero CVE	CVE-2026-6646
Urgenza	Basso
Data di pubblicazione CVE	2026-05-14
URL di origine	CVE-2026-6646

The7 Tema Stored XSS (CVE-2026-6646): Cosa Devono Fare Ora i Proprietari di Siti WordPress

In breve
Una vulnerabilità di Cross-Site Scripting (XSS) memorizzata (CVE-2026-6646) che colpisce le versioni del tema The7 fino e inclusa la 14.3.2 consente a un utente autenticato con privilegi di livello Contributor di memorizzare JavaScript in luoghi che possono essere visualizzati ed eseguiti nei browser di altri utenti. Il problema è stato corretto in The7 14.3.3 — aggiorna immediatamente. Se non puoi applicare la patch subito, applica le mitigazioni di seguito, controlla il tuo sito per script iniettati e considera di applicare patch virtuali tramite un Web Application Firewall (WAF) gestito per ridurre l'esposizione.

Questo post spiega la vulnerabilità, gli scenari di rischio, i modi per rilevare lo sfruttamento, la remediation passo dopo passo e la contenimento, e come le protezioni di WP-Firewall possono ridurre il rischio oggi mentre gestisci l'aggiornamento e la pulizia.

---

Cosa è successo (riassunto semplice)

• Vulnerabilità: Cross-Site Scripting (XSS) memorizzato nel tema The7 per WordPress (CVE-2026-6646).
• Versioni colpite: The7 ≤ 14.3.2. Corretto in 14.3.3.
• Privilegio richiesto: Ruolo di Contributor autenticato (o qualsiasi ruolo in grado di inviare contenuti memorizzati dal tema).
• CVSS (come riportato): 6.5 (rischio medio) — l'impatto può essere significativo nelle giuste condizioni.
• Sfruttamento: Un Contributor malevolo può inviare contenuti che contengono payload di script che vengono memorizzati e successivamente eseguiti quando altri utenti (inclusi utenti con privilegi superiori) visualizzano determinate pagine o opzioni del tema. Lo sfruttamento riuscito di solito richiede qualche interazione dell'utente (ad es., amministratore che visualizza una pagina o apre una pagina di impostazioni specifica).

In parole semplici: un attaccante che può accedere come contributor può salvare uno script malevolo che verrà eseguito quando il template vulnerabile o la pagina di amministrazione visualizza quel contenuto salvato.

---

Perché questo è importante: impatti nel mondo reale dello XSS memorizzato

Lo XSS memorizzato è spesso sottovalutato perché l'accesso di livello “Contributor” non è un controllo completo da amministratore. Tuttavia, lo XSS memorizzato può essere utilizzato per escalare e pivotare in un compromesso a livello di sito. Gli impatti tipici includono:

• Furto di sessione: Uno script può leggere i cookie o rubare i token di autenticazione e inviarli all'attaccante. Se i cookie non sono correttamente contrassegnati (HttpOnly), questo è più facile.
• Escalation dei privilegi: Lo script può eseguire azioni per conto di un amministratore (se l'amministratore visualizza la pagina mentre è connesso), come creare un utente amministratore, modificare impostazioni, installare plugin o modificare file del tema.
• Defacement e reindirizzamenti malevoli: L'attaccante può reindirizzare i visitatori a domini malevoli o iniettare contenuti che generano frodi pubblicitarie o phishing.
• Persistenza/backdoor: Gli script possono creare backdoor PHP o JS persistenti (caricamento di file, creazione di attività pianificate, esfiltrazione di credenziali).
• Danno alla reputazione e SEO: Lo spam iniettato, i backlink o i reindirizzamenti nascosti possono avvelenare il ranking di ricerca e la reputazione del marchio.
• Rischio della catena di approvvigionamento per siti ad alto traffico: Un singolo account di collaboratore sfruttato (o autore compromesso) su molti siti può essere utilizzato in campagne di sfruttamento di massa.

Poiché l'attacco può essere avviato da utenti di livello Collaboratore, ha un impatto particolare su blog multi-autore, siti comunitari, siti di membri o siti che consentono contenuti degli utenti senza una rigorosa sanificazione.

---

Come funziona tipicamente lo sfruttamento (spiegazione tecnica)

Lo XSS memorizzato richiede tre componenti:

1. Un modo per memorizzare input controllati dall'attaccante nell'applicazione (ad es., contenuto del post, testo del widget, opzioni del tema, dati del page-builder).
2. L'applicazione che non sanifica o codifica correttamente quell'input memorizzato durante il rendering (sia nel frontend che nell'amministratore).
3. Una vittima (amministratore o un altro utente) che visualizza la pagina o la vista dell'amministratore in cui quel payload memorizzato è reso.

In questo caso di The7 (a livello alto e generalizzato):

• Un Contributore crea contenuti (o manipola un'opzione tema/articolo del page-builder) e include un tag script malevolo o un attributo evento (ad es., <script>…</script>, onerror=…, <img src="x" onerror="…">).
• The7 memorizza il contenuto nel database (post_content, postmeta, theme_mods o altre tabelle personalizzate) e successivamente rende quel contenuto in un'anteprima dell'amministratore, nella pagina delle opzioni del tema o nel frontend senza una codifica adeguata dell'output.
• Quando un utente con privilegi più elevati carica quella pagina (o quando un amministratore visualizza un'anteprima di una pagina nel dashboard), il browser esegue il JavaScript iniettato con il contesto della sessione della vittima, consentendo all'attaccante di eseguire azioni come quell'utente.

Lo XSS memorizzato può essere silenzioso e difficile da individuare perché la pagina visibile può sembrare normale o mostrare solo un piccolo elemento inserito.

---

Rilevamento: segni che il tuo sito potrebbe essere colpito o sfruttato

Se il tuo sito utilizza il tema The7 e hai utenti di livello Collaboratore, esegui immediatamente i seguenti controlli.

1. Verifica le versioni:
   • Nel dashboard di WordPress, vai su Aspetto → Temi e controlla la versione di The7.
   • Se non puoi accedere al dashboard, ispeziona wp-content/themes/the7/style.css o i file di intestazione del tema per vedere la stringa di versione.
2. Cerca contenuti sospetti nel database. Usa queste query in sola lettura (effettua un backup del database prima di apportare modifiche):

   Esempi di SQL (esegui tramite phpMyAdmin, Adminer o console wp-db):

   • Cerca tag script nei post:
     SELEZIONA ID, post_title, post_type DA wp_posts DOVE post_content SIMILE '%<script%';
   • Cerca gestori di eventi:
     SELEZIONA post_id, meta_key, meta_value DA wp_postmeta DOVE meta_value LIKE '%onerror=%' O meta_value LIKE '%onload=%';
   • Opzioni di ricerca e theme_mods:
     SELEZIONA option_name DA wp_options DOVE option_value LIKE '%<script%' O option_value LIKE '%onerror=%';
   • Schemi generici sospetti:
     SELEZIONA ID, post_title DA wp_posts DOVE post_content REGEXP '(base64_decode|document.cookie|location.href|eval\\(|window\\.location)';

   Esempi di WP-CLI:

   • query wp db "SELEZIONA ID, post_title DA wp_posts DOVE post_content COME '%
   • wp search-replace '<script' '[scr rimosso]' --dry-run (esecuzione in prova per vedere i risultati)
3. Scansiona file e caricamenti:
   • Controllo wp-content/caricamenti per file con estensione .php o nomi di file strani.
   • Usa grep sul server:
     grep -RIl --exclude-dir=uploads 'eval(' /path/to/site/wp-content/themes/the7
   • Cerca file di tema modificati di recente:
     trova wp-content/themes/the7 -type f -mtime -30 -ls
4. Rivedi gli utenti e la cronologia di accesso:
   • Controlla gli account creati di recente con ruoli di Collaboratore o superiori.
   • Controlla i log di accesso degli amministratori e i tentativi di accesso non riusciti.
5. Log web e anomalie nel traffico:
   • Controlla i log del server web per POST insoliti a admin-ajax.php o endpoint page-builder.
   • Cerca connessioni esterne a domini sconosciuti dal tuo server.
6. Usa uno strumento di scansione/malware. (o scanner WP-Firewall) per identificare firme conosciute e contenuti sospetti.

Se una delle query restituisce risultati con tag script o chiamate a funzioni sospette, trattali come indicatori di compromissione (IoC) e procedi con il contenimento.

---

Lista di controllo per la remediation immediata (cosa fare nella prima ora)

1. Aggiorna The7 a 14.3.3 (o versioni successive) — fai questo come prima priorità. Questo elimina la vulnerabilità a livello di codice. Se puoi aggiornare immediatamente, fallo e poi verifica la funzionalità del sito. Testa sempre prima in un ambiente di staging se possibile.
2. Se l'aggiornamento immediato non è possibile:
   • Limitare temporaneamente i privilegi del Contributor:
     • Cambia il ruolo di Contributor in un ruolo senza diritti di pubblicazione/modifica, o rimuovi la capacità del ruolo di creare contenuti che vengono visualizzati senza moderazione.
     • Rimuovi gli account di contributor non affidabili o reimposta le loro password.
   • Applica una regola WAF o una patch virtuale (vedi mitigazione WAF di seguito) per bloccare i modelli di payload XSS memorizzati al confine.
3. Forza la re-autenticazione per tutti gli account admin e editor:
   • Cambia le password di admin/editor e chiedi agli utenti privilegiati di reimpostare le password.
   • Ruota le chiavi API/REST e altri segreti (token OAuth, chiavi di terze parti).
4. Blocca l'area admin del sito:
   • Limitare l'accesso admin per IP dove pratico.
   • Abilita 2FA per tutti gli utenti admin/editor.
   • Disabilita la possibilità di visualizzare in anteprima i contenuti o riduci la sua capacità di visualizzare HTML non sicuro nell'admin (se il tema ha opzioni per sfuggire ai contenuti).
5. Scansiona per contenuti dannosi e rimuovili:
   • Rimuovi eventuali payload scoperti da post, postmeta, opzioni e impostazioni del tema.
   • Esamina le opzioni del tema e gli elementi del page builder per HTML dannoso incorporato.
6. Fai un backup e uno snapshot:
   • Prima di eliminare o modificare contenuti, crea un backup completo (file + DB) e conservalo offline per analisi forensi.
7. Controlla la persistenza/backdoor:
   • Esaminare wp-content/themes/the7 E wp-content/plugin per file sconosciuti.
   • Controllo mu-plugin, wp-content/caricamenti, lavori cron, e il file wp-config.php per codice iniettato.
8. Notificare le parti interessate e pianificare un audit completo:
   • Informare i proprietari del sito e gli amministratori riguardo alla vulnerabilità e alle mitigazioni effettuate.
   • Pianificare un'indagine forense più approfondita se vengono trovati IoC.

---

Mitigazioni temporanee e indurimento (fino a quando non puoi applicare completamente la patch e auditare)

1. Sostituire temporaneamente il tema attivo con un tema sicuro e mantenuto (ad es., predefinito di WordPress) mentre applichi la patch e indaghi. Questo è il modo più veloce per rimuovere il percorso di codice vulnerabile.
2. Disabilitare le funzionalità specifiche del tema (costruttori di pagine, widget personalizzati o pagine delle opzioni del tema) che accettano HTML o markup fornito dall'utente.
3. Attivare un'intestazione della politica di sicurezza dei contenuti (CSP) per limitare l'impatto degli script inline:
   • Aggiungere default-src 'self'; script-src 'self' 'nonce-' https:; object-src 'none'; frame-ancestors 'none';
   • Nota: CSP può interrompere la funzionalità del sito; testare prima di applicare ampiamente.
4. Impostare i flag HttpOnly e Secure sui cookie (inclusi i cookie di autenticazione) e considerare gli attributi SameSite:
   • Impostare tramite PHP ini o tramite le intestazioni del tuo host/riposta.
5. Limitare i caricamenti di file e vietare le estensioni eseguibili nella cartella di caricamento.
6. Richiedere moderazione per qualsiasi contenuto inviato dagli utenti; impostare i post dei Collaboratori su “In attesa di revisione” in modo che il contenuto non venga visualizzato pubblicamente o nelle anteprime dell'amministratore senza revisione.

---

WAF e Patch Virtuali: come ridurre il rischio immediatamente

Un WAF gestito può fornire una rapida riduzione del rischio attraverso la patch virtuale. Ecco come un WAF aiuta in questa situazione:

• Bloccare i payload dannosi a livello HTTP prima che raggiungano WordPress. Per XSS memorizzati, il WAF può ispezionare i corpi POST e filtrare i tag script e i modelli XSS comuni.
• Bloccare i POST sospetti di amministratori/editor e l'accesso agli endpoint delle opzioni del tema da IP non verificati o utenti non amministratori.
• Applica regole specifiche per bloccare le richieste che tentano di memorizzare tag script o attributi di eventi inline (onerror, onload, onclick) in richieste che mappano a endpoint responsabili della memorizzazione delle opzioni/contenuti del tema.
• Fornisci registrazione e avvisi in modo da poter vedere i tentativi di sfruttamento e bloccare i trasgressori ripetuti.

Esempi di modelli di corrispondenza (concettuali - gli autori delle regole WAF dovrebbero testare e indurire per evitare falsi positivi):

• Blocca le richieste in cui il corpo contiene <script O javascript: o attributi di eventi nei campi del modulo:
  • regex: (?i)<\s*script\b|javascript:|onerror\s*=|onload\s*=|onmouseover\s*=
• Blocca i payload codificati in base64 contenenti valutazione( O documento.cookie:
  • regex: (?i)base64_decode\(|eval\(|document\.cookie|window\.location

Importante: Le regole WAF devono essere ottimizzate per evitare di interrompere contenuti legittimi (ad es., frammenti di codice, embed). Le regole basate sul comportamento che cercano payload simili a script nei campi del modulo non normalmente utilizzati per il codice (come titoli dei widget, brevi descrizioni) sono tipicamente più sicure.

WP-Firewall offre regole gestite e ottimizzate e patch virtuali per bloccare i modelli di attacco più comuni per XSS memorizzati mentre aggiorni e pulisci il sito.

---

Come WP-Firewall aiuta in questo scenario

Dalla prospettiva dei servizi di sicurezza di WP-Firewall e del WAF gestito:

• Patch virtuali rapide: il nostro team di sicurezza può implementare regole che mirano specificamente ai modelli di richiesta utilizzati per sfruttare questa vulnerabilità XSS memorizzata. Questo ferma la maggior parte dei tentativi di sfruttamento al confine senza attendere che l'aggiornamento del tema venga installato.
• Firme gestite per XSS memorizzati: aggiornamenti automatici delle firme bloccano modelli di payload XSS noti attraverso gli endpoint di invio admin e front-end.
• Protezione consapevole del contesto: WP-Firewall può creare regole personalizzate che bloccano solo le richieste agli endpoint o percorsi che il tema utilizza per memorizzare contenuti (riducendo i falsi positivi).
• Scansione malware e ispezione dei contenuti: rileva payload di script memorizzati in post, postmeta e opzioni e visualizzali nel dashboard per la remediazione.
• Monitoraggio dell'integrità dei file e pulizia post-compromissione: identifica i file modificati nel tema e avvisa per la remediazione oltre a fornire assistenza per la rimozione.
• Avvisi e registri forensi: cattura il payload esatto e i metadati della richiesta in modo da poter indagare sulla fonte di un account di contributore malevolo o tentativi di sfruttamento esterni.

Se hai bisogno di una riduzione immediata del rischio, la patch virtuale tramite un WAF gestito come WP-Firewall è un modo per guadagnare tempo per aggiornare, auditare e pulire il tuo sito in modo sicuro.

---

Comandi e query di rilevamento dettagliati (pratici)

Usa questi comandi di esempio per trovare contenuti sospetti. Esegui sempre il backup del tuo DB prima di eseguire operazioni distruttive.

Cerca i tag script nei post:

wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%' LIMIT 100;"

Trova postmeta sospetti:

wp db query "SELEZIONA post_id, meta_key DA wp_postmeta DOVE meta_value LIKE '%<script%' O meta_value LIKE '%onerror=%' LIMIT 200;"

Opzioni di ricerca e theme_mods:

wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%' OR option_value LIKE '%onerror=%' LIMIT 200;"

Scansiona i file PHP negli upload (indicatore negativo):

trova wp-content/uploads -type f -name "*.php" -ls

Elenca i file del tema modificati di recente:

trova wp-content/themes/the7 -type f -mtime -30 -ls

Grep veloce per frammenti JS sospetti nella directory del tema:

grep -RIn --exclude-dir=node_modules --exclude-dir=vendor "document.cookie\|eval(\|window.location" wp-content/themes/the7 || true

Se scopri post o meta sospetti, esportali prima di modificarli:

wp post get  --field=post_content > suspicious-post-.html

---

Se trovi codice sospetto: contenimento e pulizia

1. Esporta e isola contenuti sospetti per revisione — non eliminare immediatamente se ne hai bisogno per le indagini.
2. Rimuovi gli script dannosi dalle voci del DB. Usa strumenti di modifica sicuri (phpMyAdmin o WP-CLI).
3. Ruota tutte le password per gli utenti con capacità di editor/admin e forzare il logout per tutti gli utenti:
   • elenco utenti wp --role=administrator
   • wp user update --user_pass=
4. Cerca e rimuovi eventuali file che lo script dannoso potrebbe aver creato (controlla negli upload, mu-plugins e directory dei temi).
5. Controllo il file wp-config.php E .htaccess per modifiche.
6. Riesamina con uno scanner malware e rivedi manualmente i risultati.
7. Se trovi backdoor o modifiche persistenti, ripristina da un backup pulito effettuato prima della modifica dannosa, quindi riapplica le patch di sicurezza e il rafforzamento.

---

Piano di recupero se il tuo sito è stato compromesso

1. Metti il sito offline o impostalo in modalità manutenzione (sicurezza pubblica).
2. Crea un backup forense completo (file + DB) e conservalo fuori dal server.
3. Identificare il vettore iniziale (Account del contributore abusato? Password debole? Credenziali phishing?).
4. Rimuovere il contenuto e i file dannosi identificati nella copia forense.
5. Aggiornare il core di WordPress, tutti i temi (incluso The7) e i plugin alle loro ultime versioni.
6. Ruotare tutti i segreti: sali di WordPress, password di amministrazione, chiavi API, credenziali di terze parti.
7. Reinstallare o sostituire eventuali plugin o temi che sono stati modificati.
8. Eseguire nuovamente le scansioni fino a quando non è tutto pulito. Tenere registri di tutte le azioni per l'audit.
9. Considerare un audit di sicurezza professionale se non si è certi di una pulizia completa.

---

Raccomandazioni di indurimento a lungo termine

• Principio del minimo privilegio: Dare agli utenti le capacità minime di cui hanno bisogno. Rivalutare i ruoli di contributore e autore; utilizzare strumenti di invio senza codice o flussi di lavoro di moderazione.
• 2FA: Applicare l'autenticazione a due fattori per tutti gli account di amministrazione e di editor.
• Aggiornamenti regolari: Patchare il core, i temi e i plugin con una cadenza programmata. Utilizzare ambienti di staging per la verifica.
• Backup automatici: Backup giornalieri e retention offsite con test di ripristino rapidi.
• Monitoraggio dell'integrità dei file: Monitorare le modifiche a temi, plugin e file core.
• Limitare i plugin ed evitare estensioni non necessarie che accettano input HTML grezzo.
• Utilizzare un WAF gestito con patching virtuale per ridurre la finestra di esposizione per le vulnerabilità appena divulgate.
• Educazione degli utenti: Formare editor e contributori su phishing e attività sospette.
• Registrazione e monitoraggio: Registri centralizzati, allerta su azioni amministrative sospette e scansioni di sicurezza periodiche.

---

Esempi di regole WAF che possono essere utilizzate come base (concettuale)

Nota: Queste sono idee di regole ad alto livello — le distribuzioni in produzione richiedono test approfonditi per evitare di compromettere la funzionalità legittima.

1. Negare le richieste in cui i dati POST contengono <script o attributi di evento inline sospetti per percorsi che accettano contenuti:
   • Blocca quando REQUEST_METHOD = POST E REQUEST_URI corrisponde agli endpoint admin/post o delle opzioni tema E il corpo della richiesta corrisponde (?i)<\s*script\b|onerror\s*=|onload\s*=|javascript:
2. Blocca le firme di payload codificate o offuscate:
   • Segnala le richieste contenenti base64, valutazione(, documento.cookie, window.location, atob(, o lunghe sequenze di caratteri codificati nei campi del modulo.
3. Limita la velocità o blocca le richieste che creano rapidamente molti contenuti dallo stesso IP/user agent.
4. Monitora e blocca le richieste che tentano di aggiornare i file del tema tramite endpoint admin non normalmente utilizzati dai collaboratori.

---

Domande frequenti (FAQ)

Q: Se i collaboratori non possono essere fidati, perché permettere loro di partecipare?

UN: I collaboratori sono utili per molti siti (autori ospiti, contributi della comunità). L'obiettivo è controllare dove e come vengono visualizzati i loro contributi e moderare prima della visualizzazione. Dove è richiesto HTML/scripting grezzo, utilizzare editor di codice sicuri o consentire solo agli admin di pubblicare.

Q: L'aggiornamento del tema romperà il mio sito?

UN: Potrebbe se hai file del tema pesantemente personalizzati o modifiche al tema figlio. Testa l'aggiornamento prima su staging e fai sempre un backup.

Q: Un WAF può rompere il mio sito?

UN: Regole mal configurate possono farlo. Un WAF gestito che comprende il comportamento di WordPress minimizzerà i falsi positivi. La patch virtuale applicata da team esperti è tarata per proteggere senza interrompere il comportamento legittimo.

---

Appendice: CVE e crediti

• CVE: CVE-2026-6646
• Software interessato: The7 — Costruttore di siti web e eCommerce per WordPress tema ≤ 14.3.2
• Corretto in: 14.3.3
• Segnalato da: João Pedro Soares de Alcântara (Kinorth) — grazie alla divulgazione responsabile e allo sviluppatore per aver emesso una patch.

---

Lista di controllo rapida: Cosa fare subito

• Controlla la versione del tema The7. Se ≤14.3.2, aggiorna a 14.3.3 ora.
• Se non puoi aggiornare immediatamente, limita i privilegi dei Collaboratori, richiedi moderazione e abilita la patch virtuale WAF.
• Cerca nel tuo database e attributi di eventi in post, postmeta e opzioni. Rimuovi le voci sospette.
• Forza il reset delle password per gli account privilegiati e abilita l'autenticazione a due fattori.
• Scansiona i file del server e gli upload per file PHP o cambiamenti recenti inaspettati.
• Esegui il backup e preparati per una revisione forense se trovi indicatori di compromissione.

---

Proteggi il tuo sito oggi: Sicurezza di base immediata (Piano Gratuito)

Titolo: Protezione di base immediata — inizia gratuitamente oggi

Se desideri un modo veloce e pratico per ridurre il rischio di questa vulnerabilità mentre applichi aggiornamenti e pulisci, WP-Firewall offre un piano Base (Gratuito) sempre attivo che include protezioni essenziali: un firewall gestito, larghezza di banda illimitata, un WAF che può essere configurato per bloccare modelli XSS memorizzati, uno scanner malware e mitigazione per i rischi OWASP Top 10. Il piano gratuito è progettato per darti una copertura difensiva immediata mentre applichi patch, esegui audit e recuperi.

Iscriviti al piano Base (Gratuito) e ottieni protezione di base in pochi minuti: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Se hai bisogno di rimozione automatizzata, blacklist/whitelist IP, report di sicurezza mensili, o patch virtuali automatizzate e una risposta gestita, considera i livelli a pagamento (Standard e Pro) che si basano sul piano gratuito con rimedi proattivi, maggiore controllo e supporto dedicato.

---

Parole finali dal team di sicurezza di WP-Firewall

Lo XSS memorizzato è uno di quei problemi che possono iniziare in piccolo — un singolo account di collaboratore — e rapidamente trasformarsi in una compromissione a livello di sito. La risposta giusta è rapida e stratificata: applica la patch al tema vulnerabile il prima possibile, riduci la superficie di attacco e implementa controlli protettivi (WAF + monitoraggio) per tenere a bada gli attaccanti mentre pulisci.

Se hai bisogno di indicazioni per applicare i passaggi qui — o vuoi aiuto per implementare patch virtuali e scansionare per script iniettati — il nostro team può aiutarti. Inizia con un aggiornamento immediato del tema e un breve deployment di regole WAF per prevenire ulteriori sfruttamenti. Dai priorità ai compiti nella checklist rapida e segui con un audit completo se trovi prove di compromissione.

Rimani vigile e mantieni le tue installazioni WordPress aggiornate e monitorate.

— Team di Sicurezza WP-Firewall