Vulnerabilita di WordPress nel 2025: Perche il Tuo Sito e Ancora a Rischio

Perche WordPress Rimane il Bersaglio Piu Grande del Web

WordPress gestisce circa il 43% di tutti i siti web su internet. Questo numero da solo spiega perche gli attaccanti lo prendano di mira cosi intensamente. Se trovi un exploit che funziona su un'installazione WordPress predefinita, hai potenzialmente accesso a centinaia di migliaia di siti. Per un attore malevolo, questo e un ritorno sull'investimento straordinario.

Tuttavia, molti imprenditori a Lugano e in tutta la Svizzera trattano ancora WordPress come fosse una brochure statica configurata una volta e poi dimenticata. La realta e molto piu complessa. WordPress e un software attivo con una catena di dipendenze massiccia: un runtime PHP, un database MySQL o MariaDB, un web server, il core WordPress stesso, un tema e da cinque a cinquanta plugin. Ognuno di questi livelli e un potenziale punto d'ingresso.

In questo articolo, analizzeremo le classi di vulnerabilita piu critiche che colpiscono i siti WordPress nel 2025, faremo riferimento a CVE reali, spiegheremo perche molte agenzie web non mantengono i siti sicuri e vi daremo una checklist concreta di hardening su cui potete agire immediatamente.

Core e Versioni PHP Obsolete

Il Problema degli Aggiornamenti del Core WordPress

WordPress ha un meccanismo di auto-aggiornamento decente per le release minori (es. 6.4.1 a 6.4.2). Ma gli aggiornamenti di versione maggiore (es. 6.4 a 6.5) richiedono intervento manuale, e molti proprietari di siti li saltano per paura che qualcosa si rompa. Questa paura non e del tutto infondata: plugin e temi possono essere incompatibili con le nuove versioni del core. Ma l'alternativa e molto peggiore.

Considerate CVE-2023-39999, una vulnerabilita nel core WordPress che permetteva ai contributori di leggere post privati o in bozza tramite la REST API. E stata corretta in WordPress 6.3.2, ma i siti con versioni precedenti sono rimasti esposti per mesi. O prendete CVE-2024-31210, che permetteva agli utenti admin di eseguire codice arbitrario durante l'upload di plugin sotto determinate configurazioni del server.

Fine Vita PHP: Un Killer Silenzioso

PHP 7.4 ha raggiunto la fine del ciclo di vita nel novembre 2022. PHP 8.0 e andato in end-of-life nel novembre 2023. Eppure una porzione significativa dei siti WordPress gira ancora su queste versioni non supportate. Quando PHP smette di ricevere aggiornamenti di sicurezza, ogni vulnerabilita conosciuta diventa una caratteristica permanente del vostro stack.

Versione PHP	Supporto Sicurezza Fino a	Stato (Gen 2025)
PHP 7.4	Novembre 2022	Fine vita, nessuna patch
PHP 8.0	Novembre 2023	Fine vita, nessuna patch
PHP 8.1	Dicembre 2025	Solo fix di sicurezza
PHP 8.2	Dicembre 2026	Supporto attivo
PHP 8.3	Dicembre 2027	Supporto attivo

Se il vostro provider di hosting ha ancora PHP 7.4 come default, questo e un segnale d'allarme riguardo l'intera postura di sicurezza. Dovreste usare PHP 8.2 o 8.3 come minimo nel 2025.

L'Ecosistema Plugin: La Piu Grande Forza e Debolezza di WordPress

Una Catena di Dipendenze che Non Controllate

La directory plugin di WordPress ospita oltre 60.000 plugin. Molti di essi sono mantenuti da un singolo sviluppatore che puo abbandonare il progetto in qualsiasi momento. Quando succede, vi ritrovate con del codice che non ricevera mai un'altra patch di sicurezza, in esecuzione sul vostro server di produzione, che elabora i dati dei vostri clienti.

