WordPress: vulnerabilità +42%, ma il rischio AI va distinto

WordPress registra un aumento delle vulnerabilità censite, mentre l’integrazione degli agenti AI introduce un rischio diverso da quello degli attacchi esterni. Un articolo di Alankrita Shrivastava, datato 21 agosto 2026, riporta 11.334 nuove vulnerabilità nel 2025, il 42% in più rispetto all’anno precedente. È un indicatore della pressione sulla manutenzione dell’ecosistema, non una misura degli incidenti subiti dai siti e nemmeno una dimostrazione che l’intelligenza artificiale abbia causato quell’aumento.

La distinzione cambia le decisioni operative e il dibattito sul futuro dei plugin. L’AI offensiva cerca accessi non autorizzati; un agente collegato intenzionalmente al sito utilizza invece autorizzazioni già concesse, che possono essere eccessive rispetto al compito. Per le imprese che sviluppano estensioni, la questione strategica non è soltanto quanto codice un modello possa generare: è quale valore rimanga nella manutenzione, nelle integrazioni e nella capacità di rendere controllabili le azioni automatizzate.

WordPress: cosa significa il confronto sulle vulnerabilità

Il dato riportato da Shrivastava confronta le nuove vulnerabilità registrate nel 2025 con quelle dell’anno precedente. Il +42% descrive quindi la crescita di un conteggio annuale, non l’aumento della probabilità che un singolo sito venga compromesso. Il totale non equivale neppure al numero di installazioni esposte: una vulnerabilità può interessare un componente poco utilizzato oppure un’estensione presente su molti siti, con conseguenze operative molto diverse.

Il risultato sostiene una conclusione circoscritta: cresce il volume delle debolezze note che l’ecosistema deve valutare e correggere. Non permette di stabilire quanto siano aumentati gli attacchi riusciti, quale quota dipenda da strumenti AI o se la gravità media sia cambiata. Una maggiore attività di ricerca e segnalazione potrebbe contribuire al conteggio, ma i materiali disponibili non consentono di quantificarne il peso.

Il collo di bottiglia può quindi spostarsi dalla disponibilità dell’aggiornamento alla capacità di riconoscere quali installazioni siano interessate, verificare le dipendenze e distribuire la correzione senza interrompere il servizio. Il numero delle vulnerabilità è un punto di partenza per il triage. Non è ancora una misura del rischio residuo.

Metodo e perimetro: i dettagli che mancano al dato

La fonte disponibile è la sintesi di un articolo, non il dataset originale corredato da metodologia. Sono indicati autrice, data di pubblicazione e anno del conteggio, ma non il titolo del rapporto sottostante, l’organizzazione responsabile della rilevazione, la banca dati utilizzata o i criteri di inclusione. Non è fornito un collegamento al documento originale: attribuire il risultato direttamente a WordPress.org sarebbe improprio.

Mancano inoltre la distribuzione tra core, temi e plugin, le regole di deduplicazione e l’eventuale trattamento separato di vulnerabilità pubblicate, corrette o effettivamente sfruttate. Non sono indicati un campione di siti osservati, una geografia o una popolazione di installazioni monitorate. Il periodo disponibile riguarda l’anno delle registrazioni, non una finestra documentata di osservazione degli attacchi.

Queste assenze impediscono confronti affidabili con tassi di compromissione o con la sicurezza di altri sistemi di gestione dei contenuti. Anche la relazione con l’AI resta qualitativa: le fonti descrivono meccanismi plausibili e rischi operativi, ma non presentano una misurazione che separi gli attacchi assistiti dall’AI dall’automazione tradizionale. Il dato va usato per dimensionare l’attenzione alla manutenzione, non per costruire una classifica assoluta di insicurezza.

Attacchi esterni e agenti autorizzati: due superfici diverse

L’AI offensiva può accelerare attività già note: analisi delle pagine pubbliche, ricerca di percorsi dei plugin, raccolta di informazioni sulle versioni e tentativi di accesso con credenziali. Il meccanismo non richiede necessariamente una nuova classe di vulnerabilità. Riducendo il lavoro necessario per individuare un componente esposto e associarlo a una debolezza conosciuta, l’automazione può aumentare la pressione sulle installazioni mantenute male.

Le fonti citano pagine di login, xmlrpc.php, WordPress REST API e funzionalità di caricamento dei file tra le superfici prese di mira. Questo non significa che tali interfacce siano vulnerabili per definizione o debbano essere disabilitate indiscriminatamente. Contano le funzioni effettivamente esposte, l’autenticazione, i permessi e la presenza di difetti nei componenti che gestiscono le richieste.

