Su 11.334 vulnerabilità trovate nell’ecosistema WordPress durante il 2025, il 46% è diventato pubblico senza che lo sviluppatore avesse pronta una correzione. Nello stesso periodo, la mediana pesata fra disclosure e primo sfruttamento osservato è di cinque ore. I due numeri arrivano dallo stesso documento, il whitepaper Patchstack aggiornato al 25 febbraio 2026, e messi in fila chiudono un discorso: «tengo i plugin aggiornati» non è una policy di sicurezza. È l’attesa che qualcun altro faccia in tempo un lavoro che in quasi metà dei casi non arriva.

La ragione per cui quel 46% non scenderà da solo si è vista il 19 settembre 2026 in un altro angolo del settore. Intel ha sospeso il programma di bug bounty che pagava fino a 100.000 dollari per una singola segnalazione.

Il canale che produceva le patch si sta chiudendo

Il programma sostitutivo che Intel ospita su Intigriti è descritto come un canale di responsible disclosure senza ricompense. La vecchia bounty board risulta ancora raggiungibile, ma marcata come sospesa, e nessuna motivazione ufficiale è stata pubblicata (Tom’s Hardware, 19 settembre 2026, su segnalazione di Phoronix). Il listino sospeso era a quattro fasce: dai 2.000 ai 100.000 dollari per la Tier 1, dai 250 ai 5.000 per la Tier 4.

Vale la pena ricordare quanto quel canale producesse: secondo Intel, 105 delle 231 CVE corrette nel 2020 erano arrivate dal programma bounty. Quasi la metà del lavoro di sicurezza su un vendor di quelle dimensioni entrava da fuori, pagata a cottimo. E fino a pochi mesi fa la direzione sembrava opposta: lo scope era stato esteso ai servizi web fra metà 2025 e ottobre 2025, e un aggiornamento del 6 gennaio 2026 su Intigriti annunciava che erano allo studio criteri di bounty e bonus potenziati. Circa otto mesi dopo, il programma è sospeso.

Non è un caso isolato, ed è qui che smette di essere una notizia da produttori di chip.

  • curl ha chiuso il proprio bug bounty il 31 gennaio 2026. Nell’annuncio, Daniel Stenberg fa i conti: 87 vulnerabilità confermate e oltre 100.000 dollari pagati in sette anni, ma un tasso di conferma passato da oltre il 15% a sotto il 5% a partire dal 2025. Non una su venti era reale. Le segnalazioni ora passano dal private vulnerability reporting di GitHub, senza premi.
  • L’Internet Bug Bounty di HackerOne, il fondo che per anni ha pagato le ricompense di curl, ha sospeso le nuove submission (Tom’s Hardware). La motivazione sulla pagina del programma è esplicita: la ricerca assistita da AI sta allargando la scoperta di vulnerabilità in tutto l’ecosistema, in copertura e in velocità. Le segnalazioni già in coda vengono ancora pagate, da 68 a 2.257 dollari a seconda della gravità.
  • Il kernel Linux si avvicina alle 2.000 CVE per release, quattro volte il livello di circa 500 di prima, con i manutentori sommersi. Linus Torvalds ha definito i report AI duplicati sulla lista di sicurezza «quasi del tutto ingestibili» (Tom’s Hardware).

Una precisazione doverosa, perché la differenza fra prova e indizio conta: anche la pagina Intigriti di AMD risulta sospesa, ma la piattaforma ha un meccanismo di sospensione automatica. Quella non è una seconda conferma, è una coincidenza da verificare.

Perché questo arriva fino al sito della tua azienda

Il meccanismo che si è rotto è lo stesso a monte e a valle: il costo di produrre una segnalazione è crollato, il costo di validarla è rimasto umano. E il collo di bottiglia non è nei report che arrivano, è nelle patch che escono.

Nel mondo WordPress i numeri del 2025 raccolti da Patchstack raccontano lo stesso squilibrio:

  • 11.334 vulnerabilità nuove, +42% rispetto al 2024;
  • 1.966 (17%) ad alta gravità, cioè sfruttabili in attacchi automatizzati di massa;
  • 4.124 (36%) abbastanza serie da richiedere una regola di mitigazione immediata;
  • 91% nei plugin, 9% nei temi, 6 sole vulnerabilità nel core;
  • 46% arrivate alla pubblicazione senza una patch del fornitore.

Patchstack indica anche la causa che collega i due lati della filiera: un aumento significativo di segnalazioni AI-generate di scarsa qualità nel 2025, inviate «nella speranza di una ricompensa facile». Gli stessi report che hanno fatto chiudere curl passano davanti agli stessi sviluppatori di plugin che devono scrivere la tua patch, e che nel 46% dei casi non ce la fanno.

Il dato che dovrebbe cambiare qualche abitudine di acquisto riguarda i componenti a pagamento: 1.983 segnalazioni valide su prodotti premium o freemium, il 29% dei report ricevuti da Patchstack, di cui il 76% realmente sfruttabile in attacco. Il codice premium riceve meno attenzione dai ricercatori perché è più difficile da leggere, non perché sia scritto meglio. Aver pagato la licenza non sposta il rischio: sposta solo chi lo guarda.

