Apríl 2026 v kyberbezpečnosti: red-team analýza pre firmy


Apríl 2026 bol mesiac, v ktorom sa kybernetická bezpečnosť opäť presunula z prezentácií do reality. Nie cez jeden veľký útok, ale cez sériu menších technických zlomov, ktoré v rukách útočníka dávajú veľmi praktický zmysel. Lokálna eskalácia oprávnení v Linuxe. Kompromitované balíky v npm. Brána pre umelú inteligenciu s uloženými kľúčmi. Chyba v platforme, cez ktorú denne prechádza vývojársky kód. OAuth oprávnenia, ktoré sa tvárili ako pohodlná integrácia.

Pre Haxoris je to presne typ materiálu, ktorý má hodnotu pri red teamingových cvičeniach, penetračných testoch a hodnotení firemnej útočnej plochy. Nie je podstatné iba to, že vznikla ďalšia zraniteľnosť. Podstatné je, ako sa dá spojiť s cloudovou bezpečnosťou, ochranou CI/CD, správou prístupov, bezpečnosťou umelej inteligencie, reakciou na incidenty a kybernetickou odolnosťou firmy. Apríl ukázal, že moderný útok sa často neskladá z hollywoodskeho prieniku, ale z bežných pracovných nástrojov, ktorým organizácia dôveruje až príliš.

Ak dnes firma rieši NIS2, ISO 27001, DORA, Zero Trust, DevSecOps, cloudovú bezpečnosť alebo bezpečnosť umelej inteligencie, aprílové prípady sú dobrý stres test jej reality. Nie papierovej, ale prevádzkovej. Ukazujú, kde sa z bežnej integrácie, vývojárskeho nástroja, tokenu alebo správcovského panelu môže stať začiatok incidentu.

29. apríl

Copy Fail: keď sa slabý lokálny účet zmení na root

Xint Code Research Team zverejnil Copy Fail, zraniteľnosť sledovanú ako CVE-2026-31431. Ide o logickú chybu v jadre Linuxu, konkrétne v kryptografickej šablóne authencesn. Neprivilegovaný lokálny používateľ vďaka nej dokáže vyvolať kontrolovaný štvrojbajtový zápis do vyrovnávacej pamäte stránok čitateľného súboru.

Výskumníci ukázali, že krátky dôkazový skript v jazyku Python dokáže upraviť setuid binárny súbor iba v pamäti a získať oprávnenia používateľa root. Testovali veľké distribúcie vrátane Ubuntu, Amazon Linux, RHEL a SUSE.

Najzaujímavejšia nie je len samotná eskalácia oprávnení. Zápis sa neprejaví ako bežná zmena súboru na disku. Poškodená stránka sa neoznačí na spätný zápis, takže súbor na disku môže vyzerať nezmenený, zatiaľ čo jeho verzia v pamäti sa už správa inak. Bežné porovnávanie kontrolných súčtov tak nemusí ukázať nič podozrivé.

Pri útočnom bezpečnostnom testovaní je toto presne typ chyby, ktorá z malého prístupu robí kontrolu nad systémom. Útočník nemusí začínať ako správca. Stačí mu kompromitovaný používateľ, webový shell, slabý účet v službe alebo prístup do kontajnera. Lokálne zvýšenie oprávnení potom vytvorí most medzi prvotným prienikom a ovládnutím hostiteľa.

Dôležitá je aj kontajnerová rovina. Vyrovnávacia pamäť stránok je spoločná pre procesy na hostiteľskom systéme a podľa Xint má táto chyba dopad aj na hranice kontajnerov. To neznamená, že každý kontajner automaticky padne jedným príkazom. Znamená to však, že veta „beží to len v kontajneri“ nie je bezpečnostná stratégia.

Mini Shai-Hulud: keď bežná inštalácia závislosti začne zbierať prístupové údaje

Wiz zverejnil analýzu kampane Mini Shai-Hulud. Tá zasiahla legitímne balíky v ekosystéme SAP z registra npm. Útočníci do balíkov ako @cap-js/sqlite, @cap-js/postgres, @cap-js/db-service a mbt vložili škodlivý predinštalačný skript, ktorý sa spúšťa automaticky počas bežnej inštalácie závislostí.

To je na celom prípade najpodstatnejšie. Vývojár nemusel urobiť nič zvláštne. Nestiahol pirátsky softvér, neotvoril prílohu a neklikol na falošné prihlásenie. Urobil presne to, čo robí každý deň: nainštaloval závislosti a spustil zostavenie projektu.

Škodlivý kód podľa Wiz sťahoval spúšťacie prostredie Bun a následne vykonával zberač prístupových údajov. Cielil na tokeny GitHubu, prihlasovacie údaje pre npm, cloudové tajomstvá pre AWS, Azure a GCP, tokeny Kubernetes aj tajomstvá používané v GitHub Actions. Údaje odosielal cez útočníkom kontrolované repozitáre na GitHube a obsahoval aj logiku na ďalšie šírenie pomocou kompromitovaných tokenov.

