Do OpenAI se dostali dekodérem obrázků. Tutéž knihovnu má skoro každý web

Titulky minulý týden hlásily, že tři výzkumníci prolomili OpenAI za 72 hodin pomocí Clauda. To je pravda, ale je to ta nezajímavá část. Zajímavé je, čím se dovnitř dostali: dekodérem obrázků libheif, který nikdo z postižených firem vědomě neinstaloval a většina o něm neví, že ho má. Stejnou knihovnou se výzkumníci dostali do Slacku, Meta produktů, GitHub Enterprise a Next.js. Pokud váš web nebo aplikace přijímá obrázky od uživatelů, máte ji skoro jistě taky.

Co se stalo

• Původní zdroj, ne převyprávění: všechno níž beru z technického rozboru Hacking OpenAI, který 13. září 2026 zveřejnil bezpečnostní tým Hacktron (Harsh Jaiswal, Mohan Pedhapati, Rahul Maini), a z navazujícího webu HEIF Heist. Čísla a data jsem pak ověřoval u Discourse, Vercelu, GitHubu a v bezpečnostním trackeru Debianu — na některých místech si neodpovídají a píšu, kde.
• Řetěz vedl přes fórum, ne přes model. OpenAI provozuje komunitní fórum community.openai.com na Discourse a umožňuje na něm „Sign in with OpenAI". Discourse normálně kontroluje obrázky knihovnou FastImage, jenže ta neumí formát HEIF — takže tyhle soubory posílal na konverzi do ImageMagicku, a tím rovnou k parseru libheif. Tam byla ta díra.
• Chyba, která nikdy nedostala CVE. Hacktron píše, že zranitelný kód byl v upstreamu opraven už rok předtím, ale „commit nebyl dokumentován jako bezpečnostní oprava a nedostal žádné CVE". Proto se backport nedostal do Debianu včas. Discourse image stál na Debianu 12 s libheif 1.19.7, Debian 13 měl v té době taktéž zranitelnou 1.19.8.
• Datum po datu. 23. července 2026 začal tým procházet upload pipeline. 24. července vyrobil s Opusem 4.8 funkční exploit, ale jen s vypnutým ASLR; s ASLR zapnutým to nešlo. Ten večer vyšel Claude Opus 5 — nová session podle Hacktronu vyprodukovala funkční ARM64 exploit „do tří hodin". V 6:00 ráno 25. července bylo potvrzené lokální RCE přes upload obrázku, ve 10:00 měl agent RCE na Discourse Cloudu a doložil to výpisem /etc/hosts.
• Jak obešli odmítnutí modelu. Stojí to v rozboru otevřeně: Opus odmítal psát exploit proti vzdálené instanci, tak výzkumníci provoz proxovali přes rce.ee/ctf-forum, „aby to vypadalo jako CTF cíl". Bezpečnostní pojistka modelu padla na přejmenování domény.
• Důkaz dopadu. Po převzetí účtu zaměstnance OpenAI, jehož Codex byl napojený na GitHub organizaci, poslali jeho Codexu prompt, ať otevře PR č. 1186742 v interním monorepu openai/openai. Pak testování zastavili. OpenAI vyplatilo odměnu 6 500 dolarů. Hacktron zdůrazňuje, že slabina nebyla v Discourse — byla to chyba v SSO OpenAI a stejně by posloužila jakákoli jiná služba na tom přihlášení.
• Discourse zareagoval rychle. Podle vlastního bezpečnostního upozornění GHSA-vhm9-85gw-x335 je opraveno ve verzích 2026.7.0, 2026.6.1, 2026.5.2 a 2026.1.6 a nově se zpracování obrázků navíc izoluje v sandboxu. Report dorazil v sobotu, odpověď přišla v neděli, oprava v pondělí.
• Nezůstalo to u OpenAI. Z jednoho nálezu vznikl dvouměsíční projekt napříč ekosystémem. Podle Hacktronu stál méně než 3 000 dolarů v tokenech, dělali ho tři lidé a přizpůsobení exploitu každé další firmě trvalo „obvykle jeden nebo dva dny".

Tři věci, které v přehledech nebyly

Tohle jsem dohledal při ověřování a v žádném z převzatých článků to nestálo. Jsou to zároveň jediné tři věci z celého případu, které mají praktický dopad na běžnou firmu.

