Duben 2026 v kyberbezpečnosti: red-team analýza pro firmy


Duben 2026 byl měsíc, kdy se kybernetická bezpečnost znovu přesunula z prezentací do běžného pracovního provozu. Ne přes jeden obří incident, ale přes řadu menších technických selhání, která z pohledu útočníka dávají velmi praktický smysl. Lokální eskalace oprávnění v Linuxu. Kompromitované balíčky v npm. Brána pro umělou inteligenci s uloženými klíči. Vývojářská platforma zpracovávající důvěryhodný kód. OAuth oprávnění, která na první pohled vypadala jako nevinná produktivní integrace.

Pro Haxoris je to přesně typ materiálu, který má hodnotu při red teamingových cvičeních, penetračních testech a hodnocení firemní útočné plochy. Nejde jen o to, že vznikla další zranitelnost. Důležité je, jak se propojuje s cloudovou bezpečností, ochranou CI/CD, správou přístupů, bezpečností umělé inteligence, reakcí na incidenty a kybernetickou odolností firmy. Duben ukázal, že moderní útok se často neskládá z filmového průniku, ale z běžných pracovních nástrojů, kterým organizace důvěřuje až příliš.

29. dubna

Copy Fail: když se slabý lokální účet změní na root

Xint Code Research Team zveřejnil Copy Fail, zranitelnost sledovanou jako CVE-2026-31431. Jde o logickou chybu v jádře Linuxu, konkrétně v kryptografické šabloně authencesn. Neprivilegovaný lokální uživatel díky ní dokáže vyvolat kontrolovaný čtyřbajtový zápis do vyrovnávací paměti stránek libovolného čitelného souboru.

Výzkumníci ukázali, že krátký důkazový skript v Pythonu dokáže upravit setuid binární soubor pouze v paměti a získat oprávnění uživatele root. Testovali velké distribuce včetně Ubuntu, Amazon Linux, RHEL a SUSE.

Nejzajímavější není jen samotné zvýšení oprávnění. Zápis se neprojeví jako běžná změna souboru na disku. Poškozená stránka se neoznačí pro zpětný zápis, takže soubor na disku může stále vypadat beze změny, zatímco jeho verze v paměti už se chová jinak. Jednoduché porovnávání kontrolních součtů proto nemusí ukázat nic podezřelého.

Při útočném bezpečnostním testování je to přesně typ chyby, která z malého přístupu udělá kontrolu nad hostitelem. Útočník nemusí začínat jako administrátor. Stačí kompromitovaný uživatel, webový shell, slabý servisní účet nebo přístup do kontejneru. Lokální zvýšení oprávnění se pak stává mostem mezi prvotním průnikem a ovládnutím systému.

Důležitá je i kontejnerová rovina. Vyrovnávací paměť stránek je společná pro procesy na hostitelském systému a podle Xint má tato chyba dopad i na hranice kontejnerů. Neznamená to, že každý kontejner automaticky padne jedním příkazem. Znamená to ale, že věta „běží to jen v kontejneru“ není bezpečnostní strategie.

Mini Shai-Hulud: když běžná instalace závislosti začne sbírat přístupové údaje

Wiz zveřejnil analýzu kampaně Mini Shai-Hulud. Ta zasáhla legitimní balíčky v SAP ekosystému registru npm. Útočníci do balíčků jako @cap-js/sqlite, @cap-js/postgres, @cap-js/db-service a mbt vložili škodlivý předinstalační skript, který se spouští automaticky při běžné instalaci závislostí.

To je na celém případu nejpodstatnější. Vývojář nemusel udělat nic zvláštního. Nestáhl pirátský software, neotevřel přílohu a neklikl na falešné přihlášení. Udělal přesně to, co dělá každý den: nainstaloval závislosti a sestavil projekt.

Škodlivý kód podle Wiz stahoval běhové prostředí Bun a následně spouštěl zloděj přístupových údajů. Cílil na tokeny GitHubu, přihlašovací údaje k npm, cloudová tajemství pro AWS, Azure a GCP, tokeny Kubernetes i tajemství používaná v GitHub Actions. Data odesílal přes útočníkem kontrolované repozitáře na GitHubu a obsahoval také logiku pro další šíření pomocí kompromitovaných tokenů.

Pro firmy je to velmi praktická lekce. Automatizované sestavování a nasazování není pomocný nástroj někde bokem. Často jde o prostředí, které drží nejcennější přístupové údaje v celé firmě. Má přístup ke kódu, registrům kontejnerů, cloudu, Kubernetes, produkčním nasazením a někdy i zákaznickým datům.

