Над 135 000 инстанции на OpenClaw са изложени в интернет. Критична уязвимост позволява отдалечено изпълнение на код с едно кликване от всеки браузър. Изследователи са открили над 1 100 злонамерени умения, разпространяващи Atomic Stealer в ClawHub. Microsoft публикува статия, озаглавена „Running OpenClaw Safely”, която започва с бележката, че „за повечето среди подходящото решение може да е да не се внедрява.” Белгийският национален център за киберсигурност издаде правителствено предупреждение. Cisco нарече персоналните AI агенти като OpenClaw „кошмар за сигурността.”

Това не е паникьорство. Това са факти от независими изследователи по сигурността, корпоративни доставчици и правителствени агенции. Ако управлявате инстанция на OpenClaw, това Ви засяга.

Какво се обърка

OpenClaw беше проектиран за localhost. Инсталирате го на машината си, комуникирате чрез локален уеб интерфейс и той изпълнява задачи от Ваше име. Моделът за сигурност предполагаше, че лицето, което достъпва интерфейса, е лицето, седящо пред клавиатурата.

След това OpenClaw скочи от 9 000 на над 200 000 звезди в GitHub за няколко седмици. Хората го внедриха на VPS сървъри, изложиха го в интернет и го свързаха с каналите си за съобщения. Предположението за localhost се разпадна в мащаб. (Разгледахме пълния спектър от опции за внедряване и техните компромиси в сигурността в отделно ръководство.)

CVE-2026-25253: отдалечено изпълнение на код с едно кликване

Най-сериозната уязвимост е CVE-2026-25253, оценена с CVSS 8.8. OpenClaw не валидираше WebSocket origin заглавия. Ето как работи атаката:

  1. Жертвата посещава злонамерена уеб страница (или страница със злонамерена реклама).
  2. JavaScript на тази страница отваря WebSocket връзка към localhost:18789, порта по подразбиране на OpenClaw.
  3. Тъй като браузърът е на същата машина, връзката заобикаля всички правила на защитната стена.
  4. Атакуващият ексфилтрира gateway токена за удостоверяване чрез WebSocket.
  5. С токена атакуващият има пълен контрол: достъп до шел, четене/писане на файлове и изпълнение на команди.

Свързването към localhost не помага. Атаката се осъществява чрез собствения браузър на жертвата. Анализът на SOCRadar разглежда пълната верига.

Злонамерени умения и атаки по веригата на доставки

Изследователи откриха 341 злонамерени умения в ClawHub в началото на февруари. Това число оттогава е нараснало на над 1 100. Кампанията ClawHavoc разпространява Atomic Stealer чрез умения, които изглеждат легитимни, но съдържат скрити стъпки за изпълнение на команди. Уменията са Markdown файлове. Скрита инструкция, която казва „изпълни тази шел команда”, е лесна за вграждане и трудна за откриване.

На 17 февруари атаката по веригата на доставки на Cline отиде още по-далеч. Компрометиран npm токен беше използван за публикуване на версия на Cline CLI, която тихо инсталираше OpenClaw на машините на разработчиците. Атаката беше насочена към самия build pipeline.

Изследователите вече са разкрили шест допълнителни уязвимости в ядрото на OpenClaw, включително CVE-2026-27001. OWASP Топ 10 за агентни приложения вече включва много от тези модели като водещи рискове. Както формулира анализът на Conscia, това е пълномащабна криза в сигурността.

Защо gateway токенът не е достатъчен

Вграденото удостоверяване на OpenClaw е статичен токен. Задавате го веднъж и всяка заявка трябва да го включва. По-добре е от нищо. Но има фундаментални ограничения.

Статичните токени не изтичат. Ако токен изтече (чрез CVE-2026-25253, чрез логове, чрез злонамерено умение, четящо променливи на средата), атакуващият има постоянен достъп, докато не забележите и не го ротирате ръчно.

Статичните токени не могат да бъдат ограничени по обхват. Gateway токенът дава пълен достъп. Няма начин да се даде на някого достъп само за четене или да се ограничи какво може да прави удостоверена сесия.

Статичните токени не могат да бъдат свързани с потребител. Ако трима души споделят токен, няма одитна следа за това кой какво е направил.

Повечето ръководства за внедряване на VPS препоръчват да поставите OpenClaw зад nginx с основно удостоверяване. Това е по-добре, но все пак е статична идентификационна данна. Ако някой я прихване (подслушване на мрежата при нешифрована връзка, компрометирана конфигурация на reverse proxy, изтекъл .htpasswd файл), получава достъп.

Фундаменталният проблем е по-дълбок: удостоверяването се случва вътре в приложението. Ако приложението има уязвимост, удостоверяването може да бъде заобиколено. CVE-2026-25253 демонстрира точно това. Gateway токенът съществуваше. Уязвимостта го извлече, преди приложението да има шанс да го верифицира.

