Obsah

Claude Mythos a bezpečnostní audit Firefoxu

Vytvořeno: 16.5.2026 | Aktualizováno: 16.05.2026 14:42

Mozilla popsala, jak při hardeningu Firefoxu zapojila Claude Mythos Preview a další AI modely do hledání latentních bezpečnostních chyb. Příspěvek Min Choie na X k tomu dobře vystihuje hlavní pointu: AI audit kódu už není jen marketingová ukázka, ale prakticky použitelná metoda pro hledání reálných zranitelností.

Graf oprav bezpečnostních chyb ve Firefoxu podle Mozilla Hacks

Co se stalo

Mozilla uvádí, že v rámci Firefoxu 150 opravila 271 chyb identifikovaných pomocí Claude Mythos Preview. Z těchto 271 chyb bylo 180 hodnocených jako sec-high, 80 jako sec-moderate a 11 jako sec-low.

Důležité je, že dubnových 423 opravených bezpečnostních chyb není totéž jako „423 chyb nalezených Mythosem“. Mozilla v FAQ vysvětluje, že do dubnového čísla patřilo:

Proč je to zajímavé

Graf z článku ukazuje prudkou změnu objemu bezpečnostních oprav. V roce 2025 se měsíční počty bezpečnostních oprav Firefoxu držely přibližně v rozsahu 17–31. V roce 2026 následoval nárůst na 61 oprav v únoru, 76 v březnu a 423 v dubnu.

To neznamená, že by samotný model magicky opravil Firefox. Zásadní je kombinace modelu, harnessu a interní bezpečnostní pipeline. Mozilla popisuje posun od dřívějších LLM reportů plných šumu k agentnímu procesu, který umí nejen navrhnout hypotézu zranitelnosti, ale také vytvořit a spustit reprodukovatelný test case.

Jak fungoval přístup Mozilly

Mozilla postavila vlastní harness nad existující fuzzing infrastrukturou. Smyslem nebylo jen staticky „přečíst kód“, ale dynamicky ověřovat hypotézy o zranitelnostech.

Zjednodušený proces:

  1. Vybere se oblast kódu nebo konkrétní soubor, kde má model hledat problém.
  2. Model dostane úlohu ve stylu: v této části kódu je chyba, najdi ji a vytvoř test case.
  3. Harness umožní modelu test case vytvořit a spustit.
  4. Výsledky se sbírají z více paralelních běhů na dočasných VM.
  5. Následuje deduplikace, triage, založení bugů, oprava, testování a vydání fixů.

Mozilla zdůrazňuje, že model je jen jedna část systému. Aby to fungovalo ve velkém, musí být napojený na konkrétní procesy projektu — bug tracker, bezpečnostní klasifikaci, release management a práci vývojářů.

Typy chyb

Ve zveřejněném vzorku jsou chyby z různých částí browseru: WebAssembly GC, DOM, IndexedDB, IPC, WebTransport, DNS/ECH parsing, XSLT nebo sandboxing. Zajímavé je, že část reportů míří na sandbox escapes — tedy chyby, které samy o sobě obvykle nestačí na plný kompromis prohlížeče, ale mohou být součástí exploit chainu.

Mozilla zároveň upozorňuje, že označení sec-high nebo sec-critical neznamená automaticky praktický exploit. V prohlížeči s obranou ve vrstvách je často potřeba zkombinovat více zranitelností, například nejprve kompromitovat sandboxovaný content proces a teprve potom eskalovat do privilegovaného parent procesu.

Co z toho plyne

Praktická poznámka pro vlastní projekty

Pro menší projekt není realistické kopírovat celou infrastrukturu Mozilly. Přenositelný je ale princip:

  1. nezačínat obecným „najdi bugy v repo“,
  2. vybrat rizikovou část kódu,
  3. dát modelu možnost spouštět testy,
  4. požadovat reprodukovatelný test case,
  5. oddělit spekulace od ověřených nálezů,
  6. napojit výstup na normální triage a opravy.

Mozilla tento základní vnitřní loop shrnuje velmi jednoduše: v této části kódu je chyba, najdi ji a postav test case.

Zdroje