Otázka proto nezní jen „používáme bezpečné balíčky?“. Otázka zní: pokud se škodlivý balíček spustí ve vašem sestavovacím procesu, co všechno dokáže přečíst? Pokud odpověď zní „téměř všechno“, problém není jen v balíčku. Problém je v tom, že automatizace má více důvěry, než skutečně potřebuje.

LiteLLM: brána pro umělou inteligenci jako trezor na cizí klíče

LiteLLM řešil kritickou zranitelnost CVE-2026-42208. Belgické Centrum pro kybernetickou bezpečnost ji popsalo přímo: LiteLLM slouží jako brána pro umělou inteligenci, která centralizuje přístupové údaje k poskytovatelům jako OpenAI nebo Anthropic. Úspěšné zneužití proto může znamenat najednou ztrátu všech připojených účtů u poskytovatelů umělé inteligence.

Technická podstata byla nepříjemně jednoduchá. Hodnota přístupového tokenu z HTTP požadavku se mohla dostat do databázového dotazu bez dostatečného očištění. Útočník tak dokázal zasáhnout ještě před přihlášením a dostat se k uloženým aplikačním klíčům, přístupovým údajům poskytovatelů a dalším citlivým datům v databázi.

To je zásadní pro každou firmu, která zavádí umělou inteligenci. Podobná brána není experimentální nástroj někde na okraji infrastruktury. Velmi rychle se z ní stává centrální sklad aplikačních klíčů, fakturačních identit, pravidel používání, záznamů požadavků a někdy i interních dat.

Při red teamingu by nás taková komponenta zajímala okamžitě. Ne proto, že umělá inteligence je módní téma. Ale proto, že nové nástroje se ve firmách často nasazují rychleji, než vznikne jejich bezpečnostní model. Kde jsou uložené klíče? Kdo je umí číst? Co se zaznamenává? Dá se přístup rychle zrušit? Má každý poskytovatel samostatný účet a limit? Právě tyto odpovědi rozhodují, zda incident zůstane lokální, nebo se změní v širší kompromitaci cloudu.

28. dubna

GitHub: i běžný vývojářský příkaz může být problém na straně serveru

GitHub zveřejnil rozbor kritické zranitelnosti v části infrastruktury, která zpracovává příkaz git push. Chybu nahlásili výzkumníci z Wiz přes program odměn za nálezy. GitHub ji podle vlastního popisu interně zopakoval do čtyřiceti minut, opravil na GitHub.com za méně než dvě hodiny a forenzní analýza nenašla důkaz o zneužití.

Podstata chyby byla vážná. Uživatel s oprávněním odeslat změny do repozitáře, včetně repozitáře, který si sám vytvořil, mohl dosáhnout spuštění příkazů na serveru zpracovávajícím dané odeslání. Stačila speciálně připravená volba při odesílání změn, která využila nedostatečně očištěný znak.

Pro běžnou firmu je důležitá širší pointa. GitHub, GitLab, Bitbucket nebo interní úložiště kódu už dávno nejsou jen místo, kam se ukládá zdrojový kód. Jsou to uzly, kde se potkává identita, automatizace, schvalování změn, tajemství, sestavování, testování, nasazování a auditní stopa.

Útočná otázka zní: co všechno se ve firmě stane po úspěšném odeslání změny do repozitáře? Spustí se sestavení? Načtou se citlivé proměnné? Vytvoří se artefakt? Nasadí se změna do cloudu? Má sestavovací pracovník přístup do produkce? Každá z těchto odpovědí mění běžný vývojářský krok v bezpečnostní rozhodnutí.

cPanel a WHM: správcovský panel jako klíče od několika dveří

cPanel vydal bezpečnostní upozornění k CVE-2026-41940. Šlo o chybu umožňující obejití přihlášení v cPanel & WHM a DNSOnly. Podle cPanelu se problém týkal verzí po 11.40 a firma vydala opravená sestavení pro několik podporovaných větví.

Jako nouzové opatření doporučovala blokovat příchozí komunikaci na portech 2083, 2087, 2095 a 2096 nebo dočasně zastavit dotčené služby, pokud aktualizace nebyla okamžitě možná.

Na první pohled to vypadá jako problém poskytovatelů hostingu. Ve skutečnosti je to problém každého, kdo přes podobný panel spravuje web, poštu, domény, certifikáty nebo klientský portál. WHM je řídicí vrstva. Pokud se útočník dostane přes přihlášení, nemusí jít jen o kompromitaci jednoho webu. Může jít o přístup ke správě účtů, domén, poštovních schránek, certifikátů a někdy i serverové infrastruktury.

