Több mint 135 000 OpenClaw-példány van kitéve az interneten. Egy kritikus sebezhetőség lehetővé teszi a távoli kódfuttatást egyetlen kattintással bármely böngészőből. Kutatók több mint 1100 rosszindulatú skillt fedeztek fel, amelyek Atomic Stealert terjesztenek a ClawHub-on. A Microsoft publikált egy „Running OpenClaw Safely” című blogbejegyzést, amely azzal nyit, hogy „a legtöbb környezetben a megfelelő döntés az lehet, hogy nem telepítjük.” Belgium nemzeti kiberbiztonsági központja kormányzati figyelmeztetést adott ki. A Cisco a személyes AI-ügynököket, mint az OpenClaw, „biztonsági rémálomnak” nevezte.

Ez nem rémhírterjesztés. Ezek független biztonsági kutatók, nagyvállalati szállítók és kormányzati szervek tényei. Ha Ön OpenClaw-példányt üzemeltet, ez Önt is érinti.

Mi ment rosszul

Az OpenClaw a localhost-ra lett tervezve. Telepíted a gépedre, kommunikálsz vele egy helyi webes felületen keresztül, és ő elvégzi a feladatokat a nevedben. A biztonsági modell feltételezte, hogy a felületet elérő személy az, aki a billentyűzet előtt ül.

Aztán az OpenClaw néhány hét alatt 9000-ről több mint 200 000 GitHub-csillagra ugrott. Az emberek VPS szerverekre telepítették, kitették az internetre és összekapcsolták az üzenetküldő csatornáikkal. A localhost-feltételezés nagy léptékben összeomlott. (A telepítési lehetőségek teljes spektrumát és biztonsági kompromisszumaikat egy külön útmutatóban tárgyaltuk.)

CVE-2026-25253: távoli kódfuttatás egyetlen kattintással

A legsúlyosabb sebezhetőség a CVE-2026-25253, CVSS pontszáma 8.8. Az OpenClaw nem validálta a WebSocket origin fejléceket. Így működik a támadás:

  1. Az áldozat meglátogat egy rosszindulatú weboldalt (vagy egy rosszindulatú hirdetést tartalmazó oldalt).
  2. Az oldalon lévő JavaScript WebSocket-kapcsolatot nyit a localhost:18789 felé, az OpenClaw alapértelmezett portjára.
  3. Mivel a böngésző ugyanazon a gépen van, a kapcsolat megkerüli az összes tűzfalszabályt.
  4. A támadó a WebSocket-en keresztül kijuttatja a gateway hitelesítési tokent.
  5. A tokennel a támadó teljes irányítást kap: shell hozzáférés, fájlok olvasása/írása és parancsok végrehajtása.

A localhost-hoz kötés nem segít. A támadás az áldozat saját böngészőjén keresztül működik. A SOCRadar elemzése végigvezet a teljes láncon.

Rosszindulatú skill-ek és ellátási lánc támadások

A kutatók 341 rosszindulatú skillt találtak a ClawHub-on február elején. Ez a szám azóta több mint 1100-ra nőtt. A ClawHavoc kampány Atomic Stealert terjeszt olyan skill-eken keresztül, amelyek legitimnek tűnnek, de rejtett parancs-végrehajtási lépéseket tartalmaznak. A skill-ek Markdown fájlok. Egy rejtett utasítás, amely azt mondja „futtasd ezt a shell parancsot”, könnyen beágyazható és nehezen észlelhető.

Február 17-én a Cline ellátási lánc támadás még tovább ment. Egy kompromittált npm tokent használtak a Cline CLI egy olyan verziójának kiadására, amely csendben telepítette az OpenClaw-t a fejlesztők gépeire. A támadás magát a build pipeline-t célozta.

A kutatók azóta hat további sebezhetőséget hoztak nyilvánosságra az OpenClaw magjában, köztük a CVE-2026-27001-et. Az OWASP Top 10 Ágens Alkalmazásokhoz ma már ezeknek a mintáknak a nagy részét is felsorolja fő kockázatként. Ahogy a Conscia elemzése fogalmaz: ez egy teljes körű biztonsági válság.

Miért nem elég egy gateway token