Затова изградихме OpenClaw.rocks с удостоверяване на ниво прокси. Следващите раздели обясняват архитектурата в детайли. Ако просто искате защитена инстанция, без да изграждате всичко това сами, вижте нашите планове.

Как защитаваме gateway

В OpenClaw.rocks удостоверяването се случва на ниво прокси, преди заявката изобщо да достигне OpenClaw пода. Това е структурна разлика, не просто конфигурационна.

Ето тристепенната архитектура.

Слой 1: Подписани gateway бисквитки (HMAC-SHA256)

Когато достъпвате инстанцията си на OpenClaw чрез таблото на OpenClaw.rocks, сървърът генерира подписана бисквитка. Форматът е:

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

Бисквитката има TTL от 4 часа и се опреснява автоматично на всеки 45 минути. Ограничена е до пътя /gw/{instanceId}, така че една бисквитка не може да се използва за достъп до друга инстанция. Тя е HttpOnly (JavaScript не може да я чете), Secure (изпраща се само по HTTPS) и SameSite=Lax (не се изпраща при cross-origin заявки). HMAC се верифицира чрез сравнение с постоянно време за предотвратяване на времеви атаки.

Дори ако някой прихване стойността на бисквитката, не може да фалшифицира нова без подписващия секрет. А самата бисквитка не съдържа идентификационни данни, които дават директен достъп до OpenClaw.

Слой 2: Traefik ForwardAuth

Всяка заявка към инстанция на OpenClaw минава през Traefik, нашия reverse proxy. Преди да препрати заявката, Traefik извиква auth-gate крайна точка, която верифицира подписаната бисквитка.

Това е чиста HMAC верификация. Нула обаждания към базата данни. Нула мрежови заявки към Supabase или друга услуга. Решението се взема за микросекунди.

Ако бисквитката е невалидна, изтекла или липсва, заявката се отхвърля на ниво прокси. Заявката никога не достига OpenClaw. Това е ключовата разлика. В типична конфигурация самият OpenClaw трябва да реши дали да разреши или отхвърли заявка. Ако OpenClaw има уязвимост в логиката си за удостоверяване, атакуващ може да се промъкне. В нашата конфигурация OpenClaw никога не вижда неудостоверен трафик.

Слой 3: Инжектиране на gateway токен

Всяка инстанция на OpenClaw има вграден gateway токен. Това е същият токен, който бихте конфигурирали сами при самостоятелен хостинг. Разликата е в начина, по който достига до пода.

В типична конфигурация за самостоятелен хостинг поставяте токена в конфигурационен файл, може би го съхранявате в променлива на средата и се надявате никога да не изтече. Браузърът Ви трябва да го изпраща с всяка заявка, което е точно начинът, по който CVE-2026-25253 го ексфилтрира.

В нашата конфигурация криптографски случаен 32-байтов токен се генерира при създаването на инстанцията и се съхранява като Kubernetes Secret. Traefik го инжектира като Authorization заглавие при всяка препратена заявка. Браузърът никога не го вижда. Никога не се появява в конфигурационен файл, който бихте могли случайно да комитнете. Никога не пътува по WebSocket, който злонамерена страница би могла да отвлече. Токенът съществува, но живее изцяло вътре в клъстера, движейки се само между Traefik и пода.

Защо тази архитектура блокира CVE-2026-25253

Веригата на атака на CVE-2026-25253 ексфилтрира gateway токена чрез WebSocket. Нека разгледаме какво се случва, когато тази атака е насочена към инстанция на OpenClaw.rocks:

  1. JavaScript на атакуващия се опитва да отвори WebSocket към OpenClaw пода.
  2. Връзката първо достига Traefik. Traefik проверява подписаната бисквитка.
  3. Злонамерената страница е на друг origin. Бисквитката SameSite=Lax не се изпраща при cross-origin WebSocket връзки. Заявката се отхвърля.
  4. Дори ако бисквитката по някакъв начин бъде прикачена, страницата на атакуващия не може да я прочете (HttpOnly). Няма какво да се ексфилтрира.
  5. Дори ако бисквитката изтече, тя не съдържа bearer токен. Bearer токенът се инжектира от Traefik, никога не се излага на браузъра. Атакуващият не може да го възстанови.

Няма какво да се открадне, защото браузърът никога не притежава истинските идентификационни данни. Повърхността за атака, която CVE-2026-25253 експлоатира, просто не съществува.

Контролен списък за сигурност на OpenClaw за самостоятелно хостващите

Не всеки иска управляван хостинг и това е нормално. Ако управлявате собствена инстанция на OpenClaw, ето практически контролен списък за 2026.

