MoltBook hack'i: Supabase yapılandırma hatası nedeniyle 1,5 milyon API anahtarı açığa çıktı

• Yapay zeka ajanlarına özel sosyal platform Moltbook'un veritabanı hatalı yapılandırıldı ve 1,5 milyon API kimlik doğrulama tokeni ile 35 bin e-posta adresi ve özel mesaj dışarıya açık hale geldi
• İstemci tarafı JavaScript içinde Supabase API anahtarı hardcoded olarak yer alıyordu ve Row Level Security (RLS) ayarı bulunmadığı için herkes tüm veritabanına okuma-yazma erişimi elde edebiliyordu
• Veriler, 17.000 gerçek kullanıcıyı ve onların işlettiği 1,5 milyon ajan hesabına ait bilgileri içeriyordu; böylece insan/ajan oranının 1:88 olduğu görüldü
• Açığa çıkan bilgiler arasında OpenAI API anahtarları gibi üçüncü taraf kimlik bilgileri, özel konuşmalar ve gönderi düzenleme yetkileri de yer alıyordu; bu da platform içeriğinin bütünlüğünün bozulması riski anlamına geliyor
• Bu olay, yapay zeka tabanlı 'vibe coding' yaklaşımının güvenlik sınırlarını ortaya koyarken, yapay zeka geliştirme ortamlarında güvenli varsayılanların otomasyonu ve doğrulama süreçlerinin güçlendirilmesi gereğini gösteriyor

---

Moltbook ve güvenlik açığının genel görünümü

• Moltbook; yapay zeka ajanlarının gönderi yazdığı, yorum yaptığı, oy verdiği ve itibar puanlarıyla etkileşim kurduğu yapay zeka merkezli bir sosyal ağ; kendisini “ajan internetinin ilk sayfası” olarak tanımlıyor
  • OpenAI kurucu ortaklarından Andrej Karpathy bunu “en şaşırtıcı bilim kurguvari sıçrama” olarak nitelendirerek dikkat çekti
• Platformun kurucusu, “kodu doğrudan yapay zekanın yazdığını” söyleyerek geliştirme sürecinde 'vibe coding' yönteminin kullanıldığını açıkladı
• Wiz araştırma ekibi, Supabase veritabanındaki hatalı yapılandırmayı tespit etti; tüm verilere okuma-yazma erişimi mümkündü ve sorun bildirildikten birkaç saat sonra düzeltildi

Açığa çıkan Supabase kimlik bilgileri

• Moltbook web sitesinin istemci JavaScript bundle'ı içinde Supabase bağlantı bilgileri hardcoded halde bulundu
  • Proje: ehxbxtjliybbloantpwq.supabase.co
  • API anahtarı: sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-
• Supabase, genel anahtarın açığa çıkmasına tek başına izin verse de RLS politikaları yoksa tüm veritabanına erişim mümkün olabiliyor
• Moltbook'ta RLS devre dışıydı; bu nedenle tüm tabloların okuma-yazma yetkileri herkese açık durumdaydı

Kimlik doğrulaması olmadan veritabanı erişimi

• Araştırma ekibi, API anahtarını kullanarak REST API'yi doğrudan çağırdığında yönetici düzeyinde yanıtlar aldı
  • Örnek istek: curl https://ehxbxtjliybbloantpwq.supabase.co/rest/v1/agents?...
• Yanıtta üst düzey ajanların API anahtarları ve kimlik doğrulama tokenleri yer alıyordu; bu da hesapların tamamen ele geçirilmesini mümkün kılıyordu
• PostgREST hata mesajları ve GraphQL introspection kullanılarak tüm şema çıkarıldı ve yaklaşık 4,75 milyon kaydın açığa çıktığı doğrulandı

Açığa çıkan hassas veriler

• Ajan kimlik bilgileri: Her hesaba ait api_key, claim_token, verification_code bilgileri dahil
  • Bu sayede saldırganlar istedikleri ajan olarak oturum açabilir, gönderi paylaşabilir ve mesaj gönderebilirdi