Při testování firem se podobné panely opakovaně ukazují jako podceňovaná hranice sítě. Firma si chrání hlavní aplikaci, ale správcovské rozhraní hostingu, starý panel zákaznického portálu nebo DNS rozhraní zůstává bokem. Útočník ale nerozlišuje mezi „hlavním systémem“ a „pomocným nástrojem“. Rozlišuje jen to, co mu dá nejvíce oprávnění za nejméně práce.

24. dubna

UNC6692: falešná technická podpora, Teams a škodlivé rozšíření prohlížeče

Google Cloud a Mandiant popsaly kampaň skupiny UNC6692, která velmi dobře ukazuje, jak vypadá moderní sociální inženýrství ve firmě. Útočníci nejdříve zahltili cíl e-maily, aby vytvořili tlak a zmatek. Potom kontaktovali uživatele přes Microsoft Teams jako údajná technická podpora a nabídli „opravu“ problému.

Uživatel byl nasměrován na stránku, která se tvářila jako oprava poštovní schránky. Odtud se stáhl přejmenovaný AutoHotKey soubor a skript. Ten spustil průzkum systému a nainstaloval SNOWBELT, škodlivé rozšíření pro prohlížeč Chromium. Následně útočníci pokračovali dalšími nástroji, interním průzkumem, bočním pohybem, sběrem přihlašovacích údajů a přístupem k doménovým řadičům.

To je důležité, protože útok nevypadal jako klasický phishingový e-mail. Vypadal jako interní proces podpory. Problém nebyl jen v uživateli. Problém byl v tom, že firemní prostředí neumělo dostatečně jasně rozlišit, kdo je skutečná technická podpora, jak se ověřuje její identita a co zaměstnanec nikdy nemá instalovat na základě chatové zprávy.

Z pohledu Haxorisu je to výborný scénář pro útočné bezpečnostní cvičení. Ne „klikněte na falešný e-mail“, ale realistický řetězec: zahlcení, stres, chat přes firemní platformu, falešná podpora, instalace lokální opravy, škodlivé rozšíření, průzkum sítě a pokus o přístup k citlivým systémům.

22. dubna

Lovable: veřejný projekt neznamená jen veřejnou aplikaci

Lovable zveřejnil reakci na dubnový incident poté, co bezpečnostní výzkumník upozornil, že data ve veřejných projektech mohla být přístupná každému přihlášenému uživateli. Firma uvedla, že opravu nasadila do dvou hodin. Zároveň přiznala, že produkt i prvotní komunikace situaci nezvládly dobře.

Podle Lovable mohly být mezi 3. únorem a 20. dubnem 2026 u veřejných projektů potenciálně dostupné historie rozhovorů a zdrojový kód. Soukromé projekty a Lovable Cloud podle firmy zasaženy nebyly. Problém vznikl kombinací historického modelu veřejných projektů, pozdějších změn viditelnosti a únorové chyby v zázemí služby, která znovu otevřela přístup k věcem, které už neměly být veřejné.

To není jen příběh jednoho nástroje na tvorbu aplikací pomocí umělé inteligence. Je to širší problém jazykového zmatku kolem slova „veřejné“. Mnoho uživatelů chápe veřejnou aplikaci tak, že výsledný web může navštívit kdokoliv. Nechápe to jako přístup k editoru, rozhovorům s umělou inteligencí, zdrojovému kódu, pracovním poznámkám nebo integračním detailům.

Útočník se ale nedívá na to, jak uživatel chápe nastavení. Dívá se na to, co mu rozhraní vrátí. Pokud se v takovém projektu nacházejí odkazy na databáze, platební brány, aplikační rozhraní, interní koncové body nebo konfigurační fragmenty, špatně navržená viditelnost se může změnit na praktický zdroj dalšího průniku.

Poučení pro firmy je jednoduché: u nástrojů s umělou inteligencí nestačí řešit jen výslednou aplikaci. Je potřeba řešit také rozhovory, návrhy, pracovní kód, koncepty a všechno, co uživatel považuje za „jen proces tvorby“. I proces tvorby může obsahovat citlivé informace.

19. dubna

Vercel a Context.ai: přístupový token jako tichá vstupní karta

Vercel zveřejnil bezpečnostní incident, který nezačal přímým útokem na jeho hlavní infrastrukturu. Podle Vercelu incident vznikl přes kompromitaci třetí strany, konkrétně nástroje Context.ai používaného jedním ze zaměstnanců. Útočník následně použil tento přístup k převzetí individuálního účtu ve firemním Google Workspace, dostal se do účtu zaměstnance ve Vercelu a dál se pohyboval v interním prostředí.