Solo nel 2024, WPScan (ora parte di Automattic) ha tracciato oltre 5.000 nuove divulgazioni di vulnerabilita in plugin e temi WordPress. Alcune delle piu severe:

• CVE-2024-27956 (WP Automatic Plugin): SQL injection che permette ad attaccanti non autenticati di creare account admin. Punteggio CVSS 9.8. Oltre 30.000 installazioni attive al momento della divulgazione.
• CVE-2024-2876 (Email Subscribers by Icegram Express): Un'altra SQL injection, non autenticata, che permette l'estrazione completa del database. Oltre 90.000 installazioni.
• CVE-2024-4345 (Starter Templates by Brainstorm Force): Stored cross-site scripting che consente l'escalation dei privilegi. Oltre 1 milione di installazioni.

Lo schema e sempre lo stesso: un plugin popolare con centinaia di migliaia di installazioni contiene una vulnerabilita critica che era banalmente sfruttabile. Entro poche ore dalla divulgazione, scanner automatizzati stanno sondando ogni sito WordPress su internet per l'endpoint vulnerabile.

Attacchi alla Supply Chain dei Plugin

Una minaccia piu recente e insidiosa e la compromissione della supply chain. Nel 2024, diversi plugin WordPress sono stati acquisiti da nuovi proprietari che hanno iniettato codice malevolo negli aggiornamenti. Il plugin Social Warfare ha stabilito il modello: un attaccante ottiene l'accesso al repository di un plugin (tramite social engineering, acquisto del plugin o compromissione dell'account dello sviluppatore), poi invia un aggiornamento contenente una backdoor. Ogni sito con auto-aggiornamento abilitato lo installa automaticamente.

Non e uno scenario ipotetico. E successo con l'incidente AccessPress Themes, dove decine di temi e plugin sono stati compromessi tramite un account sviluppatore violato. Per maggiori informazioni su come le vulnerabilita dei plugin si propagano, consultate la nostra analisi sulle vulnerabilita dei plugin CMS.

Esposizione di wp-admin e Attacchi Brute Force

Il Problema della Pagina di Login Predefinita

Ogni installazione WordPress predefinita espone /wp-admin e /wp-login.php a tutto internet. Questo equivale a mettere un cartello "provate a entrare qui" sulla porta d'ingresso. Bot automatizzati scansionano range IP e liste di domini 24/7, sondando questi endpoint con combinazioni username/password raccolte da precedenti violazioni di dati.

Un tipico sito WordPress riceve tra 500 e 5.000 tentativi di brute force al giorno. I siti con nomi utente admin comuni come "admin" o "administrator" vengono colpiti di piu. Gli attacchi sono distribuiti su migliaia di indirizzi IP, rendendo il semplice blocco IP insufficiente.

Approfondiamo questo argomento nel nostro articolo dedicato sulle pagine admin esposte e perche rappresentano un rischio persistente.

Credential Stuffing vs. Brute Force

C'e una distinzione importante qui. Il brute force tradizionale prova ogni possibile combinazione. Il credential stuffing moderno e piu intelligente: gli attaccanti usano coppie username/password trapelate da altre violazioni (LinkedIn, Adobe, Dropbox, ecc.) e le provano contro il vostro login WordPress. Dato che le persone riutilizzano le password tra i servizi, questo funziona con una frequenza preoccupante.

Strumenti come WPScan rendono questo banalmente facile:

wpscan --url https://target.com --passwords leaked_passwords.txt --usernames admin,editor,john

XML-RPC: Il Vettore d'Attacco Dimenticato

WordPress viene distribuito con XML-RPC abilitato per default. Questo protocollo era originariamente progettato per permettere ad applicazioni esterne (come le app mobile) di interagire con WordPress. Il problema e che il metodo system.multicall permette a un attaccante di provare centinaia di combinazioni username/password in una singola richiesta HTTP, bypassando di fatto il rate limiting sul form di login.

