Nome del plugin	Costruttore Themify
Tipo di vulnerabilità	Controllo di accesso interrotto
Numero CVE	CVE-2025-49396
Urgenza	Basso
Data di pubblicazione CVE	2025-08-20
URL di origine	CVE-2025-49396

Themify Builder <= 7.6.7 — Controllo degli accessi non funzionante (CVE-2025-49396): cosa devono fare ora i proprietari di siti WordPress

Autore: Team di sicurezza WP-Firewall
Data: 2025-08-20

Riepilogo: Un problema di controllo degli accessi non funzionante, reso pubblico e che interessa le versioni di Themify Builder fino alla 7.6.7 (CVE-2025-49396), può consentire a un account con privilegi inferiori ("Collaboratore") o a un account compromesso con privilegi simili di accedere a funzionalità che dovrebbero essere limitate. Il problema è stato risolto nella versione 7.6.8. Questo articolo illustra i rischi, gli scenari di sfruttamento, le misure di rilevamento e mitigazione che è possibile adottare immediatamente, incluso come proteggere il proprio sito con WP-Firewall (piano gratuito disponibile).

---

Sommario

• Cosa è successo (alto livello)
• Chi è interessato
• Perché questo è importante per i proprietari di siti WordPress
• Riepilogo tecnico della vulnerabilità (cosa significa qui "controllo di accesso interrotto")
• Scenari di sfruttamento realistici
• Misure immediate per proteggere il tuo sito (mitigazioni a breve termine)
• Rimedio a lungo termine consigliato (aggiornamento, rafforzamento, monitoraggio)
• Come un Web Application Firewall (WAF) e le patch virtuali possono aiutare e cosa aspettarsi da WP-Firewall
• Lista di controllo per la risposta agli incidenti: se si sospetta una compromissione
• Guida al rilevamento e alla registrazione (a cosa prestare attenzione)
• Esempi di modelli di regole WAF e regole di monitoraggio (sicure, difensive)
• Elenco di controllo per la configurazione sicura dei siti che utilizzano page builder e flussi di lavoro multi-autore
• Piano gratuito per WP-Firewall: proteggi il tuo sito a partire da oggi
• Note conclusive e ulteriori letture

---

Cosa è successo (alto livello)

Una vulnerabilità nel controllo degli accessi è stata divulgata pubblicamente e assegnata alla codifica CVE-2025-49396. Riguarda le versioni del plugin Themify Builder fino alla versione 7.6.7 inclusa. Il fornitore ha rilasciato la versione 7.6.8 che risolve il problema.

In parole povere: una funzione o un endpoint utilizzato dal builder non ha verificato correttamente che l'utente corrente avesse i privilegi richiesti. Ciò significa che un utente con privilegi inferiori (ruolo di Collaboratore) o un account compromesso con accesso equivalente potrebbe attivare funzionalità che avrebbero dovuto essere riservate a ruoli con privilegi più elevati (Editor/Amministratore). Le vulnerabilità del controllo degli accessi non funzionanti possono portare a manomissioni dei contenuti, escalation dei privilegi, caricamento di contenuti dannosi e altre azioni successive alla compromissione.

---

Chi è interessato

• Qualsiasi sito WordPress che utilizza il plugin Themify Builder versione 7.6.7 o precedente.
• Siti in cui agli utenti non attendibili è consentito l'accesso ad account di livello collaboratore o in cui gli account dei collaboratori potrebbero essere compromessi (password deboli, credenziali riutilizzate, phishing).
• Blog multi-autore, blog aziendali, siti di clienti in cui appaltatori o collaboratori esterni hanno accesso come contributori/editori.
• Siti che si affidano al plugin per le operazioni di creazione e layout del front-end.

Se esegui Themify Builder su un sito attivo, consideralo un problema fattibile e dai priorità alla revisione e alla mitigazione.

---

Perché questo è importante per i proprietari di siti WordPress

Il controllo degli accessi non funzionante è una delle categorie di problemi di sicurezza più comuni e impattanti. Quando un plugin non applica controlli di funzionalità (o nonce) su azioni o endpoint AJAX/REST, crea un percorso prevedibile che consente agli aggressori di compiere azioni che non dovrebbero essere in grado di compiere, e spesso automatizzano i tentativi di bloccare nuove divulgazioni.

