Понад 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 не перевіряв заголовки origin WebSocket. Ось як працює атака:

  1. Жертва відвідує шкідливу веб-сторінку (або сторінку зі шкідливою рекламою).
  2. JavaScript на цій сторінці відкриває WebSocket-з’єднання до localhost:18789, стандартного порту OpenClaw.
  3. Оскільки браузер знаходиться на тій самій машині, з’єднання обходить будь-які правила фаєрвола.
  4. Зловмисник витягує токен автентифікації шлюзу через WebSocket.
  5. З токеном зловмисник має повний контроль: доступ до оболонки, читання/запис файлів та виконання команд.

Прив’язка до localhost не допомагає. Атака здійснюється через власний браузер жертви. Аналіз SOCRadar детально розглядає весь ланцюжок.

Шкідливі навички та атаки на ланцюг постачання

Дослідники знайшли 341 шкідливу навичку на ClawHub на початку лютого. Відтоді ця кількість зросла до понад 1 100. Кампанія ClawHavoc розповсюджує Atomic Stealer через навички, які виглядають легітимними, але містять приховані кроки виконання команд. Навички — це файли Markdown. Приховану інструкцію “виконай цю команду оболонки” легко вбудувати і важко помітити.

17 лютого атака на ланцюг постачання Cline пішла далі. Скомпрометований npm-токен був використаний для публікації версії Cline CLI, яка тихо встановлювала OpenClaw на машини розробників. Атака була спрямована на сам процес збірки.

Дослідники тепер розкрили шість додаткових вразливостей у ядрі OpenClaw, включаючи CVE-2026-27001. OWASP Top 10 для агентних застосунків тепер включає багато з цих шаблонів як основні ризики. Як зазначає аналіз Conscia, це повномасштабна криза безпеки.

Чому токена шлюзу недостатньо

Вбудована автентифікація OpenClaw — це статичний токен. Ви встановлюєте його один раз, і кожен запит повинен його включати. Це краще, ніж нічого. Але він має фундаментальні обмеження.

Статичні токени не закінчуються. Якщо токен витече (через CVE-2026-25253, через логи, через шкідливу навичку, що читає змінні середовища), зловмисник має постійний доступ, доки ви не помітите і не замініте його вручну.

Статичні токени не можна обмежити. Токен шлюзу дає повний доступ. Немає способу надати комусь доступ лише для читання або обмежити, що може робити автентифікована сесія.

Статичні токени не можна прив’язати до користувача. Якщо три людини ділять токен, у вас немає журналу аудиту, хто що зробив.

Більшість посібників з розгортання на VPS рекомендують розмістити OpenClaw за nginx з базовою автентифікацією. Це краще, але все ще статичне облікове дані. Якщо хтось його перехопить (прослуховування мережі на незашифрованому з’єднанні, скомпрометована конфігурація зворотного проксі, витік файлу .htpasswd), він усередині.

Фундаментальна проблема глибша: автентифікація відбувається всередині застосунку. Якщо застосунок має вразливість, автентифікацію можна обійти. CVE-2026-25253 це точно продемонструвала. Токен шлюзу існував. Вразливість витягла його до того, як застосунок взагалі встиг його перевірити.

Тому ми створили OpenClaw.rocks з автентифікацією на рівні проксі. Наступні розділи детально пояснюють архітектуру. Якщо ви просто хочете безпечний екземпляр, не будуючи це самостійно, перегляньте наші плани.

Як ми захищаємо шлюз

У OpenClaw.rocks автентифікація відбувається на рівні проксі, до того як запит взагалі досягне OpenClaw pod. Це структурна різниця, а не просто різниця в конфігурації.

Ось трирівнева архітектура.

Коли ви отримуєте доступ до свого екземпляра OpenClaw через панель керування OpenClaw.rocks, сервер генерує підписаний cookie. Формат такий:

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