• 1. Skoro nikdo si toho nevšiml. Doslovná věta z rozboru: „Nevíme o žádné firmě, která by tu aktivitu detekovala, kromě Shopify — a to i poté, co jsme poslali tisíce obrázků a jejich procesory obrázků opakovaně padaly." Přečtěte si to ještě jednou. Útok na upload endpoint vypadá v logu jako opakované pády image procesoru. To většina firem nevyhodnocuje jako bezpečnostní událost, ale jako „zase se něco kouslo".
• 2. Oprava v Next.js není oprava, je to amputace. Vercel vydal 25. srpna 2026 verze 15.5.24 a 16.3.3 kvůli neautentizovanému RCE v Image Optimization API (GHSA-2xp9-vwfh-vxw4) — přes sharp, tedy zase libheif. V poznámkách ale stojí: „V opravených vydáních se AVIF obrázky nezmenšují ani neoptimalizují. Předávají se tak, jak jsou, dokud nebude k dispozici opravená verze libheif." Vercel navíc podle svého changelogu AVIF optimalizaci ve své spravované službě rovnou vypnul. Jinými slovy: nejrychlejší dostupná obrana byla tu funkci přestat používat.
• 3. Debian 12 na tom je pořád špatně. Tohle je číslo, které jsem si spočítal sám z bezpečnostního trackeru Debianu ke dni 21. září 2026. U balíčku libheif je evidováno 39 otevřených položek. Ve stabilním sid je opravených všech 39. V trixie (Debian 13) je 25 opravených a 14 stále zranitelných. A v bookworm (Debian 12, verze 1.15.1-1+deb12u1) je opravených jen 4 a zranitelných 35 — včetně samotného CVE-2026-32882, které Discourse uvádí jako příčinu svého RCE. Debian 12 je přitom základ obrovského množství produkčních Docker images. Pokud stavíte na debian:12 nebo na něčem, co z něj vychází, opravu jste nedostali ani dnes.

Kde si zdroje protiřečí

Slíbil jsem, že napíšu i nejistoty. Jsou tu tři a nejsou bezvýznamné — právě kvůli nim nejde tenhle problém odbavit vyhledáním jednoho čísla CVE.

• Jedna chyba, různá čísla. Discourse označuje příčinu jako CVE-2026-32882. Next.js a Vercel odkazují na GHSA-g89c-p67h-r497. To nejsou synonyma: Debian popisuje CVE-2026-32882 jako heap over-read ve funkci HeifPixelImage::overlay() (čtení až 3 123 bajtů mimo buffer u obrázku 100×50), zatímco GHSA-g89c-p67h-r497 je over-write ve scale_nearest_neighbor() přes duplicitní alfa kanály. Hacktron sám v textu mluví o „heap buffer overflow". Pro obránce z toho plyne: hledat v inventáři podle jednoho CVE nestačí, je potřeba řešit verzi balíčku.
• GitHub Enterprise sedí jen částečně. Web HEIF Heist uvádí mezi zásahy „autentizované RCE na GitHub Enterprise (CVE-2026-19118)". V release notes GHES 3.21.5 z 1. září 2026 ale GitHub tutéž CVE popisuje jako „race condition, která nahradila ověřený upload obsahem pod kontrolou útočníka ještě před zpracováním" — tedy jako chybu časování, ne jako paměťovou chybu v dekodéru. Buď jde o dva pohledy na tentýž řetěz, nebo o nepřesnost v jednom z popisů. Nevím který, takže to neprodávám jako jistotu.
• Tempo oprav samo o sobě je varování. Podle vydání na GitHubu vyšly u libheif tři bezpečnostní verze během dvanácti dnů: v1.23.2 (25. 8.), v1.23.3 (1. 9.) a v1.23.4 (6. 9. 2026). Hacktron k 14. září doporučuje v1.23.4 a výslovně píše, že v1.23.2 už je překonaná. Kdo v srpnu „zaktualizoval a má hotovo", má dnes zase starou verzi.

Proč se to týká i vás

Česká firma bez vlastního modelu si řekne, že prolomení OpenAI je cizí problém. Jenže nic z toho se netýká umělé inteligence jako produktu — AI tu byla jen nástroj útočníka. Napadené místo je úplně obyčejné.

