135.000’den fazla OpenClaw örneği internette açık durumdadır. Kritik bir güvenlik açığı, herhangi bir tarayıcı üzerinden tek tıkla uzaktan kod çalıştırmaya olanak tanımaktadır. Araştırmacılar ClawHub üzerinde Atomic Stealer dağıtan 1.100’den fazla kötü amaçlı beceri tespit etmiştir. Microsoft, “Running OpenClaw Safely” başlıklı bir blog yazısı yayımladı ve yazı “çoğu ortam için uygun karar onu dağıtmamak olabilir” notu ile başlamaktadır. Belçika’nın ulusal siber güvenlik merkezi bir hükümet uyarısı yayımladı. Cisco, OpenClaw gibi kişisel AI ajanlarını “bir güvenlik kabusu” olarak nitelendirdi.

Bu korku yaymak değildir. Bunlar bağımsız güvenlik araştırmacılarından, kurumsal sağlayıcılardan ve devlet kurumlarından gelen gerçeklerdir. Bir OpenClaw örneği çalıştırıyorsanız, bu sizi ilgilendirmektedir.

Ne yanlış gitti

OpenClaw localhost için tasarlandı. Makinenize kurarsınız, yerel bir web arayüzü üzerinden iletişim kurarsınız ve sizin adınıza işlemler gerçekleştirir. Güvenlik modeli, arayüze erişen kişinin klavyede oturan kişi olduğunu varsaydı.

Ardından OpenClaw birkaç hafta içinde 9.000’den 200.000’in üzerine GitHub yıldızına ulaştı. İnsanlar onu VPS makinelerine kurdu, internete açtı ve mesajlaşma kanallarına bağladı. Localhost varsayımı ölçekte çöktü. (Tüm dağıtım seçeneklerinin yelpazesini ve güvenlik ödünleşimlerini ayrı bir rehberde ele aldık.)

CVE-2026-25253: tek tıkla uzaktan kod çalıştırma

En ciddi güvenlik açığı, CVSS 8.8 puanlı CVE-2026-25253’tür. OpenClaw, WebSocket origin başlıklarını doğrulamıyordu. Saldırı şu şekilde çalışmaktadır:

  1. Kurban kötü amaçlı bir web sayfasını (veya kötü amaçlı bir reklam içeren bir sayfayı) ziyaret eder.
  2. Sayfadaki JavaScript, OpenClaw’ın varsayılan portu olan localhost:18789’a bir WebSocket bağlantısı açar.
  3. Tarayıcı aynı makinede olduğu için bağlantı tüm güvenlik duvarı kurallarını atlar.
  4. Saldırgan, WebSocket üzerinden gateway kimlik doğrulama tokenını çıkarır.
  5. Token ile saldırgan tam kontrole sahip olur: kabuk erişimi, dosya okuma/yazma ve komut çalıştırma.

Localhost’a bağlanmak işe yaramaz. Saldırı, kurbanın kendi tarayıcısı üzerinden gerçekleştirilir. SOCRadar analizi tüm zinciri detaylı olarak incelemektedir.

Kötü amaçlı beceriler ve tedarik zinciri saldırıları

Araştırmacılar, şubat ayı başında ClawHub’da 341 kötü amaçlı beceri buldu. Bu sayı o zamandan beri 1.100’ün üzerine çıkmıştır. ClawHavoc kampanyası, meşru görünen ancak gizli komut çalıştırma adımları içeren beceriler aracılığıyla Atomic Stealer dağıtmaktadır. Beceriler Markdown dosyalarıdır. “Bu kabuk komutunu çalıştır” diyen gizli bir talimat yerleştirmek kolay, fark etmek zordur.

17 Şubat’ta Cline tedarik zinciri saldırısı işleri daha da ileri götürdü. Ele geçirilmiş bir npm tokeni, geliştiricilerin makinelerine sessizce OpenClaw kuran bir Cline CLI sürümü yayımlamak için kullanıldı. Saldırı, yapım sürecinin kendisini hedef almaktaydı.

Araştırmacılar artık OpenClaw çekirdeğinde CVE-2026-27001 dahil altı ek güvenlik açığı daha açıklamıştır. OWASP Top 10 for Agentic Applications artık bu kalıpların çoğunu en üst riskler olarak listelemektedir. Conscia analizi’nin ifade ettiği gibi, bu tam kapsamlı bir güvenlik krizidir.

Neden bir gateway tokeni yeterli değil

