Vairāk nekā 135 000 OpenClaw instanču ir atklāti pieejamas internetā. Kritiska ievainojamība ļauj veikt attālinātu koda izpildi ar vienu klikšķi caur jebkuru pārlūkprogrammu. Pētnieki ir atraduši vairāk nekā 1100 ļaunprātīgu prasmju, kas izplata Atomic Stealer platformā ClawHub. Microsoft publicēja emuāra ierakstu ar nosaukumu “Running OpenClaw Safely”, kas sākas ar norādi, ka “lielākajai daļai vižu pareizais lēmums var būt to neizvietot.” Beļģijas Nacionālais kiberdrošības centrs izdeva valdības brīdinājumu. Cisco nosauca personīgos AI aģentus, piemēram, OpenClaw, par “drošības murgu.”

Tas nav biedēšana. Tie ir fakti no neatkarīgiem drošības pētniekiem, uzņēmumu piegādātājiem un valsts iestādēm. Ja jūs darbināt OpenClaw instanci, tas jūs skar.

Kas nogāja greizi

OpenClaw tika izstrādāts darbam uz localhost. Jūs to instalējat savā datorā, sazināties ar to caur lokālo tīmekļa saskarni, un tas veic darbības jūsu vārdā. Drošības modelis pieņēma, ka persona, kas piekļūst saskarnei, ir persona, kas sēž pie tastatūras.

Tad OpenClaw no 9000 pieauga līdz vairāk nekā 200 000 GitHub zvaigznēm dažu nedēļu laikā. Cilvēki to izvietoja uz VPS mašīnām, atklāja internetam un savienoja ar saviem ziņojumu kanāliem. Localhost pieņēmums sabojājās mērogā. (Mēs apskatījām pilnu izvietošanas iespēju spektru un to drošības kompromisus atsevišķā ceļvedī.)

CVE-2026-25253: viena klikšķa attālināta koda izpilde

Vissmagākā ievainojamība ir CVE-2026-25253, novērtēta ar CVSS 8.8. OpenClaw nevalidēja WebSocket izcelsmes galvenes. Lūk, kā uzbrukums darbojas:

  1. Upuris apmeklē ļaunprātīgu tīmekļa lapu (vai lapu ar ļaunprātīgu reklāmu).
  2. JavaScript šajā lapā atver WebSocket savienojumu uz localhost:18789, noklusējuma OpenClaw portu.
  3. Tā kā pārlūkprogramma atrodas tajā pašā datorā, savienojums apiet jebkurus ugunsmūra noteikumus.
  4. Uzbrucējs izfiltrē vārtejas autentifikācijas tokenu caur WebSocket.
  5. Ar tokenu uzbrucējam ir pilna kontrole: čaulas piekļuve, failu lasīšana/rakstīšana un komandu izpilde.

Saistīšana ar localhost nepalīdz. Uzbrukums pivotē caur paša upura pārlūkprogrammu. SOCRadar analīze iziet cauri pilnajai ķēdei.

Ļaunprātīgas prasmes un piegādes ķēdes uzbrukumi

Pētnieki atrada 341 ļaunprātīgu prasmi ClawHub februāra sākumā. Kopš tā laika šis skaits ir pieaudzis līdz vairāk nekā 1100. ClawHavoc kampaņa izplata Atomic Stealer caur prasmēm, kas izskatās leģitīmas, bet satur slēptus komandu izpildes soļus. Prasmes ir Markdown faili. Slēptu instrukciju, kas saka “izpildi šo čaulas komandu”, ir viegli iegult un grūti pamanīt.

  1. februārī Cline piegādes ķēdes uzbrukums visu pacēla jaunā līmenī. Kompromitēts npm tokens tika izmantots, lai publicētu Cline CLI versiju, kas klusi instalēja OpenClaw izstrādātāju datoros. Uzbrukums bija vērsts pret pašu būvēšanas cauruļvadu.

Pētnieki tagad ir atklājuši sešas papildu ievainojamības OpenClaw kodolā, ieskaitot CVE-2026-27001. OWASP Top 10 aģentu lietojumprogrammām tagad iekļauj daudzus no šiem modeļiem kā galvenos riskus. Kā Conscia analīze to formulē, tā ir pilnvērtīga drošības krīze.

Kāpēc vārtejas tokens nav pietiekams

OpenClaw iebūvētā autentifikācija ir statisks tokens. Jūs to iestatāt vienreiz, un katram pieprasījumam tas jāiekļauj. Tas ir labāk nekā nekas. Bet tam ir fundamentāli ierobežojumi.