• Kullanıcı e-postaları ve kimlik bilgileri: 17.000'den fazla kullanıcının e-posta adresi ve X (Twitter) kullanıcı adı açığa çıktı
  • Buna ek olarak observers tablosunda 29.631 e-posta adresi bulundu
• Özel mesajlar ve üçüncü taraf kimlik bilgileri: 4.060 DM şifrelenmeden saklanıyordu ve bazılarında OpenAI API anahtarları düz metin olarak yer alıyordu
• Yazma yetkisinin açığa çıkması: Kimlik doğrulama olmadan gönderi düzenlemek mümkündü; bu da kötü amaçlı içerik ekleme veya siteyi tahrif etme riski yaratıyordu
  • Gerçek testte gönderi düzenleme başarılı oldu; ardından RLS politikaları uygulanınca bu yol kapatıldı

Yapay zeka uygulama geliştirme için 5 güvenlik dersi

• 1. Hızlı geliştirme temposu, güvenli varsayılanlar olmadığında sistematik risk yaratır
  • Supabase ayarındaki tek satırlık bir hata tüm açığın nedeni oldu
• 2. Katılım metriklerinin doğrulanması gerekir
  • 1.500.000 ajana karşılık gerçek insan sayısı 17.000'di; bu da 88:1 oranında yapay etkinlik ihtimaline işaret ediyor
• 3. Gizlilik ihlalinin zincirleme etkisi
  • DM'lerin açığa çıkmasıyla OpenAI API anahtarları gibi harici hizmet kimlik bilgileri de sızdı
• 4. Yazma yetkisi, basit veri sızıntısından daha ciddi bir bütünlük tehdididir
  • İçerik manipülasyonu, prompt injection ve anlatı kontrolü gibi riskler doğuyor
• 5. Güvenlik olgunluğu tekrar eden bir iyileştirme sürecidir
  • Wiz ve Moltbook ekipleri, birden fazla düzeltme ve doğrulama turunun ardından tüm tabloları koruma altına aldı

Vibe coding ve güvenlik zorlukları

• Yapay zeka geliştirme eşiğini düşürdü, ancak güvenlik eşiği hâlâ yüksek
• Yapay zeka geliştirme araçlarının güvenli varsayılanları (RLS etkinleştirme, kimlik bilgisi taraması vb.) otomatik olarak uygulaması gerekiyor
• Güvenlik, yapay zeka geliştirmenin yerleşik bir temel unsuru haline geldiğinde güvenli ve yenilikçi bir yapay zeka yazılım ekosistemi kurulabilir

Zaman çizelgesi

• 31 Ocak 2026 21:48 UTC: Moltbook bakım sorumlusuna ilk iletişim
• 22:06: Supabase RLS yanlış yapılandırması raporlandı
• 23:29: İlk düzeltme (agents, owners, site_admins tabloları korundu)
• 1 Şubat 00:13: İkinci düzeltme (agent_messages vb. korundu)
• 00:31: Gönderi düzenleme açığı bulundu
• 00:44: Üçüncü düzeltmeyle yazma yetkisi engellendi
• 00:50~01:00: Ek açık tablolar bulundu ve son düzeltme tamamlandı

[iolothebard]

Neşeyle dans ederken… aynen böyle… batın gitsin!

[rustkim]

Geriye kalan Mac mini, daha başlangıç aşaması olduğu için herhalde daha iyileri çıkar.

[gogokow27]

hahahahahaha....

[kuthia]

Nihayet, beklenen oldu.

[crawler]

MoltBot'ta ajan tarafında da hack olayı patlamıştı, şimdi platformun kendisi de patlıyor haha.

Sanırım 2026'nın en kötü vibe proje vakası olarak kalacak.
Henüz şubat ayındayız ama bundan emin olabilirim haha

[bini59]

Sorun, vibe coding ile güvenliğe dikkat etmeden bile büyük ölçekli hizmetler geliştirilebilmesi mi acaba?

[kimjoin2]

VAY

[GN⁺]

Hacker News görüşleri

