Opravy, které OpenAI uvádí z testů izolace modelů, vznikly dřív, než pozastavila trénink
OpenAI 23. října popsala, jak její agenti při zkouškách unikali z virtuálních strojů a hledali cestu na internet. Jako doklad uvádí opravy v Kata Containers, gVisoru a Dockeru. Podle GitHubu byly všechny začleněné mezi únorem a 16. zářím, tedy dřív, než firma pozastavila trénink a podmínila jeho obnovení právě takovými testy.
OpenAI zveřejnila 23. října rozbor toho, jak chrání prostředí pro trénink a zkoušení svých nejsilnějších modelů. Začíná incidentem z 20. září: interní výzkumný model tehdy během tréninku zneužil špatně nastavený překladač doménových jmen (DNS) a dostal se v omezené míře na internet. Jak k tomu došlo, popsal starší článek o zásadách bezpečnostních rozborů. OpenAI pak pozastavila trénink a vyhodnocování nejschopnějších modelů. Trénink obnovila 1. října, jedenáct dní po začátku pauzy.
Pauza měla podle eeNews Europe trvat, dokud firma neověří nové pojistky a nedokončí další útočné testy výzkumné infrastruktury. Nový rozbor ty testy popisuje. Týmy agentů postavené na nejsilnějších modelech OpenAI, mezi nimi na chystaném GPT-6 Astra Cyber, dostaly za úkol z prostředí uniknout. Aby měly podmínky výhodné pro útočníka, dostaly zdrojový kód infrastruktury, podrobnosti konfigurace a dokumentaci možných slabin. Zkoušky běžely na oddělených kopiích infrastruktury a spotřebovaly podle firmy stovky miliard tokenů.
Agenti se dostali z virtuálních strojů i přes sdílenou cache
Podle OpenAI agenti skládali chyby do řetězců, kterými unikli z virtuálního stroje na hostitelský počítač. V dalších pokusech dostali hostitele rovnou a měli zjistit, jestli se z něj dostanou na internet. Slabiny našli téměř ve všech službách, přes které spojení ven zůstalo: v metrikách, záznamech provozu a správě přihlašování. Jeden agent využil spojení povolené firewallem k zablokovanému přihlašovacímu bodu služby pro metriky a přiměl ji stáhnout adresu, kterou sám zadal.
Agenti v oddělených virtuálních strojích na témže hostiteli si navíc uměli předávat zprávy bez sítě a bez sdíleného souboru. Jeden vytlačoval vybraná data z vyrovnávací paměti procesoru, druhý měřil, jak dlouho trvá je znovu načíst, a z rychlých a pomalých čtení skládal zprávu. Podobné kanály našli přes sdílené úložiště, soupeření o čas procesoru a mezipaměť certifikátů TLS v offline kopii webu, na které se modely učí prohlížet. Cestu na internet, kterou by agenti zneužili snadno a bez povšimnutí monitorování, OpenAI podle svých slov nenašla.
Odkazované opravy jsou z února až září
U nálezů v otevřeném softwaru rozbor odkazuje na konkrétní opravy, které podle OpenAI vzešly z těchto testů. Na GitHubu u nich jde dohledat autora i den, kdy je správci projektu přijali:
| Projekt a oprava | Co řeší | Autor | Přijato |
|---|---|---|---|
| Kata Containers, CVE-2026-24834 | kontejner mohl přepsat souborový systém hostujícího virtuálního stroje | hlášení od účtu kostya-oai | 19. 2. 2026, verze 3.27.0 |
| Kata Containers, návrh 13587 | odmítne proces s pracovním adresářem mimo kořen kontejneru | Chris Ayoub, OpenAI | 12. 8. 2026 |
| Kata Containers, návrh 13615 | přísnější zacházení s oprávněními a jmennými prostory | Chris Ayoub, OpenAI | 17. 8. 2026 |
| gVisor, návrh 13816 | předávání popisovačů souborů přes unixové sokety | Etienne Perot | 30. 7. 2026 |
| Docker, moby/profiles 39 | výchozí filtr systémových volání povolí jen vyjmenované druhy soketů | Paweł Gronowski, Docker | 16. 9. 2026 |
Zvlášť, jako „širší práci na bezpečnosti jádra“, uvádí OpenAI tři opravy Linuxu. CVE-2026-74753 v podsystému perf a CVE-2026-80841 v síťovém rozhraní AF_PACKET napsal Kyle Zeng s adresou openai.com, do jádra se dostaly 7. a 20. srpna. Třetí, CVE-2026-80521 v unixových soketech, napsal 6. srpna Kuniyuki Iwashima s adresou google.com podle hlášení téhož Kyleho Zenga.
Nejmladší z odkazovaných oprav, filtr v Dockeru, přijali správci 16. září, čtyři dny před incidentem s DNS. Oprava CVE-2026-24834 je dokonce z února, tedy i z doby před letním incidentem, kdy se modely OpenAI z testů dostaly až na servery Hugging Face. Útočné testy izolace tedy podle veřejných záznamů běžely měsíce před pauzou, ne až během ní. Kdy začaly, rozbor neuvádí. Co agenti našli mezi 20. zářím a 1. říjnem, z odkazů nepoznáš: OpenAI píše, že nahlásila „řadu dalších zranitelností“, které zatím veřejné nejsou.
Opravy se týkají i jiných provozovatelů
Kata Containers, gVisor i výchozí profil Dockeru nepoužívá jen OpenAI. Jsou to běžné vrstvy pro spouštění cizího kódu v izolaci, tedy i kódu, který píšou agenti. Chyba CVE-2026-24834 má podle hlášení hodnocení 9,3 z 10 a týká se Kata Containers do verze 3.26.0 s Cloud Hypervisorem. Útočníkovi stačí oprávnění vytvářet soubory zařízení (CAP_MKNOD), správcovská práva v kontejneru nepotřebuje. Podle autora hlášení skončí v hostujícím virtuálním stroji a na hostitele ani k jiným kontejnerům nedosáhne.
Obě srpnové úpravy obsahuje Kata Containers 4.1.0 z 21. srpna, takže kdo chce všechny tři opravy, potřebuje aspoň tuhle verzi. Nejnovější je 4.3.1 z 21. října. U gVisoru a profilu Dockeru rozbor ani návrhy změn neuvádějí, ve kterém vydání se oprava objevila.
Útočné testy nejsilnějšími modely chce OpenAI dělat průběžně a zařadila je do bezpečnostních rozborů, které musí předcházet dalšímu tréninku nejschopnějších modelů. Rozbor vychází v době, kdy vysvětlení k letním incidentům žádá i Úřad pro umělou inteligenci Evropské komise.
Zdroje
- OpenAI: Securing our frontier model training environment (23. 10. 2026)
- eeNews Europe: OpenAI pauses frontier AI training after agent security breach (28. 9. 2026)
- Kata Containers: hlášení GHSA-wwj6-vghv-5p64 (CVE-2026-24834)
- Kata Containers: návrhy 13587 a 13615, vydání 4.1.0
- gVisor: návrh 13816
- moby/profiles: návrh 39
- Linux: commity fa091f46, 992cc9f9 a 594d9051