Nemůžete opravit to, co nevidíte

Dvě kritické zranitelnosti v jeden den, a nová byla jen jedna

října 2026 byly během pár hodin opraveny dvě kritické zranitelnosti. PHP2Shell a Node2Shell. Obě se skóre CVSS 9.2. Obě jsou dnes v katalogu CISA Known Exploited Vulnerabilities s potvrzeným zneužíváním ve volné přírodě.

	PHP2Shell	Node2Shell
CVE	CVE-2026-109618, CVE-2026-109619	CVE-2026-111497
CVSS	9.2	9.2
Opraveno v	PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35	Node.js 22.23.4, 24.22.1, 26.12.1
Vydání opravy	21. 10. 2026	21. 10. 2026
Zařazeno do CISA KEV	26. 10. 2026	27. 10. 2026
Termín pro federální úřady USA	29. 10. 2026	10. 11. 2026

PHP2Shell je dvojice chyb v práci s pamětí přímo v jádru PHP. Je dosažitelná všude, kde je zapnuté session.upload_progress, což je výchozí nastavení, a spustitelná přes endpointy pro nahrávání souborů včetně těch, které ve skutečnosti nefungují. Detaily unikly před koordinovaným datem zveřejnění, takže oprava, oznámení i první pokusy o zneužití přišly během jediného týdne.

To byl ten jednodušší případ a pozornost dostal právě proto, že byl jednoduchý. Technologie byla přímo v titulku, takže každý, kdo provozuje PHP, během vteřiny věděl, že se ho to týká. Jediná otázka byla, jak rychle to stihne nasadit.

Node2Shell stojí za váš čas víc, a skoro všichni ho přečetli špatně.

Node2Shell není chyba v Node.js

Jde o zápis mimo hranice bufferu v dekodéru Brotli, který Node.js přibaluje. Brotli stream s neplatným přepnutím bloku byl ohlášen jako “potřebuji víc vstupu” místo trvalé chyby formátu, takže streamovací dekodér dál přisypával vstup do osmibajtového interního bufferu.

Zranitelný kód pochází přímo z projektu Brotli a tam také vyšla skutečná oprava: Brotli 1.0.10, 1.1.1 a 1.2.1. Node.js ji převzal napříč všemi podporovanými větvemi ve vydání, které zavřelo deset chyb. Stejná chyba si vynutila nouzové opravy v Microsoft .NET a týká se každého HTTP serveru i klienta, který nese zranitelný build Brotli.

Jedna upstream knihovna v C, několik nesouvisejících ekosystémů a komponenta, která není v ničím package.json.

Můžete si přečíst každý řádek každého pull requestu, který váš tým za poslední čtvrtletí zmergoval, a ani jednou nenarazíte na slovo “brotli”. Nikdo si ji nevybral. Nikdo ji nerevidoval. Nikdo na ni nemá názor. Přišla jako závislost závislosti vašeho runtime a 21. října se stala tou nejzajímavější věcí ve vaší infrastruktuře.

Tohle je skutečný tvar rizika dodavatelského řetězce. Ne děsivé CVE s vlastním logem, ale komponenta o tři patra níž, než kam kdy dohlédl člověk.

Teď se zeptejte, jak by vám to řekla vaše pipeline

Bude to znít jako argument proti vývoji s AI, a není. Sám s AI pracuji každý pracovní den a vracet to nehodlám. Ale podívejme se na tu mechaniku poctivě.

Model přidá balíček, aby splnil zadání. Nainstaluje se. Zkompiluje. Funguje. Lint projde, typová kontrola projde, unit, integrační i end-to-end testy projdou. Pipeline svítí zeleně odshora dolů, a to z naprosto dobrého důvodu: každá z těch fází ověřuje chování, které jste zadali. Nikde jste nezadali “a neposílej zároveň token z CI ven”.

Mezitím objem změn na vývojáře roste a pozornost věnovaná revizi jednoho řádku klesá. Code review pořád dobře dělá to, k čemu vzniklo. Reviduje diff. Riziko ale v diffu není. Výzkumný tým Endor Labs řadí zhruba 95 % zranitelných závislostí mezi tranzitivní, tedy ty, které se do projektu dostaly nepřímo a nikdo je nevybral. Berte to číslo jako orientační, ale tvar toho zjištění se v zásadě nerozporuje.

Vyjmenujte si tedy své fáze nahlas: lint, typová kontrola, unit, integrační, e2e, možná sken závislostí při buildu. Která z nich by vám o Brotli řekla? Všechny jsou kontrolou v jednom bodě v čase proti zamýšlenému chování. Ani jedna nesleduje to, co už jste nasadili.

Přestalo to být volitelné zhruba před deseti lety

Útoky na dodavatelský řetězec přes registry nejsou novinka. Shai-Hulud byl samoreplikující se červ v ekosystému npm, který se šířil přes post-install skripty bez jakéhokoli dalšího lidského zásahu. První vlna v polovině září 2025 zasáhla přes 180 balíčků a posbírala cloudové, registrové i CI přihlašovací údaje. Mnohem širší vlna později téhož roku dosáhla zhruba na 640 balíčků a desítky tisíc GitHub repozitářů. Počáteční přístup podle všeho začal phishingovou kampaní vydávající se za npm.

