11.334 nuove vulnerabilità WordPress nel 2025. Tempo mediano al primo exploit: 5 ore dal rilascio della CVE. Tre plugin con installazioni combinate che superano 1,7 milioni di siti — WPvivid, Smart Slider 3 e User Registration & Membership — hanno CVE critiche attive in questo momento, e almeno una è già sotto attacco. Se gestisci WordPress su un LXC Proxmox, un VPS, o qualsiasi installazione self-hosted, questo non è un post da leggere con comodo.
Le vulnerabilità plugin WordPress 2026 che contano adesso
CVE-2026-1357: RCE senza autenticazione in WPvivid (CVSS 9.8)
WPvivid Backup & Migration, 900.000+ installazioni attive, versioni fino alla 0.9.123: un attaccante remoto senza nessuna credenziale può eseguire codice arbitrario sul server. Il meccanismo è una concatenazione di due falle — non una.
Prima falla: openssl_private_decrypt() non interrompe l'esecuzione in caso di fallimento — passa false alla routine AES, che lo interpreta come chiave nulla prevedibile (\x00x16). Seconda falla: path traversal da mancata sanitizzazione dei nomi file nel backup, che permette scrittura di una webshell in /wp-content/uploads/. Risultato: shell come www-data sul server.
"Full compromise of the WordPress installation is trivial from this point" — Ostorlab, analisi tecnica CVE-2026-1357
CVE-2026-3098: wp-config.php leggibile in Smart Slider 3
Iscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
Cybersecurity
CVE-2026-7482, Bleeding Llama fa sanguinare 300mila server Ollama
CVE-2026-7482: con tre chiamate API la vulnerabilita Ollama 2026 Bleeding Llama leakka memoria e token da 300k server esposti. Patch e mitigazioni.
Smart Slider 3, 800.000+ siti totali, circa 500.000 non ancora aggiornati alla data di pubblicazione: la funzione
actionExportAll
non valida il tipo di file esportato. Un utente con account subscriber — la categoria di account più bassa, quella che spesso si crea per accedere a contenuti riservati — può leggere
wp-config.php
direttamente.
In un homelab multi-sito con database condiviso, quello che sembra un problema limitato a un singolo sito diventa accesso a tutta l'infrastruttura. Credenziali DB, chiavi crittografiche, salt: tutto in chiaro in quel file. Patch: v3.5.1.34 (24 marzo 2026).
Conferma RCE via lettura /etc/passwd su CVE-2026-1357 (WPvivid ≤0.9.123) — credit: Ostorlab
CVE-2026-1492: privilege escalation già in-the-wild
Questa è quella da risolvere adesso, non tra dieci minuti. User Registration & Membership di WPEverest, versioni fino alla 5.1.2: il plugin accetta parametri di ruolo lato client senza validazione server-side durante la registrazione. Chiunque può creare un account admin su qualsiasi sito che lo usa.
Defiant (il team dietro Wordfence) ha bloccato più di 200 tentativi di exploit in 24 ore sulle installazioni dei propri clienti. CVSS 9.8. Exploit attivo, confermato, con numeri concreti.
Il quadro generale: 91% delle falle viene dai plugin
Il report Patchstack State of WordPress Security 2026 mette in fila i numeri: 11.334 nuove vulnerabilità nell'anno, +42% rispetto al 2024. Le falle high severity sono aumentate del +113%. Il core WordPress? 6 vulnerabilità in tutto l'anno. Il 91% del problema sono i plugin, il 9% i temi.
Al 4 marzo 2026, il report LOUD Agency censisce 108 vulnerabilità attive con 8 plugin critici ancora senza patch. Tra questi: W3 Total Cache con 900.000+ installazioni (CVE-2026-27384, Arbitrary Code Execution), Widget Options con 100.000+ (CVE-2026-27984, RCE), Royal Addons Elementor con 600.000+ (CVE-2026-28135). Nessuna patch disponibile al momento del report.
Un dettaglio che vale la pena tenere a mente quando si sceglie un plugin a pagamento: Secondo il report Patchstack 2026, i componenti da marketplace premium (come Envato) hanno tre volte più Known Exploited Vulnerabilities dei plugin gratuiti. Il prezzo non è una proxy della sicurezza.
Su questo fronte, la gestione delle identità per il tuo homelab è un problema separato ma correlato: se un attaccante ottiene credenziali da wp-config.php e le tue applicazioni condividono le stesse password, il danno si moltiplica. Centralizzare l'autenticazione con Authentik SSO homelab: un login per 14 container riduce la superficie d'attacco: un breach non compromette tutto il resto.
Hardening WordPress self-hosted: cosa fare nei prossimi 30 minuti
Il checklist che segue usa esclusivamente misure dalla documentazione ufficiale WordPress e da fonti verificate. Nessuna raccomandazione da "top 10 plugins" — quelle liste sono spesso aggiornate raramente e non distinguono tra misure server-level e misure applicazione.
1. Aggiornamenti immediati (5 minuti)
WPvivid Backup & Migration: aggiornare a v0.9.124, o disabilitare la feature "receive backup from another site" se non necessaria
Smart Slider 3: aggiornare a v3.5.1.34
User Registration & Membership: aggiornare a v5.1.4 o rimuoverlo se non in uso attivo
W3 Total Cache, Widget Options, Royal Addons Elementor — nessuna patch disponibile: valutare la disinstallazione temporanea finché non escono fix
2. Proteggere wp-config.php (10 minuti)
Dalla documentazione ufficiale WordPress Hardening: permessi corretti sul file più sensibile dell'installazione.
bash
# Permessi wp-config.php
chmod 400 /var/www/html/wp-config.php
# Regola .htaccess (Apache) — blocca accesso diretto
<Files "wp-config.php">
Require all denied
</Files>
# In wp-config.php: blocca editor file dalla dashboard
define('DISALLOW_FILE_EDIT', true);
# Opzione avanzata: sposta wp-config.php sopra la document root
mv /var/www/html/wp-config.php /var/www/wp-config.php
3. WAF: la scelta giusta per sicurezza wordpress homelab
Wordfence free è il punto di partenza realistico per chi gestisce WordPress su homelab a budget zero: WAF endpoint server-side, malware scanner, 2FA, protezione login. Il limite da conoscere: le signature del piano free hanno 30 giorni di ritardo rispetto al premium.
Dato che il tempo mediano al primo exploit è 5 ore, 30 giorni di ritardo sulle signature significa che per le falle più pericolose il WAF plugin non ti protegge nell'intervallo critico. La vera difesa in quella finestra è l'aggiornamento immediato del plugin vulnerabile — non il WAF.
Se controlli il server (LXC Proxmox, VPS con accesso root), aggiungi un layer server-level: ModSecurity con OWASP Core Rule Set per Apache o Nginx, più rate limit su wp-login.php e Fail2ban per il brute force. Questi strumenti agiscono prima che la richiesta arrivi a PHP, indipendentemente dalle signature.
WPvivid Backup plugin ≤0.9.123 nel pannello admin WordPress: la versione vulnerabile a CVE-2026-1357 — credit: Ostorlab
4. Automazione aggiornamenti e backup separato
WP-CLI permette di automatizzare gli aggiornamenti via cron su server senza interfaccia grafica — utile se gestisci più istanze WordPress nel tuo homelab. Il backup deve essere fisicamente separato dall'installazione: un backup nella stessa directory del sito è inutile se l'installazione viene compromessa (la stessa falla WPvivid scrive nella cartella uploads, che spesso è inclusa nei backup locali).
Chi gestisce più servizi self-hosted ha spesso il problema del monitoraggio distribuito: sapere quando un sito va giù o quando un aggiornamento fallisce. Su questo avevamo analizzato Uptime Kuma su PikaPods come monitoring esterno — utile anche per tenere d'occhio i siti WordPress dopo il hardening.
5. Riduzione della superficie d'attacco
Cambiare prefisso tabelle DB da wp_ — mitiga alcune categorie di SQL injection che assumono il prefisso default
Disabilitare XML-RPC se non usato — attack vector storico, non necessario nella maggior parte delle installazioni moderne
Abilitare aggiornamenti automatici per security release: define('WP_AUTO_UPDATE_CORE', 'minor') in wp-config.php
Rivedere periodicamente i plugin installati: ogni plugin disattivato ma non rimosso è codice vulnerabile che gira sul server
Il verdetto
Le vulnerabilità plugin WordPress 2026 non sono nuove per tipologia — privilege escalation via role injection, file read da funzioni di export, RCE da gestione crittografica difettosa sono categorie note da anni. Quello che cambia è il volume: +42% in un anno, +113% per le falle high severity, tempo mediano all'exploit di 5 ore. Per chi gestisce WordPress in self-hosted, la differenza tra un'installazione sicura e una compromessa si misura in ore, non in settimane. Le patch esistono per tutte e tre le CVE trattate. L'unica variabile è quanto tempo ci si mette ad applicarle.