OpenClaw’ın yerleşik kimlik doğrulaması statik bir tokendir. Bir kez ayarlarsınız ve her istek onu içermelidir. Hiç yoktan iyidir. Ancak temel sınırlamaları vardır.

Statik tokenlar sona ermez. Bir token sızarsa (CVE-2026-25253 üzerinden, loglar üzerinden, ortam değişkenlerini okuyan kötü amaçlı bir beceri üzerinden), saldırgan siz fark edip manuel olarak değiştirene kadar kalıcı erişime sahip olur.

Statik tokenlar kapsamlandırılamaz. Gateway tokeni tam erişim sağlar. Birine salt okunur erişim vermenin veya kimliği doğrulanmış bir oturumun neler yapabileceğini sınırlamanın yolu yoktur.

Statik tokenlar bir kullanıcıya bağlanamaz. Üç kişi bir tokeni paylaşıyorsa, kimin ne yaptığına dair denetim iziniz yoktur.

VPS dağıtım rehberlerinin çoğu, OpenClaw’ı temel kimlik doğrulama ile nginx arkasına koymayı önerir. Bu daha iyidir, ancak hala statik bir kimlik bilgisidir. Birisi onu yakalarsa (şifrelenmemiş bir bağlantıda ağ dinleme, ele geçirilmiş bir ters proxy yapılandırması, sızmış bir .htpasswd dosyası), içeridedir.

Temel sorun daha derindir: kimlik doğrulama uygulamanın içinde gerçekleşir. Uygulamada bir güvenlik açığı varsa, kimlik doğrulama atlanabilir. CVE-2026-25253 bunu tam olarak kanıtlamıştır. Gateway tokeni mevcuttu. Güvenlik açığı, uygulama doğrulama şansı bile bulamadan onu çıkardı.

Bu yüzden OpenClaw.rocks platformunu proxy düzeyinde kimlik doğrulama ile inşa ettik. Aşağıdaki bölümler mimariyi detaylı olarak açıklamaktadır. Bunu kendiniz oluşturmadan güvenli bir örnek istiyorsanız, planlarımıza bakın.

Gateway’i nasıl güvence altına alıyoruz

OpenClaw.rocks’ta kimlik doğrulama, istek OpenClaw pod’una ulaşmadan önce proxy düzeyinde gerçekleşir. Bu yapısal bir farktır, yalnızca bir yapılandırma farkı değildir.

İşte üç katmanlı mimari.

Katman 1: İmzalı gateway çerezleri (HMAC-SHA256)

OpenClaw örneğinize OpenClaw.rocks kontrol paneli üzerinden eriştiğinizde, sunucu imzalı bir çerez oluşturur. Biçimi şöyledir:

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

Çerezin 4 saatlik TTL’si vardır ve her 45 dakikada otomatik olarak yenilenir. /gw/{instanceId} yoluna kapsamlandırılmıştır, bu nedenle bir çerez farklı bir örneğe erişmek için kullanılamaz. HttpOnly (JavaScript okuyamaz), Secure (yalnızca HTTPS üzerinden gönderilir) ve SameSite=Lax (çapraz kaynak isteklerinde gönderilmez) özelliklerine sahiptir. HMAC, zamanlama saldırılarını önlemek için zamanlama açısından güvenli karşılaştırma kullanılarak doğrulanır.

Birisi çerez değerini yakalasa bile, imzalama sırrı olmadan yenisini oluşturamaz. Ve çerezin kendisi, OpenClaw’a doğrudan erişim sağlayan kimlik bilgileri içermez.

Katman 2: Traefik ForwardAuth

OpenClaw örneğine yapılan her istek, ters proxy’miz Traefik üzerinden geçer. İsteği yönlendirmeden önce Traefik, imzalı çerezi doğrulayan bir auth-gate uç noktasını çağırır.

Bu saf HMAC doğrulamasıdır. Sıfır veritabanı çağrısı. Supabase veya başka herhangi bir servise sıfır ağ isteği. Karar mikrosaniyeler içinde verilir.

Çerez geçersiz, süresi dolmuş veya eksikse, istek proxy düzeyinde reddedilir. İstek asla OpenClaw’a ulaşmaz. Bu kilit farktır. Tipik bir kurulumda, OpenClaw’ın kendisi bir isteğe izin verip vermeyeceğine karar vermelidir. OpenClaw’ın kimlik doğrulama mantığında bir güvenlik açığı varsa, saldırgan sızabilir. Bizim kurulumumuzda OpenClaw asla kimliği doğrulanmamış trafiği görmez.

