Většina bezpečnostních příběhů v tomto newsletteru se týká věcí, které se dějí přímo vám: phishingová zpráva, uniklé heslo, falešný nákupní web. Tento je jiný. Níže popsané incidenty se staly vývojářům — lidem, kteří píší aplikace a služby, jež každý den používáte. Důvod, proč sem ale patří, je jednoduchý: když někdo otráví nástroje používané k tvorbě softwaru, jed nezůstane u tvůrce. Odešle se spolu s produktem.

Nedávno se staly dvě věci, které to ilustrují. Ani jedna se nedostala na titulní stránky jako velký únik dat, protože ani v jednom případě nešlo konkrétně o narušení vašich účtů. Oba útoky mířily na řetězec, v němž vzniká software, který si nakonec nainstalujete, otevřete nebo se do něj přihlásíte.

Padělaná rozšíření převlečená za důvěryhodné značky

Open VSX je veřejné tržiště rozšíření pro editory kódu — drobných doplňků, které si vývojáři instalují kvůli automatickému doplňování, lintování a integracím pro nástroje, jež denně používají (Visual Studio Code a několik jeho open source odvozenin z něj čerpá). V období od 26. července do 1. srpna 2026 našli bezpečnostní výzkumníci z Manifold Security v registru 77 padělaných rozšíření. Každé z nich kopírovalo název a jmenný prostor skutečného, důvěryhodného rozšíření, ale bylo zveřejněno z účtu, který původní rozšíření nevlastnil — šlo o klasický pokus vydávat se za někoho jiného, někdy označovaný jako squatování jmenného prostoru.

Zabrané názvy nebyly náhodné. Převzaly identity společností AMD, LEGO Education, Hyperledger, Azure, Artsy, open source projektů Salesforce, jednoho federálního úřadu USA a — v poněkud černě ironickém obratu — samotného tržiště s rozšířeními. Všech 77 balíčků se hlásilo na jedinou doménu, která byla zaregistrována pouhých 11 dní před zveřejněním prvního falešného balíčku. To naznačuje koordinovanou, účelově připravenou kampaň, nikoli oportunistické kopírování.

Většina falešných rozšíření dělala něco poměrně nenápadného: tiše odesílala název hostitele na server útočníka, což samo o sobě mohlo být jen ověřování, kdo návnadu nainstaloval. Výzkumníci však zjistili, že přibližně čtvrtina ze 77 — 19 balíčků — šla dál. Několik sekund po aktivaci shromáždily název hostitele, uživatelské jméno operačního systému, údaje o editoru a ID počítače. Poté přečetly jakýkoli projekt, který měl vývojář otevřený: vzdálený repozitář git (z nějž lze zjistit organizaci a hostitele repozitáře), doménu e-mailu u commitu, aktuální větev a poslední commit. Získaly také hodnoty pro kontinuální integraci — přihlašovací údaje a konfiguraci, které automatizovaným systémům umožňují sestavovat a nasazovat kód bez toho, aby člověk pokaždé ručně zadával heslo.

Žádná z těchto dat nejsou užitečná k vyprázdnění něčího bankovního účtu. Hodí se k něčemu jinému: ke zjištění, pro jaké společnosti vývojář pracuje, jak vypadá jejich interní infrastruktura a jak v ní získat opěrný bod.

Chyba s hodnocením 9,8 z 10 v počítači, který sestavuje software

Druhý incident se týká TeamCity, platformy pro kontinuální integraci a kontinuální doručování (CI/CD) od společnosti JetBrains. Jestliže editor kódu je místem, kde vývojáři software píší, platforma CI/CD je automatizovaná tovární hala, kde se tento kód zkompiluje, otestuje a odešle do produkce — často bez jediného kliknutí člověka na tlačítko „nasadit“. TeamCity je v mnoha společnostech ústřední součástí tohoto mechanismu.

V on-premise verzích TeamCity byla zveřejněna zranitelnost vedená jako CVE-2026-63077, se závažností 9,8 z maximálních 10. Jde o chybu při deserializaci — třídu chyb, kdy program příchozím datům natolik důvěřuje, že je bez předchozí kontroly toho, co skutečně obsahují, přímo převede na spuštěný kód. V praxi to útočníkovi umožňovalo odeslat požadavek na zranitelný server TeamCity bez nutnosti přihlášení a spustit libovolné příkazy se stejnými oprávněními, jaká má samotná služba TeamCity. JetBrains vydala opravy (verze 2025.11.7 a 2026.1.3 a také opravný plugin pro starší instalace od verze 2017.1), ale americký Úřad pro kybernetickou a infrastrukturní bezpečnost (CISA) od té doby varuje, že útočníci aktivně zneužívají neopravené systémy.