La maggior parte dei firewall WordPress e dei rate limiter non ispeziona i payload XML-RPC, quindi questo vettore rimane completamente aperto sui siti non protetti. Se non usate XML-RPC (e la maggior parte dei siti moderni non ne ha bisogno), bloccatelo completamente a livello di web server.

SQL Injection Tramite Plugin

Come WordPress Gestisce le Query al Database

Il core WordPress usa il metodo $wpdb->prepare() per query parametrizzate, che fornisce una protezione solida contro la SQL injection quando usato correttamente. Il problema e che gli sviluppatori di plugin frequentemente aggirano questo meccanismo, per ignoranza o pigrizia.

Una query vulnerabile in un plugin potrebbe apparire cosi:

$results = $wpdb->get_results(
  "SELECT * FROM {$wpdb->prefix}custom_table WHERE id = " . $_GET['id']
);

Contro la versione sicura:

$results = $wpdb->get_results(
  $wpdb->prepare(
    "SELECT * FROM {$wpdb->prefix}custom_table WHERE id = %d",
    intval($_GET['id'])
  )
);

Catena di Attacco SQL Injection Reale

Ecco come si sviluppa un tipico attacco SQL injection contro un plugin WordPress vulnerabile:

1. Scoperta: L'attaccante usa strumenti automatizzati (SQLMap, script personalizzati) per sondare ogni parametro GET e POST sul sito.
2. Conferma: Un parametro in un form di contatto o plugin di ricerca restituisce un errore del database quando iniettato con un singolo apostrofo.
3. Estrazione: L'attaccante usa UNION SELECT per estrarre l'hash della password dell'utente admin da wp_users.
4. Cracking: WordPress usa l'hashing phpass per default. Con un cluster GPU, le password deboli cadono in pochi minuti.
5. Accesso: L'attaccante accede a wp-admin con le credenziali craccate.
6. Persistenza: Una backdoor PHP shell viene caricata tramite l'editor del tema o l'uploader dei plugin.
7. Esfiltrazione: Dati dei clienti, informazioni di pagamento e altri dati sensibili vengono estratti.

L'intera catena puo essere eseguita in meno di un'ora. Il punto d'ingresso e una singola query non parametrizzata in un plugin che il proprietario del sito probabilmente ha installato anni fa e dimenticato.

Vulnerabilita di Upload File

Quando l'Upload Media Diventa Esecuzione di Codice

WordPress permette agli utenti di caricare file tramite la libreria media e tramite vari plugin (form di contatto, foto profilo, gestione documenti). Ogni gestore di upload e un potenziale vettore di esecuzione di codice se non valida correttamente i tipi di file.

L'attacco classico prevede il caricamento di un file PHP mascherato da immagine. Se il server e configurato per eseguire PHP nella directory degli upload (che e l'impostazione predefinita su molti hosting condivisi), l'attaccante puo eseguire comandi arbitrari sul server.

Mitigazione dei Rischi di Upload

• Validare l'estensione del file contro una lista di estensioni consentite (non una lista di blocco)
• Verificare il tipo MIME del file usando la rilevazione lato server (es. finfo_file())
• Rinominare i file caricati per prevenire il directory traversal
• Archiviare gli upload fuori dalla web root quando possibile
• Aggiungere un file .htaccess nella directory degli upload che disabilita l'esecuzione PHP
• Usare un Web Application Firewall (WAF) che ispeziona il contenuto dei file

Perche Molte Agenzie Non Aggiornano

Il Problema del Modello di Business

Ecco la verita scomoda sull'ecosistema WordPress: il modello di business standard delle agenzie web non incentiva la sicurezza. Un'agenzia tipica costruisce un sito WordPress, lo consegna al cliente e va avanti. Puo esserci un contratto di manutenzione, ma spesso copre il "monitoraggio dell'uptime" piuttosto che l'effettivo patching di sicurezza.