Vercel uvedl, že útočník enumeroval a dešifroval necitlivé proměnné prostředí uložené na platformě. Zároveň firma doporučila rotovat hodnoty, které nebyly označené jako citlivé, protože i „necitlivá“ proměnná může v praxi obsahovat token, aplikační klíč, databázové přihlašovací údaje nebo podpisový klíč.

To je ukázkový příklad toho, proč hesla už nejsou jediným problémem identity. Přístupový token je často tišší a nebezpečnější. Nepožaduje vícefaktorové ověření při každém použití, nevzbuzuje stejnou pozornost jako nové přihlášení a v některých případech přežije i změnu hesla. Pokud má navíc široká oprávnění, funguje jako vstupní karta do firemního světa cloudových služeb.

Z pohledu Haxorisu je to typická útočná cesta přes důvěru. Neútočí se přímo na velkou firmu. Útočí se na menší nástroj, který má velká oprávnění. Potom se hledá uživatel s firemním účtem, široký přístup k dokumentům, sdílené složky, proměnné prostředí, interní pracovní postupy a další místa, kde se dá posunout dál.

17. dubna

Codex v incidentu: když uživatel během kompromitace zapojí umělou inteligenci

Společnost Huntress popsala nezvyklý incident na linuxovém koncovém zařízení. Na systému bylo aktivních několik útočníků, kteří instalovali těžaře kryptoměn, sbírali přístupové údaje a připravovali další škodlivou aktivitu. Zároveň uživatel na stejném zařízení používal OpenAI Codex, aby mu pomohl auditovat a řešit podezřelou aktivitu.

Bezpečnostní nástroj Huntress byl nainstalován až uprostřed kompromitace. Tým proto neměl úplnou historickou telemetrii. Vyšetřování komplikovalo i to, že příkazy generované Codexem v některých případech vypadaly podobně jako příkazy útočníka. Uživatel se snažil pomoci, ale vytvořil další vrstvu šumu přesně v okamžiku, kdy bylo potřeba oddělit legitimní kroky od škodlivé aktivity.

To je nová kategorie incidentů. Uživatel si všimne problému, otevře asistenta s umělou inteligencí, nechá ho spustit diagnostiku, upravovat soubory, navrhovat příkazy a „opravit“ systém. Mezitím může být útočník stále aktivní. Bez jasných pravidel vzniká chaos, který prodlužuje vyšetřování.

Pro firmy z toho plyne praktický závěr. Reakce na incident nemá být improvizace uživatele s umělou inteligencí. Pokud zaměstnanec podezřívá kompromitaci, musí vědět, co udělat, koho kontaktovat a co určitě nespouštět. Umělá inteligence může pomoci odborníkům, ale nemá nahrazovat řízený postup při incidentu.

Microsoft Defender: když se ochranný nástroj stane cestou k vyšším oprávněním

Huntress ve stejném období upozornil na reálné zneužívání zranitelností označovaných jako BlueHammer, RedSun a UnDefend. BlueHammer byl sledován jako CVE-2026-33825 a Microsoft ho opravil v dubnových aktualizacích. Podle Huntress šlo o chybu typu „zkontroluji teď, použiji později“ ve Windows Defenderu, která mohla útočníka posunout z běžného účtu na oprávnění SYSTEM.

Z pohledu firmy je tento příběh nepříjemný právě proto, že se týká ochranného nástroje. Obranný software má vysoká oprávnění, široký přístup do systému a přirozeně je přítomen na velkém počtu zařízení. Pokud se v něm objeví zneužitelná chyba, útočník ji může použít jako součást zvýšení oprávnění po prvotním průniku.

Při útočném testování to mění způsob uvažování. Nestačí se ptát, zda má firma bezpečnostní nástroj. Je potřeba se ptát, jak rychle se opravuje, zda má omezený dosah, zda jsou chráněné jeho konfigurace a zda tým sleduje i zranitelnosti v samotných nástrojích, kterým dává nejvyšší důvěru.

16. dubna

Nginx UI: správa webového serveru jako vstup do produkce

Rapid7 a další bezpečnostní zdroje upozornily na zranitelnost CVE-2026-33032 v nástroji Nginx UI. Jde o webové rozhraní pro správu Nginx serverů. Chyba souvisela s novou integrací Model Context Protocol a umožňovala neověřenému útočníkovi převzít kontrolu nad serverem. Podle dostupných údajů existovaly tisíce internetově dostupných instancí.