Kdo ovládá firemní build server, ovládá to, co daná společnost dodává. Není to hypotéza — to je doslovná funkce tohoto nástroje.

Stejný postup, dvoje různé dveře

Jde o nesouvisející incidenty od různých výzkumníků, ale mají podobný tvar. Ani jeden útok nemíří na hotový produkt. Oba útočí o krok dříve — na editor, v němž vývojář píše kód, nebo na server, který tento kód promění v distribuovanou verzi. To je určující rys útoku na dodavatelský řetězec softwaru: místo prolomení jednoho cíle napadnete něco nadřazeného, na čem závisí mnoho cílů, a necháte jejich vlastnímu důvěryhodnému procesu, aby za vás váš přístup posunul dál.

Stojí za to být upřímní v tom, co zatím nevíme. Ani jedna zpráva zveřejněná tento týden neuvádí potvrzený případ, kdy by v přímém důsledku došlo ke kompromitaci následné aplikace nebo uživatele — kampaň s rozšířeními vypadá jako průzkum a shromažďování přístupů a zneužívání TeamCity je popisováno jako aktivní, avšak bez uvedení konkrétních obětí. To je běžné; kompromitace dodavatelského řetězce se často odhalí u vstupního bodu dlouho předtím, než se podaří dohledat (nebo místo toho, aby se podařilo dohledat) konečný zisk.

Proč je to váš problém, ne jen jejich

Rozšíření pro programování si pravděpodobně nikdy nenainstalujete a server CI/CD provozovat nebudete. Používáte však výstupy stovek takových nástrojů: svou bankovní aplikaci, správce hesel, školní portál svého dítěte i prohlížeč, ve kterém toto čtete. Než se to všechno dostalo do vašeho telefonu, prošlo to editorem nějakého vývojáře a build pipeline nějaké společnosti. Pokud je některý z těchto článků nenápadně kompromitován, může se škodlivá změna svézt spolu s běžnou, rutinní aktualizací softwaru — s takovou, kterou nainstalujete, protože vám bylo řečeno, že aktualizace jsou bezpečné.

Proto také rady v analýze incidentu po úniku dat někdy znějí netechnickým čtenářům podivně: společnost uvede, že její systémy byly napadeny prostřednictvím build serveru, odcizených přihlašovacích údajů vývojáře nebo škodlivé závislosti, a vedle věty „někdo uhodl moje heslo“ to může působit abstraktně. Abstraktní to není. Jde o stejný výsledek — ohrožení vašich dat nebo integrity vaší aplikace — jen k němu došlo dveřmi, o jejichž existenci jste nikdy nevěděli.

Co skutečně pomáhá

Nemůžete prověřovat CI/CD pipeline své banky a ani byste to dělat neměli. Několik návyků však skutečně snižuje vaše vystavení tomuto typu rizika:

Automatické aktualizace ponechte zapnuté, ale nepovažujte aktualizace automaticky za důvěryhodné. Opravy, jako je výše zmíněná oprava TeamCity, se k používanému softwaru dostávají právě prostřednictvím aktualizací — udržování aktuální verze uzavírá okna, která útočníci aktivně zkoušejí. Zároveň je aktualizace jen tak dobrá jako pipeline, která ji vytvořila, a právě ta je zde cílem; proti skutečně otrávené nadřazené verzi neexistuje dokonalá individuální obrana, a proto jde v zásadě o problém na straně dodavatele, nikoli o problém váš.

Pokud pracujete s vývojáři nebo je řídíte, ověřte dvě konkrétní věci: že každé rozšíření pro editor kódu je nainstalováno ze skutečného ověřeného účtu vydavatele, nikoli jen z účtu se shodným názvem (Open VSX a podobná tržiště zobrazují identitu vydavatele — ověřte ji, nespoléhejte pouze na ikonu a název); a pokud vaše organizace provozuje TeamCity on-premise, ještě dnes potvrďte, že používá verzi 2025.11.7, 2026.1.3 nebo že má nainstalovaný opravný plugin, nikoli až při příštím servisním okně — varování CISA znamená, že tato zranitelnost je aktivně zneužívána, nejde o teoretickou možnost.

Pro všechny ostatní je užitečnou změnou prostě informovanost: když čtete o úniku dat ve společnosti, který vede zpět ke „kompromitovanému nástroji vývojáře“ nebo „build systému“, nejde o okrajovou technickou poznámku. Je to stejná kategorie události jako úniky hesel a phishingové podvody, o nichž tento newsletter informuje častěji — jen to začalo o jednu vrstvu výše, dříve než se produkt vůbec dostal k vám.