Anche quando una vulnerabilità è classificata "bassa" in termini CVSS (in questo caso il punteggio CVSS è 4,3), l'impatto reale dipende da cosa un aggressore può fare dopo averla sfruttata. Un account a livello di collaboratore con la possibilità di modificare i layout del builder, inserire script o manipolare il contenuto dei post è già pericoloso: codice JavaScript dannoso, notifiche di amministrazione iniettate o un uso improprio creativo delle funzionalità del builder possono essere utilizzati per aumentare l'impatto e persistere su un sito.

Punti chiave:

• Questa vulnerabilità richiede l'accesso a un account con privilegi bassi (Collaboratore) o la compromissione riuscita dell'account.
• Il problema è stato risolto in Themify Builder 7.6.8; l'aggiornamento è la soluzione definitiva.
• Esistono delle misure di mitigazione immediate che puoi applicare se non riesci ad aggiornare subito (consigliato per siti di grandi dimensioni o complessi che necessitano di verifica di staging).

---

Riepilogo tecnico: cosa significa qui “Broken Access Control”

“Controllo accessi non funzionante” è una classificazione generica che comprende controlli mancanti o insufficienti che dovrebbero verificare:

• la capacità dell'utente corrente (ad esempio, current_user_can('edit_theme_options') o capacità X),
• il nonce/token corretto per prevenire CSRF e
• che il ruolo dell'utente sia autorizzato a eseguire l'azione richiesta.

In questa informativa, il percorso del codice vulnerabile esponeva la funzionalità del builder a utenti che non avrebbero dovuto avervi accesso. Il problema potrebbe presentarsi in:

• Gestori AJAX (admin-ajax.php) o endpoint REST registrati dal plugin,
• gestori di endpoint che implementano un'azione ma dimenticano di controllare current_user_can() o di controllare una capacità troppo permissiva,
• manca la convalida del nonce per le richieste di modifica dello stato.

Poiché la divulgazione ha classificato il privilegio richiesto come Collaboratore, la vulnerabilità deriva probabilmente da un percorso che presuppone che i collaboratori siano considerati attendibili per un'operazione correlata al builder, ma in realtà dovrebbero essere limitati.

---

Scenari di sfruttamento realistici

Comprendere i probabili scenari di exploit aiuta a stabilire le priorità di mitigazione.

Scenario A — Collaboratore malintenzionato:

• Il proprietario di un sito crea account per i collaboratori degli autori ospiti.
• Un collaboratore inserisce contenuti che sfruttano l'interfaccia utente del builder o attivano un endpoint del builder che dovrebbe essere riservato agli amministratori.
• A causa della mancanza del controllo di accesso, il collaboratore manipola le risorse di layout o inserisce script che il builder poi pubblica, con conseguente XSS memorizzato o inserimento di contenuti.

Scenario B — Account collaboratore compromesso:

• Un aggressore ottiene le credenziali del collaboratore (credential stuffing, password riutilizzate).
• L'aggressore utilizza l'account compromesso per chiamare l'endpoint vulnerabile ed eseguire azioni privilegiate (modificare modelli, inserire script rivolti all'amministratore o contenuti nascosti che possono portare a un'ulteriore compromissione).

Scenario C — Script di terze parti + CSRF:

• Se un endpoint che modifica lo stato non dispone di controlli nonce, un aggressore potrebbe indurre un collaboratore autenticato a visitare un URL esterno che attiva l'azione (falsificazione della richiesta tra siti), eseguendo una modifica non autorizzata senza interazione diretta.

Impatti potenziali:

• Manomissione dei contenuti o inserimento di codice JavaScript dannoso (visitatori del sito o amministratori esposti).
• Caricamento di file o inserimento di risorse che persistono nonostante le modifiche al contenuto.
• Creazione di una backdoor o modifica dei file del tema/plugin (se il costruttore può modificarli).
• Escalation dei privilegi come parte di una catena di attacco in più fasi.

Nota: l'insieme esatto di azioni possibili dipende dalla funzionalità del builder esposta prima della correzione. Trattare qualsiasi esposizione imprevista a funzionalità come seria.

---

Misure immediate per proteggere il tuo sito (mitigazioni a breve termine)

Se ospiti un sito con Themify Builder <= 7.6.7, esegui immediatamente le seguenti azioni, ordinate in base alla velocità e all'impatto:

1. Aggiorna Themify Builder alla versione 7.6.8 (consigliato)
   • La patch è la soluzione corretta. Aggiorna prima in un ambiente di staging se gestisci un sito complesso; quindi aggiorna la produzione.
   • Eseguire sempre il backup dei file e del database prima di effettuare l'aggiornamento.