Pre firmy je toto veľmi praktická lekcia. Automatizované zostavovanie a nasadzovanie nie je pomocný nástroj niekde bokom. Je to prostredie, ktoré často drží najcennejšie prístupové údaje v celej firme. Má prístup ku kódu, registru kontajnerov, cloudu, Kubernetes, produkčným nasadeniam a niekedy aj k zákazníckym dátam.

Otázka preto neznie iba „používame bezpečné balíky?“. Otázka znie: ak sa škodlivý balík spustí vo vašom zostavovacom procese, čo všetko vie prečítať? Ak odpoveď znie „takmer všetko“, problém nie je iba v balíku. Problém je v tom, že automatizácia má viac dôvery, než reálne potrebuje.

LiteLLM: brána pre umelú inteligenciu ako trezor na cudzie kľúče

LiteLLM riešil kritickú zraniteľnosť CVE-2026-42208. Belgické Centrum pre kybernetickú bezpečnosť ju popísalo priamo: LiteLLM slúži ako brána pre umelú inteligenciu, ktorá centralizuje prístupové údaje k poskytovateľom ako OpenAI alebo Anthropic. Úspešné zneužitie preto môže znamenať naraz stratu všetkých pripojených účtov u poskytovateľov umelej inteligencie.

Technická podstata bola nepríjemne jednoduchá. Hodnota prístupového tokenu z HTTP požiadavky sa mohla dostať do databázového dotazu bez dostatočného očistenia. Útočník tak vedel zasiahnuť ešte pred prihlásením a dostať sa k uloženým aplikačným kľúčom, prístupovým údajom poskytovateľov a ďalším citlivým dátam v databáze.

Toto je zásadné pre každú firmu, ktorá zavádza umelú inteligenciu. Podobná brána nie je experimentálny nástroj niekde na okraji infraštruktúry. Veľmi rýchlo sa z nej stáva centrálny sklad aplikačných kľúčov, fakturačných identít, pravidiel používania, záznamov požiadaviek a niekedy aj interných dát.

Pri útočnom testovaní by nás takýto komponent zaujímal okamžite. Nie preto, že umelá inteligencia je módna téma. Ale preto, že nové nástroje sa vo firmách často nasadzujú rýchlejšie, než vznikne ich bezpečnostný model. Kde sú uložené kľúče? Kto ich vie čítať? Čo sa zaznamenáva? Dá sa prístup rýchlo zrušiť? Má každý poskytovateľ samostatný účet a limit? Práve tieto odpovede rozhodujú o tom, či incident zostane lokálny, alebo sa zmení na širší kompromis cloudu.

28. apríl

GitHub: aj bežný vývojársky príkaz môže byť problém na strane servera

GitHub zverejnil rozbor kritickej zraniteľnosti v časti infraštruktúry, ktorá spracúva príkaz git push. Chybu nahlásili výskumníci z Wiz cez program odmien za nálezy. GitHub ju podľa vlastného opisu interne zopakoval do štyridsiatich minút, opravil na GitHub.com za menej než dve hodiny a forenzná analýza nenašla dôkaz o zneužití.

Podstata chyby bola vážna. Používateľ s oprávnením odoslať zmeny do repozitára, vrátane repozitára, ktorý si sám vytvoril, mohol dosiahnuť spustenie príkazov na serveri spracúvajúcom dané odoslanie. Stačila špeciálne pripravená voľba pri odosielaní zmien, ktorá využila nedostatočne očistený znak.

Pre bežnú firmu je dôležitá širšia pointa. GitHub, GitLab, Bitbucket alebo interné úložiská kódu už dávno nie sú iba miesto, kam sa ukladá zdrojový kód. Sú to uzly, kde sa stretáva identita, automatizácia, schvaľovanie zmien, tajomstvá, zostavovanie, testovanie, nasadzovanie a auditná stopa.

Útočná otázka znie: čo všetko sa vo firme stane po úspešnom odoslaní zmeny do repozitára? Spustí sa zostavenie? Načítajú sa citlivé premenné? Vytvorí sa artefakt? Nasadí sa zmena do cloudu? Má zostavovací pracovník prístup do produkcie? Každá z týchto odpovedí mení bežný vývojársky krok na bezpečnostné rozhodnutie.

cPanel a WHM: správcovský panel ako kľúče od viacerých dverí

cPanel vydal bezpečnostné upozornenie k CVE-2026-41940. Išlo o chybu umožňujúcu obídenie prihlásenia v cPanel & WHM a DNSOnly. Podľa cPanelu sa problém týkal verzií po 11.40 a firma vydala opravené zostavy pre viacero podporovaných vetiev.

Ako núdzové opatrenie odporúčala blokovať prichádzajúcu komunikáciu na portoch 2083, 2087, 2095 a 2096 alebo dočasne zastaviť dotknuté služby, ak aktualizácia nebola okamžite možná.

