Nell'ultimo anno, @pewdiepie è diventato uno dei più visibili sostenitori del computing privato e auto-ospitato, ed è stato un vero piacere da osservare.
Quello che è iniziato a fine 2025 come un esperimento divertente – un rig domestico pieno di GPU modificate che eseguono modelli open-source, chatbot che votano in un "consiglio", potenza di calcolo in eccesso donata alla ricerca sul ripiegamento delle proteine – si è evoluto in circa dodici mesi in qualcosa con una missione chiara.
Il 31 maggio 2026 è arrivato come Odysseus, uno spazio di lavoro AI open-source, auto-ospitato e gratuito, che ha presentato senza mezzi termini come un colpo al modello di abbonamento: locale-first, privacy-first, nessuna telemetria, i tuoi dati che rimangono sul tuo hardware invece di fluire verso una manciata di grandi aziende.
Per qualcuno con la sua portata, mettere l'inferenza locale davanti a un pubblico mainstream e non tecnico è il tipo di cosa che il mondo della privacy desidera da anni, e io lo sostengo con tutto il cuore.
Sono anche la persona che, testando la mia implementazione autorizzata, ha trovato un modo per prendere il controllo di uno di questi server con un solo clic. Le due cose non sono in conflitto. Un software così ambizioso, rilasciato così velocemente, in una categoria così nuova, è esattamente il posto dove vivono i bug di sicurezza interessanti, e trovarli presto è il modo in cui il progetto diventa affidabile in seguito.
Quindi, nello spirito di aiutare, ecco l'intera catena, spiegata dalle fondamenta, insieme a cosa dice sul momento che stiamo costruendo.
una porta senza serratura, e una porta che sembrava solo innocua
Odysseus può affidare lavori pesanti a macchine GPU remote che raggiunge tramite SSH, il modo standard con cui un computer esegue comandi su un altro.
Ad alcuni dei suoi endpoint interni è quindi permesso toccare una shell di comando – la riga di comando grezza dove, se riesci a raggiungerla, puoi far fare alla macchina praticamente qualsiasi cosa.
Sensatamente, quasi tutti questi endpoint iniziano controllando che il chiamante sia un amministratore.
L'eccezione è un piccolo endpoint tranquillo il cui compito è elencare quali pacchetti Python sono installati su un server remoto, e questa eccezione è dove tutto si disfa.
Il primo problema è che questo endpoint non riceve mai le informazioni necessarie per identificare il suo chiamante, quindi non esegue alcun controllo di amministrazione e non può, nemmeno in linea di principio.
L'unica cosa che lo protegge è la regola generale dell'app che bisogna essere loggati, il che significa che qualsiasi account – incluso uno registrato da uno sconosciuto un minuto fa – può raggiungere una porta che tocca la shell, mentre ogni endpoint gemello la protegge attentamente.
La causa principale strutturale: un handler che non può vedere chi sta chiamando non può imporre chi è autorizzato, come si vede sotto.
Da solo, potrebbe essere sopravvivibile, ma c'è un secondo problema in come questo endpoint svolge il suo lavoro reale, ed è il cuore dell'intero attacco.
Per scoprire quali pacchetti ha installato una macchina remota, il programma scrive un'istruzione come una singola riga di testo semplice e la passa a una parte del sistema chiamata la shell, il cui compito è leggere la riga ed eseguirla.
Il modo più semplice per immaginare la shell è come un assistente che segue le istruzioni scritte in modo assolutamente letterale, dove alcuni segni di punteggiatura hanno un significato speciale.
Quello importante qui è il punto e virgola, che la shell legge come "quell'istruzione è finita, ora fai la prossima cosa", quindi una singola riga con punti e virgola viene eseguita come diversi comandi in sequenza.
Per questo motivo, i programmi attenti prendono qualsiasi cosa una persona abbia digitato e la racchiudono tra virgolette prima di passarla alla shell – è il modo della shell per essere istruita a trattare quei caratteri come testo normale, senza il potere di essere eseguiti come comandi.
Lo sviluppatore ha fatto correttamente questo per il nome del server e per il comando inviato, quindi quegli input erano sicuri.
Il numero di porta, però, è stato inserito nella riga nudo, senza virgolette, partendo dal presupposto apparentemente ragionevole che una porta sia sempre solo un numero e che un numero non possa fare alcun danno. (Anche il percorso dell'ambiente virtuale è stato concatenato allo stesso modo, senza virgolette, per lo stesso motivo.)
Il buco nel presupposto è che la porta non deve essere per forza un numero. Arriva come testo semplice estratto direttamente dall'indirizzo web, e chi fa la richiesta decide cosa deve dire.
Quindi, al posto di 22, un attaccante scrive 22; id; hostname #.
La shell legge il primo pezzo, prova a connettersi e fallisce inoffensivamente, poi raggiunge il primo punto e virgola e ubbidientemente esegue i due comandi dell'attaccante, mentre il # alla fine le dice di ignorare il testo rimanente che doveva seguire.
Un punto e virgola trasforma "elenca i pacchetti su una macchina remota" in "esegui i miei comandi su questa macchina."
Per raggiungerlo non serve niente di più esotico di una sessione con login e un indirizzo web modificato:
La richiesta restituisce HTTP 200 con il normale JSON dei pacchetti — mentre i comandi iniettati vengono eseguiti lato server.
I comandi che ho inserito erano sonde innocue, e quando il loro output è tornato nominando l'account di servizio del server stesso, ha confermato che le mie istruzioni erano state eseguite sulla macchina stessa.
Metti insieme i due difetti e il quadro locale si riassume in una frase: qualsiasi utente connesso può eseguire comandi a sua scelta sul server.
Il rischio di scala è acuito proprio dalla cosa che rende Odysseus entusiasmante.
Se un creatore con cento milioni di iscritti riesce a portare un pubblico vasto e non tecnico all'auto-hosting, il risultato sono migliaia di istanze simili, configurate in modo simile, esposte in modo simile, che è una monocultura, e le monoculture sono ciò che i worm amano.
@ashnichrist lo ha detto bene.
trasformarlo in un singolo clic
Un bug che "qualsiasi utente connesso" può attivare sembra ancora richiedere un malintenzionato interno, e il passo successivo è ciò che rimuove anche quel requisito, perché fa sì che il browser della vittima stessa esegua l'attacco.
La tecnica è il cross-site request forgery, e si basa su un'abitudine silenziosa del browser.
Una volta che ti connetti a un sito, il tuo browser memorizza un piccolo token e poi lo allega automaticamente alle richieste dirette a quel sito, basandosi puramente sulla destinazione della richiesta, senza riguardo per quale pagina l'ha messa in moto.
Odysseus ha impostato quel token con la politica SameSite=Lax, che è l'impostazione predefinita ragionevole e blocca il token dall'essere trasportato in richieste di sottofondo subdole – ma lo invia comunque deliberatamente in una navigazione di primo livello, il che significa un clic normale che sposta l'intera scheda da qualche parte.
Poiché l'endpoint vulnerabile risponde a un semplice link, non esegue alcun controllo su dove sia originata una richiesta e non usa un token anti-falsificazione, un attaccante deve solo ospitare una pagina con un pulsante invitante.
Per la dimostrazione ho costruito esattamente questo: una pagina tributo a CoComelon allegra, adatta ai bambini e, cosa più importante, fedele alla tradizione – colori da filastrocca, Comic Sans, un grande pulsante "play".
Il pulsante non è un link a una canzone. Il suo gestore di clic apre il vero target in una piccola finestra popup usa-e-getta, in modo che la richiesta dannosa avvenga come una navigazione di primo livello – portando con sé il cookie di sessione SameSite=Lax – senza rubare il focus, e poi si chiude automaticamente un momento dopo. L'indirizzo che apre è semplicemente l'endpoint del pacchetto con il comando nascosto nella "porta":
Mentre quel clic atterra, la pagina esca mette su uno spettacolo per la telecamera: l'opera d'arte di CoComelon lampeggia sullo schermo come un lampo di volata, e un terminale scrive da solo narrando ogni passo della presa di controllo. (Il testo del terminale è una narrazione in scena per la demo; la vera esecuzione è la richiesta silenziosa che il popup ha appena fatto.)
Per rendere l'impatto concreto, quel singolo clic ha fatto tre cose: ha riscritto l'interfaccia servita per un evidente imbrattamento visivo (una sovrapposizione a schermo intero "🍉 il tuo Odysseus è stato CoMmelon-ato 🍉", icone di anguria, l'app rinominata), ha letto tutto ciò che l'utente del servizio poteva leggere, e – in modo più duraturo – ha scritto un account amministratore nascosto direttamente nell'auth.json dell'app.
Il punto dolente: un riavvio pulisce il pasticcio evidente e mantiene l'account dell'attaccante.
Ecco una demo dal vivo.
perché questo è il peggior tipo di bug da avere in uno strumento agentico
Il motivo per cui una compromissione di una singola istanza dovrebbe preoccuparti nel 2026 è che raramente le cose si fermano lì, e il worm che ha definito l'anno mostra perché.
Shai-Hulud, il worm npm auto-propagante visto per la prima volta a settembre 2025 e tornato in ondate più grandi da allora, esegue un ciclo brutalmente semplice: uno script malevolo al momento dell'installazione viene eseguito nell'istante in cui un pacchetto viene installato, scansiona la macchina alla ricerca di segreti come token npm e GitHub, chiavi SSH e credenziali cloud, e poi usa quelle credenziali rubate per pubblicare versioni backdoorate degli altri pacchetti della vittima, così ogni nuova installazione diventa il prossimo punto di lancio senza ulteriore sforzo da parte dell'attaccante.
La lezione che vale la pena portare avanti è che il compito più difficile di un worm è raccogliere credenziali e trovare un modo per passare alla macchina successiva.
Un assistente AI agentico offre a un worm
entrambe
queste cose gratuitamente, perché detenere potenti segreti e raggiungere altre macchine è il suo intero scopo.
Il singolo clic contro Odysseus ha prodotto molto più dell'esecuzione di codice. Ha consegnato un caveau pre-collezionato di chiavi API memorizzate, il database, la configurazione e l'accesso SSH che lo strumento usa per connettersi ai server GPU remoti che gestisce. Questo è esattamente il carburante su cui si basa un attacco auto-propagante, seduto in un posto con l'etichetta rivolta verso l'esterno, e il manuale per usarlo esiste già nel mondo reale.
cosa significa tutto questo
Ciò che mi colpisce di più è che il bug che ha effettivamente preso il server è antico. L'iniezione di comandi e la falsificazione di richieste hanno soluzioni da manuale che uno sviluppatore del 2005 riconoscerebbe, e si trovavano all'interno di uno dei software AI consumer più lungimiranti in circolazione – che è lo schema in tutta l'industria quest'anno, dove le vulnerabilità AI di testa si rivelano essere difetti classici all'interno di nuovi strumenti scintillanti.
La frontiera ha lasciato quei fondamenti pienamente in vigore, poi ha impilato un livello potente, veloce e spesso eccessivamente fidato sopra di essi e ha collegato quel livello a tutto ciò che possiedi.
il campanello che non era ancora stato collegato
C'è un altro dettaglio da cui imparare, perché è la parte che ha meno a che fare con il codice.
Quando ho provato per la prima volta a segnalare questo problema, c'era una politica di sicurezza nel repository – una politica ponderata, con indicazioni di implementazione sensate.
Ma la sua sezione di segnalazione indirizzava i potenziali segnalatori a "avvisi di sicurezza GitHub se disponibili", e all'inizio quel canale privato semplicemente non era aperto.
La cosa più sensibile che uno sconosciuto poteva trovare sul progetto non aveva un posto privato dove atterrare. Quel divario è stato da allora chiuso – la catena di iniezione di comandi è ora tracciata da un avviso critico, e le correzioni sono state unite – ma l'assenza iniziale è il segno rivelatore.
Per fortuna, sono riuscito a parlare con uno dei manutentori, che ha aperto la funzione degli avvisi – e da allora ho presentato un certo numero di altre correzioni.
Tutto ciò a parte... è un segno dei tempi.
I progetti ora passano da un hobby su un rig GPU domestico a un pubblico di cento milioni di persone nel giro di un singolo annuncio, e l'impalcatura di sicurezza – una casella di posta privata per le cattive notizie, un flusso di lavoro per gli avvisi, l'abitudine di trattare l'output del modello come ostile – è in ritardo rispetto al codice, che a sua volta è in ritardo rispetto al pubblico.
Quell'ordine è esattamente l'opposto di ciò di cui un avversario ha bisogno.
Una base di fan ampia, fiduciosa e in gran parte non tecnica che installa lo stesso software nella stessa settimana, indirizzata da qualcuno di cui già si fida, è il bersaglio più attraente che ci sia: enorme, uniforme e già convinto.
È esattamente la monocultura che un worm desidera, con il tappeto di benvenuto già steso.
Quindi la parte incoraggiante di questa storia non è che il codice fosse perfetto – non lo era – ma che il progetto ha collegato il campanello e ha rilasciato le correzioni entro circa un giorno dall'aver sentito il bussare.
Per un software che si muove così velocemente, di fronte a un pubblico di queste dimensioni, quel riflesso – aprire un canale privato, rispondere rapidamente, correggere in pubblico – vale più che avere avuto una fedina penale immacolata all'inizio. È, in definitiva, come la fiducia nell'auto-hosting viene effettivamente guadagnata.
Per ora... è tutto, gente!
https://x.com/Grummz/status/2061300454907371953
https://x.com/ashnichrist/status/2061481763516399737