2. Se non è possibile effettuare l'aggiornamento immediatamente, limitare chi può accedere
   • Revoca temporaneamente gli account dei collaboratori e degli autori oppure modifica i loro ruoli in ruoli più restrittivi finché non potrai effettuare l'aggiornamento.
   • Forza la reimpostazione della password per tutti gli utenti con accesso di livello collaboratore o superiore.
   • Controlla e rimuovi gli account inattivi o sospetti.
3. Disattiva le funzionalità non necessarie nel plugin
   • Se Themify offre opzioni per gli endpoint del builder remoto o per la modifica front-end, disabilitare tali funzionalità finché non vengono corrette.
   • Se il plugin espone un endpoint REST o un editor di builder pubblico rivolto all'amministratore, limitarlo tramite IP o altri controlli a livello di server.
4. Rafforzare le capacità degli utenti e i permessi di caricamento
   • Rimuovere la capacità upload_files dal ruolo Contributor, a meno che non sia necessario.
   • Utilizzare un plugin di gestione dei ruoli (o WP-CLI) per limitare le capacità degli account a livello di collaboratore.
5. Applicare patch virtuali temporanee a livello di server/WAF
   • Se si utilizza WP-Firewall o un WAF simile, abilitare una regola che blocchi le richieste agli endpoint del builder da account con privilegi bassi, blocchi i POST sospetti agli URI correlati al builder o rifiuti le richieste di modifica dello stato prive di un nonce valido.
   • Se non si dispone di un WAF, implementare, ove possibile, restrizioni IP sui percorsi di amministrazione wp-admin e builder.
6. Aumentare il monitoraggio e la registrazione
   • Abilitare e rivedere i registri di accesso, in particolare per il traffico degli endpoint admin-ajax.php e REST.
   • Monitora i nuovi file caricati, le modifiche inaspettate ai file dei plugin/temi e i nuovi utenti amministratori.

---

Bonifica a lungo termine consigliata (dopo interventi immediati)

1. Aggiorna tutti i siti che eseguono Themify Builder alla versione 7.6.8 o successiva
   • Eseguire il test in staging, eseguire il backup della produzione, quindi aggiornare.
   • Esegui nuovamente i test funzionali del tuo sito per assicurarti che i widget e le personalizzazioni del builder continuino a funzionare.
2. Applicare il principio del privilegio minimo per i siti multi-autore
   • Fornire i ruoli e le capacità minime necessarie ai collaboratori.
   • Se possibile, utilizzare flussi di lavoro editoriali (revisione delle bozze) anziché ampi privilegi di contributore.
3. Applicare un'autenticazione più forte
   • Richiedere password complesse, abilitare l'autenticazione a due fattori per gli utenti con privilegi più elevati e utilizzare una policy sulle password o un SSO per autori e amministratori.
4. Utilizzare patch virtuali e regole gestite
   • Un WAF con patch virtuale può bloccare i tentativi di exploit mentre si distribuisce la correzione pubblicata dal fornitore in tutti gli ambienti. Ad esempio, bloccare le chiamate non autorizzate agli endpoint del builder che dovrebbero essere eseguite solo dagli amministratori.
5. Manutenzione e controllo regolari dei plugin
   • Mantieni aggiornati tutti i plugin, i temi e il core di WordPress.
   • Stabilire una routine per la revisione dei plugin installati e la rimozione di quelli che non sono attivamente mantenuti o necessari.
6. Test di sicurezza e revisione del codice per codice personalizzato
   • Se tu o un appaltatore avete personalizzato la funzionalità del builder, verificate tutti gli endpoint personalizzati, le azioni AJAX o i percorsi REST per garantire che vengano applicati i controlli di capacità e i nonce appropriati.

---

Come un Web Application Firewall (WAF) e le patch virtuali possono aiutare e cosa aspettarsi da WP-Firewall

Un WAF responsabile svolge tre ruoli fondamentali per questo tipo di vulnerabilità:

1. Mitigazione immediata (patch virtuale)

   Le regole WAF possono bloccare i tentativi di exploit che prendono di mira gli endpoint vulnerabili del builder prima che un aggressore raggiunga WordPress. Questa funzionalità è particolarmente utile quando non è possibile un aggiornamento immediato (multisito di grandi dimensioni, finestre di manutenzione, test di dipendenza complessi).