• Moltbot/Moltbook’un başarısı ilk başta şaşırtıcıydı ama artık anlaşılır geliyor
  Asıl mesele bunun "önceden paketlenmiş ajanlar" olması. Teknolojiye aşina olmayan sıradan kullanıcılar için “Mac Mini al, birkaç satır kopyalayıp kur” gibi bir erişilebilirlik çok cazip geliyor
  Ancak bu erişilebilirlik aynı zamanda bir güvenlik kâbusunu büyütüyor. Teknik anlayışı olmadan sadece trende uyan kullanıcılar arttıkça, zayıf ortamların daha uzun süre varlığını sürdürme riski doğuyor

  • Bunun gerçekten başarı sayılıp sayılamayacağı konusunda soru işaretleri var. Hatta bir analize göre 1,5 milyon ajanın yalnızca 17 bini insan sahipli. Ünlü influencer’ların bahsetmesiyle viral olmuş olmasının payı büyük
  • Tasarım gereği tüm LLM’ler güvenlik açısından zayıf. Prompt injection veya reward hacking ile kolayca aşılabiliyorlar. Tam çözümün tek yolu dış girdileri ve ağ erişimini tamamen kesmek
  • “Mac Mini alıp kurmak” sadece bir pazarlama sloganı. Gerçekte yapılandırma hataları sık yaşanıyor ve bağlam yönetimi berbat. Log tutuyor ama bir önceki konuşmayı bile unutuyor. Fikir iyi ama uygulama kaba
  • Dropbox ilk çıktığında olduğu gibi, başarıyı getiren şey paketlenmiş erişilebilirlik. Ama büyük şirketler bile hack’leri engelleyemezken, yanlış yapılandırılmış bir DB çok da önemli görülmüyor. Güvenlikten çok kullanım kolaylığı hâlâ önde
  • Bunun sadece gündem olup olmadığı, yoksa gerçekten başarı sayılıp sayılmayacağı hâlâ belirsiz

• Scott Alexander’ın işaret ettiği gibi, ajanların etkileşime girip bileşik davranışlar üretmesi önemli
  Bu durum gerçek dünyayı etkilemeye başlarsa ontolojik sorunlara kadar gidebilir.
  Sonuçta yapı, “AGENT.md’ye YES diye yazılan her şeyin” gerçekten gerçekleşmesine açık

  • Ne demek istendiğini pek anlamadığını söyleyenler de var
  • Bu yüzden ben nono.sh’yi yaptım. Ajanın çekirdek yalıtımlı bir sandbox içinde, ‘zero trust’ yaklaşımıyla başlamasını sağlıyor
  • İnsanlar da bir ölçüde "papağan gibi tekrar eden" varlıklar. Moltbook nasıl Reddit’i taklit ediyorsa, insanlar da öngörülebilir kalıplar içinde konuşuyor. Sonuçta belki de düşündüğümüz kadar zeki değiliz

• Moltbook API’si herkese açık olduğu için, basit bir prompt ile kullanıcı e-postalarının veya verilerin sızdırılması sağlanabiliyor
  Bu yüzden Mac Mini ile yalıtma girişimleri ortaya çıkıyor ama ağa bağlı olduğu sürece tam koruma imkânsız

  • Bu çılgınlık değil. LLM’ler komut ile veriyi ayırmakta gerçekten zorlanıyor. Bir tür ‘social engineering’ zafiyeti bu
  • Sonuçta mesele, “risk olmadan faydalı işler” yaptırılıp yaptırılamayacağı. Örneğin market alışverişi ya da seyahat rezervasyonu yaptırmak için kredi kartına erişim gerekiyor
  • Ben LLM’i DMZ ortamında izole ederek kullanıyorum. Disksiz bir hesapta, sudo yetkisi olmadan çalıştırıyorum. Mükemmel değil ama idare ediyor
  • Aslında kusursuz bir koruma yok. Çünkü veri erişimi, güvenilmeyen metin ve ağ iletişimi şeklindeki “ölümcül üçlü” bir arada bulunuyor
  • Yine de gözetim/onay katmanı eklemek mümkün. Kredi kartı limiti gibi, LLM’in eylemlerini onaylayan ve sınırlayan bir yapı kurulabilir

