Apple postavil nejověřitelnější AI cloud na světě. Chyba se našla tam, kde ověřování nesahá

Apple postavil kolem svého AI cloudu tu nejdůkladnější obranu, jakou dnes v oboru najdete: ověřitelné sestavení, veřejně publikovaný kód, transparentní protokol a odměny za nalezené chyby. A přesto se v něm našla díra — v místě, které to ověřování nekontroluje. Neuniklo z ní jediné slovo z konverzace. Uniklo něco jiného a pro vaši firmu poučnějšího: údaje o konverzacích. Tenhle článek je o tom, proč se u dodavatelů AI vyplatí ptát zvlášť na obsah a zvlášť na metadata — a proč vám na dnešní zprávu žádný audit kupovat netřeba.

Co se stalo

• Kde: v Private Cloud Compute (PCC), což je serverová část Apple Intelligence. Když si iPhone na dotaz nestačí sám, pošle ho do PCC. Celá architektura je postavená na tom, aby k datům nemohl ani Apple.
• Co našel: průchod cestou (path traversal) v komponentě darwin-init — prvním procesu, který se na startu uzlu PCC spouští pod účtem root a instaluje podepsané softwarové balíky. Chyba je popsaná v rozboru výzkumníka Drinora Selmanaje z 31. července 2026. Rozbalovací rutina brala jméno záznamu rovnou z archivu a připojila ho k výstupní složce bez jakékoli kontroly — takže stačilo do archivu vložit cestu, která ze složky vede pryč.
• Proč to prošlo: darwin-init rozhodoval podle prvních čtyř bajtů souboru. Co neodpovídalo podpisu Applu, šlo obecnou rozbalovací cestou přes libarchive — a ta se na jména záznamů neptala.
• K čemu se tím útočník dostal: mohl zapsat soubory pod účtem root do /var/db/, tedy na zapisovatelný datový svazek. Konkrétně tam podstrčil konfiguraci logovacího démona splunkloggingd a přesměroval telemetrii uzlu na vlastní server.
• Co v té telemetrii bylo: stav démonů, telemetrie uzlu a hlavně metadata k jednotlivým dotazům — identifikátory požadavků, identifikátory aplikací, typy úloh, počty tokenů (vstupních, výstupních, návrhových i uživatelských) a časy odezvy. Podle rozboru jde o pole, která má Apple sám označená jako údaje, jež se nesmějí veřejně logovat.
• Co v ní nebylo: text dotazu ani text odpovědi, ani identifikátory či řetězce tokenů. Nešlo obejít atestaci ani se dostat k zašifrovaným uživatelským datům. Totéž nezávisle potvrzuje zpráva heise online z 10. srpna 2026.
• Jak to Apple vyhodnotil a opravil: jako vyzrazení informací se závažností CVSS 6.5, pod označením CVE-2026-20685. Opraveno ve vydání PCC 5E290.3 a novějších. Výzkumník za nález dostal odměnu 150 000 dolarů z Apple Security Bounty.

Co jsem při ověřování zjistil navíc

Titulky, které se k tomuhle nálezu nabalily, zní ve stylu „útočníci mohou v Apple cloudu zapisovat soubory jako root". To je technicky pravda a zároveň to vede k úplně špatnému závěru. Když jsem si otevřel původní rozbor a oficiální popis zranitelnosti, vyšly najevo čtyři věci, které v přejímkách chybí.

• Nešlo o útok přes internet. Oficiální vektor závažnosti zní AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. To „AV:A" znamená adjacent network — útočník musí být v sousední síti, ne kdekoli na internetu. Formulace samotného popisu chyby mluví o útočníkovi v privilegované síťové pozici. To je zásadní rozdíl oproti tomu, jak se to čte v titulcích.
• Celé se to odehrálo v testovacím prostředí, které Apple sám postavil. Autor výslovně uvádí, že veškerá práce proběhla uvnitř Virtual Research Environment — oficiálního nástroje, který Apple pro výzkum bezpečnosti PCC poskytuje — a že na produkční infrastruktuře netestoval nic. Škodlivý archiv si zaregistroval jako třetí balík ve vlastním testovacím uzlu. V žádném zdroji, který jsem četl, není zmínka o zneužití v reálném provozu.
• Tohle je ten nejdůležitější bod: atestace to nezachytila a ani zachytit nemohla. PCC ověřuje, že na uzlu běží přesně ten software, který Apple zveřejnil. Jenže konfigurační soubory na zapisovatelném datovém svazku, které za běhu řídí chování démonů, podle autora do toho ověřování zahrnuté nejsou. Útok nezměnil ani bajt ověřovaného kódu. Změnil nastavení, kterého se ověřování netýká — a získal tím jiné chování systému, který dál procházel jako neporušený.
• Vyzradila se metadata, ne obsah — a právě proto to stojí za pozornost. Neuniklo, na co se lidé ptali. Uniklo, kdo se ptal odkud, kdy, jak dlouho to trvalo a jak dlouhá byla odpověď. U jednotlivého dotazu je to bezvýznamné. U delší řady dotazů je to popis toho, jak firma pracuje. Většina firemních posouzení dodavatelů se přitom ptá jen na obsah.