Tento případ je zajímavý tím, že spojuje dvě věci, které firmy často podceňují: správcovská rozhraní a nové integrace pro umělou inteligenci. Nginx UI není jen hezký panel. Je to nástroj, kterým se spravuje konfigurace webového serveru, směrování provozu, certifikáty, reverzní proxy, přesměrování a někdy i přístup k interním aplikacím.

Pokud útočník převezme takový bod, nemusí hned číst databázi. Může měnit směrování, vkládat škodlivá přesměrování, zachytávat komunikaci, připravovat phishing na stejné doméně nebo si vytvořit trvalejší přístup.

Z pohledu Haxorisu je to další důkaz, že hranice sítě dnes často není jeden firewall. Je to množina správcovských rozhraní, která mají větší moc, než si jejich majitelé připouštějí.

15. dubna

Model Context Protocol: když se nástroj pro umělou inteligenci dostane příliš blízko k systému

Bezpečnostní výzkumníci upozornili na slabinu ve způsobu, jakým se používá Model Context Protocol. Problém nebyl jen v jedné konkrétní aplikaci. Týkal se širšího principu: nástroje napojené na umělou inteligenci mohou přes nesprávně zpracované konfigurace nebo příkazy získat možnost spouštět příkazy v systému.

The Hacker News s odkazem na OX Security uvedl, že riziko se týká několika projektů a může vést k přístupu k uživatelským datům, interním databázím, aplikačním klíčům a historiím rozhovorů. Podstatné je, že jde o typ problému, který vzniká na rozhraní mezi asistentem, nástrojem a systémem.

Pro firmy je to varování před slepým připojováním umělé inteligence ke všemu. Pokud model nebo jeho nástroj umí číst soubory, volat externí služby, spouštět skripty nebo pracovat s interními daty, nejde o neškodnou pomůcku. Je to nový vykonávací kanál.

Při útočném bezpečnostním testování nás proto nezajímá jen otázka „jaký model používáte“. Zajímá nás, co smí dělat. K jakým souborům má přístup. Jaké příkazy umí spustit. Jaká tajemství vidí. A co se stane, když uživatel vloží do rozhovoru něco, co model nebo nástroj nesprávně interpretuje jako pokyn.

NIST a přetížený svět zranitelností

NIST oznámil změnu v tom, jak bude zpracovávat zranitelnosti v Národní databázi zranitelností. Důvodem byl prudký nárůst počtu CVE záznamů. Prakticky to znamená, že obránci se nemohou spoléhat na to, že každá zranitelnost bude rychle a kompletně obohacena o všechny souvislosti.

Pro technické týmy to může znít jako detail. Pro vedení firmy je to ale důležitý signál. Počet zranitelností roste rychleji než schopnost lidí všechno ručně zpracovat. Bez prioritizace podle reálného dopadu, vystavení na internetu, aktivního zneužívání a hodnoty zasaženého systému se bezpečnost mění v nekonečný seznam úkolů.

Z pohledu útočníka je to výhodné. Stačí počkat, až firma nestíhá. Z pohledu Haxorisu je to důvod testovat útočné cesty, ne jen počítat nálezy. Deset kritických zranitelností v seznamu nemusí být horších než jedna méně nápadná chyba, která vede přímo k tokenům a produkci.

14. dubna

Composer: škodlivý projekt jako příkaz na vašem vývojářském stroji

V ekosystému PHP byly zveřejněny dvě zranitelnosti v nástroji Composer, sledované jako CVE-2026-40176 a CVE-2026-40261. Problém se týkal zpracování konfigurace repozitářů typu Perforce. Útočník, který ovládal škodlivý composer.json nebo zdrojovou referenci, mohl dosáhnout spuštění příkazů v kontextu uživatele, který Composer spouštěl.

To je přesně druh chyby, který je ve firmách podceňovaný. Vývojář otevře cizí projekt, spustí instalaci závislostí a předpokládá, že v nejhorším stáhne knihovny. Ve skutečnosti se vývojářské nástroje často chovají jako vykonávací prostředí. Čtou konfigurace, volají externí systémy, spouštějí skripty a používají lokální přístupové údaje.

Při útočném testování je vývojářské prostředí velmi zajímavý cíl. Ne proto, že by vývojáři dělali něco špatně. Ale proto, že jejich stroje často drží přístup k repozitářům, testovacím databázím, cloudovým účtům, interním balíčkům a nástrojům na nasazování. Pokud se škodlivý projekt spustí ve špatném prostředí, může být prvním krokem do celé firmy.

Microsoft Patch Tuesday: hodně oprav, málo času