Katman 3: Gateway token enjeksiyonu

Her OpenClaw örneğinin yerleşik bir gateway tokeni vardır. Bu, kendi sunucunuzu barındırsaydınız kendiniz yapılandıracağınız tokenin aynısıdır. Fark, pod’a nasıl ulaştığıdır.

Tipik bir kendi barındırma kurulumunda, tokeni bir yapılandırma dosyasına yapıştırır, belki bir ortam değişkeninde saklarsınız ve asla sızmayacağını umarsınız. Tarayıcınız her istekle birlikte göndermek zorundadır; CVE-2026-25253’ün onu çıkardığı yol tam olarak budur.

Bizim kurulumumuzda, örnek oluşturma sırasında kriptografik olarak rastgele 32 baytlık bir token oluşturulur ve Kubernetes Secret olarak saklanır. Traefik, her yönlendirilen istekte bunu Authorization başlığı olarak enjekte eder. Tarayıcı onu asla görmez. Yanlışlıkla commit edebileceğiniz bir yapılandırma dosyasında asla görünmez. Kötü amaçlı bir sayfanın ele geçirebileceği bir WebSocket üzerinden asla iletilmez. Token mevcuttur, ancak tamamen küme içinde yaşar ve yalnızca Traefik ile pod arasında hareket eder.

Bu mimari neden CVE-2026-25253’ü engelliyor

CVE-2026-25253 saldırı zinciri, gateway tokenını WebSocket üzerinden çıkarır. Bu saldırı bir OpenClaw.rocks örneğini hedef aldığında ne olduğunu inceleyelim:

  1. Saldırganın JavaScript’i OpenClaw pod’una WebSocket bağlantısı açmaya çalışır.
  2. Bağlantı önce Traefik’e ulaşır. Traefik imzalı çerezi kontrol eder.
  3. Kötü amaçlı sayfa farklı bir kaynaktadır. SameSite=Lax çerezi, çapraz kaynak WebSocket bağlantılarında gönderilmez. İstek reddedilir.
  4. Çerez bir şekilde eklenmiş olsa bile, saldırganın sayfası onu okuyamaz (HttpOnly). Çıkarılacak bir şey yoktur.
  5. Çerez sızsa bile, bearer tokenı içermez. Bearer token Traefik tarafından enjekte edilir ve tarayıcıya asla açılmaz. Saldırgan onu yeniden oluşturamaz.

Çalınacak bir şey yoktur çünkü tarayıcı asla gerçek kimlik bilgilerini tutmaz. CVE-2026-25253’ün istismar ettiği saldırı yüzeyi basitçe mevcut değildir.

Kendi sunucunuzu barındıranlar için OpenClaw güvenlik kontrol listesi

Herkes yönetilen barındırma istemez ve bu gayet normaldir. Kendi OpenClaw örneğinizi çalıştırıyorsanız, 2026 için pratik bir kontrol listesi sunuyoruz.

Gateway kimlik doğrulama tokenınız etkin mi? Kontrol etmek için openclaw doctor komutunu çalıştırın. Gateway kimlik doğrulaması devre dışıysa, 18789 portuna ulaşabilen herkes ajanınızı ve erişebildiği her şeyi kontrol eder.

Örneğiniz TLS ile ters proxy arkasında mı? Düz HTTP, ağ yolundaki herkesin gateway tokenınızı aktarım sırasında okuyabileceği anlamına gelir. Geçerli bir TLS sertifikası ile nginx, Caddy veya Traefik kullanın. Let’s Encrypt ücretsizdir.

En son sürümde misiniz? CVE-2026-25253 v2026.1.29’da düzeltildi. CVE-2026-27001 v2026.2.15’te düzeltildi. Eski bir sürüm çalıştırıyorsanız, şimdi güncelleyin. Adversa AI sağlamlaştırma rehberi ek adımları kapsamaktadır.

Yüklü becerilerinizi denetlediniz mi? ClawHavoc kampanyası özellikle ClawHub’ı hedef almaktaydı. Yüklediğiniz her beceriyi kontrol edin. Kendiniz yüklemediyseniz, kaldırın ve kaynağı doğrulayın.

Ters proxy’niz WebSocket origin’lerini doğruluyor mu? Bu, CVE-2026-25253’ün istismar ettiği belirli vektördür. Ters proxy’niz beklenmeyen origin’lerden gelen WebSocket yükseltme isteklerini reddetmelidir. OpenClaw güvenlik belgeleri yapılandırma örnekleri içermektedir.