Cookie має TTL 4 години і автоматично оновлюється кожні 45 хвилин. Він обмежений шляхом /gw/{instanceId}, тому один cookie не можна використати для доступу до іншого екземпляра. Він HttpOnly (JavaScript не може його прочитати), Secure (надсилається лише через HTTPS) та SameSite=Lax (не надсилається в крос-доменних запитах). HMAC перевіряється з використанням безпечного щодо часу порівняння для запобігання атакам на основі часу.

Навіть якщо хтось перехопить значення cookie, він не зможе підробити нове без секрету підпису. І сам cookie не містить облікових даних, які надають прямий доступ до OpenClaw.

Рівень 2: Traefik ForwardAuth

Кожен запит до екземпляра OpenClaw проходить через Traefik, наш зворотний проксі. Перед перенаправленням запиту Traefik викликає ендпоінт auth-gate, який перевіряє підписаний cookie.

Це чиста HMAC-перевірка. Нуль запитів до бази даних. Нуль мережевих запитів до Supabase або будь-якого іншого сервісу. Рішення приймається за мікросекунди.

Якщо cookie недійсний, прострочений або відсутній, запит відхиляється на рівні проксі. Запит ніколи не досягає OpenClaw. Це ключова різниця. У типовій конфігурації OpenClaw сам повинен вирішити, дозволити чи відхилити запит. Якщо OpenClaw має вразливість у логіці автентифікації, зловмисник може проникнути. У нашій конфігурації OpenClaw ніколи не бачить неавтентифікований трафік.

Рівень 3: Ін’єкція токена шлюзу

Кожен екземпляр OpenClaw має вбудований токен шлюзу. Це той самий токен, який ви налаштували б самостійно при самостійному хостингу. Різниця в тому, як він потрапляє в pod.

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

У нашій конфігурації криптографічно випадковий 32-байтний токен генерується при створенні екземпляра і зберігається як Kubernetes Secret. Traefik додає його як заголовок Authorization до кожного перенаправленого запиту. Браузер його ніколи не бачить. Він ніколи не з’являється у конфігураційному файлі, який ви могли б випадково закомітити. Він ніколи не подорожує через WebSocket, який шкідлива сторінка може перехопити. Токен існує, але він живе повністю всередині кластера, переміщуючись лише між Traefik та pod.

Чому ця архітектура блокує CVE-2026-25253

Ланцюжок атаки CVE-2026-25253 витягує токен шлюзу через WebSocket. Давайте розглянемо, що відбувається, коли ця атака спрямована на екземпляр OpenClaw.rocks:

  1. JavaScript зловмисника намагається відкрити WebSocket-з’єднання з OpenClaw pod.
  2. З’єднання спершу потрапляє на Traefik. Traefik перевіряє підписаний cookie.
  3. Шкідлива сторінка знаходиться на іншому домені. Cookie SameSite=Lax не надсилається в крос-доменних WebSocket-з’єднаннях. Запит відхиляється.
  4. Навіть якби cookie якимось чином було прикріплене, сторінка зловмисника не може його прочитати (HttpOnly). Немає чого витягувати.
  5. Навіть якби cookie витік, він не містить bearer-токен. Bearer-токен додається Traefik і ніколи не розкривається браузеру. Зловмисник не може його відтворити.

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

Контрольний список безпеки OpenClaw для самостійного хостингу

Не всі хочуть керований хостинг, і це нормально. Якщо ви запускаєте власний екземпляр OpenClaw, ось практичний контрольний список на 2026 рік.

Чи увімкнено ваш токен автентифікації шлюзу? Запустіть openclaw doctor, щоб перевірити. Якщо автентифікація шлюзу вимкнена, будь-хто, хто може досягти порту 18789, контролює вашого агента і все, до чого він має доступ.

Чи ваш екземпляр за зворотним проксі з TLS? Простий HTTP означає, що будь-хто на мережевому шляху може прочитати ваш токен шлюзу під час передачі. Використовуйте nginx, Caddy або Traefik з дійсним TLS-сертифікатом. Let’s Encrypt безкоштовний.

Чи ви на останній версії? CVE-2026-25253 було виправлено у v2026.1.29. CVE-2026-27001 було виправлено у v2026.2.15. Якщо ви використовуєте старішу версію, оновіть зараз. Посібник зміцнення від Adversa AI охоплює додаткові кроки.