To je rok stará věc a ta technika je výrazně starší. Inventura závislostí přestala být volitelná zhruba ve chvíli, kdy se útoky přes registry staly populárním vektorem, tedy asi před deseti lety. Poctivá otázka tedy nezní, jestli to už tehdy bylo povinné. Bylo. Otázka je, čím se to stává teď, když objem produkovaného kódu dostal zesilovač.

Nebezpečí moc nevzrostlo. Šum vzrostl obrovsky.

Tady většina dodavatelských textů zleniví a napíše odstavec o tom, jak se týmy topí v CVE. Data říkají něco ostřejšího a užitečnějšího.

Objem publikovaných CVE za leden až září 2026 dosáhl 75 242 proti 48 244 za celý rok 2025. Řekněme plus 56 %. Potvrzené zneužívání je přitom prakticky stejné: 249 přírůstků v CISA KEV v roce 2026 proti 245 v roce 2025. Ve třetím čtvrtletí 2026 vykázalo známky weaponizace 186 z 37 940 publikovaných CVE, tedy kolem 0,5 %.

Část toho nárůstu je změna v počítání. V červnu 2026 se pro automatizované pipeline zveřejňování stalo povinným pravidlo “jedna zranitelnost, jedno ID”, které uprostřed řady změnilo jednotku měření. Automatizovaný objev a automatizované vydávání to násobí dál. Software se ze dne na den o 56 % nezhoršil.

Co se zhoršilo, je bezplatná pomoc s tříděním. Ve třetím čtvrtletí 2026 zaevidovala NVD 36 970 záznamů, z nichž jen 8,4 % neslo závažnost podle CVSS v3, oproti 37,3 % o rok dřív. Backlog překročil v červnu 2026 hranici 27 000 nezpracovaných záznamů, z asi 13 000 v únoru 2024.

Dejte to dohromady: nebezpečí je zhruba stabilní, šum se přibližně zdvojnásobil a lidé, kteří vám to dřív oskórovali, přestali. Vzácným zdrojem není kapacita na patchování, a nikdy vlastně nebyla. Je to pozornost.

PHP2Shell a Node2Shell byly v těch 0,5 %. To je vám ale k užitku jen tehdy, když dokážete těch 0,5 % oddělit od zbytku v první hodině, ne v prvním týdnu. Infrastruktura, která to neumí, není jen neefektivní. Nese existenční riziko na neohraničeném časovači, a pro menší firmu je jeden špatný týden celý příběh.

Co v SDLC doopravdy chybí

Ne lepší testování. Fáze, která sleduje dál i potom, co je build hotový. Konkrétně pět věcí.

Inventura, kterou vygeneruje build, ne dotazník. SBOM vytvořený v CI z artefaktu, který se skutečně nasazuje, ne ze zdrojového stromu a ne z toho, co si vývojář myslí, že má nainstalované. CycloneDX nebo SPDX, strojově čitelné, a hlavně celý tranzitivní uzávěr. Samotná první úroveň by vám Brotli neukázala.

SBOM je zkratka, kterou zná každý, ale je to jen jeden člen rodiny. Stejný standard CycloneDX definuje i kryptografický bill of materials pro algoritmy a délky klíčů, na kterých stojíte, hardwarový bill of materials a bill of materials pro strojové učení kvůli původu modelů a trénovacích dat. Kde se vás kterýkoli z nich týká, platí stejná disciplína: generujte inventuru z toho, co se skutečně nasadilo, ne z dokumentu, který někdo vyplnil ručně.

Mapa, kde která verze běží. SBOM v šuplíku je divadlo pro auditora. Otázka, kterou potřebujete zodpovědět v řádu minut, zní “je někde v produkci Brotli nižší než 1.1.1, ve kterých službách, prostředích a u kterých tenantů”. To znamená propojit artefakt s image, prostředím a tenantem a to propojení udržovat živé. Hodnotou je ta mapa; dokument je v ní jeden řádek.

Průběžné přehodnocování místo skenu při mergi. 21. října se ve vašem kódu nezměnilo nic. Změnila se vaše expozice. Jakákoli kontrola, která se spouští jen při commitu, je strukturálně neschopná tuhle třídu událostí zachytit. Sken se musí spustit znovu nad stojící inventurou pokaždé, když se změní data o zranitelnostech.

Filtrování, které vyrobí alert, jejž někdo přečte. Dosažitelnost a kontext nasazení jsou to, co ze 75 000 CVE udělá hrstku, kterou dnes v noci musí vidět člověk. Pravidlo, které pípne na každé nové critical, je funkčně totéž jako žádné alerty, protože se ve druhém týdnu umlčí.