Aggiornare il core WordPress, i plugin e i temi richiede tempo. Testare dopo gli aggiornamenti richiede piu tempo. Risolvere problemi di compatibilita dopo gli aggiornamenti richiede ancora piu tempo. La maggior parte dei contratti di manutenzione non prevede budget per questo lavoro, quindi le agenzie lo evitano.

Abbiamo visto aziende svizzere con installazioni WordPress 4.x e PHP 5.6, completamente senza patch per anni. Non perche non potessero permettersi gli aggiornamenti, ma perche nessuno aveva detto loro che era importante.

Checklist Concreta di Hardening per WordPress nel 2025

Se state usando WordPress e non potete migrare a un'architettura piu sicura, ecco i passaggi minimi da seguire:

1. Aggiornate Tutto, Regolarmente

• Abilitate gli aggiornamenti automatici minori del core
• Configurate un ambiente di staging per testare gli aggiornamenti maggiori
• Aggiornate tutti i plugin e i temi almeno mensilmente
• Rimuovete qualsiasi plugin o tema che non state usando attivamente
• Usate PHP 8.2 o 8.3

2. Blindate l'Autenticazione

• Imponete password forti e uniche per tutti gli account
• Abilitate l'autenticazione a due fattori (TOTP, non SMS)
• Rinominate o riposizionate l'URL di login
• Implementate il rate limiting sugli endpoint di login
• Disabilitate XML-RPC a meno che non ne abbiate specificamente bisogno
• Limitate l'accesso admin per IP se possibile

3. Minimizzate la Superficie d'Attacco

• Verificate ogni plugin installato: ne avete davvero bisogno?
• Rimuovete il plugin "Hello Dolly" predefinito e i temi non utilizzati
• Disabilitate l'editor di file integrato (aggiungete define('DISALLOW_FILE_EDIT', true); a wp-config.php)
• Disabilitate il listing delle directory sul web server

4. Rafforzate il Server

• Usate HTTPS ovunque
• Impostate header di sicurezza appropriati: X-Frame-Options, Content-Security-Policy, X-Content-Type-Options, Strict-Transport-Security
• Limitate i permessi dei file: directory a 755, file a 644, wp-config.php a 400
• Bloccate l'esecuzione PHP in wp-content/uploads/
• Usate un Web Application Firewall

5. Monitorate e Rispondete

• Configurate il monitoraggio dell'integrita dei file
• Monitorate i tentativi di login e bloccate i recidivi
• Mantenete backup (off-site, testati, automatizzati)
• Abbonatevi ai feed di vulnerabilita (WPScan, Wordfence intelligence)
• Abbiate un piano di risposta agli incidenti

Quando WordPress Non e la Scelta Giusta

Per molte aziende, la domanda non e come proteggere WordPress ma se WordPress sia lo strumento giusto. Se il vostro sito e principalmente informativo (sito aziendale, portfolio, blog), un generatore di siti statici elimina intere classi di vulnerabilita. Nessun database significa nessuna SQL injection. Nessun runtime lato server significa nessuna esecuzione remota di codice. Nessuna pagina di login significa nessun attacco brute force.

Esploriamo questo argomento in dettaglio nel nostro articolo sulla sicurezza dei siti statici vs. dinamici. Per le aziende a Lugano e in tutta la Svizzera che cercano una presenza web sicura, la decisione architetturale e spesso piu impattante di qualsiasi plugin di sicurezza.

Conclusione

La sicurezza di WordPress non e una questione da impostare e dimenticare. Richiede attenzione continua, aggiornamenti regolari e una chiara comprensione della superficie d'attacco che state esponendo. Le vulnerabilita che abbiamo trattato qui non sono casi limite; sono il pane quotidiano degli attacchi automatizzati che stanno avvenendo proprio ora contro siti come il vostro.

Se gestite un sito WordPress per la vostra azienda e non ne avete revisionato la sicurezza di recente, contattate il nostro team. Possiamo eseguire un assessment di sicurezza approfondito e aiutarvi a decidere se rafforzare la vostra configurazione esistente o migrare a un'architettura piu sicura sia la strada giusta.