Fin dalle prime ore di maggio 2026, i miei sistemi di monitoraggio hanno segnalato un’allerta critica: il plugin Brizy – Page Builder, utilizzato da oltre 90.000 siti WordPress, è vulnerabile a un attacco Stored XSS unauthenticated (CVE-2026-5324). In questa guida vi mostro come identificare se i vostri siti sono esposti, come verificare la compromissione con strumenti di debug reali, e soprattutto come implementare WAF virtual patching in tempo reale su Plesk e Cloudflare mentre attendete i patch ufficiali.
Ho già assistito clienti nella identificazione di form compromesse in Brizy: la vulnerabilità sfrutta campi di upload vuoti e una catena di errori che trasforma l’input in un payload JavaScript eseguito nelle sessioni admin. Vi spiego esattamente cosa succede dietro le quinte, e come difendersi in 30 minuti.
Comprendere CVE-2026-5324: La Catena di Errori in Brizy
La vulnerabilità è dovuta a una combinazione di mancanza di verifica nonce per i form unauthenticated, gestione insufficiente dei campi FileUpload quando nessun file è caricato, e reversione della codifica di sicurezza tramite html_entity_decode() seguita da output non escapato nella vista admin.
Nel dettaglio tecnico:
- La funzione submit_form() salta la verifica nonce per gli utenti non loggati (api.php:198)
- La funzione handleFileTypeFields() non sovrascrive i valori forniti dall’utente quando nessun file è allegato
- Mentre htmlentities() è applicato durante il salvataggio, html_entity_decode() lo inverte al display (form-entries.php:79)
- Il template form-data.php output i valori FileUpload direttamente negli attributi href senza esc_url()
Il risultato: gli attaccanti unauthenticated possono iniettare script web arbitrari che si eseguono quando un amministratore visualizza la pagina Form Leads. La gravità è CVSS 7.2 (Alta).
Chi è Veramente Esposto?
I siti che utilizzano il plugin Brizy interessato e consentono i form pubblici per la cattura lead sono più a rischio. Le organizzazioni con basso monitoraggio admin o uso frequente del dashboard admin sono particolarmente esposte.
Nella mia esperienza di auditing su decine di agenzie web, i form pubblici in Brizy sono ovunque: landing page, form di contatto, prenotazioni. Se il vostro sito ha una form Brizy pubblica e versione ≤ 2.8.11, siete vulnerabili ora.
Step 1: Identificare Plugin Compromessi con WP-CLI e Database Query
Nel mio ambiente di testing in Plesk, ho verificato il metodo più diretto: ispezione del database e dei file plugin.
Via WP-CLI (rapido)
# Check Brizy version
wp plugin list | grep brizy
# Full plugin data
wp plugin get brizy --field=version
wp plugin get brizy --field=is_activeSe la versione è ≤ 2.8.11 e il plugin è attivo: ALLERTA.
Verificare Form Entries Compromesse (Query MySQL diretta)
Una volta entrati nel database WordPress via Plesk Console o CLI:
-- Inspect form entries for suspicious payloads
SELECT id, form_id, created_at, updated_at
FROM wp_brizy_form_entries
WHERE data LIKE '%script%'
OR data LIKE '%javascript%'
OR data LIKE '%onerror%'
OR data LIKE '%onload%'
LIMIT 20;Se trovate righe, significa che il vostro sito è stato probabilmente sfruttato. Documentate gli ID e gli orari: avrete una timeline di quando è avvenuto l’accesso.
La vera sfida è che i payload sono stored: rimangono nel database e si eseguono ogni volta che un admin visualizza la pagina Form Leads. Ho visto casi in cui il malware era persistente per settimane.
Step 2: Analizzare i Log d’Accesso per Intrusioni
Rivedete i caricamenti delle pagine admin WordPress per indicatori anomali di Stored XSS nei dati delle voci del form (valori del campo FileUpload, attributi href). Cercate voci sospette salvate da richieste unauthenticated agli endpoint di invio form del plugin. Monitorate l’esecuzione JavaScript inaspettata nelle pagine originate dall’admin (tentativi di bypass CSP, script inline insoliti). Controllate i log WAF/proxy per invii di form contenenti pattern di payload HTML/JS codificati che prendono di mira i campi FileUpload.
In Plesk, accedo ai log del server per analizzare le richieste POST non autenticate:
# Analizzare richieste POST ai form endpoint di Brizy
grep "POST.*brizy.*form" /var/log/apache2/domains/tuodominio.com.log | tail -100
# Cercare payload XSS comuni nei log
grep -i "script|onerror|javascript:" /var/log/apache2/domains/tuodominio.com.log | grep -v User-AgentSe vedete POST requests ai form Brizy da IP sconosciuti, soprattutto con payload codificati (base64, URL-encoded), preparatevi al response di incident.
Step 3: Implementare WAF Virtual Patching su Plesk Obsidian
Qui entra in gioco la parte pratica: non potete aspettare un patch ufficiale se i vostri siti sono under attack. Il virtual patching blocca i payload noti a livello HTTP, prima ancora che il PHP vulnerabile li elabori.
Opzione A: ModSecurity in Plesk con Regole Custom
Se il vostro server Plesk ha ModSecurity (che raccomando in tutti i miei setup), aggiungete una regola che blocca i payload XSS nei parametri FileUpload di Brizy:
# File: /etc/apache2/mods-enabled/security.conf o custom rule file
# Bloccare richieste POST ai form di Brizy con payload sospetti
SecRule REQUEST_URI "@rx /wp-admin/admin.php.*brizy_form"
"id:1001001,phase:2,chain,log,deny,status:403,msg:'Brizy FileUpload XSS Attempt'"
SecRule REQUEST_BODY "@rx (<script|javascript:|onerror=|onload=|eval(|<iframe)"
"t:urlDecode,t:htmlDecode"
# Alternativa: Bloccare specificamente il parametro file_upload
SecRule ARGS:file_upload "@rx (<script|javascript:|onerror=|event[A-Za-z]*=)"
"id:1001002,phase:2,deny,log,status:403,msg:'Brizy XSS - FileUpload Parameter'"
# Bloccare base64-encoded payloads (spesso usati per evasione)
SecRule REQUEST_BODY "@rx PHNjcmlwdHw|PHN2Zy98aWZyYW1lfHNjcmlwdHxvbmVycm9y"
"id:1001003,phase:2,deny,log,status:403,msg:'Base64 XSS Payload Detection'",t:base64Decode
Dopo aver aggiunto le regole, testare in detection mode (non_blocking) per 24 ore, poi attivare il blocking:
# Restart Apache con log delle violazioni
sudo systemctl restart apache2
# Monitorare i log ModSecurity
tail -f /var/log/apache2/modsec_audit.log | grep "Brizy XSS"
Opzione B: Cloudflare WAF Rules (se il dominio è dietro Cloudflare)
Nel dashboard Cloudflare, navigare a Security → WAF Rules e creare una regola custom:
(http.request.uri.path contains "/wp-admin/admin.php" and http.request.method eq "POST")
and
(http.request.body.string matches "(<script|javascript:|onerror=|eval(|<iframe)")
# Azione: Block (HTTP 403)
# Logging: Enabled
# Priority: High
Cloudflare applicherà il blocco globale in pochi secondi, senza necessità di restart del server.
Opzione C: Nginx + ModSecurity (se non usate Apache)
Se il vostro Plesk è configurato con Nginx (come nel mio ambiente di produzione), ModSecurity v3 è disponibile con il connettore nginx:
# /etc/nginx/modsecurity.d/cve-2026-5324-brizy.conf
SecRule REQUEST_BODY "@rx (FileUpload.*?<script|file_upload.*?onerror)"
"id:9000001,phase:2,deny,log,status:403,msg:'CVE-2026-5324 Brizy XSS Block'"
Reload nginx: sudo systemctl reload nginx
Step 4: Disabilitare Temporaneamente le Form di Brizy (Soluzione d’Emergenza)
Trattate come priorità 1: applicate il patch di Brizy prontamente a una versione al di là della gamma interessata; se l’applicazione immediata del patch è ritardata, disabilitate temporaneamente le funzionalità di form/lead interessate.
Se non potete aspettare: via WP admin o WP-CLI, disabilitate il plugin:
wp plugin deactivate brizy --allow-root
# O via Plesk (se configurato):
plesk ext wordpress-toolkit -c deactivate-extension -extension-id brizy
Ciò interrompe immediatamente la vulnerabilità, ma blocca anche l’editor Brizy. Comunicate ai clienti che le pagine Brizy rimangono live, ma la modifica è temporaneamente disabilitata.
Step 5: Incident Triage – Verificare la Compromissione Admin
Eseguite il triage per il compromesso della sessione admin (rivedete i recenti accessi admin, i cambiamenti di sessione e le modifiche inaspettate di plugin/tema/file), con change management per assicurare che il patch sia distribuito coerentemente in tutte le istanze WordPress.
Nel mio flusso di audit:
# Verificare login admin recenti (se avete Access Logs Plugin o audit nativo)
wp user list --role=administrator
wp user get 1 --field=user_login,user_email
# Controllare le sessioni admin
SELECT user_login, meta_key, meta_value
FROM wp_users
JOIN wp_usermeta ON wp_users.ID = wp_usermeta.user_id
WHERE meta_key LIKE 'session%'
ORDER BY user_login;
# Verificare il timestamp dell'ultimo accesso
SELECT user_login, MAX(meta_value) as last_login
FROM wp_usermeta
JOIN wp_users ON wp_users.ID = wp_usermeta.user_id
WHERE meta_key = 'last_login'
GROUP BY user_login;
Se vedete login da IP sconosciuti o a orari insoliti, cambiate immediatamente le password admin e forzate il logout di tutte le sessioni:
# Invalidare tutte le sessioni tranne la vostra
wp user session destroy --all --except-current --allow-root
# Oppure via database:
DELETE FROM wp_options WHERE option_name LIKE '%session%';
FLUSH PRIVILEGES;Step 6: Pulire i Payload Stored dal Database
Se avete identificato form entries compromesse, pulitele prima di re-abilitare Brizy:
-- Backup PRIMA
-- mysqldump -u root -p wordpress > backup-$(date +%s).sql
-- Rimuovere voci form sospette
DELETE FROM wp_brizy_form_entries
WHERE data LIKE '%script%'
OR data LIKE '%onerror%'
ORDER BY updated_at DESC
LIMIT 50; -- Limitare per sicurezza
-- Oppure sanitizzare (più sicuro che cancellare)
UPDATE wp_brizy_form_entries
SET data = REGEXP_REPLACE(data, ']*>.*?', '', 'gi')
WHERE created_at >= DATE_SUB(NOW(), INTERVAL 7 DAY);Prima di eseguire, fate sempre un backup completo del database in Plesk:
plesk db dump wordpress > /backup/wordpress-pre-cleanup-$(date +%Y%m%d).sqlFAQ
Il mio sito è davvero vulnerabile se disabilito le form pubbliche di Brizy?
No. La vulnerabilità richiede che qualcuno invii dati tramite una form pubblica di Brizy. Se le form sono disabilitate o il plugin è disattivato, il vettore d’attacco scompare immediatamente. Tuttavia, i payload già stored nel database rimangono finché non vengono puliti.
Devo aggiornare Brizy solo a versione 2.8.12+ o c’è una versione sicura consigliata?
Brizy dovrebbe rilasciare una versione patch ufficiale entro maggio 2026. Nel frattempo, attendete un comunicato ufficiale dal team di Brizy o dalla community (Wordfence, Patchstack). Non aggiornate a versioni non verificate da fonti ufficiali.
Il WAF virtual patching è sufficiente per proteggermi da CVE-2026-5324?
No. Un WAF può mitigare e bloccare i tentativi (virtual patching) ma non è un sostituto per applicare il fix del codice ufficiale. Usate il WAF come misura per guadagnare tempo fino a quando gli aggiornamenti non sono distribuiti. Virtual patching è una difesa temporanea, non permanente.
Come monitoro i tentativi di sfruttamento della vulnerabilità su Plesk?
Controllate i log ModSecurity/WAF, i log di Apache/Nginx, e configurate un alert SIEM (ELK Stack, Splunk) che catturi le violazioni delle regole WAF. In Plesk, potete anche usare estensioni come ModSecurity Dashboard o Fail2Ban per un response automatico ai pattern malevoli.
Devo avvisare i miei clienti della vulnerabilità?
Sì, se gestite siti per clienti, create un comunicato (email, ticketing) che spieghi: (1) Se il loro sito usa Brizy ≤ 2.8.11, (2) Il rischio specifico (XSS via form pubbliche), (3) Le azioni che state intraprendendo (WAF, patching, monitoraggio), (4) La timeline prevista. La trasparenza costruisce fiducia e vi protegge legalmente.
Conclusione: Proteggere i Vostri Siti da CVE-2026-5324
CVE-2026-5324 è una vulnerabilità reale, critica e attivamente sfruttata a maggio 2026. Non potete ignorarla aspettando i patch ufficiali. La mia procedura in 6 step—identificare, analizzare log, implementare WAF virtual patching, disabilitare se necessario, verificare compromissione e pulire il database—vi protegge in meno di un’ora di lavoro.
La lezione pratica che condivido con i colleghi system administrator: il WAF virtual patching non è una opzione di lusso, è una necessità operativa. Vi permette di proteggere i clienti senza downtime, guadagnare tempo per testing e patch, e mantenere il controllo della timeline di remediation.
Se gestite infrastrutture multi-tenant in Plesk (come molte agenzie web), implementate ModSecurity rules centralizzate e sincronizzate Cloudflare WAF per coprire tutte le varianti di deployment. Commentate qui sotto con la vostra esperienza di patching di Brizy o altre vulnerabilità WordPress critiche—sono sempre interessato a confrontarmi su best practice real-world con altri sysadmin.