Statiskie tokeni neterminējas. Ja tokens noplūst (caur CVE-2026-25253, caur žurnālfailiem, caur ļaunprātīgu prasmi, kas nolasa vides mainīgos), uzbrucējam ir pastāvīga piekļuve, līdz jūs to pamanāt un manuāli nomainīsiet.

Statiskos tokenus nevar ierobežot. Vārtejas tokens piešķir pilnu piekļuvi. Nav iespējas piešķirt kādam tikai lasīšanas piekļuvi vai ierobežot, ko autentificēta sesija var darīt.

Statiskos tokenus nevar sasaistīt ar lietotāju. Ja trīs cilvēki koplieto tokenu, jums nav audita izsekojamības par to, kurš ko darīja.

Lielākā daļa VPS izvietošanas ceļvežu iesaka novietot OpenClaw aiz nginx ar pamata autentifikāciju. Tas ir labāk, bet joprojām ir statisks akreditācijas dokuments. Ja kāds to pārtver (tīkla noklausīšanās nešifrētā savienojumā, kompromitēta reversā starpniekservera konfigurācija, noplūdis .htpasswd fails), viņš ir iekšā.

Fundamentālā problēma ir dziļāka: autentifikācija notiek lietojumprogrammas iekšienē. Ja lietojumprogrammai ir ievainojamība, autentifikāciju var apiet. CVE-2026-25253 to precīzi demonstrēja. Vārtejas tokens eksistēja. Ievainojamība to izfiltrēja, pirms lietojumprogramma vispār ieguva iespēju to verificēt.

Tāpēc mēs izveidojām OpenClaw.rocks ar autentifikāciju starpniekservera līmenī. Turpmākās sadaļas detalizēti izskaidro arhitektūru. Ja vēlaties drošu instanci, to neveidojot pats, skatiet mūsu plānus.

Kā mēs nodrošinām vārteju

OpenClaw.rocks autentifikācija notiek starpniekservera līmenī, pirms pieprasījums vispār sasniedz OpenClaw podu. Tā ir strukturāla atšķirība, nevis tikai konfigurācijas atšķirība.

Lūk, trīs līmeņu arhitektūra.

1. līmenis: Parakstītas vārtejas sīkdatnes (HMAC-SHA256)

Kad jūs piekļūstat savai OpenClaw instancei caur OpenClaw.rocks paneli, serveris ģenerē parakstītu sīkdatni. Formāts ir:

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

Sīkdatnei ir 4 stundu derīguma termiņš un tā automātiski atjaunojas ik pēc 45 minūtēm. Tā ir ierobežota uz ceļu /gw/{instanceId}, tāpēc vienu sīkdatni nevar izmantot piekļuvei citai instancei. Tā ir HttpOnly (JavaScript to nevar nolasīt), Secure (tiek nosūtīta tikai caur HTTPS) un SameSite=Lax (netiek nosūtīta starpdomēnu pieprasījumos). HMAC tiek verificēts, izmantojot laika drošu salīdzināšanu, lai novērstu laika uzbrukumus.

Pat ja kāds pārtver sīkdatnes vērtību, viņš nevar viltot jaunu bez parakstīšanas noslēpuma. Un pati sīkdatne nesatur akreditācijas datus, kas tieši piešķir piekļuvi OpenClaw.

2. līmenis: Traefik ForwardAuth

Katrs pieprasījums OpenClaw instancei iet caur Traefik, mūsu reverso starpniekserveri. Pirms pieprasījuma pārsūtīšanas Traefik izsauc auth-gate galapunktu, kas verificē parakstīto sīkdatni.

Tā ir tīra HMAC verifikācija. Nulle datubāzes izsaukumu. Nulle tīkla pieprasījumu uz Supabase vai jebkuru citu pakalpojumu. Lēmums tiek pieņemts mikrosekundēs.

Ja sīkdatne ir nederīga, beigusies vai trūkst, pieprasījums tiek noraidīts starpniekservera līmenī. Pieprasījums nekad nesasniedz OpenClaw. Tā ir galvenā atšķirība. Tipiskā konfigurācijā OpenClaw pašam jāizlemj, vai atļaut vai noraidīt pieprasījumu. Ja OpenClaw ir ievainojamība autentifikācijas loģikā, uzbrucējs var izslīdēt cauri. Mūsu konfigurācijā OpenClaw nekad neredz neautentificētu trafiku.