Na prvý pohľad to vyzerá ako problém poskytovateľov hostingu. V skutočnosti je to problém každého, kto cez podobný panel spravuje web, poštu, domény, certifikáty alebo klientsky portál. WHM je riadiaca vrstva. Ak sa útočník dostane cez prihlásenie, nemusí ísť len o kompromitáciu jedného webu. Môže ísť o prístup k správe účtov, domén, poštových schránok, certifikátov a niekedy aj serverovej infraštruktúry.

Pri testovaní firiem sa podobné panely opakovane ukazujú ako podceňovaná hranica siete. Firma si chráni hlavnú aplikáciu, ale správcovské rozhranie hostingu, starý panel zákazníckeho portálu alebo DNS rozhranie zostáva bokom. Útočník však nerozlišuje medzi „hlavným systémom“ a „pomocným nástrojom“. Rozlišuje len to, čo mu dá najviac oprávnení za najmenej práce.

24. apríl

UNC6692: falošná technická podpora, Teams a škodlivé rozšírenie prehliadača

Google Cloud a Mandiant popísali kampaň skupiny UNC6692, ktorá veľmi dobre ukazuje, ako vyzerá moderné sociálne inžinierstvo vo firme. Útočníci najprv zahltili cieľ e-mailmi, aby vytvorili tlak a zmätok. Potom kontaktovali používateľa cez Microsoft Teams ako údajná technická podpora a ponúkli „opravu“ problému.

Používateľ bol nasmerovaný na stránku, ktorá sa tvárila ako oprava poštovej schránky. Odtiaľ sa stiahol premenovaný AutoHotKey súbor a skript. Ten spustil prieskum systému a nainštaloval SNOWBELT, škodlivé rozšírenie pre prehliadač Chromium. Následne útočníci pokračovali ďalšími nástrojmi, interným prieskumom, bočným pohybom, zberom prihlasovacích údajov a prístupom k doménovým radičom.

Toto je dôležité, pretože útok nevyzeral ako klasický phishingový e-mail. Vyzeral ako interný proces podpory. Problém nebol len v používateľovi. Problém bol v tom, že firemné prostredie nevedelo dostatočne jasne rozlíšiť, kto je skutočná technická podpora, ako sa overuje jej identita a čo zamestnanec nikdy nemá inštalovať na základe chatovej správy.

Z pohľadu Haxorisu je toto výborný scenár pre útočné bezpečnostné cvičenie. Nie „kliknite na falošný e-mail“, ale realistická reťaz: zahltenie, stres, chat cez firemnú platformu, falošná podpora, inštalácia lokálnej opravy, škodlivé rozšírenie, prieskum siete a pokus o prístup k citlivým systémom.

22. apríl

Lovable: verejný projekt neznamená len verejnú aplikáciu

Lovable zverejnil reakciu na aprílový incident po tom, čo bezpečnostný výskumník upozornil, že dáta vo verejných projektoch mohli byť prístupné každému prihlásenému používateľovi. Firma uviedla, že opravu nasadila do dvoch hodín. Zároveň priznala, že produkt aj prvotná komunikácia situáciu nezvládli dobre.

Podľa Lovable mohli byť medzi 3. februárom a 20. aprílom 2026 pri verejných projektoch potenciálne dostupné histórie rozhovorov a zdrojový kód. Súkromné projekty a Lovable Cloud podľa firmy zasiahnuté neboli. Problém vznikol kombináciou historického modelu verejných projektov, neskorších zmien viditeľnosti a februárovej chyby v zázemí služby, ktorá znova otvorila prístup k veciam, ktoré už nemali byť verejné.

Toto nie je len príbeh jedného nástroja na tvorbu aplikácií cez umelú inteligenciu. Je to širší problém jazykového zmätku okolo slova „verejné“. Mnoho používateľov chápe verejnú aplikáciu tak, že výsledný web môže navštíviť ktokoľvek. Nechápe to ako prístup k editoru, rozhovorom s umelou inteligenciou, zdrojovému kódu, pracovným poznámkam alebo integračným detailom.

Útočník sa však nepozerá na to, ako používateľ chápe nastavenie. Pozerá sa na to, čo mu rozhranie vráti. Ak sa v takomto projekte nachádzajú odkazy na databázy, platobné brány, aplikačné rozhrania, interné koncové body alebo konfiguračné fragmenty, zle nastavená viditeľnosť sa môže zmeniť na veľmi praktický zdroj ďalšieho prieniku.

Poučenie pre firmy je jednoduché: pri nástrojoch s umelou inteligenciou nestačí riešiť iba výslednú aplikáciu. Treba riešiť aj rozhovory, návrhy, pracovný kód, koncepty a všetko, čo používateľ považuje za „len proces tvorby“. Aj proces tvorby môže obsahovať citlivé informácie.

19. apríl

Vercel a Context.ai: prístupový token ako tichá vstupná karta