Чи перевірили ви свої встановлені навички? Кампанія ClawHavoc була спрямована саме на ClawHub. Перевірте кожну навичку, яку ви встановили. Якщо ви не встановлювали її самостійно, видаліть і перевірте джерело.

Чи перевіряє ваш зворотний проксі WebSocket origins? Це саме той вектор, який використовувала CVE-2026-25253. Ваш зворотний проксі повинен відхиляти WebSocket upgrade-запити з неочікуваних origins. Документація з безпеки OpenClaw містить приклади конфігурації.

Чи ваша автентифікація відбувається до або після того, як запит досягне OpenClaw? Це найважливіше питання. Якщо OpenClaw обробляє власну автентифікацію, вразливість в OpenClaw може її обійти. Якщо ваш зворотний проксі обробляє автентифікацію, запит ніколи не досягне OpenClaw, якщо він ще не перевірений.

Що ми не вирішуємо

Чесність тут важлива. Автентифікація на рівні проксі вирішує безпеку шлюзу. Вона не вирішує все.

Ін’єкція промптів — це проблема рівня застосунку. Вміло складене повідомлення потенційно може обманути агента на виконання ненавмисних дій. Це активна область досліджень у всій індустрії AI, і жоден провайдер хостингу не може повністю запобігти цьому сьогодні.

Шкідлива поведінка навичок виконується в контексті агента. Якщо ви встановите навичку, яка витягує дані через дозволений HTTPS-вихід, автентифікація проксі не може це зупинити. Що робить наша інфраструктура — це обмежує радіус ураження: кожен екземпляр працює у власному Kubernetes pod з мережевою ізоляцією, скинутими capabilities, seccomp та файловою системою root лише для читання. Скомпрометований агент не може досягти інших агентів або хост-системи. Kubernetes оператор забезпечує ці налаштування за замовчуванням для кожного екземпляра.

Довіра до LLM-провайдера залежить від вашого плану. Якщо ви використовуєте власні API-ключі (план Light), ваші розмови проходять через провайдера, якого ви налаштуєте, і діє його політика конфіденційності. На плані Pro ми маршрутизуємо трафік через наш власний AI-шлюз із попередньо налаштованими провайдерами. Вам не потрібно передавати свої API-ключі екземпляру OpenClaw або довіряти, що ключ третьої сторони зберігається безпечно. Шлюз керує обліковими даними провайдерів від вашого імені, і ви ніколи їх не бачите та не обробляєте безпосередньо.

Безпека — це шари. Ми обробляємо шари інфраструктури. Виклики на рівні застосунку реальні і варті розуміння.

Безпека — це архітектурне рішення

Криза безпеки OpenClaw — це не про одну CVE або одну партію шкідливих навичок. Це про інструмент, розроблений для localhost, який сотні тисяч людей розгортають в інтернеті, з автентифікацією, що відбувається всередині застосунку, який вона повинна захищати.

Переміщення автентифікації на рівень проксі — це не функція. Це архітектурне рішення. Це означає, що коли з’явиться наступна CVE OpenClaw (а вона з’явиться), автентифіковані запити все ще перевіряються до того, як вони торкнуться застосунку. Поверхня атаки структурно менша.

Ми прийняли це рішення з першого дня. Кожен екземпляр OpenClaw.rocks працює за підписаними cookie, перевіркою ForwardAuth та окремими bearer-токенами для кожного екземпляра. Жодних токенів шлюзу в браузері. Жодних статичних облікових даних для витягування. Жодної логіки автентифікації всередині вразливого застосунку.

Якщо ви хочете дізнатися більше про те, як ми розгортаємо OpenClaw на Kubernetes з повним зміцненням безпеки, посібник з розгортання розглядає це детально.

Якщо ви просто хочете працюючого агента, який залишається безпечним, не думаючи про все це, саме це ми створили.

Почніть з OpenClaw.rocks або дослідіть Kubernetes оператор з відкритим кодом, якщо віддаєте перевагу власній інфраструктурі.