2. Rilevamento basato sul comportamento

   I WAF possono rilevare modelli anomali, ad esempio un utente con privilegi bassi che attiva endpoint riservati agli amministratori o sequenze di richieste sospette che prendono di mira la funzionalità del builder.

3. Indurimento e limitazione della superficie di attacco

   I WAF possono limitare le richieste ai pannelli di amministrazione e agli endpoint del builder in base all'IP, richiedere determinate intestazioni o eliminare le richieste prive di nonce validi o cookie wp-auth.

Cosa farà WP-Firewall per il tuo sito:

• Se utilizzi WP-Firewall, implementeremo una regola di patch virtuale di emergenza per bloccare i vettori di exploit noti per questa divulgazione per i nostri clienti con piani gestiti (e forniremo indicazioni sulla configurazione agli utenti del piano gratuito).
• Il firewall gestito di WP-Firewall esamina le richieste in arrivo per individuare indicatori di exploit noti e può bloccare i tentativi che corrispondono alle firme contraffatte associate alla divulgazione, riducendo i rischi durante l'applicazione della patch.
• Le nostre routine di scansione e rilevamento del malware ti aiuteranno a identificare se si sono già verificati tentativi o attività sospette e a indirizzare la correzione.

Nota sulle aspettative:

• I WAF non sostituiscono le patch fornite dal fornitore. Sono controlli complementari che consentono di risparmiare tempo e ridurre i rischi durante l'applicazione delle patch e la risposta.
• L'applicazione di patch virtuali dovrebbe essere utilizzata insieme al monitoraggio e all'applicazione di patch di follow-up; si tratta di una strategia di contenimento, non di una soluzione permanente.

---

Lista di controllo per la risposta agli incidenti: se si sospetta una compromissione

Se ritieni che la vulnerabilità sia stata sfruttata sul tuo sito, segui questi passaggi prioritari:

1. Isolare il sito
   • Se viene confermata una grave compromissione, mettere temporaneamente il sito in modalità di manutenzione o metterlo offline.
   • Se ospitato in un ambiente condiviso, coordinarsi con l'host.
2. Eseguire backup e snapshot dei log
   • Esportare una copia del sito interessato (file + database) prima di apportare modifiche di pulizia: ciò supporta l'analisi forense.
   • Raccogli i log del server, i log di accesso, i log delle richieste admin-ajax.php e REST, i log di autenticazione.
3. Cerca indicatori di compromissione
   • Esegui la scansione di wp-content/uploads per individuare file PHP o eseguibili inaspettati.
   • Controllare le directory dei plugin e dei temi per individuare i file modificati di recente.
   • Cerca nel database contenuti sospetti inseriti in post, opzioni o metadati utente.
4. Rimuovere web shell e file dannosi
   • Se trovi web shell o file PHP nei caricamenti, rimuovili e verifica come sono stati introdotti.
   • Sostituisci i file dei plugin/temi modificati con copie pulite provenienti da fonti ufficiali.
5. Controlla utenti, autorizzazioni e chiavi API
   • Rimuovere gli account sospetti, forzare la reimpostazione delle password per tutti gli utenti amministratori/privilegiati, ruotare tutte le chiavi esposte (API/FTP/DB).
   • Se i collaboratori sono stati sfruttati, ruotare le loro credenziali e verificare la cronologia delle attività.
6. Ripristinare da un backup sicuramente funzionante, se necessario
   • Se l'integrità del sito è in dubbio e i tempi di pulizia sono lunghi, valuta la possibilità di ripristinare un backup precedente al compromesso, quindi applica la patch del plugin e altre misure di protezione.
7. Indurisci e ripeti il test prima di riportare il sito online
   • Applica aggiornamenti di plugin/temi/core, esegui nuovamente le scansioni anti-malware, verifica che i plugin provengano da fonti ufficiali e, se possibile, esegui i checksum.
   • Abilita la registrazione per rilevare le attività di follow-up.
8. Segnalare e registrare l'incidente
   • Mantenere un registro degli incidenti con date, azioni intraprese, backup e prove. Questo facilita l'analisi delle cause profonde e previene il ripetersi degli incidenti.

---

Guida al rilevamento e alla registrazione (a cosa prestare attenzione)

Poiché questa vulnerabilità riguarda il controllo degli accessi, il rilevamento si basa sull'identificazione di modelli di autorizzazione insoliti:

Indicatori di registro ad alta priorità:

• Richieste POST o GET ad admin-ajax.php o endpoint REST specifici del builder da account/client con privilegi bassi.
• Richieste con parametri di query specifici del builder o valori di azione che normalmente vengono attivati solo dall'interfaccia utente di amministrazione.
• Richieste POST ripetute agli endpoint del builder dallo stesso IP o account (automazione).
• Richieste prive di un nonce WP valido quando l'endpoint in genere ne prevede uno (assenza di token nonce nel corpo del POST).
• Nuovi file caricati su /wp-content/uploads con estensione .php o nomi offuscati.
• Modifiche inaspettate a post, pagine, modelli o file di temi.

Modelli di ricerca da eseguire nei log (esempi):

• Filtra i registri di accesso per le richieste admin-ajax.php e controlla il parametro "azione".
• Cerca le richieste a /wp-json/ che contengono "themify", "builder" o altri token identificativi del builder.
• Cerca un'attività elevata da parte degli account dei collaboratori: molti POST in un breve periodo o POST al di fuori del normale orario di lavoro.

Suggerimento: mantieni una regola di tagging e avviso che segnali quando gli utenti a livello di collaboratore eseguono azioni solitamente associate a editor o amministratori.

---

Esempi di modelli di regole WAF e regole di monitoraggio (difensive, sicure)

Di seguito sono riportati esempi di modelli di regole difensive e di monitoraggio. Si tratta di modelli concettuali che devono essere adattati al vostro ambiente. Non utilizzateli come modelli di exploit: sono difensivi.

1. Blocca le azioni sospette del builder admin-ajax.php per i ruoli non autorizzati
   • Condizione: richiesta a /wp-admin/admin-ajax.php con POST e parametri di azione corrispondenti alle azioni correlate al builder.
   • Azione: bloccare o contestare (403) quando la richiesta non dispone di un'intestazione nonce valida o proviene da una sessione non autenticata.

   Pseudocodice:
   SE request_uri contiene “/admin-ajax.php” E metodo == POST E params[“action”] corrisponde a /(themify|builder|tfb)_/i
     – E request-cookie non contiene un cookie wordpress_logged_in valido OPPURE nonce mancante/non valido
     – POI blocca o richiedi la sfida

2. Blocca le chiamate degli endpoint REST agli endpoint del builder da origini non amministrative
   • SE request_uri contiene “/wp-json/themify” OPPURE “/wp-json/builder” E metodo di richiesta in (POST, PUT, DELETE)
   • POI blocca a meno che la richiesta non provenga dall'intervallo IP dell'amministratore o da una sessione amministratore autenticata valida
3. Limitare le azioni sospette dei collaboratori
   • SE il ruolo utente = collaboratore (dedotto da cookie/sessione) E > N POST agli endpoint del builder in M secondi
   • POI accelerare o bloccare
4. Rileva il nonce mancante nelle richieste che cambiano stato
   • SE POST all'endpoint del builder E il parametro nonce è assente OPPURE il formato non è valido
   • POI log + aumenta il punteggio di rischio, opzionalmente blocca
5. Ispezione del caricamento dei file
   • SE la richiesta genera un nuovo file nei caricamenti con estensione .php o doppia estensione (.jpg.php)
   • POI metti in quarantena il file e avvisa

Note:

• Il rilevamento WAF che si basa sui cookie o sui dati di sessione deve essere configurato correttamente per analizzare i cookie di WordPress e dovrebbe evitare falsi positivi per gli utenti amministratori validi.
• Le regole di patching virtuale devono essere testate in modalità di monitoraggio prima dell'applicazione per verificare la presenza di falsi positivi.

---

Elenco di controllo per la configurazione sicura dei siti che utilizzano page builder e flussi di lavoro multi-autore

Utilizzare questa checklist per ridurre la possibilità che una vulnerabilità simile abbia un impatto significativo:

Account e ruoli

• Applicare il principio del privilegio minimo: fornire ai collaboratori solo le capacità di cui hanno bisogno.
• Rimuovere upload_files da Contributor a meno che non sia esplicitamente richiesto.
• Implementare l'autenticazione a due fattori per editor e amministratori (e valutare attentamente anche per gli autori).

Igiene dei plugin

• Mantieni aggiornati Themify Builder e tutti i plugin/temi.
• Rimuovere i plugin e i temi non utilizzati dal server.
• Monitorare i registri delle modifiche dei plugin e iscriversi alle notifiche di sicurezza del fornitore (se disponibili).

Server e protezione WP