Vercel zverejnil bezpečnostný incident, ktorý nezačal priamym útokom na jeho hlavnú infraštruktúru. Podľa Vercelu incident vznikol cez kompromitáciu tretej strany, konkrétne nástroja Context.ai používaného jedným zo zamestnancov. Útočník následne použil tento prístup na prevzatie individuálneho účtu vo firemnom Google Workspace, dostal sa do účtu zamestnanca vo Verceli a ďalej sa pohyboval v internom prostredí.

Vercel uviedol, že útočník enumeroval a dešifroval necitlivé premenné prostredia uložené na platforme. Zároveň firma odporúčala rotovať hodnoty, ktoré neboli označené ako citlivé, pretože aj „necitlivá“ premenná môže v praxi obsahovať token, aplikačný kľúč, databázové prihlasovacie údaje alebo podpisovací kľúč.

Toto je ukážkový príklad toho, prečo heslá už nie sú jediný problém identity. Prístupový token je často tichší a nebezpečnejší. Nepýta si viacfaktorové overenie pri každom použití, nevzbudzuje rovnakú pozornosť ako nové prihlásenie a v niektorých prípadoch prežije aj zmenu hesla. Ak má navyše široké oprávnenia, funguje ako vstupná karta do firemného sveta cloudových služieb.

Z pohľadu Haxorisu je to typická útočná cesta cez dôveru. Neútočí sa priamo na veľkú firmu. Útočí sa na menší nástroj, ktorý má veľké oprávnenia. Potom sa hľadá používateľ s firemným účtom, široký prístup do dokumentov, zdieľané priečinky, premenné prostredia, interné pracovné postupy a ďalšie miesta, kde sa dá posunúť ďalej.

17. apríl

Codex v incidente: keď používateľ počas kompromitácie zapojí umelú inteligenciu

Spoločnosť Huntress opísala nezvyčajný incident na Linuxovom koncovom zariadení. Na systéme boli aktívni viacerí útočníci, ktorí inštalovali ťažiarne kryptomien, zbierali prístupové údaje a pripravovali ďalšiu škodlivú aktivitu. Zároveň používateľ na rovnakom zariadení používal OpenAI Codex, aby mu pomohol auditovať a riešiť podozrivú aktivitu.

Bezpečnostný nástroj Huntress bol nainštalovaný až uprostred kompromitácie. Tím preto nemal úplnú historickú telemetriu. Vyšetrovanie komplikovalo aj to, že príkazy generované Codexom vyzerali v niektorých prípadoch podobne ako príkazy útočníka. Používateľ sa snažil pomôcť, ale vytvoril ďalšiu vrstvu šumu v presne tom momente, keď bolo potrebné oddeliť legitímne kroky od škodlivej aktivity.

Toto je nová kategória incidentov. Používateľ zbadá problém, otvorí asistenta s umelou inteligenciou, nechá ho spustiť diagnostiku, upravovať súbory, navrhovať príkazy a „opraviť“ systém. Medzitým môže byť útočník stále aktívny. Bez jasných pravidiel vzniká chaos, ktorý predlžuje vyšetrovanie.

Pre firmy z toho vyplýva praktický záver. Reakcia na incident nemá byť improvizácia používateľa s umelou inteligenciou. Ak zamestnanec podozrieva kompromitáciu, musí vedieť, čo urobiť, koho kontaktovať a čo určite nespúšťať. Umelá inteligencia môže pomôcť odborníkom, ale nemá nahradiť riadený postup pri incidente.

Microsoft Defender: keď sa ochranný nástroj stane cestou k vyšším oprávneniam

Huntress v rovnakom období upozornil aj na reálne zneužívanie zraniteľností označovaných ako BlueHammer, RedSun a UnDefend. BlueHammer bol sledovaný ako CVE-2026-33825 a Microsoft ho opravil v aprílových aktualizáciách. Podľa Huntress išlo o chybu typu „skontrolujem teraz, použijem neskôr“ vo Windows Defenderi, ktorá mohla útočníka posunúť z bežného účtu na oprávnenia SYSTEM.

Z pohľadu firmy je tento príbeh nepríjemný práve preto, že sa týka ochranného nástroja. Obranný softvér má vysoké oprávnenia, široký prístup do systému a prirodzene je prítomný na veľkom počte zariadení. Ak sa v ňom objaví zneužiteľná chyba, útočník ju môže použiť ako súčasť eskalácie po prvotnom prieniku.

Pri útočnom testovaní to mení spôsob uvažovania. Nestačí sa pýtať, či má firma bezpečnostný nástroj. Treba sa pýtať, ako rýchlo sa opravuje, či má obmedzený dosah, či sú chránené jeho konfigurácie a či tím sleduje aj zraniteľnosti v samotných nástrojoch, ktorým dáva najvyššiu dôveru.

16. apríl

Nginx UI: správa webového servera ako vstup do produkcie

Rapid7 a ďalšie bezpečnostné zdroje upozornili na zraniteľnosť CVE-2026-33032 v nástroji Nginx UI. Ide o webové rozhranie na správu Nginx serverov. Chyba súvisela s novou integráciou Model Context Protocol a umožňovala neoverenému útočníkovi prevziať kontrolu nad serverom. Podľa dostupných údajov existovali tisíce internetovo dostupných inštancií.