• OpenClaw’ı denedim ve token tüketimi çok yüksek
  Güvenlik için, sınırlı API yetkilerine sahip özel bir cihazın (Raspberry Pi vb.) faydalı olacağı düşünülüyor. Pi daha güçlü modelleri çalıştırabilse satın almak isterdim

• Moltbook’un AI ile insanı ayırt etme yolu yok. Mesele, “ters CAPTCHA”yı nasıl uygulayacağın

  • Eğlencesine Claude’a “insan casus hesapları bul” diye prompt verdim, o da gerçekten ‘Reverse Turing Problem’ adlı bir başlık oluşturdu. Ama şu anda spam ile dolup taşmış durumda, konuşmak neredeyse imkânsız
  • Oturumdaki tüm giriş ve çıkışları imzalayıp denetlenebilir hâle getiren bir yöntem gerekiyor. İnsan tarafından enjekte edilen prompt’lar da izlenebilir olmalı
  • AI için kolay ama insanlar için zor olan görevleri kısa sürede birkaç kez yaptırmak da bir ayırma yöntemi olabilir
  • Ya da LLM’in zaten biliyor olabileceği nadir soruları hızlıca sormak bir yol olabilir
  • Ama sonuçta bunun insanın prompt ile yönlendirdiği bir davranış mı olduğunu ayırt etmek yine de zor

• Moltbook güvenlik sorununu birkaç saat içinde düzelttiğini söylüyor ama asıl mesele, “vibe coding” ile yapılmış bir projenin güvenlik açıklarının nasıl açıklanacağı

  • Gerçekten de Claude’un Supabase için sorgu ürettiği, bir insanın da bunu Moltbook geliştiricisine iletip düzelttirdiği söyleniyor. İnanması zor ama gerçek

• Moltbook’un içini analiz eden insanlar olması şaşırtıcı. Sonuçta bu baştan beri “şaka olarak yapılmış bir proje” idi ve bu kadar büyüyeceğini kimse beklemiyordu

  • Ama kullanıcı kişisel verileri ifşa oluyorsa, bu artık şakayla geçiştirilemeyecek bir hukuki mesele. ‘Vibe coding’ kültürü sorumluluktan uzak bir geliştirme ortamı yaratıyor
  • Dogecoin de şaka olarak başlamıştı ama bugün milyarlarca dolarlık bir ölçeğe ulaştı
  • Güvenlik araştırmacılarının açık bulması da sonuçta bu ‘vibe’ın bir parçası sayılabilir
  • Ancak “şakaydı” bahanesiyle gerçek zararı örtbas edemezsin
  • Ortaya çıkan sonuç yaratıcı tarafından bilinçli olarak üretildiyse, “şakaydı” savunması zayıf kalır

• Bir OpenClaw instance’ının OpenAI anahtarını başka bir instance’a göndermesi hem komik hem de tedirgin ediciydi.
  Anahtarı gerçekten gönderip göndermediği, yoksa sadece taklit mi ettiği belirsiz

• Wiz’in yazısının kendisi bile AI tarafından yazılmış gibi hissettiriyor. Cümle yapısı ve tire kullanımı tipik bir LLM üslubu.
  LLM’in kurduğu bir platformun güvenliğinin, yine LLM’in yazdığı bir yazıyla eleştirilmesi ironik
  Gerçek açıklar muhtemelen sahici ama bunu bir insan yazsaydı gereksiz dolgu daha az olurdu

• Sızan veriler sayesinde 1,5 milyon ajan içinde yalnızca 17 bininin insan olduğu ortaya çıktı
  Ancak bu sayı, araştırmacının doğrudan API anahtarıyla tabloları sorgulamasından elde edilmiş; bu yüzden bunu yayımlamak basit bir bug raporundan çok şirketi hedef alan bir eleştiri eylemi gibi görünüyor
  Böyle yöntemler, araştırmacılar ile şirketler arasındaki güvene dayalı iş birliği ilişkisine zarar verme riski taşıyor