Активиран ли е Вашият gateway токен за удостоверяване? Изпълнете openclaw doctor, за да проверите. Ако gateway удостоверяването е деактивирано, всеки, който може да достигне порт 18789, контролира Вашия агент и всичко, до което има достъп.

Инстанцията Ви зад reverse proxy с TLS ли е? Нешифрованият HTTP означава, че всеки по мрежовия път може да прочете Вашия gateway токен при преминаване. Използвайте nginx, Caddy или Traefik с валиден TLS сертификат. Let’s Encrypt е безплатен.

На последната версия ли сте? CVE-2026-25253 беше поправена във v2026.1.29. CVE-2026-27001 беше поправена във v2026.2.15. Ако използвате по-стара версия, актуализирайте сега. Ръководството за укрепване на Adversa AI обхваща допълнителни стъпки.

Одитирали ли сте инсталираните си умения? Кампанията ClawHavoc беше насочена конкретно към ClawHub. Проверете всяко умение, което сте инсталирали. Ако не сте го инсталирали Вие лично, премахнете го и проверете източника.

Вашият reverse proxy валидира ли WebSocket origin-ите? Това е конкретният вектор, който CVE-2026-25253 експлоатира. Вашият reverse proxy трябва да отхвърля WebSocket upgrade заявки от неочаквани origin-и. Документацията за сигурност на OpenClaw съдържа конфигурационни примери.

Удостоверяването Ви случва ли се преди или след като заявката достигне OpenClaw? Това е въпросът, който има най-голямо значение. Ако OpenClaw обработва собственото си удостоверяване, уязвимост в OpenClaw може да го заобиколи. Ако Вашият reverse proxy обработва удостоверяването, заявката никога не достига OpenClaw, освен ако не е вече верифицирана.

Какво не решаваме

Честността е важна тук. Удостоверяването на ниво прокси решава сигурността на gateway. Не решава всичко.

Инжектирането на промптове е проблем на ниво приложение. Умело съставено съобщение може потенциално да подведе агента да предприеме нежелани действия. Това е активна област на изследване в цялата AI индустрия и нито един хостинг доставчик не може да го предотврати напълно днес.

Злонамереното поведение на уменията се изпълнява в контекста на агента. Ако инсталирате умение, което ексфилтрира данни чрез разрешен изходящ HTTPS трафик, прокси удостоверяването не може да го спре. Това, което нашата инфраструктура прави, е да ограничи радиуса на поражение: всяка инстанция работи в собствен Kubernetes под с мрежова изолация, премахнати capabilities, seccomp и файлова система root само за четене. Компрометиран агент не може да достигне други агенти или хост системата. Kubernetes операторът налага тези настройки по подразбиране за всяка инстанция.

Доверието към LLM доставчика зависи от Вашия план. Ако използвате собствени API ключове (план Light), разговорите Ви минават през доставчика, който конфигурирате, и неговата политика за поверителност се прилага. При плана Pro насочваме трафика през нашия собствен AI gateway с предварително конфигурирани доставчици. Не е нужно да предавате API ключовете си на инстанция на OpenClaw или да се доверявате, че ключ на трета страна е съхранен сигурно. Gateway управлява идентификационните данни на доставчиците от Ваше име и Вие никога не ги виждате или обработвате директно.

Сигурността работи на слоеве. Ние се грижим за инфраструктурните слоеве. Предизвикателствата на ниво приложение са реални и заслужават да бъдат разбрани.

Сигурността е архитектурно решение

Кризата със сигурността на OpenClaw не е за един CVE или една партида злонамерени умения. Тя е за инструмент, проектиран за localhost, който се внедрява в интернет от стотици хиляди хора, с удостоверяване, което се случва вътре в приложението, което трябва да защитава.

Преместването на удостоверяването на ниво прокси не е функционалност. Това е архитектурно решение. То означава, че когато следващият OpenClaw CVE излезе (а ще излезе), удостоверените заявки все още ще бъдат верифицирани, преди да достигнат приложението. Повърхността за атака е структурно по-малка.

Взехме това решение от първия ден. Всяка инстанция на OpenClaw.rocks работи зад подписани бисквитки, ForwardAuth верификация и bearer токени за всяка инстанция. Без gateway токени в браузъра. Без статични идентификационни данни за ексфилтриране. Без логика за удостоверяване вътре в уязвимото приложение.

Ако искате да прочетете повече за това как внедряваме OpenClaw на Kubernetes с пълно укрепване на сигурността, ръководството за внедряване го разглежда в детайли.

Ако просто искате работещ агент, който остава защитен, без да мислите за нищо от това, точно това изградихме.

Започнете на OpenClaw.rocks или разгледайте Kubernetes оператора с отворен код, ако предпочитате да управлявате собствена инфраструктура.