Ještě poznámka k poctivosti: databáze zranitelností uvádějí u tohohle záznamu jiné datum zveřejnění než rozbor výzkumníka. Ten rozpor jsem nerozhodl, a proto tu s daty zveřejnění chyby nepracuji — pracuji jen s daty publikací, které jsem si otevřel, a s číslem opravné verze, na kterém se zdroje shodují.

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

Česká firma bez vlastního modelu nemá s PCC co dělat a opravu dostane v aktualizaci telefonu, aniž by o tom věděla. Přenositelné je tu něco jiného — tři otázky, které se dají položit každému dodavateli AI.

• Slib o soukromí má rozsah, a ten rozsah je skoro vždycky obsah. „Vaše data neukládáme a netrénujeme na nich" je věta o obsahu. Neříká nic o tom, co se děje s protokoly, identifikátory požadavků, časy a objemy. Apple je v tomhle nadprůměrně přísný — sám si tyhle údaje označuje za citlivé. Váš dodavatel to nejspíš neřeší vůbec.
• Metadata umí být výmluvnější, než se čeká. Když víte, že z jednoho oddělení chodí každý týden dvacet dlouhých dotazů a od pátku jich chodí dvě stě, víte něco o té firmě, aniž byste přečetli jediné slovo. Jestli a nakolik jsou taková data osobními údaji, závisí na tom, jak jsou spojitelná s konkrétními lidmi — to je otázka do vašich záznamů o činnostech zpracování, ne věc, kterou vyřeším jednou větou v článku.
• Certifikát pokrývá to, co má v rozsahu — a běhové nastavení v něm bývá málokdy. Tenhle případ je učebnicová ukázka: nejpřísnější ověřování v oboru krylo kód a minulo konfiguraci. Až vám dodavatel pošle certifikát, užitečná otázka nezní „máte ho", ale „co konkrétně je v jeho rozsahu a co v něm není".
• A poznatek, který se špatně říká nahlas: tahle chyba se našla jen proto, že Apple zveřejnil zdrojový kód, postavil pro výzkumníky testovací prostředí a za nález zaplatil 150 tisíc dolarů. U dodavatele, který nedělá nic z toho, se srovnatelná chyba nenajde — ne proto, že tam není, ale protože ji nemá kdo hledat.

Co s tím

• 1. Doplňte si k AI dodavatelům jeden řádek navíc. U každé služby, která zpracovává vaše data, si k poznámce „co se děje s obsahem" připište „co se děje s metadaty a protokoly a jak dlouho se drží". Když to v dokumentaci ani ve smlouvě o zpracování není, je to otázka na dodavatele — písemně, ať máte odpověď doloženou.
• 2. Ptejte se, co přesně je ověřované. Užitečná formulace: „Když nám garantujete integritu prostředí, vztahuje se to jen na software, nebo i na běhovou konfiguraci?" Odpověď „máme podepsané image" je odpověď na první polovinu otázky.
• 3. Ve vlastním nasazení se podívejte na konfiguraci logování. Ten útok stál a padl na tom, že proces mohl přepsat nastavení, které určuje, kam se posílají protokoly. Jestli si u sebe provozujete AI bránu nebo agenta, tohle je konkrétní kontrola na deset minut: kdo má právo zápisu do konfiguračních souborů odesílání logů a proč. Souvisí to s tím, o čem jsme psali u útoku na bránu LiteLLM — nejrychlejší cesta dovnitř nevede přes model, ale přes to, co kolem něj běží.
• 4. Nedělejte z toho závěr, že Apple je nebezpečný. Správný závěr je opačný: ověřitelnost je funkce, za kterou se vyplatí připlatit. Při výběru dodavatele AI má publikovaná dokumentace, program pro hlášení chyb a schopnost ukázat vlastní opravné vydání větší vypovídací hodnotu než marketingový slib o soukromí.

Kde to řeším s klienty

Rovnou a proti vlastnímu byznysu: jestli u vás lidé používají Apple Intelligence na firemních telefonech, po dnešním článku nemusíte dělat nic. Chyba je opravená, testovala se v prostředí, které Apple sám k testování vydal, a nikde není známka toho, že by ji někdo použil v ostrém provozu. Kdyby vám na tuhle zprávu chtěl někdo prodat audit, odmítněte ho.

Smysl má ozvat se v jiné situaci — když si nejste jistí, kolik AI služeb u vás vlastně běží a co která z nich vidí. To je obsah AI Agent Governance Checkupu: soupis nasazených nástrojů, jejich oprávnění a dosahu, včetně toho, co o vás sbírají mimo samotný obsah dotazů. Když chcete jen zjistit, jestli je co řešit, napište si o AI Risk Scan zdarma.