Aplikace OpenClaw pro iOS psala do systémového logu trvalý klíč k agentovi
Verze OpenClaw pro iPhone před 2026.8.11 vypisovala do sjednoceného logu celou adresu odkazu, kterým se agentovi zadává práce. V té adrese bývá trvalý klíč, který zadání propustí bez potvrzení na telefonu. Oprava ubrala jeden řádek kódu, číslo CVE k ní přibylo o tři týdny později.
Aplikace OpenClaw pro iPhone zapisovala do sjednoceného systémového logu celou adresu odkazu, kterým se agentovi zadává práce na dálku. V té adrese může být trvalý klíč, který zadání propustí bez potvrzení na telefonu. Kdo získá diagnostický archiv z přístroje, přečte klíč z logu a může agentovi poslat vlastní zadání. Projekt to popsal ve vlastním bezpečnostním hlášení 11. září 2026, číslo CVE-2026-95815 k tomu přibylo o jedenáct dní později.
Jeden řádek, který řekl systému všechno ukázat
Chyba je na jednom místě. Ve funkci handleAgentDeepLink v souboru NodeAppModel.swift stálo před opravou tohle:
self.deepLinkLogger.info(
"agent deep link messageChars=\\(message.count) url=\\(originalURL.absoluteString, privacy: .public)")Rozhoduje poslední část. Apple má pro zápis do logu čtyři volby soukromí a v dokumentaci k nim píše doslova, že systém ve výchozím stavu čísla nechává vidět, ale obsah dynamických řetězců zakrývá. Adresa odkazu je dynamický řetězec, takže by ji log ukázal jako skrytou hodnotu. Značka privacy: .public znamená podle přehledu těch voleb „vždy zobrazit“ – někdo ji tam tedy musel napsat.
Oprava z 1. září ubrala jeden řádek a jeden přidala: z logu zmizela adresa a zůstal počet znaků zprávy. Spolu s tím přibyl test, který neměří chování programu, ale čte vlastní zdrojový soubor a kontroluje, že se v té funkci řetězec originalURL.absoluteString, privacy: .public už nevyskytuje.
Proč je zrovna ten klíč cenný
Z kódu je vidět, co klíč dělá. Obsluha odkazu se ptá metodou isUnattendedDeepLinkAllowed, jestli předložený klíč platí. Když ano, zadání jde rovnou agentovi. Když ne, aplikace ukáže potvrzovací okno s náhledem zprávy a adresy, a ještě před tím odmítne zprávy nad určitou délku. Klíč je tedy přesně ten díl, který zastupuje člověka u telefonu.
Útok má své podmínky a hlášení je vyjmenovává: telefon musel nejdřív zpracovat opravdový odkaz s klíčem, klíč se od té doby nesměl změnit a útočník potřebuje vlastní adresu na přístroji spustit. Diagnostické archivy z iPhonu přitom nejsou nic exotického – sbírají se při hlášení chyb a posílají se podpoře nebo vývojáři.
Dvě hodnocení závažnosti u jednoho záznamu
Projekt svoje hlášení označil za středně závažné se známkou 6,3 podle metodiky CVSS ve verzi 3.1. Firma VulnCheck, která číslo CVE přidělila, vede tentýž případ jako vysoce závažný se známkou 7,2 podle novější verze 4.0. Obě čísla platí, jen každé pochází z jiné metodiky; databáze hlášení GitHubu vypisuje vedle sebe obě. Kategorie slabiny je v obou případech tatáž, CWE-532, tedy vložení citlivé informace do souboru logu.
Časová osa je na tomhle případu zajímavější než čísla. Oprava byla v repozitáři 1. září, hlášení projektu vyšlo 11. září a záznam CVE si VulnCheck rezervoval a zveřejnil až 22. září. Mezi opravou a číslem, podle kterého si věc najde běžný správce, tak uběhly tři týdny.
Verze v obchodě a verze v repozitáři nejsou totéž
Hlášení mluví o opravené verzi 2026.8.11. V repozitáři OpenClaw taková značka není: jeho vydání jdou v2026.8.1, v2026.8.2 a pak rovnou v2026.9.1 až v2026.9.5. Číslování aplikace pro iOS běží vedle toho samostatně. Rozhraní App Storu vede aplikaci pod vydavatelem OpenClaw Foundation, první vydání 24. června 2026 a poslední aktualizaci 12. září 2026 s verzí 2026.9.20 – ta je tedy novější než opravená. Komu se aplikace aktualizuje sama, má opravu dávno.
Pro ostatní má hlášení tři kroky: povýšit na 2026.8.11 nebo výš, změnit klíče, které mohly v logu skončit, a zahodit uložené diagnostické archivy s těmi odkazy. To druhé je to, na co se zapomíná – povýšení aplikace klíč, který už někdo viděl, nijak nezneplatní.
Souvislost se starším opatřením
Ochranou klíče se OpenClaw zabýval už v srpnu, kdy zavedl omezení uloženého klíče na vyjmenované servery. Obojí se týká téže věci z opačné strany: tehdy šlo o to, komu se klíč pošle, tentokrát o to, že si ho aplikace vypsala sama u sebe. Opatření proti odeslání na cizí server s logem na vlastním přístroji nic nesvede.