Az OpenClaw beépített hitelesítése egy statikus token. Egyszer állítod be, és minden kérésnek tartalmaznia kell. Jobb, mint a semmi. De alapvető korlátai vannak.

A statikus tokenek nem járnak le. Ha egy token kiszivárog (a CVE-2026-25253-on, logokon vagy egy környezeti változókat olvasó rosszindulatú skill-en keresztül), a támadó állandó hozzáférést kap, amíg észre nem veszi és manuálisan nem rotálja.

A statikus tokenek hatóköre nem korlátozható. A gateway token teljes hozzáférést biztosít. Nincs lehetőség csak olvasási hozzáférést adni vagy korlátozni, mit tehet egy hitelesített munkamenet.

A statikus tokenek nem köthetők felhasználóhoz. Ha három személy oszt meg egy tokent, nincs audit nyom arról, ki mit csinált.

A legtöbb VPS telepítési útmutató azt javasolja, hogy az OpenClaw-t nginx mögé tegyük alapszintű hitelesítéssel. Ez jobb, de továbbra is statikus hitelesítő adat. Ha valaki megszerzi (hálózati lehallgatás titkosítatlan kapcsolaton, kompromittált reverse proxy konfiguráció, kiszivárgott .htpasswd fájl), hozzáférést kap.

Az alapvető probléma mélyebb: a hitelesítés az alkalmazáson belül történik. Ha az alkalmazásnak sebezhetősége van, a hitelesítés megkerülhető. A CVE-2026-25253 pontosan ezt demonstrálta. A gateway token létezett. A sebezhetőség kinyerte, mielőtt az alkalmazásnak egyáltalán esélye lett volna ellenőrizni.

Ezért építettük az OpenClaw.rocks-ot proxy szintű hitelesítéssel. A következő szakaszok részletesen ismertetik az architektúrát. Ha egyszerűen biztonságos példányt szeretne anélkül, hogy mindezt saját maga építené fel, tekintse meg csomagjainkat.

Hogyan biztosítjuk a gateway-t

Az OpenClaw.rocks-nál a hitelesítés a proxy rétegben történik, mielőtt a kérés elérné az OpenClaw podot. Ez strukturális különbség, nem csupán konfigurációs.

Íme a háromrétegű architektúra.

Amikor az OpenClaw.rocks irányítópulton keresztül éri el OpenClaw-példányát, a szerver egy aláírt cookie-t generál. A formátum a következő:

{expiry}.{userId}.{instanceId}.{hmac_base64url}

A cookie 4 órás TTL-lel rendelkezik, és 45 percenként automatikusan megújul. Útvonalhoz kötött a /gw/{instanceId} elérési útra, így egy cookie nem használható más példány eléréséhez. HttpOnly (a JavaScript nem tudja olvasni), Secure (csak HTTPS-en keresztül küldött) és SameSite=Lax (cross-origin kéréseknél nem küldött). A HMAC időzítés-biztos összehasonlítással kerül ellenőrzésre az időzítési támadások megelőzése érdekében.

Még ha valaki el is kapja a cookie értékét, nem tud újat hamisítani az aláíró titok nélkül. És maga a cookie nem tartalmaz olyan hitelesítő adatokat, amelyek közvetlen hozzáférést biztosítanának az OpenClaw-hoz.

2. réteg: Traefik ForwardAuth

Az OpenClaw-példányokhoz intézett minden kérés a Traefik-en, a reverse proxy-nkon halad át. A kérés továbbítása előtt a Traefik meghív egy auth-gate végpontot, amely ellenőrzi az aláírt cookie-t.

Ez tiszta HMAC-ellenőrzés. Nulla adatbázis-hívás. Nulla hálózati kérés a Supabase-hez vagy bármely más szolgáltatáshoz. A döntés mikroszekundumok alatt megszületik.

Ha a cookie érvénytelen, lejárt vagy hiányzik, a kérés a proxy rétegben kerül elutasításra. A kérés soha nem éri el az OpenClaw-t. Ez a kulcskülönbség. Egy tipikus beállításban magának az OpenClaw-nak kell eldöntenie, hogy engedélyez vagy elutasít egy kérést. Ha az OpenClaw-nak sebezhetősége van a hitelesítési logikájában, a támadó átsiklhat. A mi beállításunkban az OpenClaw soha nem lát hitelesítetlen forgalmat.