Con un agente AI il percorso cambia: l’applicazione invia una richiesta, un connettore la traduce in un’azione WordPress e il sito restituisce dati o esegue l’operazione. Se l’accesso comprende gestione degli utenti, impostazioni o registri sensibili, un’istruzione errata può produrre effetti senza violare l’autenticazione. Il problema è l’uso improprio di una capacità autorizzata, non soltanto il furto delle credenziali.

Da qui derivano controlli differenti. L’autenticazione multifattore protegge l’accesso all’account, ma non decide se un’azione dell’agente sia appropriata. Un accesso in sola lettura limita le modifiche, non impedisce necessariamente la divulgazione dei dati leggibili. Il connettore delimita un percorso di integrazione: non è, da solo, una garanzia sulla correttezza delle operazioni.

Plugin e agentic web: i limiti delle conclusioni economiche

Il materiale disponibile non documenta perdite di ricavi dei produttori di plugin attribuibili all’AI, né casi verificati di agenzie che abbiano riconvertito con successo la propria attività. Non consente quindi di affermare che il mercato delle estensioni sia già stato sostituito dalla generazione automatica di codice. Analogamente, non identifica uno standard tecnico specifico per un agentic web di WordPress.

Il progetto WordPress.org dispone di un AI Team che esplora e coordina iniziative nell’ecosistema, invitando alla partecipazione attraverso WordPress Slack. L’esistenza di questo coordinamento non dimostra però la disponibilità di un protocollo condiviso, né certifica la sicurezza di un particolare connettore o agente. Coordinamento della comunità e compatibilità operativa sono livelli diversi.

Quanto ai vantaggi competitivi dei plugin, le fonti suggeriscono criteri concreti di valutazione: continuità degli aggiornamenti, attività del supporto, reputazione dello sviluppatore e precedenti di sicurezza. È ragionevole considerarli candidati a un vantaggio più difendibile della sola disponibilità del codice, perché riguardano obblighi continuativi. Non è invece dimostrato quanto proteggano ricavi o margini dalla concorrenza AI.

La complessità delle integrazioni rafforza questa distinzione. Le fonti descrivono siti giapponesi e dell’area Asia-Pacifico che combinano plugin internazionali, strumenti locali, pagamenti regionali e codice personalizzato. Il possibile punto cieco riguarda la copertura degli avvisi nelle diverse lingue. Non è una misura comparativa dell’insicurezza regionale, ma un esempio di manutenzione che richiede conoscenza del contesto, non soltanto capacità di generare codice.

Le decisioni sostenibili: manutenzione, permessi e verifica

Le evidenze sostengono una difesa stratificata, non l’acquisto di un singolo prodotto risolutivo. Un Web Application Firewall, o WAF, può filtrare richieste sospette, ma non sostituisce la correzione del componente vulnerabile. Scansioni e controlli d’integrità aiutano a cercare anomalie; i backup separati dall’account di hosting e le prove di ripristino servono a recuperare il servizio. Nessuno di questi controlli dimostra, isolatamente, che il sito sia integro.

• Mantenere un inventario di core, temi e plugin, rimuovere i componenti inutilizzati e seguire gli avvisi pertinenti all’installazione.
• Combinare aggiornamenti tempestivi, verifiche in staging proporzionate all’urgenza e controlli successivi alla distribuzione.
• Assegnare agli agenti soltanto le operazioni necessarie, prevedendo approvazioni per le azioni sensibili e registri utili a ricostruirle.
• Indagare account amministrativi sconosciuti, file inattesi, pagine indicizzate estranee e avvisi di Search Console, senza trattare ogni anomalia come prova definitiva di compromissione.

Per valutare un plugin o un’integrazione AI, il costo totale di proprietà deve quindi includere manutenzione, revisione delle autorizzazioni e capacità di recupero, non soltanto licenza e velocità di configurazione. Chi offre continuità verificabile può avere un vantaggio; chi promette autonomia senza rendere visibili permessi e azioni lascia irrisolto il problema principale.

Oggi il conteggio sostiene l’esigenza di maggiore capacità di triage, non una causalità tra AI e vulnerabilità né una previsione sui ricavi dei plugin. Servono dati sulle installazioni realmente esposte, sui tempi di correzione, sugli incidenti e sugli errori degli agenti. La verifica decisiva resta questa: l’automazione riduce il lavoro complessivo o trasferisce il costo verso controllo e ripristino?