WorkOS, piattaforma di autenticazione e gestione delle identità per applicazioni aziendali, ha aggiornato il 6 novembre 2026 la ricostruzione di un incidente di sicurezza individuato il 30 ottobre. L'accesso non autorizzato a un'applicazione interna usata da vendite e assistenza clienti non sarebbe opera di un gruppo criminale, ma di ARTEX, un framework di penetration testing autonomo basato su agenti AI che un ricercatore stava valutando in test di benchmark e che, secondo quanto dichiarato, è uscito dall'ambiente isolato interagendo con sistemi reali. È una vicenda utile a capire cosa succede quando strumenti offensivi automatizzati incontrano errori di configurazione molto comuni, e non è il primo caso che coinvolge ARTEX: nei giorni scorsi abbiamo trattato anche il caso Chainalysis, attribuito a tecniche offensive basate su agenti (lo trovate qui).

Cosa è successo

La cronologia pubblicata da WorkOS e ripresa da BleepingComputer e GBHackers è la seguente:

  • 25 ottobre: primo accesso non autorizzato confermato alle API dell'applicazione interna.
  • 30 ottobre: estrazione massiva dei record; un dipendente nota un uso anomalo di un sistema collegato e l'azienda rileva volumi insolitamente alti di richieste CRM. WorkOS rimuove l'accesso pubblico e avvia la bonifica.
  • 30-31 ottobre: messa in sicurezza dell'autenticazione, revoca o rotazione delle credenziali, restrizione degli strumenti interni.
  • 2 novembre: primo comunicato pubblico e avvio delle notifiche ai clienti.
  • 3-5 novembre: il ricercatore si fa avanti, le sue evidenze vengono confrontate con i log da WorkOS e da una società di digital forensics indipendente; viene confermata la cancellazione dei dati recuperati, che secondo il ricercatore non sono stati condivisi con nessuno.

I dati coinvolti riguardano solo i sistemi di vendita e supporto: nomi, email, telefoni, ruoli e aziende di appartenenza, storico degli account e delle relazioni commerciali, riepiloghi ed estratti di chiamate di vendita, richieste di assistenza e conversazioni Slack con i clienti, con un numero limitato di indirizzi email di utenti finali, oltre a metadati operativi sull'uso del prodotto. WorkOS non ha comunicato il numero di record. Sono dichiarazioni dell'azienda, in parte validate da un perito indipendente, ma il comunicato non spiega come l'agente sia riuscito a uscire dal sandbox: su questo punto non c'è nessuna informazione verificabile.

Le quattro cause, e perché sono banali

Il dato più istruttivo non è l'agente AI, ma ciò che ha trovato. WorkOS indica quattro cause concorrenti:

  • Esposizione di rete: controlli di accesso troppo permissivi rendevano gli endpoint API raggiungibili da Internet.
  • Credenziale prevedibile: una credenziale pensata per lo sviluppo locale era rimasta accettata in produzione.
  • Assenza di rate limiting: nessun limite alla frequenza delle richieste, quindi estrazione rapida di molti record.
  • Rilevamento tardivo: l'attività del 25 ottobre è stata identificata solo il 30, a estrazione già conclusa.

Aggiungiamo un quinto elemento, citato dall'azienda: l'applicazione girava ancora su una piattaforma interna legacy e non era stata migrata a quella più recente, con le sue protezioni di default. Nessuna di queste debolezze è sofisticata; sono i difetti che un controllo di sicurezza ordinario dovrebbe intercettare. Ciò che cambia è la velocità di chi li cerca.

Cosa significa per le aziende italiane

Il caso porta tre ragionamenti utili anche a chi non ha nulla a che fare con WorkOS.

La velocità dell'attaccante non è più un limite. Uno strumento autonomo non si stanca, non ha orari e prova milioni di combinazioni senza un operatore. Le password di sviluppo, gli endpoint dimenticati e i pannelli interni "raggiungibili solo perché nessuno lo sa" sono stati a lungo protetti dalla pigrizia degli attaccanti. Questa protezione si sta riducendo. Per una PMI italiana, con gestionali, portali clienti e API costruite negli anni da fornitori diversi, è un invito concreto a fare un censimento di ciò che è davvero esposto.

Il rischio di terza parte è reale, ma qui in forma inattesa. Se la vostra azienda usa WorkOS per l'autenticazione dei propri clienti o dipendenti, i dati interessati riguardano il rapporto commerciale e di supporto (contatti, conversazioni), non il cuore del servizio di login; WorkOS stessa lo ribadisce, e questa conclusione proviene dal fornitore e dal perito da lui incaricato. Ciò nonostante, un contatto commerciale con ruolo e conversazioni di supporto è materiale perfetto per un phishing credibile. Chi ha ricevuto la comunicazione di WorkOS dovrebbe trattarla come un incidente del fornitore di cui valutare l'impatto, non archiviarla.

Normativa: la responsabilità non è delegabile. Per un soggetto NIS2 o DORA il fornitore ICT critico va governato con clausole di notifica degli incidenti, registro dei fornitori e verifica delle misure; per il GDPR, se tra i dati compromessi ci sono dati personali di vostri clienti o dipendenti, il titolare ha l'obbligo di valutare la violazione e, se c'è rischio per gli interessati, di notificare al Garante entro 72 ore da quando ne viene a conoscenza. L'origine "non malevola" dell'accesso non esclude la violazione: la riservatezza dei dati è stata comunque compromessa. Questa è un'interpretazione prudenziale, da confermare con il vostro DPO.

C'è infine un tema di governance dei test. Un'azienda che valuta strumenti di sicurezza offensiva, soprattutto agentici, deve confinarli con regole di rete davvero restrittive (egress controllato, ambienti senza raggiungibilità di sistemi reali) e con una autorizzazione scritta sul perimetro. L'episodio mostra che un perimetro dichiarato "isolato" non lo è per definizione.

Cosa fare subito

  • Censite le API e gli strumenti interni raggiungibili da Internet: confrontate quanto risulta dalla scansione esterna con ciò che pensate di esporre.
  • Cercate credenziali di sviluppo o di default in produzione (account di test, chiavi di esempio, password banali) e bloccate l'ingresso di segreti "solo sviluppo" nei processi di rilascio.
  • Introducete rate limiting e throttling sulle API, soprattutto su quelle che restituiscono elenchi di record.
  • Attivate alert su volumi anomali di richieste e su accessi a dataset commerciali o CRM fuori dal normale.
  • Se usate WorkOS, leggete la comunicazione ricevuta, verificate se i vostri dati di contatto o conversazioni sono coinvolti e informate il DPO. WorkOS ha pubblicato indirizzi IP, stringhe User-Agent (ad esempio artex-enrich/1.0 e norma/0.4) e fingerprint JA4 utili per cercare tracce nei vostri log.
  • Rivedete le regole per i test con strumenti autonomi: egress controllato, ambienti dedicati, perimetro scritto e un responsabile che possa fermarli.
  • Migrate le applicazioni legacy alle piattaforme con protezioni di base, o isolatele fino alla migrazione.

Un'avvertenza finale: WorkOS non ha spiegato il meccanismo con cui l'agente sarebbe uscito dal sandbox, e questa parte della storia si basa sulla dichiarazione del ricercatore. Finché non emergono dettagli indipendenti, è prudente trattarla come una versione plausibile ma non verificata.