Kimlik doğrulamanız istek OpenClaw’a ulaşmadan önce mi yoksa sonra mı gerçekleşiyor? Bu en önemli sorudur. OpenClaw kendi kimlik doğrulamasını yönetiyorsa, OpenClaw’daki bir güvenlik açığı onu atlayabilir. Ters proxy’niz kimlik doğrulamayı yönetiyorsa, istek zaten doğrulanmadıkça asla OpenClaw’a ulaşmaz.

Ne çözmüyoruz

Dürüstlük burada önemlidir. Proxy düzeyinde kimlik doğrulama, gateway güvenliğini çözer. Her şeyi çözmez.

Prompt enjeksiyonu uygulama düzeyinde bir sorundur. Ustaca hazırlanmış bir mesaj, ajanı istenmeyen eylemlere yönlendirebilir. Bu, tüm AI endüstrisinde aktif bir araştırma alanıdır ve hiçbir barındırma sağlayıcı bunu bugün tam olarak önleyemez.

Kötü amaçlı beceri davranışı ajanın bağlamında çalışır. İzin verilen HTTPS çıkışı üzerinden veri sızdıran bir beceri yüklerseniz, proxy kimlik doğrulaması bunu durduramaz. Altyapımızın yaptığı, patlama yarıçapını sınırlamaktır: her örnek kendi Kubernetes pod’unda ağ izolasyonu, kaldırılmış yetenekler, seccomp ve salt okunur root dosya sistemi ile çalışır. Ele geçirilmiş bir ajan diğer ajanlara veya ana sisteme ulaşamaz. Kubernetes operatörü bu varsayılanları her örnek için uygulamaktadır.

LLM sağlayıcı güveni planınıza bağlıdır. Kendi API anahtarlarınızı kullanıyorsanız (Light planı), görüşmeleriniz yapılandırdığınız sağlayıcı üzerinden geçer ve onların gizlilik politikası uygulanır. Pro planında, trafiği önceden yapılandırılmış sağlayıcılarla kendi AI gateway’imiz üzerinden yönlendiriyoruz. API anahtarlarınızı bir OpenClaw örneğine teslim etmeniz veya üçüncü taraf anahtarının güvenli bir şekilde saklandığına güvenmeniz gerekmez. Gateway, sağlayıcı kimlik bilgilerini sizin adınıza yönetir ve siz bunları asla görmez veya doğrudan ele almazsınız.

Güvenlik katmanlardan oluşur. Biz altyapı katmanlarını yönetiyoruz. Uygulama düzeyindeki zorluklar gerçektir ve anlamaya değerdir.

Güvenlik bir mimari karardır

OpenClaw güvenlik krizi tek bir CVE veya tek bir kötü amaçlı beceri serisi ile ilgili değildir. Localhost için tasarlanmış bir aracın, yüz binlerce kişi tarafından internette konuşlandırılması ve kimlik doğrulamanın korumayı amaçladığı uygulamanın içinde gerçekleşmesiyle ilgilidir.

Kimlik doğrulamayı proxy düzeyine taşımak bir özellik değildir. Bir mimari karardır. Bu, bir sonraki OpenClaw CVE yayımlandığında (ve yayımlanacaktır), kimliği doğrulanmış isteklerin uygulamaya dokunmadan önce hala doğrulanması anlamına gelir. Saldırı yüzeyi yapısal olarak daha küçüktür.

Bu kararı ilk günden aldık. Her OpenClaw.rocks örneği imzalı çerezler, ForwardAuth doğrulaması ve örneğe özel bearer tokenların arkasında çalışır. Tarayıcıda gateway tokeni yok. Sızdırılacak statik kimlik bilgileri yok. Savunmasız uygulamanın içinde kimlik doğrulama mantığı yok.

OpenClaw’ı Kubernetes üzerinde tam güvenlik sağlamlaştırması ile nasıl dağıttığımız hakkında daha fazla okumak istiyorsanız, dağıtım rehberi bunu detaylı olarak ele almaktadır.

Bunların hiçbirini düşünmeden güvenli kalan çalışan bir ajan istiyorsanız, tam olarak bunu inşa ettik.

OpenClaw.rocks’ta başlayın veya kendi altyapınızı çalıştırmayı tercih ediyorsanız açık kaynak Kubernetes operatörünü keşfedin.