Pojistka na samotnou inventuru. Tohle je jemné a viděl jsem to kousat. Inventurní pipeline, která tiše vyrobí skoro prázdný dokument, se stejně v pořádku nahraje a komponenta se dál tváří jako monitorovaná. Nic se přitom neskenuje a dashboard svítí zeleně. Inventura, která selhává na zeleno, je horší než žádná, protože vyrábí falešnou jistotu. Nastavte věrohodnou spodní hranici počtu komponent a pod ní build shoďte.

EU už na to pustila stopky

Podle Cyber Resilience Act začaly 11. září 2026 platit ohlašovací povinnosti výrobců. Aktivně zneužívané zranitelnosti a závažné incidenty teď nesou 24hodinovou lhůtu pro první hlášení do ENISA přes CRA Single Reporting Platform, adresované koordinujícímu CSIRT členského státu hlavní provozovny. Týká se to i produktů, které už jsou na trhu.

Hlavní blok povinností včetně výslovného požadavku na SBOM platí od 11. prosince 2027. Příloha I žádá strojově čitelný SBOM v běžně používaném formátu, který pokrývá alespoň závislosti první úrovně.

Dvě poznámky pro každého, kdo prodává software do EU. 24hodinová ohlašovací lhůta je požadavek na průběžný monitoring v jiném kabátě: nemůžete do 24 hodin nahlásit něco, co vám trvá tři týdny zinventarizovat, a ta lhůta běží už přes měsíc. A “alespoň závislosti první úrovně” je zákonné minimum, které by vám Brotli neukázalo. Compliance a znalost vlastní expozice jsou dva různé projekty a jen jeden z nich vás drží online.

V pondělí ráno

Změřte si čas na jednu otázku: které služby běží na Brotli nižším než 1.1.1 a ve kterých prostředích, bez ptaní se vývojáře. Jak dlouho to trvá, tak dlouhá je vaše reálná doba reakce na incident.
Generujte SBOM v CI z nasazovaného artefaktu, s celým tranzitivním uzávěrem, a shoďte build, když počet komponent vypadá nevěrohodně nízko.
Ukládejte inventury per nasazení, per prostředí, per tenant. Nejdřív postavte to propojení, o formátech dokumentů se hádejte až potom.
Přeskenovávejte stojící inventuru při aktualizaci zdrojů o zranitelnostech, ne při commitech. Tahle jediná změna by Node2Shell zachytila.
Alerty vyladěte podle kontextu nasazení a dosažitelnosti dřív, než je zapnete. Kanál, který se umlčí, je horší než ticho, protože vypadá jako pokrytí.
Zkontrolujte expozici po konci podpory. Kolem PHP2Shell napozoroval Qualys zhruba 167 milionů instalací PHP, 73 % z nich na assetech dostupných z internetu, a asi 110 milionů z nich (71 %) na verzích 5.4 až 8.1 po konci podpory, které opravu od dodavatele nikdy nedostanou. Tam, kde jste za koncem podpory, “patchujte rychle” není strategie a potřebujete jiný plán.

Jedna polovina expozice, ne celá

Všechno výše je expozice, kterou jste si nevybrali. Balíček, runtime, verze operačního systému, které ve vaší infrastruktuře sedí proto, že je tam přinesl strom závislostí, ne proto, že by někdo rozhodl, že tam patří. Ta mezera je reálná a málo obsluhovaná a tenhle text je o ní.

Není to ale jediná mezera. Formulář, který věří kontrole na klientovi, které nikdy věřit neměl. Pravidlo pro slevu, které platí pro každý testovací případ, co kohokoli napadl, a selže na tom jediném, co nenapadlo nikoho. Rozhodnutí o řízení přístupu, které je pro každou funkci zvlášť správné a ve chvíli, kdy se dvě z nich složí, špatné. Nic z toho se nikdy neobjeví v SBOM, v CVE feedu ani v patch cyklu operačního systému, protože kód dělá přesně to, co jste mu řekli. Vada je v logice, ne v knihovně.

Tam míří příští díl: rozšířit testování za závislosti a infrastrukturu do funkční a logické vrstvy, s OWASP nástroji, které sami reálně provozujeme, mimo jiné OWASP ZAP, ne s OWASP Top 10 čteným jako checklist.

Kde do toho vstupujeme my

Tenhle typ monitoringu stavíme a provozujeme pro vlastní multiprojektovou a multitenantní infrastrukturu už dlouho předtím, než se bezpečnost dodavatelského řetězce stala tématem, o kterém se píše. Ne proto, že bychom něco předvídali, ale proto, že když provozujete cizí produkci, je ta mezera rychle vidět.

Pokud tohle máte na seznamu, umíme pomoct třemi způsoby: vybrat nástroje, které sedí vaší reálné infrastruktuře, ne referenční architektuře; postavit inventurní a alertovací pipeline společně s vaším týmem; nebo vás provést tím, jak to funguje u nás ve složitém multiprojektovém prostředí. Fungující systém, do kterého můžete šťourat, ne slide.

Žádné drama, jen poctivý obrázek toho, co byste věděli a jak rychle, až jedna z těchhle věcí přistane příště.