Cinque ore, non cinque giorni

La finestra operativa è il numero più importante di tutto il documento. Circa metà delle vulnerabilità ad alto impatto viene sfruttata entro 24 ore dalla disclosure; pesando per l’intensità di sfruttamento osservata, la mediana del primo attacco scende a cinque ore. Le più bersagliate non aspettano nemmeno mezza giornata lavorativa.

Chi conta sul WAF dell’hosting per coprire quelle ore dovrebbe leggere il risultato dei due test condotti da Patchstack nel 2025 su difese comuni, WAF interni e Cloudflare inclusi: il primo, su vulnerabilità note e sfruttate, ha visto bloccato il 12% degli attacchi specifici per WordPress; il secondo, con uno scope più ampio, il 26% del totale. Combinazioni simili di prodotti hanno reso in modo molto diverso da host a host, il che dice quanto pesi la configurazione rispetto al marchio.

Tradotto per chi gestisce venti siti di clienti: il WAF non è la patch, è il tempo che compri per applicarla. Se la tua procedura prevede di aggiornare «entro la settimana», la settimana la passi scoperto.

La policy che regge, in sei passaggi

1. Inventario, prima di tutto

Non puoi decidere su cosa non conosci. Con WP-CLI bastano tre comandi, e l’output va tenuto, non guardato una volta:

wp core version
wp plugin list --fields=name,status,version,update,auto_update --format=csv
wp theme list --fields=name,status,version,update --format=csv

Il numero che conta è quanti plugin sono attivi, non quanti sono installati: è la superficie che qualcuno può raggiungere da fuori.

2. Ridurre la superficie prima di difenderla

Il 91% delle vulnerabilità sta nei plugin. Ogni plugin che rimuovi è un fornitore in meno da cui dipende la tua sicurezza, ed è l’unico intervento che non richiede manutenzione successiva. Disattivare non basta: il codice disattivato resta sul disco, quindi resta raggiungibile da chi conosce il percorso del file. Si disinstalla.

3. Procurarsi un feed, sapendo che non è più gratis

Qui serve una verifica fatta oggi, 20 settembre 2026, perché la documentazione in giro è vecchia. Interrogando i due endpoint più citati:

GET www.wordfence.com/api/intelligence/v2/vulnerabilities/scanner
  → 410  "The requested version of this API has now been removed"
GET www.wordfence.com/api/intelligence/v3/vulnerabilities/scanner
  → 401  "API key must be supplied using a Bearer token"
GET wpscan.com/api/v3/plugins/contact-form-7
  → 403  {"status":"forbidden"}

La v2 di Wordfence Intelligence non esiste più, la v3 vuole una chiave, WPScan vuole un token. Il feed anonimo e gratuito su cui si appoggiavano parecchi script casalinghi è finito. Le opzioni concrete restano tre: un plugin di sicurezza che porta con sé il proprio feed, un account con chiave API su un servizio di threat intelligence, oppure la lettura manuale di un bollettino. La terza non scala oltre i tre o quattro siti, ed è bene saperlo prima di prometterla a un cliente in un contratto di manutenzione.

4. Triage per esposizione, non per punteggio CVSS

Il punteggio di gravità descrive la vulnerabilità in astratto, non il tuo sito. Quattro domande, in ordine:

  1. Il plugin è attivo su questa installazione?
  2. Serve autenticazione? Con quale ruolo minimo?
  3. La funzionalità vulnerabile è raggiungibile (endpoint REST esposto, shortcode in pagina, form pubblico)?
  4. Esiste già un exploit pubblico o attività osservata?

Un’esecuzione di codice non autenticata in un plugin di form attivo sulla home batte un XSS che richiede privilegi da amministratore, anche se il secondo ha il punteggio più alto. Sulla stessa logica si decide dove spendere il tempo quando i bollettini aperti sono otto e l’ora è una.

5. Finestre dichiarate, scritte da qualche parte

Una policy esiste quando è un numero, non un’intenzione. Una scala che ha senso con la mediana a cinque ore:

  • vulnerabilità sfruttabile senza autenticazione su componente attivo: stesso giorno, misurato in ore;
  • sfruttabile con account di basso privilegio, o sito con registrazioni aperte e WooCommerce: entro 72 ore;
  • richiede amministratore, o componente non attivo: ciclo di manutenzione ordinario;
  • aggiornamenti automatici attivi sui plugin di sicurezza e sul core minore, sempre, con backup verificato a monte.

Il backup fa parte della policy, non è un’altra voce di menu: senza un ripristino provato negli ultimi 90 giorni, nessuno applicherà mai una patch urgente di venerdì pomeriggio.

6. Cosa fare nel 46% dei casi in cui la patch non arriva