Tento prípad je zaujímavý tým, že spája dve veci, ktoré firmy často podceňujú: správcovské rozhrania a nové integrácie pre umelú inteligenciu. Nginx UI nie je len pekný panel. Je to nástroj, ktorým sa spravuje konfigurácia webového servera, smerovanie prevádzky, certifikáty, spätné proxy, presmerovania a niekedy aj prístup k interným aplikáciám.

Ak útočník prevezme takýto bod, nemusí hneď čítať databázu. Môže meniť smerovanie, vkladať škodlivé presmerovania, zachytávať komunikáciu, pripravovať phishing na rovnakej doméne alebo si vytvoriť trvalejší prístup.

Z pohľadu Haxorisu je to ďalší dôkaz, že hranica siete dnes často nie je jeden firewall. Je to množina správcovských rozhraní, ktoré majú väčšiu moc, než si ich majitelia priznávajú.

15. apríl

Model Context Protocol: keď sa nástroj pre umelú inteligenciu dostane príliš blízko k systému

Bezpečnostní výskumníci upozornili na slabinu v spôsobe, akým sa používa Model Context Protocol. Problém nebol len v jednej konkrétnej aplikácii. Týkal sa širšieho princípu: nástroje napojené na umelú inteligenciu môžu cez nesprávne spracované konfigurácie alebo príkazy získať možnosť spúšťať príkazy v systéme.

The Hacker News s odkazom na OX Security uviedol, že riziko sa týka viacerých projektov a môže viesť k prístupu k používateľským dátam, interným databázam, aplikačným kľúčom a históriám rozhovorov. Podstatné je, že ide o typ problému, ktorý vzniká na rozhraní medzi asistentom, nástrojom a systémom.

Pre firmy je to varovanie pred slepým pripájaním umelej inteligencie ku všetkému. Ak model alebo jeho nástroj vie čítať súbory, volať externé služby, spúšťať skripty alebo pracovať s internými dátami, nejde o neškodnú pomôcku. Je to nový vykonávací kanál.

Pri útočnom bezpečnostnom testovaní nás preto nezaujíma iba otázka „aký model používate“. Zaujíma nás, čo smie robiť. K akým súborom má prístup. Aké príkazy vie spustiť. Aké tajomstvá vidí. A čo sa stane, keď používateľ vloží do rozhovoru niečo, čo model alebo nástroj nesprávne interpretuje ako pokyn.

NIST a preťažený svet zraniteľností

NIST oznámil zmenu v tom, ako bude spracúvať zraniteľnosti v Národnej databáze zraniteľností. Dôvodom bol prudký nárast počtu CVE záznamov. Prakticky to znamená, že obrancovia sa nemôžu spoliehať na to, že každá zraniteľnosť bude rýchlo a kompletne obohatená o všetky súvislosti.

Pre technické tímy to znie ako detail. Pre vedenie firmy je to však dôležitý signál. Počet zraniteľností rastie rýchlejšie než schopnosť ľudí všetko ručne spracovať. Bez prioritizácie podľa reálneho dopadu, vystavenia na internete, aktívneho zneužívania a hodnoty zasiahnutého systému sa bezpečnosť mení na nekonečný zoznam úloh.

Z pohľadu útočníka je to výhodné. Stačí počkať, kým firma nestíha. Z pohľadu Haxorisu je to dôvod testovať útočné cesty, nie iba počítať nálezy. Desať kritických zraniteľností v zozname nemusí byť horších než jedna menej nápadná chyba, ktorá vedie priamo k tokenom a produkcii.

14. apríl

Composer: škodlivý projekt ako príkaz na vašom vývojárskom stroji

V ekosystéme PHP boli zverejnené dve zraniteľnosti v nástroji Composer, sledované ako CVE-2026-40176 a CVE-2026-40261. Problém sa týkal spracovania konfigurácie repozitárov typu Perforce. Útočník, ktorý ovládal škodlivý composer.json alebo zdrojovú referenciu, mohol dosiahnuť spustenie príkazov v kontexte používateľa, ktorý Composer spúšťal.

Toto je presne ten druh chyby, ktorý je vo firmách podceňovaný. Vývojár otvorí cudzí projekt, spustí inštaláciu závislostí a predpokladá, že maximálne stiahne knižnice. V skutočnosti sa vývojárske nástroje často správajú ako vykonávacie prostredie. Čítajú konfigurácie, volajú externé systémy, spúšťajú skripty a používajú lokálne prístupové údaje.

Pri útočnom testovaní je vývojárske prostredie veľmi zaujímavý cieľ. Nie preto, že by vývojári robili niečo zle. Ale preto, že ich stroje často držia prístup k repozitárom, testovacím databázam, cloudovým účtom, interným balíkom a nástrojom na nasadzovanie. Ak sa škodlivý projekt spustí v nesprávnom prostredí, môže byť prvým krokom do celej firmy.