3. līmenis: Vārtejas tokena injekcija

Katrai OpenClaw instancei ir iebūvēts vārtejas tokens. Tas ir tas pats tokens, ko jūs konfigurētu paši, ja mitinātu paši. Atšķirība ir tajā, kā tas nonāk podā.

Tipiskā pašmitināšanas konfigurācijā jūs ielīmējat tokenu konfigurācijas failā, varbūt saglabājat to vides mainīgajā un cerat, ka tas nekad nenoplūdīs. Jūsu pārlūkprogrammai tas jānosūta ar katru pieprasījumu, kas ir tieši tas, kā CVE-2026-25253 to izfiltrēja.

Mūsu konfigurācijā kriptogrāfiski nejaušs 32 baitu tokens tiek ģenerēts instances izveidošanas brīdī un saglabāts kā Kubernetes Secret. Traefik to injicē kā Authorization galveni katrā pārsūtītajā pieprasījumā. Pārlūkprogramma to nekad neredz. Tas nekad neparādās konfigurācijas failā, ko jūs varētu nejauši iekļaut versiju kontrolē. Tas nekad nepārvietojas caur WebSocket, ko ļaunprātīga lapa var nolaupīt. Tokens eksistē, bet tas dzīvo pilnībā klastera iekšienē, pārvietojoties tikai starp Traefik un podu.

Kāpēc šī arhitektūra bloķē CVE-2026-25253

CVE-2026-25253 uzbrukuma ķēde izfiltrē vārtejas tokenu caur WebSocket. Apskatīsim, kas notiek, kad šis uzbrukums tiek vērsts pret OpenClaw.rocks instanci:

  1. Uzbrucēja JavaScript mēģina atvērt WebSocket savienojumu ar OpenClaw podu.
  2. Savienojums vispirms sasniedz Traefik. Traefik pārbauda parakstīto sīkdatni.
  3. Ļaunprātīgā lapa ir citā izcelsmes punktā. SameSite=Lax sīkdatne netiek nosūtīta starpdomēnu WebSocket savienojumos. Pieprasījums tiek noraidīts.
  4. Pat ja sīkdatne kaut kā tiktu pievienota, uzbrucēja lapa to nevar nolasīt (HttpOnly). Nav ko izfiltrēt.
  5. Pat ja sīkdatne noplūstu, tā nesatur nesēja tokenu. Nesēja tokens tiek injicēts ar Traefik, nekad netiek atklāts pārlūkprogrammai. Uzbrucējs to nevar rekonstruēt.

Nav ko nozagt, jo pārlūkprogramma nekad neglabā īstos akreditācijas datus. Uzbrukuma virsma, ko CVE-2026-25253 izmanto, vienkārši neeksistē.

OpenClaw drošības kontrolsaraksts pašmitinātājiem

Ne visi vēlas pārvaldītu mitināšanu, un tas ir labi. Ja jūs darbināt savu OpenClaw instanci, šeit ir praktisks kontrolsaraksts 2026. gadam.

Vai jūsu vārtejas autentifikācijas tokens ir iespējots? Palaidiet openclaw doctor, lai pārbaudītu. Ja vārtejas autentifikācija ir atspējota, jebkurš, kas var sasniegt portu 18789, kontrolē jūsu aģentu un visu, kam tam ir piekļuve.

Vai jūsu instance ir aiz reversā starpniekservera ar TLS? Vienkāršs HTTP nozīmē, ka jebkurš tīkla ceļā var nolasīt jūsu vārtejas tokenu tranzītā. Izmantojiet nginx, Caddy vai Traefik ar derīgu TLS sertifikātu. Let’s Encrypt ir bezmaksas.

Vai jūs izmantojat jaunāko versiju? CVE-2026-25253 tika izlabots v2026.1.29. CVE-2026-27001 tika izlabots v2026.2.15. Ja jūs darbināt vecāku versiju, atjauniniet tagad. Adversa AI nostiprināšanas ceļvedis aptver papildu soļus.

Vai esat pārbaudījuši savas instalētās prasmes? ClawHavoc kampaņa bija vērsta tieši pret ClawHub. Pārbaudiet katru instalēto prasmi. Ja jūs to neinstalējāt paši, noņemiet to un verificējiet avotu.

Vai jūsu reversais starpniekserveris validē WebSocket izcelsmes? Tas ir konkrētais vektors, ko CVE-2026-25253 izmantoja. Jūsu reversajam starpniekserverim jānoraida WebSocket uzlabošanas pieprasījumi no negaidītām izcelsmēm. OpenClaw drošības dokumentācijā ir konfigurācijas piemēri.