Dubnové opravy Microsoftu řešily 167 zranitelností včetně dvou zero-day chyb. Osm zranitelností bylo označeno jako kritických, většina z nich umožňovala vzdálené spuštění kódu.

Toto není sekce o tom, že „patchování je důležité“. To už ví každý. Důležitější je realita ve firmách. Bezpečnostní tým dostane za jeden den desítky oprav, část systémů je kritická, část je stará, část patří dodavateli, část má výjimku, část nesmí vypadnout během pracovní doby a část nikdo přesně nevlastní.

Útočník tuto realitu zná. Nepotřebuje, aby firma ignorovala všechny opravy. Stačí, aby odložila tu jednu, která je vystavená na internetu nebo umožňuje zvýšení oprávnění po prvotním přístupu. Proto dává smysl řešit opravy podle útočné cesty: co je dostupné zvenku, co je aktivně zneužívané, co vede k vyšším oprávněním a co chrání systémy s největší hodnotou.

13. dubna

Itron: když se útok na dodavatele dotýká kritické infrastruktury

Itron, velký dodavatel technologií pro energetiku, měření a městskou infrastrukturu, potvrdil útok, při kterém útočníci získali přístup k částem jeho interního IT prostředí. Společnost uvedla, že incident zaznamenala 13. dubna, aktivovala plán reakce, zapojila externí poradce a podle jejího vyjádření nedošlo k materiálnímu narušení provozu ani dopadu na zákazníky.

Důležité je, kdo Itron je. Společnost dodává inteligentní měřiče, senzory a datové platformy pro tisíce utilit a měst ve více než stovce zemí. I když samotný incident podle firmy nezasáhl zákazníky, připomíná, že dodavatelský řetězec kritické infrastruktury není abstraktní pojem.

Při útočném bezpečnostním testování se na dodavatele díváme jako na součást útočné cesty. Ne každý útok musí začít přímo u provozovatele. Někdy dává větší smysl hledat slabinu v nástroji, podpoře, vzdáleném přístupu, aktualizačním procesu nebo datové platformě, která má přirozenou důvěru vůči více zákazníkům.

Pro firmy z toho plyne jednoduchá věc: hodnocení dodavatelů nemá být jen dotazník jednou ročně. Má zahrnovat i technické otázky. Jaké přístupy má dodavatel? Jak se logují? Jak se ruší? Jaký má plán reakce? Jak rychle informuje zákazníky? A co se stane, pokud se kompromituje jeho interní účet?

Adobe Acrobat: PDF jako starý, ale stále účinný vstup

Adobe vydal mimořádnou opravu pro Acrobat a Acrobat Reader k zranitelnosti CVE-2026-34621. Chyba umožňovala spuštění kódu po otevření škodlivého PDF souboru a Adobe potvrdil, že byla aktivně zneužívaná.

Tento typ zranitelnosti je zajímavý právě proto, že nepůsobí moderně. PDF je starý formát, který uživatelé otevírají denně. Faktury, smlouvy, objednávky, dokumentace, právní podklady, životopisy, přílohy od dodavatelů. Přesně proto je stále použitelný jako vstup do firmy.

Z pohledu útočníka je škodlivý dokument často levnější než hledání exotické chyby v hlavní aplikaci. Stačí správný příběh, správný odesílatel, správné načasování a zranitelný klient. Pokud se k tomu přidá uživatel s přístupem do interních systémů, dokument se mění v první krok útočné cesty.

Pro firmy to znamená, že ochrana koncových zařízení, izolace dokumentů, rychlé aktualizace a omezená oprávnění uživatelů pořád nejsou nudná hygiena. Jsou to vrstvy, které rozhodují, jestli se otevření přílohy změní v incident.

10. dubna

Marimo: datový notebook jako shell bez přihlášení

Sysdig upozornil, že kritická zranitelnost CVE-2026-39987 v nástroji Marimo byla zneužita do deseti hodin od zveřejnění. Marimo je otevřený Python notebook pro datovou vědu a analýzu. Chyba spočívala v tom, že WebSocket koncový bod terminálu neměl dostatečné ověření a neověřený útočník mohl získat plnohodnotný shell na systému.

To je dobrý příklad toho, jak se mění hranice mezi vývojem, datovou analytikou a produkcí. Notebooky se často spouštějí rychle, někdy dočasně, někdy v cloudu, někdy s přístupem k datům, modelům, databázím a tokenům. Právě proto jsou pro útočníka atraktivní.

Pokud notebook běží na serveru s přístupem do interního prostředí, zdánlivě malý nástroj se může změnit ve vstupní bod. Útočník získá příkazovou řádku, podívá se na proměnné prostředí, konfigurační soubory, historii příkazů, datová připojení a pokračuje dál.