Microsoft Patch Tuesday: veľa opráv, málo času

Aprílové opravy Microsoftu riešili 167 zraniteľností vrátane dvoch zero-day chýb. Osem zraniteľností bolo označených ako kritických, väčšina z nich umožňovala vzdialené spustenie kódu.

Toto nie je sekcia o tom, že „patchovanie je dôležité“. To už vie každý. Dôležitejšia je realita vo firmách. Bezpečnostný tím dostane za jeden deň desiatky opráv, časť systémov je kritická, časť je stará, časť patrí dodávateľovi, časť má výnimku, časť nesmie vypadnúť počas pracovnej doby a časť nikto presne nevlastní.

Útočník túto realitu pozná. Nepotrebuje, aby firma ignorovala všetky opravy. Stačí, aby odložila tú jednu, ktorá je vystavená na internete alebo umožňuje zvýšenie oprávnení po prvotnom prístupe. Preto má zmysel riešiť opravy podľa útočnej cesty: čo je dostupné zvonka, čo je aktívne zneužívané, čo vedie k vyšším oprávneniam a čo chráni systémy s najväčšou hodnotou.

13. apríl

Itron: keď sa útok na dodávateľa dotýka kritickej infraštruktúry

Itron, veľký dodávateľ technológií pre energetiku, meranie a mestskú infraštruktúru, potvrdil útok, pri ktorom útočníci získali prístup k častiam jeho interného IT prostredia. Spoločnosť uviedla, že incident zaznamenala 13. apríla, aktivovala plán reakcie, zapojila externých poradcov a podľa jej vyjadrenia nedošlo k materiálnemu narušeniu prevádzky ani k dopadu na zákazníkov.

Dôležité je, kto je Itron. Spoločnosť dodáva inteligentné merače, senzory a dátové platformy pre tisíce utilít a miest vo viac ako stovke krajín. Aj keď samotný incident podľa firmy nezasiahol zákazníkov, pripomína, že dodávateľský reťazec kritickej infraštruktúry nie je abstraktný pojem.

Pri útočnom bezpečnostnom testovaní sa na dodávateľov pozeráme ako na súčasť útočnej cesty. Nie každý útok musí začať priamo u prevádzkovateľa. Niekedy dáva väčší zmysel hľadať slabinu v nástroji, podpore, vzdialenom prístupe, aktualizačnom procese alebo dátovej platforme, ktorá má prirodzenú dôveru voči viacerým zákazníkom.

Pre firmy z toho vyplýva jednoduchá vec: hodnotenie dodávateľov nemá byť len dotazník raz ročne. Má zahŕňať aj technické otázky. Aké prístupy má dodávateľ? Ako sa logujú? Ako sa rušia? Aký má plán reakcie? Ako rýchlo informuje zákazníkov? A čo sa stane, ak sa kompromituje jeho interný účet?

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

Adobe vydal mimoriadnu opravu pre Acrobat a Acrobat Reader k zraniteľnosti CVE-2026-34621. Chyba umožňovala spustenie kódu po otvorení škodlivého PDF súboru a Adobe potvrdil, že bola aktívne zneužívaná.

Tento typ zraniteľnosti je zaujímavý práve preto, že nepôsobí moderne. PDF je starý formát, ktorý používatelia otvárajú denne. Faktúry, zmluvy, objednávky, dokumentácia, právne podklady, životopisy, prílohy od dodávateľov. Presne preto je stále použiteľný ako vstup do firmy.

Z pohľadu útočníka je škodlivý dokument často lacnejší ako hľadanie exotickej chyby v hlavnej aplikácii. Stačí správny príbeh, správny odosielateľ, správny timing a zraniteľný klient. Ak sa k tomu pridá používateľ s prístupom do interných systémov, dokument sa mení na prvý krok útočnej cesty.

Pre firmy to znamená, že ochrana endpointov, izolácia dokumentov, rýchle aktualizácie a obmedzené oprávnenia používateľov stále nie sú nudná hygiena. Sú to vrstvy, ktoré rozhodujú, či sa otvorenie prílohy zmení na incident.

10. apríl

Marimo: dátový notebook ako shell bez prihlásenia

Sysdig upozornil, že kritická zraniteľnosť CVE-2026-39987 v nástroji Marimo bola zneužitá do desiatich hodín od zverejnenia. Marimo je otvorený Python notebook pre dátovú vedu a analýzu. Chyba spočívala v tom, že WebSocket koncový bod terminálu nemal dostatočné overenie a neoverený útočník mohol získať plnohodnotný shell na systéme.

Toto je výborný príklad toho, ako sa mení hranica medzi vývojom, dátovou analytikou a produkciou. Notebooky sa často spúšťajú rýchlo, niekedy dočasne, niekedy v cloude, niekedy s prístupom k dátam, modelom, databázam a tokenom. Práve preto sú pre útočníka atraktívne.

