Mythos 'Discovered' a CVE Already in Its Training Data - and That’s Still Worrying
Anthropic made headlines claiming Claude Mythos achieved the “first remote kernel exploit discovered and exploited by an AI.” We went looking for how - and found a 20-year-old bug hiding in plain sight. # What did Claude Find? In Anthropic’s initial Claude Mythos post, they discuss multiple different vulnerabilities that Mythos discovered and exploited. The one with the most detail (including a CVE and full technical writeup) is CVE-2026-4747 - a remote code execution capability in FreeBSD’s networked file system. [...] This vulnerable code has roots in Sun Microsystem’s Open Network Computing Remote Procedure Call (ONC RPC) and its Network File System (NFS) - developed initially in 1984 and released in 1985. [...] So, you would expect Mythos’ CVE to be for MIT’s implementation too? Is it possible we have a bigger problem on our hands? Please welcome, an oldie-but-goodie, CVE-2007-3999! [...] The George Bush-era patch to Kerberos is also nearly identical to what FreeBSD implemented last month in response to Mythos [...] in the case of CVE-2026-4747, the finding of the vulnerability itself seems much more an instance of combinatorial creativity, with AI making a discovery already within its training data. # Bottom Lines Understanding the true risk of AI in cybersecurity means separating the sci-fi hype from the reality of how these models actually work. The FreeBSD’s CVE was caused by human negligence in the early 2000’s. But, in 2026, decades-old flaws are being baked directly into our systems faster than ever. LLMs, as they configure our environments and write new code, regurgitate the same insecure patterns they were trained on. Continua con una breve ma interessante analisi storica del codice di FreeBSD qui: https://rival.security/posts/mythos-discovered-a-cve-already-in-its-training... Si noti comunque come riconoscere Claude Mythos come un grosso archivio compresso con perdita di cui è possibile estrarre approssimazioni di alcune zone prossime all'input (prompt, contesto etc...) non lo rende inutile. Giacomo
Buongiorno, On 2026-05-14, Giacomo Tesio via nexa wrote: [...]
# Bottom Lines
Understanding the true risk of AI in cybersecurity means separating the sci-fi hype from the reality of how these models actually work. The
[...]
Continua con una breve ma interessante analisi storica del codice di FreeBSD qui: https://rival.security/posts/mythos-discovered-a-cve-already-in-its-training...
siccome sono cose molto tecniche e sconosciute ai più, faccio sommessamente notare alcune questioni facili facili da non ignorare: 1. fuori di dubbio che l'analisi svolta attraverso quel LLM abbia scovato un pezzo di codice che provoca il duecentomiliardesimo buffer overflow della storia del software scritto in C 2. fuori di dubbio che di tecniche per scovare automaticamente potenziali buffer overflow [1] o "addirittura" per evitare _alla radice_ i buffer overflow [2] ne esistano e siano conosciute ai bravi programmatori da decenni 3. fuori di dubbio - e questo è il punto fondamentale - che questa analisi, sia che sia svolta con LLM che da _esseri umani_ con altri strumenti, richiede: 3.1 che siano dedicate adeguate risorse al compito _e_ che tra le risorse dedicate vi siano persone competenti in materia, anche se usano LLM (se non altro per non sparare "prompt" a caso) 3.2 che il software sia: 3.2.a disponibile in formato sorgente 3.2.b disponibile con una licenza che NON impedisca di pubblicare i risultati ottenuti Fatelo con MS Windows o MAC OSX, se ne avete le risorse. In ogni caso: ci stanno forse suggerendo che le aziende che producono software dovrebbero usare "a tappeto" strumenti come quel LLM per aumetare i loro profitti risparmiando sui bravi _analisti_ programmatori in grado di scrivere codice "safe by design" o di farne analisi per il debugging? Auguroni!!! ...e poi, volete _davvero_ fare a gara a chi c'è l'ha più lunga, la lista dei CVS?!? :-D [...] Saluti, 380° [1] https://en.wikipedia.org/wiki/Static_program_analysis https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis [2] l'argomento è "ostico", solo per segnalare un esempio: https://www.cisa.gov/resources-tools/resources/secure-design-alert-eliminati... ma la discussione tecnica NON deve diventare una guerra "Rust contro C" anche perché ci sono _per forza_ alcune operazioni che devono essere svolte in modalità "memory unsafe", anche in linguaggi "memory safe" come Rust. Certo è che per moltissime applicazioni (per ora non per il kernel, non si può) sarebbe meglio evitare linguaggi memory unsafe. -- 380° (lost in /traslation/) «Welcome to the chaos of the times If you go left and I go right Pray we make it out alive This is Karmageddon»
participants (2)
-
380° -
Giacomo Tesio