Pro firmy je zde praktická pointa: dočasné analytické a vývojové nástroje musí být v inventáři. Pokud nejsou evidované, nikdo je neopravuje, nikdo je nesleduje a nikdo neví, jaké přístupy drží.

8. dubna

Ivanti EPMM: mobilní správa jako vstupní brána do sítě

CISA přidala zranitelnost CVE-2026-1340 v Ivanti Endpoint Manager Mobile do katalogu aktivně zneužívaných chyb. Šlo o chybu umožňující injektáž kódu v produktu používaném pro správu mobilních zařízení.

Systémy pro správu zařízení mají ve firmách speciální postavení. Mají přehled o zařízeních, politikách, profilech, certifikátech, aplikacích a často také o tom, co se smí připojovat do firemního prostředí. Pokud se útočník dostane k takové vrstvě, nezíská jen jeden server. Získá řídicí bod nad flotilou zařízení.

Z pohledu útočného testování je to velmi citlivý cíl. Správa mobilních zařízení, správa koncových stanic a vzdálený přístup často sedí na hranici mezi internetem a interním prostředím. Jsou určeny k administraci, a proto mají přirozeně velká oprávnění.

To je důvod, proč se tyto systémy nemají opravovat „až bude čas“. Pokud jsou dostupné zvenku a chyba je v katalogu aktivně zneužívaných zranitelností, nejde o běžnou údržbu. Jde o rozhodnutí, zda útočníkovi necháváte otevřený řídicí panel.

7. dubna

Flowise: nástroj na tvorbu AI agentů jako spouštěč kódu

VulnCheck a další zdroje upozornily na aktivní zneužívání zranitelnosti CVE-2025-59528 ve Flowise. Flowise je otevřená platforma na tvorbu aplikací a agentů s umělou inteligencí. Chyba měla nejvyšší hodnocení závažnosti a umožňovala spuštění kódu přes nesprávné zpracování konfigurace v uzlu CustomMCP.

Podstatné je, že Flowise není jen textový nástroj. Běží jako služba, napojuje se na modely, úložiště, interní systémy, aplikační rozhraní a automatizované pracovní postupy. Pokud útočník získá spuštění kódu na takovém serveru, může mít přístup k souborům, tajemstvím, integračním klíčům a datovým zdrojům.

To je širší problém nových AI nástrojů. Firmy je často nasazují jako experiment. Útočník je ale bere jako infrastrukturu. Pokud mají přístup k interním datům a systémům, musí být chráněny jako produkční systémy, ne jako hračka pro inovační tým.

Při testování bychom se ptali velmi přímo: kde Flowise běží, kdo se tam přihlašuje, co je připojené, jaké klíče jsou uložené, zda je rozhraní dostupné z internetu a zda se dá přes konfiguraci dosáhnout spuštění příkazů.

5. dubna

Falešné Strapi balíčky v npm: když plugin není plugin

Bezpečnostní výzkumníci objevili 36 škodlivých balíčků v registru npm, které se tvářily jako pluginy pro Strapi. Používaly názvy začínající strapi-plugin-, aby působily důvěryhodně, ale ve skutečnosti obsahovaly škodlivé skripty na sběr údajů, zneužití Redis a PostgreSQL, reverzní shelly a trvalejší přístup.

Tento případ je zajímavý tím, že nešlo jen o jednoduchý sběrač tokenů. Podle analýzy se útočníci pokoušeli o několik přístupů: od zneužití Redis přes průzkum až po krádež přihlašovacích údajů a udržování přístupu.

Pro vývojářské týmy je to další připomenutí, že název balíčku není důkaz důvěryhodnosti. V ekosystémech s tisíci balíčky se útočníci často nesnaží prolomit ochranu. Snaží se vypadat dost podobně jako legitimní věc, kterou vývojář očekává.

Z pohledu Haxorisu je to otázka procesu. Má firma pravidla pro nové závislosti? Vidí, co se spouští během instalace? Omezuje práva v sestavovacím prostředí? Má přehled o tom, které balíčky se používají v produkci? Pokud ne, dodavatelský řetězec se netestuje. Jen se mu věří.

2. dubna

Progress ShareFile: brána pro výměnu souborů jako vstup do firmy

watchTowr Labs zveřejnil výzkum k Progress ShareFile Storage Zone Controlleru. Dvě zranitelnosti, CVE-2026-2699 a CVE-2026-2701, bylo možné spojit do řetězce umožňujícího vzdálené spuštění kódu ještě před přihlášením. Dotčená komponenta slouží jako zákazníkem spravovaná brána, přes kterou organizace ukládají a zpřístupňují soubory ve vlastní infrastruktuře.

