OpenAI bucata da tre ricercatori: il vettore era software obsoleto

Come tre ricercatori hanno compromesso OpenAI con un'immagine corrotta e un forum vulnerabile. Cosa insegna alle PMI sulla sicurezza IT.

25/09/26
Christian Ray Lantieri
Christian Ray Lantieri
Illustrazione sulla vulnerabilità di software obsoleto, strati di codice esposti, architettura difettosa
Web & Infrastruttura
Errori da Evitare

Nel settembre 2026, un team di tre ricercatori ha dimostrato di poter compromettere OpenAI usando due vettori comuni: un file immagine corrotto e un software forum non aggiornato. Non è stato un exploit sofisticato o zero-day esotico. Era software di terze parti vecchio, quello che la maggior parte delle aziende - soprattutto PMI - ha abbandonato sotto il tavolo due anni fa. La storia, riportata da The Verge, è una lezione brutale sulla sicurezza IT.

In breve: la vulnerabilità non nasceva da un errore di progettazione di OpenAI, ma da componenti di terze parti lasciate indietro. Ogni PMI che usa WordPress, plugin, integrazioni software o gestisce un forum interno ha lo stesso problema. La soluzione non è tecnica (non serve un firewall più sofisticato), ma organizzativa: inventario dei componenti, cadenza di aggiornamenti, e responsabilità chiara.

Come è andata: il racconto del principio

I tre ricercatori hanno sfruttato il principio di accumulo di vulnerabilità. Non hanno bucato OpenAI con una mossa. Hanno usato una combinazione di due fattori:

  • Un file immagine corrotto, progettato per sfruttare un parser debole a livello di sistema.
  • Accesso a un software forum vulnerabile non aggiornato, usato internamente per discussioni e supporto.

Il forum non era un'eccezione. Era software di terze parti, probabilmente installato anni fa, dimenticato perché "funzionava", mai toccato in fase di aggiornamento. Quella lentezza è diventata il ponte verso il resto della rete.

Il principio è semplice: se un attaccante trova un punto di ingresso in un componente secondario (un forum, un plugin, un tool interno), e da lì raggiunge sistemi più critici, la sicurezza complessiva crolla. Non importa quanto sia blindato il resto.

Perché questo non è "un problema di OpenAI"

OpenAI è una delle aziende con più risorse al mondo per la sicurezza. Non è loro la colpa diretta. Il problema è universale: le organizzazioni (grandi e piccole) tendono a dimenticare le componenti di terze parti una volta installate.

Succede perché:

  • L'aggiornamento di un plugin o tool spesso non è prioritario finché "non è rotto".
  • Nessuno ha incarichi chiari su chi dovrebbe controllare quelle componenti.
  • Un software che funziona sembra stabile; aggiornarlo sembra un rischio inutile.
  • Manca un inventario centrale. Metà dell'IT sa che il forum c'è, l'altra metà no.

Proprio questo è il vettore scelto dai ricercatori: il punto dove la negligenza è sistemica e universale.

L'angolo PMI: quanti forum WordPress vecchi di due anni hai

Se OpenAI è stata colpita da software non aggiornato, una PMI che usa WordPress, WooCommerce, plugin di contatti, form builder, o una community interna è ancora più esposta. Non per mancanza di risorse (non è solo quello), ma perché il modello di gestione è lo stesso: "l'abbiamo installato, funziona, non tocchiamo".

Una domanda concreta: quanti plugin WordPress hai attivato che non ricordano neppure quando è stato l'ultimo aggiornamento? Quanti strumenti di terze parti usi (Zapier, form builder, forum, chat, strumenti di automazione AI) senza sapere se hanno patch di sicurezza in sospeso?

La vulnerabilità di OpenAI non è stata sofisticata. È stata l'esatto errore che commettiamo quando trattiamo il software come "set and forget".

Inventario, cadenza, responsabilità: i tre pilastri

Per ridurre il rischio, servono tre cose concrete:

Inventario centralizzato di tutti i componenti di terze parti: WordPress, plugin attivi, integrazioni (Zapier, Stripe, Google Forms, e tutto quello che usi), software interno, tool di automazione, estensioni browser. Una lista semplice, uno spreadsheet basta. Chi usa cosa. Dove è installato.