3. réteg: Gateway token injektálás

Minden OpenClaw-példány rendelkezik beépített gateway tokennel. Ez ugyanaz a token, amelyet Ön is beállítana, ha saját maga hosztolna. A különbség abban van, hogyan jut el a podhoz.

Egy tipikus self-hosting beállításban beilleszti a tokent egy konfigurációs fájlba, esetleg egy környezeti változóban tárolja, és reméli, hogy soha nem szivárog ki. A böngészőnek minden kérésnél el kell küldenie, ami pontosan az a módszer, amellyel a CVE-2026-25253 kinyerte.

A mi beállításunkban egy kriptográfiailag véletlenszerű 32 bájtos token generálódik a példány létrehozásakor, és Kubernetes Secret-ként tárolódik. A Traefik Authorization fejlécként injektálja minden továbbított kéréshez. A böngésző soha nem látja. Soha nem jelenik meg egy konfigurációs fájlban, amelyet véletlenül commitolhatna. Soha nem utazik egy WebSocket-en, amelyet egy rosszindulatú oldal eltéríthetne. A token létezik, de teljes egészében a klaszteren belül él, csak a Traefik és a pod között mozog.

Miért blokkolja ez az architektúra a CVE-2026-25253-at

A CVE-2026-25253 támadási lánca a gateway tokent WebSocket-en keresztül juttatja ki. Nézzük végig, mi történik, ha ez a támadás egy OpenClaw.rocks-példányt céloz:

  1. A támadó JavaScript-je megpróbál WebSocket-et nyitni az OpenClaw podhoz.
  2. A kapcsolat először a Traefik-et éri el. A Traefik ellenőrzi az aláírt cookie-t.
  3. A rosszindulatú oldal más originen van. A SameSite=Lax cookie nem küldődik cross-origin WebSocket-kapcsolatoknál. A kérés elutasításra kerül.
  4. Még ha a cookie valahogy csatolva lenne is, a támadó oldala nem tudja olvasni (HttpOnly). Nincs mit kijuttatni.
  5. Még ha a cookie ki is szivárogna, nem tartalmazza a bearer tokent. A bearer tokent a Traefik injektálja, soha nem kerül a böngésző elé. A támadó nem tudja rekonstruálni.

Nincs mit ellopni, mert a böngésző soha nem birtokolja a valódi hitelesítő adatokat. A támadási felület, amelyet a CVE-2026-25253 kihasznál, egyszerűen nem létezik.

OpenClaw biztonsági ellenőrzőlista önálló hosztolóknak

Nem mindenki akar menedzselt hosztolást, és ez rendben van. Ha saját OpenClaw-példányt üzemeltet, íme egy gyakorlati ellenőrzőlista 2026-ra.

Engedélyezve van a gateway hitelesítési token? Futtassa az openclaw doctor parancsot az ellenőrzéshez. Ha a gateway hitelesítés ki van kapcsolva, bárki, aki eléri a 18789-es portot, irányítja az ügynökét és mindent, amihez hozzáfér.

A példánya reverse proxy mögött van TLS-sel? A titkosítatlan HTTP azt jelenti, hogy bárki a hálózati útvonalon olvashatja a gateway tokenjét. Használjon nginx-et, Caddy-t vagy Traefik-et érvényes TLS tanúsítvánnyal. A Let’s Encrypt ingyenes.

A legújabb verziót futtatja? A CVE-2026-25253 a v2026.1.29-ben lett javítva. A CVE-2026-27001 a v2026.2.15-ben lett javítva. Ha régebbi verziót futtat, frissítsen most. Az Adversa AI keményítési útmutató további lépéseket ismertet.

Auditálta a telepített skill-jeit? A ClawHavoc kampány kifejezetten a ClawHub-ot célozta. Ellenőrizze minden telepített skill-jét. Ha nem Ön telepítette, távolítsa el és ellenőrizze a forrást.

A reverse proxy-ja validálja a WebSocket origineket? Ez az a konkrét vektor, amelyet a CVE-2026-25253 kihasznált. A reverse proxy-jának el kell utasítania a váratlan originekről érkező WebSocket upgrade kéréseket. Az OpenClaw biztonsági dokumentációja konfigurációs példákat tartalmaz.