• Tu knihovnu jste si nevybrali. libheif a libde265 jsou nativní C/C++ dekodéry, které se do produkce dostávají nepřímo: zabalené v ImageMagicku, libvips nebo Sharpu, ve standardních balíčcích distribuce a v předpřipravených kontejnerových image. Nefiguruje v žádném vašem rozhodnutí. Přesto stačí, aby vaše aplikace kdekoli přijala .heic, .heif nebo .avif — třeba fotku od zákazníka do reklamace nebo avatara do zákaznického portálu.
• Je to jazykově a frameworkově neutrální. Protože chyba sedí pod aplikační vrstvou, nezachrání vás Java, .NET, PHP ani Node. V advisory libheif stojí: „Ovlivněna je jakákoli aplikace používající heif_decode_image(). Nejsou potřeba žádné zvláštní volby API ani neobvyklé způsoby volání." Žádná chyba ve vašem kódu k tomu není nutná.
• Ekonomika útoku se změnila, obsah rizika ne. Tohle je jediné místo, kde AI do příběhu skutečně patří. Hacktron to shrnuje takto: software dlouho chránila „bezpečnost skrze složitost" — chyba mohla být veřejná, ale proměnit ji ve spolehlivý exploit vyžadovalo vzácnou expertizu a měsíce práce. Podle FAQ na HEIF Heist zkrátil agentní postup s frontier modelem vývoj exploitu na zhruba 1 až 3 dny od prvního průzkumu k RCE. To, co vás dřív chránilo prakticky (nestojí to za to), přestalo platit. Vaše hodnocení rizik ale pravděpodobně pořád počítá se starými cenami.
• Tisíce uploadů nebyly problém. Útok vyžadoval otisknout verzi knihovny opakovanými pokusy. Pokud váš upload endpoint nemá limit počtu pokusů a pády konverze obrázků nikam nehlásí, dali jste útočníkovi přesně ten prostor, který potřebuje — a jak ukázalo Shopify, detekovat to jde.
• Pro řízení dodavatelů z toho plyne nepříjemný závěr. Dodavatel, který vám odpoví „používáme podporovanou LTS distribuci a pravidelně aktualizujeme", vám touhle konkrétní odpovědí nesdělil nic. Debian 12 je podporovaná distribuce a přesto u něj dnes zbývá 35 otevřených položek u jedné knihovny. Správná otázka nezní „aktualizujete", ale „jakou verzi libheif máte v produkčním image".

Co s tím

Čtyři kroky, každý zvládne vlastní IT nebo dodavatel webu za jedno dopoledne. Nic z toho není projekt.

• 1. Zjistěte, jestli tu knihovnu vůbec máte. V běžícím kontejneru nebo na serveru: dpkg -l | grep -i -E 'libheif|libde265' (Debian/Ubuntu) nebo rpm -qa | grep -i heif. U Node projektů npm ls sharp. Když něco najdete, porovnejte verzi s aktuálním upstreamem — k 6. září 2026 je to v1.23.4, ale pozor: distribuce často backportují opravy pod starším číslem verze, takže se dívejte i na bezpečnostní advisory balíčku, ne jen na číslo.
• 2. Vypněte formáty, které nepotřebujete. Nejlevnější obrana v celém tomhle případu, a použil ji i Vercel. Pokud vaše aplikace nemá skutečný důvod přijímat HEIC/HEIF/AVIF, odmítejte je už na vstupu — a ne podle přípony, ale podle skutečného obsahu souboru. U ImageMagicku jde seznam povolených formátů omezit v policy.xml.
• 3. Nastavte si, že pád konvertoru obrázků je bezpečnostní událost. Tohle je z celého článku ta nejcennější a nejlevnější věc. Opakované pády image procesoru na jednom endpointu od jednoho zdroje = alert, ne řádek v logu. Byla to jediná stopa, kterou celá kampaň zanechala, a z desítek firem ji zachytila jedna. Zároveň k tomu přidejte rate limit na upload endpointy.
• 4. Zeptejte se dodavatele na verzi, ne na proces. Jednou větou e-mailem: „Jakou verzi libheif obsahuje produkční image naší aplikace a kdy byla naposledy aktualizována?" Odpověď „aktualizujeme pravidelně" není odpověď. Pokud běžíte na base image odvozeném od debian:12, počítejte s tím, že oprava zatím nedorazila, a řešte to bodem 2.

A teď proti vlastnímu byznysu: tenhle případ není důvod objednávat si AI audit a nesouvisí s tím, jestli máte governance na jazykové modely. Je to obyčejná správa zranitelností v závislostech — disciplína stará třicet let, kterou umí každý slušný systémový administrátor a která nepotřebuje nikoho zvenčí. Kdo vám na základě zpráv o „prolomení OpenAI pomocí Clauda" nabízí bezpečnostní projekt kolem AI, prodává vám špatnou věc: útok nemířil na AI, mířil na upload obrázků. Jestli máte v pořádku inventář závislostí a někdo u vás čte bezpečnostní oznámení k balíčkům, máte hotovo a nepotřebujete nás.

Kde to řeším s klienty

Kde to naopak dává smysl řešit společně, je rozhraní mezi tímhle a AI agenty: útok skončil tím, že se převzatý účet použil k poslání promptu do Codexu, který měl přístup do interního repozitáře. Přesně tenhle bod — co všechno může udělat agent, když někdo získá účet běžného zaměstnance — probírám v rámci AI Agent Governance Checkupu. Když netušíte, kam až vaši agenti dosáhnou, začněte AI Risk Scanem zdarma. Na stejný vzorec jsem tu narazil už dřív: agent se přihlásil správným heslem a agent si vypnul vlastní sandbox jedním příkazem. Pokaždé selhalo něco úplně obyčejného, a teprve agent z toho udělal přístup tam, kam neměl.