Cadenza di aggiornamenti pianificata: non "quando mi ricordo", ma calendario fisso. Per WordPress e plugin critici, almeno mensile. Per strumenti meno esposti, trimestrale. Dipende dal rischio, non dal confort.

Responsabilità assegnata: una persona o un ruolo (non un team diffuso) deve essere accountable. "Chi controlla che WordPress sia aggiornato?" Se la risposta è "boh", il rischio è già presente.

Cosa insegna sulla sicurezza informatica aziendale

La lezione non è "usate un firewall migliore" o "implementate un SOC (Security Operations Center)". È più radicale.

La sicurezza informatica moderna non è un problema tecnico puro. È un problema di inventario e governance. Se non sai cosa hai installato, non puoi sapere se è vulnerabile. Se non hai una cadenza di aggiornamenti, non puoi essere proattivo. Se la responsabilità è nebulosa, nessuno agisce.

Questo è ancora più vero per le PMI, che spesso non hanno un CIO o un team IT dedicato. Usano consulenti saltuari, outsourcing, o si arrangiajno internamente.

Aggiungiamo un'altra complicazione: molti strumenti di automazione e AI che le PMI usano adesso (dai chatbot ai tool di generazione immagini) sono proprietari. Non puoi aggiornarli tu. Dipendi da chi li fa. E se il provider non è diligente, rischi lo stesso.

Come controllare il tuo stack di terze parti

Un approccio concreto, non burocratico:

  1. Fai una lista di tutto quello che usi: WordPress, plugin, servizi cloud, integrazioni API, software interno, tool di automazione. Scrivi dove è usato, chi lo gestisce, quando è stato controllato l'ultima volta.
  2. Accedi a ogni piattaforma e verifica gli aggiornamenti: WordPress admin > Aggiornamenti, Google Workspace > Centro sicurezza, Zapier > Integrazioni, ecc. Se mancano patch, applicale (in staging prima, se possibile).
  3. Imposta reminder mensili: per i tool critici (WordPress, database, servizi di pagamento), un reminder il primo lunedì del mese "controllo aggiornamenti". Se è nell'agenda, accade.
  4. Per i tool di terze parti che non controlli direttamente (SaaS, API, servizi), accedi almeno una volta al trimestre e verifica se ci sono avvisi di sicurezza o deprecazioni. Molti provider avvisano via email, ma gli avvisi spariscono nella posta.

Checklist operativa per una PMI

  1. Inventario dei componenti: Scrivi un foglio (carta o digitale) con tutti i software, plugin, integrazioni e servizi che usi. Metti accanto il responsabile di ogni voce e la data dell'ultimo aggiornamento conosciuto. Se la data è più di tre mesi fa o è vuota, controlla subito.
  2. Priorità aggiornamenti: Dividi l'elenco in tre categorie: critico (WordPress, database, pagamenti), importante (plugin di uso frequente, integrazioni principali), secondario (estensioni rare, tool di supporto). La cadenza è: critico = mensile, importante = trimestrale, secondario = semestrale.
  3. Assegnazione responsabilità: Una persona (può essere il proprietario, il consulente IT, o un dipendente con accesso) è responsabile di controllare gli aggiornamenti. Scrivi il nome. Se non c'è, designalo ora.
  4. Test prima di live: Se aggiorni WordPress o componenti critiche, fai un backup prima e testa in ambiente di staging (oppure in offline, se non puoi). L'aggiornamento può rompere un plugin obsoleto; meglio saperlo prima di andare live.
  5. Servizi SaaS e cloud: Per strumenti come Google Workspace, Zapier, tool di automazione AI, controlla una volta al trimestre il pannello di sicurezza e gli avvisi. Molti provider avvisano di vulnerabilità o deprecazioni; non leggerli è come lasciar passare una lettera della banca.
  6. Documenta le versioni attuali: Scrivi (o fai scrivere da chi ha accesso) la versione attuale di WordPress, plugin principali, software interno. Servirà per capire velocemente se sei esposto a una vulnerabilità pubblica quando emerge.