Nebezpečnost byla v tom, že útočník nepotřeboval přihlašovací údaje. Stačil síťový přístup k zasaženému řadiči úložné zóny. Po obejití přihlášení mohl spustit libovolný kód na podkladovém systému. Podle watchTowr byly zasažené verze StorageCenter 5.x do 5.12.3 včetně, přičemž opravená verze je 5.12.4.

ShareFile je dobrý příklad systému, který firmy často vnímají jako bezpečný kanál pro výměnu souborů, ne jako kritickou hranici sítě. Jenže právě takové portály sedí mezi externím světem a interními daty. Řeší přihlášení, přístup k dokumentům, konfigurace úložišť, síťová sdílení, cloudová úložiště a komunikaci s klienty.

Pro útočníka je to atraktivní cíl. Kombinuje externí dostupnost s vysokou hodnotou dat. Pokud se podobná brána kompromituje, útočník nemusí citlivé informace hledat po celé síti. Velká část z nich tímto systémem přirozeně prochází.

Co si z dubna odnášíme v Haxorisu

Kdybychom z dubnových událostí postavili jedno útočné cvičení, nezačalo by hollywoodsky. Žádné dramatické lámání hlavní brány. Spíš obyčejný pracovní moment: nový balíček v projektu, testovací nástroj vystavený na internetu, uživatel ve stresu, oprávnění udělené aplikaci, která měla šetřit čas, nebo starší portál, který už nikdo nevnímá jako kritický systém.

Přesně tak dnes vznikají zajímavé incidenty. Ne z jedné magické chyby, ale z kombinace drobností, které samostatně působí nevinně. Jedna z nich dá útočníkovi vstup. Druhá mu otevře více práv. Třetí mu ukáže, kde jsou uložené klíče. Čtvrtá mu dovolí pohybovat se dál bez velkého hluku.

Pro vedení firmy je na tom důležitá jedna věc: bezpečnost se nedá hodnotit jen podle toho, zda byl proveden sken, audit nebo školení. To všechno má smysl, ale nestačí to. Reálný útok se neptá, zda je systém formálně zařazen mezi kritická aktiva. Ptá se, zda je dostupný, zda má oprávnění, zda ukládá tokeny, zda ho někdo monitoruje a zda si vůbec někdo všimne, když se začne chovat jinak.

Duben zároveň ukázal, že nové technologie nepřinášejí jen nové možnosti, ale také nová slepá místa. Nástroje pro umělou inteligenci, automatizované sestavování, vývojářské platformy a chatové aplikace se staly přirozenou součástí firemního života. Útočníci je nevidí jako doplňky. Vidí je jako další dveře.

Z pohledu Haxorisu je proto nejdůležitější testovat firmu jako živé prostředí, ne jako seznam IP adres. Kde bychom získali první přístup? Kam bychom se posunuli po kompromitaci jednoho účtu? Který nástroj má příliš velká oprávnění? Kde se ukládají klíče? Který proces by člověk ve stresu obešel? A co by se stalo, kdyby útočník nesledoval nejviditelnější systém, ale ten nejpraktičtější?

To je důvod, proč má útočné bezpečnostní testování stále větší hodnotu. Ne proto, že najde nejhezčí CVE. Ale proto, že ukáže, zda se z běžného incidentu dokáže stát skutečný problém pro firmu. A duben takových příkladů nabídl víc než dost.

Časté otázky

Pro koho je tento April Throwback určený?

Pro bezpečnostní týmy, vývojáře, IT manažery i vedení firem, které řeší red teaming, penetrační testování, NIS2, cloudovou bezpečnost, DevSecOps nebo bezpečnost umělé inteligence.

Proč se článek zaměřuje na útočné cesty?

Samotný seznam zranitelností firmě mnoho neřekne. Útočná cesta ukazuje, jak by útočník spojil prvotní přístup, tokeny, cloud, CI/CD, identitu, aplikace a uživatele do reálného incidentu.

Jak s tím může Haxoris pomoct?

Haxoris pomáhá firmám ověřit útočnou plochu pomocí red teamingu, penetračních testů, testování cloudové a aplikační bezpečnosti, kontroly CI/CD, bezpečnostních cvičení a praktických doporučení ke snížení rizika.

Zdroje a doporučené čtení

Související články

Nečekejte na útočníky - odhalte své nejslabší místo penetračním testem už teď!

Rezervovat