Ak notebook beží na serveri s prístupom do interného prostredia, zdanlivo malý nástroj sa môže zmeniť na vstupný bod. Útočník získa príkazový riadok, pozrie premenné prostredia, konfiguračné súbory, históriu príkazov, dátové pripojenia a pokračuje ďalej.

Pre firmy je tu praktická pointa: dočasné analytické a vývojové nástroje musia byť v inventári. Ak nie sú evidované, nikto ich neopravuje, nikto ich nesleduje a nikto nevie, aké prístupy držia.

8. apríl

Ivanti EPMM: mobilná správa ako vstupná brána do siete

CISA pridala zraniteľnosť CVE-2026-1340 v Ivanti Endpoint Manager Mobile do katalógu aktívne zneužívaných chýb. Išlo o chybu umožňujúcu injektáž kódu v produkte používanom na správu mobilných zariadení.

Systémy na správu zariadení majú vo firmách špeciálne postavenie. Majú prehľad o zariadeniach, politikách, profiloch, certifikátoch, aplikáciách a často aj o tom, čo sa smie pripájať do firemného prostredia. Ak sa útočník dostane k takejto vrstve, nezíska len jeden server. Získa riadiaci bod nad flotilou zariadení.

Z pohľadu útočného testovania je to veľmi citlivý cieľ. Správa mobilných zariadení, správa koncových staníc a vzdialený prístup často sedia na hranici medzi internetom a interným prostredím. Sú určené na administráciu, a preto majú prirodzene veľké oprávnenia.

To je dôvod, prečo sa tieto systémy nemajú opravovať „keď bude čas“. Ak sú dostupné zvonka a chyba je v katalógu aktívne zneužívaných zraniteľností, nejde o bežnú údržbu. Ide o rozhodnutie, či nechávate útočníkovi otvorený riadiaci panel.

7. apríl

Flowise: nástroj na tvorbu AI agentov ako spúšťač kódu

VulnCheck a ďalšie zdroje upozornili na aktívne zneužívanie zraniteľnosti CVE-2025-59528 v Flowise. Flowise je otvorená platforma na tvorbu aplikácií a agentov s umelou inteligenciou. Chyba mala najvyššie hodnotenie závažnosti a umožňovala spustenie kódu cez nesprávne spracovanie konfigurácie v uzle CustomMCP.

Podstatné je, že Flowise nebol len textový nástroj. Beží ako služba, napája sa na modely, úložiská, interné systémy, aplikačné rozhrania a automatizované pracovné postupy. Ak útočník získa spustenie kódu na takomto serveri, môže mať prístup k súborom, tajomstvám, integračným kľúčom a dátovým zdrojom.

Toto je širší problém nových AI nástrojov. Firmy ich často nasadzujú ako experiment. Útočník ich však berie ako infraštruktúru. Ak majú prístup k interným dátam a systémom, musia byť chránené ako produkčné systémy, nie ako hračka pre inovačný tím.

Pri testovaní by sme sa pýtali veľmi priamo: kde Flowise beží, kto sa tam prihlasuje, čo je pripojené, aké kľúče sú uložené, či je rozhranie dostupné z internetu a či sa dá cez konfiguráciu dosiahnuť spustenie príkazov.

5. apríl

Falošné Strapi balíky v npm: keď plugin nie je plugin

Bezpečnostní výskumníci objavili 36 škodlivých balíkov v registri npm, ktoré sa tvárili ako pluginy pre Strapi. Používali názvy začínajúce strapi-plugin-, aby pôsobili dôveryhodne, no v skutočnosti obsahovali škodlivé skripty na zber údajov, zneužitie Redis a PostgreSQL, reverzné shelly a trvalejší prístup.

Tento prípad je zaujímavý tým, že nešlo len o jednoduchý zberač tokenov. Podľa analýzy sa útočníci pokúšali o viacero prístupov: od zneužitia Redis cez prieskum až po krádež prihlasovacích údajov a udržiavanie prístupu.

Pre vývojárske tímy je to ďalšie pripomenutie, že názov balíka nie je dôkaz dôveryhodnosti. V ekosystémoch s tisíckami balíkov sa útočníci často nesnažia prelomiť ochranu. Snažia sa vyzerať dostatočne podobne ako legitímna vec, ktorú vývojár očakáva.

Z pohľadu Haxorisu je to otázka procesu. Má firma pravidlá pre nové závislosti? Vidí, čo sa spúšťa počas inštalácie? Obmedzuje práva v zostavovacom prostredí? Má prehľad o tom, ktoré balíky sa používajú v produkcii? Ak nie, dodávateľský reťazec sa netestuje. Len sa mu verí.

2. apríl

Progress ShareFile: brána na výmenu súborov ako vstup do firmy

watchTowr Labs zverejnil výskum k Progress ShareFile Storage Zone Controlleru. Dve zraniteľnosti, CVE-2026-2699 a CVE-2026-2701, bolo možné spojiť do reťazca umožňujúceho spustenie kódu na diaľku ešte pred prihlásením. Dotknutý komponent slúži ako zákazníkom spravovaná brána, cez ktorú organizácie ukladajú a sprístupňujú súbory vo vlastnej infraštruktúre.

