Binlerce yazılım şirketinin ürün belgelerini, API dokümanlarını ve yardım merkezlerini barındırdığı GitBook, 2 Kasım 2026 akşamı ciddi bir siber saldırıya uğradı. Şirket, 4 Kasım’da yayımladığı ayrıntılı olay raporunda saldırının tek bir müşteriyi hedef aldığını, ancak saldırganın kısa sürede tüm platformun altyapısına ulaştığını açıkladı. GitBook’a göre saldırgan, ilk sızmadan tam erişime kadar olan yolu “büyük ölçüde otomasyon ve yapay zekâ ile yürütülen bir saldırıya işaret eden” bir hız ve isabetle kat etti.
Şirket, saldırganı altyapıdan atmak için platformu bilinçli olarak çevrim dışına aldı. GitBook uygulaması 2 Kasım’da 20.32’den (UTC) 3 Kasım’da 11.56’ya kadar, yani yaklaşık 16 saat kapalı kaldı. Bu sürede önbellekteki yayımlanmış belgeler bir süre daha erişilebilir durumda tutuldu.
Saldırı adım adım nasıl gelişti?
GitBook’un paylaştığı zaman çizelgesine göre olay, hedef alınan müşterinin bir hesabının 2 Kasım’da 12.27’de (UTC) ele geçirilmesiyle başladı. Saldırgan daha sonra GitBook’un tek oturum açma (SSO) akışındaki bir açığı kullanarak kendini GitBook çalışanı gibi gösteren oturumlar oluşturdu. Bu oturumlar sayesinde şirketin kendi organizasyonunda entegrasyon olarak kurulu, yanlış yapılandırılmış bir GitHub uygulamasının kimlik bilgilerine ulaştı ve şirketin iç kod depolarına erişti.
Kod depolarında ilerleyen saldırgan, sonunda bir Cloudflare API anahtarı buldu. Bu anahtarla üretim ortamının sırlarına erişen saldırgan, bir hizmet hesabı üzerinden altyapının tamamına uzanabilecek yetkiye kavuştu. Çizelgeye göre saldırgan 16.32’de çalışan oturumlarına ve kaynak koda, 17.48’de ise üretim ortamına ulaştı. GitBook’un iç alarm sistemi 18.10’da yetkisiz etkinliği yakaladı; SSO açığı 19.58’de kapatıldı ve 20.32’de ele geçirilen hesaplar devre dışı bırakılarak saldırganın bağlantısı kesildi.
Şirketin açıklamasına göre saldırgan üretim ortamında 2 Kasım akşamı yaklaşık 2 saat 45 dakika, 3 Kasım’ın erken saatlerinde ise yaklaşık 40 dakika boyunca erişime sahip oldu.
Hangi veriler risk altına girdi?
GitBook, saldırının tek bir müşteriye odaklandığını ve başka hiçbir müşterinin içeriğinin değiştirildiğine dair kanıt bulunmadığını vurguluyor. Buna rağmen şirket, saldırganın erişim süresince tüm müşteri verilerine ulaşabilecek durumda olduğu için bütün müşteri verilerini açığa çıkmış kabul ettiğini açıkladı. Erişilebilir durumdaki veriler şunlar:
- GitBook API anahtarları,
- Entegrasyon anahtarları ve sırları,
- Oturum imzalama sırları,
- Kimlik doğrulamalı erişimle yayımlanan dokümantasyon siteleri,
- GitHub ve GitLab bağlantıları (saldırgan, yalnızca müşterilerin GitBook uygulamasına izin verdiği depolarda GitBook adına işlem yapabilecek durumdaydı),
- Belgeler, alanlar ve değişiklik talepleri gibi içerikler.
Şirket ayrıca ilk açıklamasında, site ziyaretçilerinin GitBook Assistant adlı yapay zekâ asistanına sorduğu soruların da erişilmiş olabileceğini belirtmişti. Fatura bilgileri, parolalar ve IP adreslerinin ise etkilenmediği bildirildi. GitBook, saldırganın müşteri depolarında herhangi bir işlem yapıp yapmadığını kesin olarak tespit edemediğini de açıkça kabul ediyor.
Müşterilerin hemen yapması gerekenler
GitBook olay sırasında tüm kişisel API anahtarlarını iptal etti, altyapıdaki her sırrı ve GitBook’un müşteriler adına yönettiği tüm sırları yeniledi. Ancak bazı adımların müşteriler tarafından atılması gerekiyor. Şirketin listesine göre:
- GitBook API kullanan herkes yeni bir API anahtarı oluşturmalı ve mevcut uygulamalarını bu anahtarla güncellemeli.
- Bağlı üçüncü taraf araçları olanlar, GitBook’a bağlamak için kullandıkları tüm API anahtarlarını ve sırları yenilemeli. Uzmanlar, anahtarın yalnızca GitBook tarafında değil, onu üreten hizmette de iptal edilmesi gerektiğini hatırlatıyor.
- Yayımlanmış entegrasyonu olanlar, bu entegrasyonların kullandığı sırları değiştirmeli.
- Özel bir arka uçla kimlik doğrulamalı erişim kullananlar, imzalama anahtarını GitBook uygulamasında yeniden üretip arka uçlarına işlemeli.
- GitBook MCP sunucusunu yapay zekâ araçlarına bağlayanlar, bu bağlantıyı yeniden yetkilendirmeli.
Git Sync için GitHub uygulaması ve GitLab bağlantılarında anahtarların şirket tarafından yenilendiği, bu nedenle ek işlem gerekmediği belirtildi. Yine de bağlı depolarda ekibin yapmadığı işlemlerin, dalların veya webhook’ların gözden geçirilmesi öneriliyor. GitBook, saldırıyla ilişkili üç IP adresini de yayımlayarak kurumların kendi kayıtlarında bu adresleri aramasını tavsiye etti.
“SaaS şirketleri müşterilerine giden bir yol”
GitBook’un yöneticileri raporda bu saldırının sıradan bir tarama olmadığını, ilk sızmadan tam erişime geçiş hızının “birkaç yıl önce düşünülemeyecek” düzeyde olduğunu yazdı. Şirket, olaydan üç ders çıkardığını belirtiyor: Unutulmuş her kimlik bilgisi bir risktir ve en az yetki, kısa ömürlü anahtarlar ve sır taraması varsayılan olmalıdır; müdahale hızı saldırı hızına yetişmelidir; ve her SaaS sağlayıcısı aslında müşterilerinin güvenlik çevresinin bir parçasıdır.
Bu son ders özellikle önemli. Saldırgan GitBook’u değil, GitBook’un bir müşterisini hedefliyordu; ancak hedefe ulaşmak için hizmet sağlayıcının altyapısını bir köprü olarak kullandı. Bulut hizmetlerinin birbirine anahtarlarla bağlandığı günümüzde, bir dokümantasyon aracındaki zayıflık bile kod depolarına ve üçüncü taraf sistemlere uzanan bir zincirin ilk halkası olabiliyor.
Yapay zekâ saldırıların temposunu değiştiriyor
GitBook, saldırıda hangi yapay zekâ sistemlerinin kullanıldığını açıklamadı. Ancak olay, son haftalarda art arda gelen yapay zekâ ajanı destekli saldırı haberlerinin bir halkası olarak görülüyor. Güvenlik araştırmacıları, ajanların keşif, kimlik bilgisi arama ve yanal hareket gibi zahmetli adımları dakikalar içinde tamamlayabildiğine dikkat çekiyor. Bu da savunma tarafında otomatik tespit ve hızlı izolasyonu artık bir tercih olmaktan çıkarıyor.
Kullanıcılar için ders ise basit ama hayati: Bir hizmete verdiğiniz her anahtar, o hizmet kadar güvendedir. Kullanılmayan anahtarları silmek, anahtarlara yalnızca gerekli yetkileri vermek ve bir ihlal duyurusunda vakit kaybetmeden anahtarları yenilemek, zincirin sizin tarafınızda kopmasını sağlar.
Kaynak: GitBook olay raporu ve güvenlik duyuruları