È lo scenario più probabile del documento, ed è quello per cui nessuno ha una procedura. L’ordine giusto è per costo crescente e per rischio decrescente:

  1. Rimuovere. Se la funzione è marginale, disinstallare chiude il problema in cinque minuti e per sempre.
  2. Sostituire. Un concorrente mantenuto, con lo stesso lavoro di migrazione che avresti fatto comunque fra sei mesi.
  3. Mitigare nel codice. Se la vulnerabilità sta in un endpoint o in un hook identificabile, si può disattivare quel pezzo da un plugin di sito: remove_action(), un rest_endpoints che elimina la route, una capability alzata, senza toccare il plugin di terzi, che al prossimo aggiornamento sovrascriverebbe la modifica.
  4. Virtual patching a pagamento, che è esattamente il prodotto che i servizi di mitigazione vendono, con i limiti misurati sopra.
  5. Aspettare è una scelta, ma va dichiarata al cliente con una data, altrimenti diventa un rischio non assegnato a nessuno.

Dieci minuti per valutare un fornitore prima di installarlo

Se il canale delle segnalazioni si sta restringendo, la domanda «questo fornitore riceve e gestisce le segnalazioni?» vale più di ogni feature comparison. Quattro controlli, nessuno dei quali richiede strumenti:

  • /.well-known/security.txt (RFC 9116). Verificato oggi: wordfence.com lo serve, con contatto e chiave di cifratura; patchstack.com risponde 404. L’assenza non è un verdetto sul fornitore, visto che Patchstack gestisce un programma di disclosure per conto di terzi, ma è il segnale che il canale di contatto va cercato altrove, e se non lo trovi nemmeno in una pagina di supporto, il piano B di un ricercatore è la pubblicazione.
  • Changelog. Cerca le voci che dicono «security fix» e guarda la distanza fra le release. Un plugin con cinque CVE chiuse in 48 ore è più sicuro di uno con zero CVE e nessun canale per segnalarle.
  • Storico nelle basi dati pubbliche. Quante vulnerabilità, e soprattutto quanto tempo fra segnalazione e patch.
  • Segni di abbandono. Data dell’ultimo aggiornamento, versione di WordPress dichiarata come testata, ticket di supporto senza risposta. Le installazioni attive non misurano la manutenzione: misurano solo quante persone stanno correndo lo stesso rischio.

Lo stesso ragionamento vale un piano più sopra, quando si scelgono i modelli e i componenti di un’automazione: ne ho scritto nella checklist di sicurezza per i modelli open weight, e la domanda di fondo non cambia: chi risponde quando qualcosa si rompe, e in quanto tempo.

La take: le bounty non stanno morendo, stanno diventando un servizio

La lettura comoda di queste settimane è «l’AI ha rotto le bug bounty». È sbagliata nei fatti. Nessuno ha smesso di ricevere segnalazioni: Intel le riceve ancora, curl le riceve su GitHub, HackerOne paga la coda arretrata. Quello che è saltato è il filtro gratuito.

Per dieci anni l’ecosistema ha avuto un servizio di triage pagato in reputazione: ricercatori competenti che sceglievano da soli cosa valesse la pena scrivere, perché scrivere costava tempo. Quando produrre un report plausibile è costato zero, quel filtro si è riempito di rumore e il costo si è spostato tutto sul lato di chi legge. Chi può permetterselo ora compra il triage, ed è esattamente ciò che Patchstack vende agli sviluppatori di plugin, validazione dei report per conto loro e consulenza sulla patch. Chi non può permetterselo chiude il programma, come curl, o toglie i premi e tiene la porta, come Intel.

La conseguenza per una PMI non è filosofica. La sicurezza del tuo sito dipende sempre di più da chi paga il triage del tuo fornitore. È una domanda da mettere in fase di acquisto, accanto al prezzo della licenza, e oggi quasi nessuno la fa.

La seconda conseguenza riguarda chi installa plugin per mestiere: il 46% senza patch non è un’anomalia da aspettare che passi, è il nuovo caso base. Una procedura di manutenzione che contempla solo «aggiorna quando esce l’update» copre poco più della metà degli eventi. L’altra metà va gestita rimuovendo, sostituendo o mitigando, e quelle sono decisioni che richiedono un inventario aggiornato e un’ora dichiarata di risposta. Lo stesso tipo di disciplina che serve quando si decide come trattare i crawler AI su un sito WordPress: regole scritte prima, non reazioni dopo.

Cosa monitorare da lunedì

  • Numero di plugin attivi per sito, con un obiettivo di riduzione dichiarato.
  • Tempo medio fra bollettino e aggiornamento applicato, misurato davvero su tre o quattro casi.
  • Percentuale di siti con aggiornamenti automatici attivi su core minore e plugin di sicurezza.
  • Per ogni componente critico: esiste un canale di disclosure del fornitore, sì o no.
  • Data dell’ultimo ripristino di backup provato, non dell’ultimo backup eseguito.

Cinque righe in un foglio. Costano mezza giornata da impostare e sono l’unica parte di questa storia che dipende da te: che Intel riattivi le ricompense o no, la finestra fra la pubblicazione di una vulnerabilità e il primo tentativo sul tuo sito resta di cinque ore.

Fonti