Gli errori da evitare

  • Aggiornare tutto insieme senza staging: Un aggiornamento di WordPress può rompere tre plugin vecchi. Testa prima, live dopo.
  • Dimenticare i plugin inattivi: Se un plugin è disabilitato ma non cancellato, è ancora vulnerabile. Se non lo usi, eliminalo.
  • Non documentare chi sa cosa: Se solo una persona sa password di WordPress e non la dici a nessuno, quando non c'è sei fermo. Documentalo in modo sicuro (password manager aziendale, non un post-it).
  • Ignorare i messaggi di deprecazione: Quando un servizio dice "questa versione di questa libreria non è più supportata", non è un consiglio. È un avviso. Agisci entro la data che danno.
  • Affidarsi a "aggiornamenti automatici" senza controllo: Molti CMS offrono auto-update. Utile, ma controlla almeno una volta al mese che sia acceso e che non sia stato disabilitato per sbaglio.
  • Pensare che "non siamo grandi abbastanza per essere attaccati": L'attacco a OpenAI non era mirato a OpenAI; era una dimostrazione. I veri attacchi a PMI sono automatizzati, non personali. Chiunque usi WordPress è un bersaglio.

Domande frequenti su sicurezza AI e vulnerabilità software

Se aggiorno WordPress male, il sito smette di funzionare?

Può succedere se hai plugin vecchi non compatibili con la nuova versione di WordPress. Per evitarlo: fai sempre un backup completo prima, testa in staging, e aggiorna i plugin contemporaneamente a WordPress, non dopo. Se poi qualcosa si rompe, hai il backup da cui ripristinare.

Devo aggiornare anche plugin che non uso più?

No, devi eliminarli. Un plugin disattivato ma presente sul server è comunque vulnerabile perché il codice c'è. Se non lo usi, cancellalo. Libera anche spazio.

OpenAI è stata bucata con un'immagine. Devo aver paura dei file caricati sul mio sito?

Il rischio esiste, specialmente se accetti caricamenti di file da utenti. La soluzione: usa plugin per la validazione dei file, scansiona i file caricati per malware (strumenti come VirusTotal), e limita i tipi di file consentiti (es. solo JPG e PNG, non EXE o SVG non compresso). Se usi un servizio cloud come Cloudinary per le immagini, il rischio è molto più basso perché loro controllano.

Chi dovrebbe aggiornare il software di una PMI senza IT interno?

Se non hai un IT interno, il tuo consulente esterno o un'agenzia web. Ma devi specificare contrattualmente: "Chi gestisce gli aggiornamenti? Ogni quanto? Chi avvisa se c'è un problema?". Se nessuno è incaricato, è una lacuna.

Se uno strumento AI che usiamo non è mai stato aggiornato, quanto rischio corro?

Dipende da due cose: quanti dati sensibili usi con quello strumento, e quanto è esposto a Internet. Se usi un chatbot interno su una rete locale vecchio di due anni, il rischio è basso. Se usi uno strumento pubblico non aggiornato per processare dati clienti, il rischio è alto. In entrambi i casi, preferisci strumenti attivamente mantenuti.

Posso usare strumenti di sicurezza automatici per controllare tutto?

Parzialmente. Strumenti come Wordfence (per WordPress), Sucuri, o servizi di vulnerability scanning scansionano il tuo sito e avvisano di plugin vulnerabili. Utili, ma non bastano. Riducono il lavoro manuale, non lo eliminano.

Il punto centrale

L'attacco a OpenAI non era il risultato di una sofisticazione tecnica esterna. Era il risultato della negligenza interna: software di terze parti non aggiornato, nessun inventario centralizzato, responsabilità diffusa.

Se una delle aziende più ricche e ben resourced del mondo cade su questo errore, una PMI cade ancora più facilmente. La buona notizia è che la soluzione non è costosa né difficile: è organizzativa. Inventario, cadenza, responsabilità. Tre cose che richiedono tempo, non soldi.

Inizia subito: apri un foglio, scrivi tutto quello che usi, metti la data dell'ultimo aggiornamento accanto a ogni voce. Quello che ha una data vecchia o vuota è il tuo punto di partenza. Aggiorna quello per primo.

Metti in sicurezza i tuoi sistemi
arrow
Altri articoli