• Disabilita la modifica del file (define('DISALLOW_FILE_EDIT', true);).
• Imposta permessi rigorosi sui file (file 644, cartelle 755, wp-config.php 600/640 dove possibile).
• Se possibile, limitare l'accesso a wp-admin tramite IP oppure aggiungere un'autenticazione aggiuntiva prima di admin.

Rete e WAF

• Installa un WAF davanti al tuo sito e abilita l'applicazione di patch virtuali per le divulgazioni ad alto rischio.
• Limita la frequenza degli endpoint wp-admin e builder.
• Blocca gli user agent sospetti o gli scanner automatici che analizzano gli endpoint del builder.

Monitoraggio e backup

• Utilizza backup giornalieri automatizzati archiviati fuori sede; testa periodicamente il processo di ripristino.
• Abilitare la registrazione e la conservazione per almeno 90 giorni per i registri critici per la sicurezza (registri di accesso, di errore e di controllo).
• Esegui scansioni malware pianificate.

Test e messa in scena

• Testare gli aggiornamenti dei plugin negli ambienti di staging prima della produzione.
• Mantenere un sito di staging/test separato che rispecchi le versioni dei plugin di produzione per i test di accettazione.

---

Piano gratuito per WP-Firewall: proteggi il tuo sito a partire da oggi

Titolo: Proteggi il tuo sito WordPress con la protezione gestita: inizia gratuitamente

Se desideri un livello di difesa immediato e pratico mentre applichi patch e rafforzi il tuo sito, valuta la possibilità di sottoscrivere il piano gratuito di WP-Firewall. Il nostro piano Basic gratuito include un firewall gestito, WAF, uno scanner antimalware e la mitigazione per i 10 principali rischi OWASP: esattamente le protezioni che aiutano a contenere e bloccare tentativi di exploit come la divulgazione di accessi non funzionanti da parte di Themify Builder durante l'aggiornamento alla versione corretta del plugin.

Inizia con il piano Basic gratuito qui: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Cosa ti offre il piano gratuito (breve riassunto):

• Firewall gestito essenziale e regole WAF su misura per WordPress.
• Larghezza di banda illimitata protetta dal nostro livello WAF (nessun limite di traffico).
• Guida alla scansione e alla pulizia del malware su richiesta.
• Protezione e mitigazione per i 10 principali vettori OWASP, come il controllo degli accessi non funzionante e XSS.

Se in seguito desideri l'implementazione automatica di patch virtuali, report pianificati o un gestore di sicurezza dedicato, WP-Firewall offre anche livelli di aggiornamento con questi servizi avanzati.

---

Note di chiusura e checklist immediata consigliata

Se esegui Themify Builder su un sito qualsiasi, procedi ora come segue (in ordine di priorità):

1. Backup: Backup completo di file + database.
2. Aggiornamento: Aggiorna Themify Builder alla versione 7.6.8 (se necessario, esegui prima lo staging).
3. Utenti di audit: Forzare la reimpostazione delle password per i collaboratori e i livelli superiori; rimuovere gli account non utilizzati.
4. WAF: Se si utilizza WP-Firewall, assicurarsi che il set di regole di emergenza sia abilitato; in caso contrario, abilitare tutte le patch virtuali disponibili e rafforzare i percorsi di amministrazione.
5. Scansione: Esegui una scansione completa del malware e controlla i caricamenti e i file modificati.
6. Monitorare: Esaminare i registri per individuare attività sospette relative agli endpoint del builder e ad admin-ajax.php.
7. Indurire: Rimuovere le funzionalità non necessarie dai ruoli con privilegi bassi e implementare l'autenticazione a due fattori per gli utenti con privilegi elevati.

Nota finale del team WP-Firewall: i problemi di controllo degli accessi non funzionanti sono spesso "invisibili" finché qualcuno non tenta intenzionalmente di abusarne. Ecco perché le difese a più livelli sono importanti: privilegi minimi, patch tempestive e protezioni a livello di rete riducono il rischio e danno il tempo di reagire senza interruzioni.

Se hai bisogno di assistenza per l'implementazione di patch virtuali o di una revisione della sicurezza per un sito che esegue Themify Builder, il nostro team può aiutarti a diagnosticare l'esposizione e implementare rapidamente le protezioni. Inizia con il piano gratuito per ottenere WAF e scansione gestiti, e aggiornalo in base alle tue esigenze per l'applicazione automatizzata di patch virtuali e la correzione gestita.

Rimani al sicuro,
Team di sicurezza WP-Firewall