Szerkesztői megjegyzés: Ez az elemzés Alon Hertz kiberbiztonsági kutató esettanulmánya alapján készült, kibővítve a modern webfejlesztési és kódolási asszisztensekre (pl. Cursor, Claude Code) vonatkozó gyakorlati védelmi lépésekkel.
Az internet történetének nagy részében egy weboldalon lévő szöveges tartalom csupán statikus információ volt: emberek olvasták, keresőmotorok indexelték, de senki sem tekintett rá végrehajtandó parancsként. A kódoló és böngésző AI-ágensek elterjedésével azonban ez az alapfeltevés megdőlt: a puszta dokumentáció közvetlen, végrehajtható kóddá lépett elő a fejlesztői környezetekben.
Mi az az llms.txt és hol keletkezett a rés?
Egyre több technológiai vállalat és nyílt forráskódú projekt helyez el egy llms.txt vagy llms-full.txt nevű fájlt a domainje gyökérkönyvtárában. A Google Lighthouse auditjai által is szorgalmazott fájl célja, hogy strukturált útmutatót nyújtson az AI-ágenseknek: mit érdemes elolvasni, milyen API-kat kell hívni, és milyen csomagokat kell telepíteni egy integráció során.
A kutatás során több mint 8500 ilyen fájlt elemeztek mintegy 6200 aktív domainen (Fortune 500 vállalatoktól kezdve felhőszolgáltatókig). A mintában 237-nél is több olyan hivatkozást találtak, ahol a hivatalos, HTTPS-en kiszolgált vállalati instrukció egy olyan csomagnév telepítését kérte (pip install ..., npm i ...), amelyet senki sem regisztrált a nyilvános csomagkezelőkben (PyPI, npm, crates.io).
Nem elgépelésről (typosquatting) volt szó: a hivatalos leírás pontosan megnevezett egy csomagot, a hozzá tartozó névteret viszont a cég sosem foglalta le.
A támadás mechanizmusa: 4 perc a vállalati belső hálózatig
A kutatók regisztráltak néhányat az érintett csomagnevek közül a PyPI és npm felületein, bennük egy ártalmatlan, kizárólag a telepítés tényét jelző visszahívással (phone-home beacon).
- Az első visszajelzés kevesebb mint 4 perc alatt futott be egy több százmilliárd dolláros Fortune 500-as cég infrastruktúrájából.
- Egy órán belül újabb multinacionális vállalatok fejlesztői gépei futtatták le az ismeretlen forrású csomagot.
- A folyamathoz nem volt szükség sem kártékony prompt injectionre, sem phishre, sem pedig ismert szoftverhibára (CVE).
Az AI kódoló ágensek a legegyszerűbb promptra (pl. “Készíts egy projektet az adott cég SDK-jával a hivatalos dokumentáció alapján”) maguktól keresték meg a megbízhatónak ítélt llms.txt fájlt, és kritika nélkül lefuttatták a benne szereplő csomagkezelő parancsot.
Éles incidens a vadonban: A Clerk-eset (MAL-2026-11069)
A kockázat nem csupán elméleti. Az elemzés rávilágított egy éles, aktív támadásra is:
A széles körben használt Clerk autentikációs szolgáltató AI-nak szánt útmutatója az npx clerk-next-fix-auth-protection parancs futtatását javasolta. A parancssori bináris eredetileg a scoped @clerk/eslint-plugin csomag része volt. Ha egy környezetben a fő csomag még nem volt helyileg telepítve, az npx automatikusan a globális, nyilvános npm registry-ben kereste a névnek megfelelő önálló csomagot.
Mivel ezt a nevet a Clerk nem publikálta önálló csomagként, egy támadó lefoglalta, és egy automatikusan lefutó adatgyűjtő kártevőt ágyazott bele. A csomag minden futáskor elküldte a fejlesztői gép felhasználónevét, gépnevét és munkakönyvtárát egy külső szerverre. A sebezhetőséget MAL-2026-11069 néven jegyezték be (CWE-506). A Clerk a felelős bejelentést követően azonnal javította az eljárásrendet.
Miért hatástalanok a hagyományos védelmi vonalak?
A hagyományos vállalati végpontvédelmi (EDR) rendszerek és kimenő proxyk szemszögéből az eseménylánc teljesen ártalmatlannak tűnik:
- A hivatalos fejlesztői AI-eszköz megnyit egy hiteles, HTTPS-en keresztül kiszolgált partnermenedzsment- vagy cégoldalt.
- A terminálban lefut egy legitim csomagkezelő parancs (pip vagy npm).
- A letöltés egy engedélyezett, globális csomagtárból (pypi.org, npmjs.org) érkezik.
A biztonsági lánc ott csuklik össze, hogy az adat és a kód közötti határ elmosódott: az AI-ágensek a külső szöveges tartalmat közvetlen utasításként értelmezik.
Gyakorlati védekezés két fronton
1. Fejlesztői és felhasználói oldal (AI asszisztensekkel dolgozva)
- Terminal Command Review: Kapcsold ki az AI ágensek teljesen autonóm terminál-végrehajtását. Minden külső csomagtelepítést (
npm i,npx,pip) emberi felülvizsgálatnak kell megelőznie. - Gyanús csomagok ellenőrzése: Ha egy asszisztens ritkán látott vagy furcsa nevű segédeszköz futtatását kéri, ellenőrizd a csomag adatlapját a registry-ben (publikálás dátuma, heti letöltésszám, karbantartó profilja).
- Konténerizált környezet: Autonóm ágensek futtatását érdemes Docker konténerbe vagy szeparált virtuális gépbe zárni, megvédve a fejlesztői gép érzékeny környezeti változóit (
.env, SSH kulcsok).
2. Projektgazdai és közzétevői oldal (Dokumentáció és API publikálás)
- Névtér-eltérítés (Namespace Squatting) megelőzése: Ha a nyilvános dokumentációdban, README-ben vagy llms.txt-dben megemlítesz egy parancsot, a nevet azonnal foglald le az adott nyilvános csomagtárban.
- Helyfoglaló (placeholder) csomag közzététele: Amennyiben a parancs egy belső eszközt jelöl, tölts fel egy üres csomagot, majd jelöld meg elavultként:
mkdir my-internal-tool && cd my-internal-tool
npm init -y
echo "console.warn('Security placeholder package.');" > index.js
npm publish
npm deprecate my-internal-tool "SECURITY PLACEHOLDER - DO NOT USE"- Aldomainek és külső linkek auditja: Rendszeresen vizsgáld felül az llms.txt-ben szereplő linkeket. A megszűnt, törölt felhőszolgáltatós aldomaineket (pl. elhagyott Vercel, Fly vagy Render címek) támadók könnyen újraregisztrálhatják.
Források és hivatkozások
- Alon Hertz eredeti kutatása: Data Became Code: We Ran Code Inside Fortune 500s Using Files They Published for AI Agents (Medium, 2026. augusztus)
- Kártékony csomag biztonsági adatlapja: OSV / Amazon Inspector adatbázis – MAL-2026-11069 (CWE-506: Embedded Malicious Code)
- LLMs.txt szabvány és audit: Google Chrome DevTools / Lighthouse Agentic Browsing Audits (developer.chrome.com/docs/lighthouse/agentic-browsing/llms-txt)
- Kapcsolódó vizsgálati eszköz: What Would AI Do Project