Sedmkrát CVSS 10,0 a nemáte co stáhnout. Microsoft opravil díry v Azure a Copilotu dřív, než o nich řekl

Microsoft zveřejnil 17. září osmnáct zranitelností ve svých cloudových službách. Sedm z nich má nejvyšší možné skóre 10,0 — mezi nimi chybějící autentizaci v Azure AI Foundry a příkazovou injekci v Microsoft 365 Copilotu. U všech osmnácti je v katalogu poznámka „Customer Action Required: No". Nemáte co stáhnout, nemusíte nic dělat. Přesně to je ale důvod, proč se o nich vaše firma nedozví ze žádného patch reportu — a proč o nich při auditu nebudete mít jediný záznam.

Co se stalo

• Kde to je: všechna čísla níž beru z dokumentu September 2026 Security Updates (ID 2026-Sep, poslední revize 18. září 2026), který Microsoft publikuje strojově čitelně přes MSRC CVRF API. Ne z novinových článků — ty u tohoto tématu pravidelně slučují zářijové Patch Tuesday s pozdějšími cloudovými CVE do jednoho čísla, a pak to nesedí.
• Kolik toho je: celý zářijový dokument obsahuje 1 774 záznamů. Z nich má 27 v poli Customer Action Required hodnotu No — to jsou takzvané cloud service CVEs, tedy díry ve službách, které Microsoft provozuje sám. Devět z nich vyšlo 8. září, osmnáct 17. září.
• Sedm z těch osmnácti má CVSS 10,0: CVE-2026-85889 (Azure AI Foundry), CVE-2026-62874 (Azure Billing), CVE-2026-69399 (Azure Arc), CVE-2026-69843 (Microsoft Fabric), CVE-2026-69865 (Microsoft Container Registry) a dvě v Azure Logic Apps (CVE-2026-70200 a CVE-2026-83944). Další čtyři jsou mezi 9,0 a 9,9 — Azure Database for PostgreSQL, Microsoft 365 Copilot, Azure Cosmos DB, Microsoft Dataverse.
• Nejvyšší skóre má AI služba a příčina je banální. U CVE-2026-85889 Microsoft píše: „Missing authentication for critical function in Azure AI Foundry allows an unauthorized attacker to elevate privileges over a network." Klasifikace je CWE-306 — Missing Authentication for Critical Function, vektor AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H: po síti, bez oprávnění, bez interakce uživatele, s únikem mimo hranici systému. Podle záznamu v CVE.org byl zveřejněn 17. září 2026 ve 14:00 UTC a nese značku exclusively-hosted-service. Nahlásil ho externí výzkumník Rémy Marot.
• Není to ojedinělý typ chyby. Úplně stejnou klasifikaci CWE-306 a stejné skóre 10,0 má i CVE-2026-70352 v Azure AI Language z dávky o devět dní dřív. Dvě AI služby téhož poskytovatele, dvakrát „u kritické funkce chyběla autentizace", během deseti dnů.
• Copilot má v téhle dávce čtyři záznamy. CVE-2026-85885 (M365 Copilot, 9,9, příkazová injekce CWE-77, útočník ale musí být přihlášený), CVE-2026-85887 (M365 Copilot, 7,7, špatně přidělená oprávnění, CWE-732), CVE-2026-78501 (M365 Copilot Business Chat, 7,4, CWE-77 plus CWE-923 — Improper Restriction of Communication Channel to Intended Endpoints, tedy komunikace mimo zamýšlený cíl) a CVE-2026-55946 (Microsoft Copilot, 6,1). Za Business Chat je v poděkování uveden Vitaly Simonovich z Cato Networks.
• Detail, který v přehledech nikde nebyl: sedmnáct z osmnácti záznamů má ve vektoru E:U, tedy Exploit Code Maturity: Unproven. Jediná výjimka je CVE-2026-85917 — SSRF v Azure AI Foundry (CWE-918, skóre 7,5), která má E:P, tedy existující proof-of-concept. Nižší skóre, ale jako jediná z celé dávky doložitelně napsaný funkční postup.
• Kdo to našel: u osmnácti záznamů uvádí Microsoft poděkování. Pět chyb nahlásili jeho vlastní lidé („with Microsoft"), dvanáct přišlo zvenku — mimo jmenované i Binary Security, SpecterOps, Upwind Security, XBREACH.AI, Cato Networks. U jedné (CVE-2026-55946) poděkování chybí úplně.
• Proč vůbec CVE vzniká, když není co opravovat: Microsoft to vysvětlil v blogu Toward greater transparency: Unveiling Cloud Service CVEs (27. června 2024, autorka Lisa Olson): „budeme vydávat CVE pro kritické zranitelnosti cloudových služeb bez ohledu na to, zda si zákazníci musí nainstalovat opravu nebo podniknout jiné kroky". Opírá se o pravidlo CNA 4.2.2.2, podle kterého se má CVE přidělit, pokud zranitelnost „má potenciál způsobit významnou škodu" nebo „vyžaduje akci či posouzení rizika stranami mimo CNA nebo dodavatele". Microsoft zároveň přiznává, že „ne všichni zákazníci chtějí investovat čas a energii" do téhle nové třídy CVE — proto to pole Customer Action Required vzniklo, jako filtr na odfiltrování.

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

Pokud vaše firma nepoužívá Azure ani Microsoft 365, tenhle článek si můžete odpustit. Pokud používá — a v Česku ho používá většina —, je tu jedna nepříjemná vlastnost celé téhle kategorie.

• Nedozvíte se to. Vůbec. Když vyjde díra ve Windows, dorazí vám patch, IT to vidí v konzoli, je o tom řádek v reportu. Když vyjde díra v Azure AI Foundry, Microsoft ji opraví dřív, než ji zveřejní, a vy nedostanete žádné oznámení. Zranitelnost s nejvyšším možným skóre tedy proběhne vaší infrastrukturou, aniž by o ní kdokoli u vás věděl. Microsoft navíc sám nabízí, jak si to nechat schovat — filtr existuje právě proto.
• Chybí vám doba expozice. Microsoft u těchto CVE neuvádí, kdy chyba vznikla ani jak dlouho ve službě byla. Zveřejňuje až stav „opraveno". Znamená to, že na otázku „byli jsme někdy zranitelní a jak dlouho" neumíte odpovědět — ne proto, že byste špatně měřili, ale protože ta informace neexistuje. Kdo staví bezpečnostní dokumentaci na tvrzení „u dodavatele jsme neevidovali žádný incident", staví ji na tom, že mu dodavatel nic neposlal.
• AI služby tu nejsou zvláštní kategorie, jsou to prostě cloudové služby. Azure AI Foundry a Azure AI Language nespadly kvůli ničemu „AI". Spadly kvůli chybějící autentizaci u kritické funkce — chybě, kterou pojmenoval katalog CWE dávno před jazykovými modely. Když si tedy do analýzy rizik píšete AI zvlášť a cloud zvlášť, pravděpodobně dvakrát popisujete tutéž vrstvu. A naopak: to, že máte prověřený cloudový přístup, vás neposouvá v tom, co dělá agent uvnitř.
• Injekce do Copilotu má jinou povahu než injekce do serveru. U CVE-2026-85885 stojí, že útočník musí být „authorized" — tedy přihlášený. To v praxi u M365 Copilotu znamená kdokoli s firemním účtem. A doprovodná klasifikace CWE-923 u Business Chatu (komunikace mimo zamýšlené koncové body) je přesně ta vlastnost, kvůli které je Copilot s přístupem k vaší SharePoint knihovně jiná bezpečnostní role než Copilot, který jen doplňuje text.
• Dvě třetiny nálezů přišly zvenku. Dvanáct z osmnácti nahlásili externí výzkumníci a bug bounty týmy. To není výtka Microsoftu — je to argument, který si vezměte ke svým vlastním dodavatelům: jestli váš SaaS dodavatel nemá kanál pro externí hlášení zranitelností, nemá ani ty dvě třetiny nálezů.
• Regulace se na dodavatele ptá. Zákon č. 264/2025 Sb. o kybernetické bezpečnosti je podle NÚKIB účinný od 1. listopadu 2025 a do 60 dnů po účinnosti vznikla většině regulovaných organizací povinnost ohlásit regulovanou službu; další lhůty běží od doručení rozhodnutí o registraci. Pokud pod něj spadáte, řízení dodavatelského řetězce není dobrovolné cvičení — a „nevíme, jestli náš cloudový poskytovatel měl kritickou zranitelnost" je špatná odpověď bez ohledu na to, že za ni nemůžete.

Co s tím

Nic z toho nevyžaduje nákup nástroje. Je to jedno dopoledne a pak deset minut měsíčně.

• 1. Přihlaste se k odběru cloudových CVE svého poskytovatele. U Microsoftu to jde strojově: https://api.msrc.microsoft.com/cvrf/v3.0/cvrf/RRRR-Mmm vrací celý měsíc v JSON a pole Customer Action Required vám oddělí cloudové záznamy od těch, které se patchují. Jednou měsíčně si nechte vypsat ty s hodnotou No a projděte je proti seznamu služeb, které skutečně používáte. Bez tohohle kroku se o nich nedozvíte nikdy.
• 2. Veďte si evidenci „co se stalo u dodavatele". Jeden sdílený soubor: datum, služba, CVE, skóre, jestli se nás to týkalo a co jsme z toho vyvodili. U většiny záznamů tam bude „používáme / nepoužíváme, žádná akce" — a právě to je ten doklad, který u auditu nebo po incidentu chybí. Bez záznamu neprokážete, že jste to sledovali.
• 3. Zjistěte, co váš Copilot skutečně vidí. Ne jestli ho máte zapnutý, ale ke kterým SharePointům, poštovním schránkám a týmům se dostane pod účtem běžného zaměstnance. Dvě z letošních zářijových chyb se týkají oprávnění a komunikace mimo zamýšlené cíle; dopad obojího se počítá z toho, co bylo dostupné. Firmy tu pravidelně zjistí, že Copilot indexuje složky, o kterých si mysleli, že jsou pro pár lidí.
• 4. Doplňte si do smluv oznamovací lhůtu. Ne „dodavatel je povinen zajistit bezpečnost", ale „dodavatel nás informuje o kritické zranitelnosti ve službě do X dnů od jejího vyřešení, včetně doby, po kterou byla služba zranitelná". Přesně tu druhou informaci teď od cloudových poskytovatelů nedostáváte a bez smluvního ustanovení ji nedostanete ani příště.

A teď proti vlastnímu byznysu: osmnáct zranitelností opravených poskytovatelem bez vaší součinnosti není důvod k panice a rozhodně není důvod objednávat si kvůli tomu audit. Ve skutečnosti je to dobrá zpráva — díry našli a zavřeli lidé, které za to platí někdo jiný, a vy jste se o tom mohli dozvědět jen proto, že se Microsoft rozhodl je zveřejnit, i když nemusel. Kdo z toho udělá argument pro nákup bezpečnostního projektu, prodává strach. Jediná věc, kterou byste si z toho měli odnést, je administrativní: mít někde zapsáno, že jste to viděli a vyhodnotili. To je půl hodiny měsíčně, ne zakázka.

Kde to řeším s klienty

U firem, které staví procesy na Microsoft 365 a Azure, je tohle v rámci AI Agent Governance Checkupu nudná, ale nutná část: seznam služeb, které opravdu používáte, kdo u nich sleduje bezpečnostní oznámení a kam se zapisuje výsledek. Když si nejste jistí, jestli se vás regulace vůbec týká, začněte AI Risk Scanem zdarma — u části firem z něj vyjde, že nepotřebují nic než ten jeden soubor s evidencí. Na dodavatelskou vrstvu tu píšu opakovaně: viz dřívější rozbor hlášení zneužité zranitelnosti do 24 hodin a text o tom, jak rozsah nezávislého auditu určil sám auditovaný. Vzorec je stejný: informace, kterou od dodavatele nedostanete, si musíte buď vyžádat smlouvou, nebo sbírat sami.