A hitelesítés azelőtt vagy azután történik, hogy a kérés eléri az OpenClaw-t? Ez a legfontosabb kérdés. Ha az OpenClaw kezeli a saját hitelesítését, az OpenClaw egy sebezhetősége megkerülheti. Ha a reverse proxy kezeli a hitelesítést, a kérés soha nem éri el az OpenClaw-t, hacsak már nem lett ellenőrizve.

Amit nem oldunk meg

Az őszinteség fontos itt. A proxy szintű hitelesítés megoldja a gateway biztonságát. Nem old meg mindent.

A prompt injection alkalmazásszintű probléma. Egy ügyesen megírt üzenet potenciálisan rávehet egy ügynököt nem szándékolt cselekvésekre. Ez aktív kutatási terület az egész AI-iparágban, és egyetlen hosztolási szolgáltató sem tudja ma teljesen megakadályozni.

A rosszindulatú skill viselkedés az ügynök kontextusában fut. Ha telepít egy skillt, amely engedélyezett HTTPS kimenő forgalmon keresztül juttat ki adatokat, a proxy hitelesítés nem tudja megállítani. Amit az infrastruktúránk tesz, az a robbanási sugár korlátozása: minden példány saját Kubernetes podban fut hálózati izolációval, csökkentett capability-kkel, seccomp-pal és csak olvasható root fájlrendszerrel. Egy kompromittált ügynök nem érheti el a többi ügynököt vagy a gazdarendszert. A Kubernetes operátor ezeket az alapértelmezéseket érvényesíti minden példányra.

Az LLM szolgáltató iránti bizalom a csomagjától függ. Ha saját API-kulcsokat használ (Light csomag), a beszélgetései az Ön által beállított szolgáltatón mennek keresztül, és annak adatvédelmi irányelvei érvényesek. A Pro csomagban a forgalmat a saját AI gateway-ünkön irányítjuk át előre konfigurált szolgáltatókkal. Nem kell átadnia API-kulcsait egy OpenClaw-példánynak, és nem kell bíznia abban, hogy egy harmadik fél kulcsa biztonságosan van tárolva. A gateway kezeli a szolgáltatói hitelesítő adatokat az Ön nevében, és Ön soha nem látja vagy kezeli azokat közvetlenül.

A biztonság rétegekből áll. Mi az infrastruktúra rétegeket kezeljük. Az alkalmazásszintű kihívások valósak, és érdemes megérteni őket.

A biztonság architektúrai döntés

Az OpenClaw biztonsági válsága nem egyetlen CVE-ről vagy egyetlen rosszindulatú skill-csoportról szól. Egy localhost-ra tervezett eszközről szól, amelyet százezrek telepítenek az internetre, olyan hitelesítéssel, amely azon az alkalmazáson belül történik, amelyet védenie kellene.

A hitelesítés áthelyezése a proxy rétegbe nem funkció. Architektúrai döntés. Azt jelenti, hogy amikor a következő OpenClaw CVE megjelenik (és meg fog), a hitelesített kérések továbbra is ellenőrzésre kerülnek, mielőtt elérnék az alkalmazást. A támadási felület strukturálisan kisebb.

Ezt a döntést az első napon hoztuk meg. Minden OpenClaw.rocks-példány aláírt cookie-k, ForwardAuth-ellenőrzés és példányonkénti bearer tokenek mögött fut. Nincsenek gateway tokenek a böngészőben. Nincsenek statikus hitelesítő adatok, amelyeket ki lehetne juttatni. Nincs hitelesítési logika a sebezhető alkalmazáson belül.

Ha többet szeretne olvasni arról, hogyan telepítjük az OpenClaw-t Kubernetes-re teljes biztonsági keményítéssel, a telepítési útmutató részletesen tárgyalja.

Ha egyszerűen csak egy működő ügynököt szeretne, amely biztonságos marad anélkül, hogy bármelyikre is gondolnia kellene, pontosan ezt építettük.

Kezdje el az OpenClaw.rocks-on vagy fedezze fel a nyílt forráskódú Kubernetes operátort, ha inkább saját infrastruktúrát szeretne üzemeltetni.