Nebezpečnosť bola v tom, že útočník nepotreboval prihlasovacie údaje. Stačil sieťový prístup k zasiahnutému radiču úložnej zóny. Po obídení prihlásenia mohol spustiť ľubovoľný kód na podkladovom systéme. Podľa watchTowr boli zasiahnuté verzie StorageCenter 5.x do 5.12.3 vrátane, pričom opravená verzia je 5.12.4.

ShareFile je dobrý príklad systému, ktorý firmy často vnímajú ako bezpečný kanál na výmenu súborov, nie ako kritickú hranicu siete. Lenže práve takéto portály sedia medzi externým svetom a internými dátami. Riešia prihlásenie, prístup k dokumentom, konfigurácie úložísk, sieťové zdieľania, cloudové úložiská a komunikáciu s klientmi.

Pre útočníka je to atraktívny cieľ. Kombinuje externú dostupnosť s vysokou hodnotou dát. Ak sa podobná brána kompromituje, útočník nemusí citlivé informácie hľadať po celej sieti. Veľká časť z nich sa cez tento systém prirodzene presúva.

Čo si z apríla odnášame v Haxorise

Ak by sme z aprílových udalostí postavili jedno útočné cvičenie, nezačalo by hollywoodsky. Žiadne dramatické prelamovanie hlavnej brány. Skôr obyčajný pracovný moment: nový balík v projekte, testovací nástroj vystavený na internete, používateľ v strese, oprávnenie udelené aplikácii, ktorá mala šetriť čas, alebo starší portál, ktorý už nikto nevníma ako kritický systém.

Presne tak dnes vznikajú zaujímavé incidenty. Nie z jednej magickej chyby, ale z kombinácie drobností, ktoré samostatne pôsobia nevinne. Jedna z nich dá útočníkovi vstup. Druhá mu otvorí viac práv. Tretia mu ukáže, kde sú uložené kľúče. Štvrtá mu dovolí pohybovať sa ďalej bez toho, aby musel robiť veľký hluk.

Pre vedenie firmy je na tom dôležitá jedna vec: bezpečnosť sa nedá hodnotiť iba podľa toho, či bol urobený sken, audit alebo školenie. To všetko má zmysel, ale nestačí to. Reálny útok sa nepýta, či je systém formálne zaradený medzi kritické aktíva. Pýta sa, či je dostupný, či má oprávnenia, či má uložené tokeny, či ho niekto monitoruje a či si vôbec niekto všimne, keď sa začne správať inak.

Apríl zároveň ukázal, že nové technológie neprinášajú len nové možnosti, ale aj nové slepé miesta. Nástroje pre umelú inteligenciu, automatizované zostavovanie, vývojárske platformy a chatové aplikácie sa stali prirodzenou súčasťou firemného života. Útočníci ich nevidia ako doplnky. Vidia ich ako ďalšie dvere.

Z pohľadu Haxorisu je preto najdôležitejšie testovať firmu ako živé prostredie, nie ako zoznam IP adries. Kde by sme získali prvý prístup? Kam by sme sa posunuli po kompromitácii jedného účtu? Ktorý nástroj má príliš veľké oprávnenia? Kde sa ukladajú kľúče? Ktorý proces by človek v strese obišiel? A čo by sa stalo, keby útočník nesledoval najviditeľnejší systém, ale ten najpraktickejší?

To je dôvod, prečo má útočné bezpečnostné testovanie stále väčšiu hodnotu. Nie preto, že nájde najkrajšie CVE. Ale preto, že ukáže, či sa z bežného incidentu dokáže stať skutočný problém pre firmu. A apríl dal takýchto príkladov viac než dosť.

Časté otázky

Pre koho je tento April Throwback určený?

Pre bezpečnostné tímy, vývojárov, manažérov IT aj vedenie firiem, ktoré rieši red teaming, penetračné testovanie, NIS2, cloudovú bezpečnosť, DevSecOps alebo bezpečnosť umelej inteligencie.

Prečo sa v článku riešia práve útočné cesty?

Samotný zoznam zraniteľností firme veľa nepovie. Útočná cesta ukazuje, ako by útočník spojil prvotný prístup, tokeny, cloud, CI/CD, identitu, aplikácie a používateľov do reálneho incidentu.

Ako s tým vie Haxoris pomôcť?

Haxoris pomáha firmám preveriť útočnú plochu cez red teaming, penetračné testovanie, testovanie cloudovej a aplikačnej bezpečnosti, kontrolu CI/CD, bezpečnostné cvičenia a praktické odporúčania pre zníženie rizika.

Zdroje a odporúčané čítanie

Súvisiace články

Nečakajte na útočníkov - odhaľte svoje najslabšie miesto s penetračným testom už teraz!

Rezervovať