Vai jūsu autentifikācija notiek pirms vai pēc pieprasījuma sasniegšanas OpenClaw? Tas ir jautājums, kas ir vissvarīgākais. Ja OpenClaw pats apstrādā savu autentifikāciju, ievainojamība OpenClaw var to apiet. Ja jūsu reversais starpniekserveris apstrādā autentifikāciju, pieprasījums nekad nesasniedz OpenClaw, ja vien tas jau nav verificēts.

Ko mēs nerisinām

Godīgums ir svarīgs. Starpniekservera līmeņa autentifikācija risina vārtejas drošību. Tā nerisina visu.

Uzvednes injekcija ir lietojumprogrammas līmeņa problēma. Prasmīgi formulēts ziņojums var potenciāli apmānīt aģentu veikt neparedzētas darbības. Tā ir aktīva pētniecības joma visā AI nozarē, un neviens mitināšanas pakalpojumu sniedzējs to šodien nevar pilnībā novērst.

Ļaunprātīga prasmju uzvedība darbojas aģenta kontekstā. Ja jūs instalējat prasmi, kas izfiltrē datus caur atļautu HTTPS izeju, starpniekservera autentifikācija to nevar apturēt. Ko mūsu infrastruktūra dara, ir ierobežo sprādziena rādiusu: katra instance darbojas savā Kubernetes podā ar tīkla izolāciju, atmestām iespējām, seccomp un tikai lasāmu saknes failu sistēmu. Kompromitēts aģents nevar sasniegt citus aģentus vai resursdatora sistēmu. Kubernetes operators ievieš šos noklusējumus katrai instancei.

LLM pakalpojumu sniedzēja uzticamība ir atkarīga no jūsu plāna. Ja jūs izmantojat savas API atslēgas (Light plāns), jūsu sarunas iet caur to pakalpojumu sniedzēju, ko jūs konfigurējat, un tiek piemērota viņu konfidencialitātes politika. Pro plānā mēs maršrutējam trafiku caur mūsu AI vārteju ar iepriekš konfigurētiem pakalpojumu sniedzējiem. Jums nav jānodod savas API atslēgas OpenClaw instancei vai jāuzticas, ka trešās puses atslēga tiek droši glabāta. Vārteja pārvalda pakalpojumu sniedzēju akreditācijas datus jūsu vārdā, un jūs tos nekad neredzat un neapstrādājat tieši.

Drošība ir slāņi. Mēs apstrādājam infrastruktūras slāņus. Lietojumprogrammas līmeņa izaicinājumi ir reāli un tos ir vērts saprast.

Drošība ir arhitektūras lēmums

OpenClaw drošības krīze nav par vienu CVE vai vienu ļaunprātīgu prasmju partiju. Tā ir par rīku, kas izstrādāts priekš localhost, ko simtiem tūkstošu cilvēku izvieto internetā, ar autentifikāciju, kas notiek tās lietojumprogrammas iekšienē, kuru tai vajadzētu aizsargāt.

Autentifikācijas pārvietošana uz starpniekservera līmeni nav funkcija. Tas ir arhitektūras lēmums. Tas nozīmē, ka, kad nākamais OpenClaw CVE parādās (un tas parādīsies), autentificēti pieprasījumi joprojām tiek verificēti, pirms tie skar lietojumprogrammu. Uzbrukuma virsma ir strukturāli mazāka.

Mēs pieņēmām šo lēmumu no pirmās dienas. Katra OpenClaw.rocks instance darbojas aiz parakstītām sīkdatnēm, ForwardAuth verifikācijas un katrai instancei atsevišķiem nesēja tokeniem. Nekādi vārtejas tokeni pārlūkprogrammā. Nekādi statiski akreditācijas dati izfiltrēšanai. Nekāda autentifikācijas loģika ievainojamā lietojumprogrammā.

Ja vēlaties lasīt vairāk par to, kā mēs izvietojam OpenClaw uz Kubernetes ar pilnu drošības nostiprināšanu, izvietošanas ceļvedis to detalizēti apraksta.

Ja jūs vienkārši vēlaties darbojošos aģentu, kas paliek drošs, nedomājot par neko no tā, tieši to mēs izveidojām.

Sāciet darbu OpenClaw.rocks vai izpētiet atvērtā koda Kubernetes operatoru, ja dodat priekšroku savas infrastruktūras pārvaldīšanai.