Grafana Labs, GitHub ortamını hedef alan bir ihlal sonrası kaynak kodlarının ve bazı dahili depo içeriklerinin dışarı sızdığını doğruladı. Şirket, olayın üretim sistemlerine ya da müşteri operasyonlarına sıçradığına dair bir bulguya rastlanmadığını, ancak etkilenen alanın hem açık hem de özel kaynak kodlarını barındıran GitHub organizasyonu olduğunu açıkladı.
İlk incelemelere göre sızan veriler yalnızca kod dosyalarıyla sınırlı kalmadı. Bazı ekiplerin iç operasyon notları, iş süreçlerine ilişkin ayrıntılar ve profesyonel iletişim kapsamında kullanılan iş e-posta adresleri ile kişi adlarının da erişilen içerikler arasında yer aldığı belirtildi. Buna karşın, üretim ortamlarından çekilmiş müşteri verisi ya da Grafana Cloud üzerinden işlenmiş bilgi bulunduğuna dair bir işaret paylaşılmadı.
Saldırının başlangıç noktası: TanStack npm zinciri
Olayın kökeni, TeamPCP tarafından organize edilen TanStack npm tedarik zinciri saldırısına bağlanıyor. Bu kampanya daha önce OpenAI ve Mistral AI gibi farklı hedefleri de etkilemişti. Grafana tarafı, şüpheli etkinliği 11 Mayıs 2026 tarihinde fark ettiğini ve ardından GitHub workflow token’larının önemli bir bölümünü hızla döndürdüğünü bildirdi.
Ancak yapılan analizde gözden kaçan bir token nedeniyle saldırganların GitHub depolarına erişim elde ettiği anlaşıldı. Sonraki inceleme, başlangıçta etkilenmediği düşünülen belirli bir GitHub workflow’un da aslında ele geçirildiğini ortaya koydu. Bu tür olaylar, özellikle CI/CD boru hatlarında kullanılan kısa ömürlü ama yüksek yetkili kimlik bilgilerinin ne kadar kritik olduğunu bir kez daha gösteriyor.
Hangi veriler risk altında?
Bu vakada en önemli ayrım, üretim sistemleri ile geliştirme ve iş birliği ortamları arasındaki sınırın net biçimde çizilmiş olması. Sızan içerikler arasında kaynak kodu, iç GitHub depoları ve bazı iş iletişim bilgileri bulunuyor. Bu durum, doğrudan servis kesintisi yaratmasa bile, saldırganlara gelecekteki hedefli saldırılar için ciddi bir keşif avantajı sağlayabilir.
Özellikle iç dokümantasyon, yapılandırma notları, erişim kalıpları ve otomasyon akışları; kimlik avı, yetki yükseltme ve daha sonra yapılacak yatay hareket girişimleri için değerli olabilir. Bu nedenle olay, yalnızca bir kod sızıntısı olarak değil, aynı zamanda kurumsal saldırı yüzeyinin genişlemesi olarak da okunmalı.
Şantaj talebi ve kurumsal yanıt
Grafana, 16 Mayıs’ta ismi açıklanmayan bir tehdit aktöründen şantaj talebi aldığını da duyurdu. Şirket, çalındığı iddia edilen verilerin gerçekten silineceğine dair bir garanti bulunmadığı ve bu tür ödemelerin yeni kampanyaları teşvik edebileceği gerekçesiyle fidye ödememe kararı aldı.
Sonraki aşamada otomasyon token’larının yeniden düzenlendiği, izleme kapasitesinin artırıldığı, tüm commit kayıtlarının kötüye kullanım belirtileri açısından denetlendiği ve GitHub güvenlik duruşunun güçlendirildiği aktarıldı. Bu adımlar, olay müdahale süreçlerinde IAM, token yaşam döngüsü yönetimi ve denetim kayıtlarının ne kadar kritik olduğunu gösteriyor.
Teknik zincir: tedarik zinciri saldırısı nasıl büyüyor?
Bu olay, klasik bir tedarik zinciri saldırısının nasıl kurumsal bir ihlale dönüşebildiğine dair iyi bir örnek sunuyor. Saldırı zinciri kabaca şu adımlarla ilerlemiş görünüyor:
1) npm ekosisteminde yer alan bir bağımlılık ya da paket üzerinden güven zincirinin bozulması.
2) CI/CD veya GitHub workflow ortamında kullanılan token’ların ele geçirilmesi.
3) İç depolara erişim sağlanarak kaynak kodu, operasyon notları ve iletişim verilerinin dışarı aktarılması.
Bu modelde saldırganın amacı çoğu zaman hemen zararlı yazılım çalıştırmak değil, önce görünürlük kazanmak ve kalıcı erişim elde etmektir. Ardından veri sızdırma, şantaj ve ikinci aşama kimlik avı kampanyaları gelebilir. Bu yüzden olay, fidye yazılımı ekosistemine yakın bir veri gaspı senaryosu olarak da değerlendirilebilir.
SOC ve sistem yöneticileri için pratik kontrol listesi
Benzer bir riskin önüne geçmek için güvenlik ekiplerinin aşağıdaki kontrolleri düzenli olarak uygulaması faydalı olur:
1) GitHub, npm, CI/CD ve bulut yönetim hesaplarındaki tüm token’ları periyodik olarak döndürün ve kullanım süresini kısaltın.
2) Repo erişimlerini en az ayrıcalık prensibine göre yeniden gözden geçirin; özellikle write ve admin yetkilerini sınırlayın.
3) GitHub audit log, workflow log ve SSO oturum kayıtlarını SIEM’e aktararak anomali avı yapın.
4) Beklenmeyen commit, branch oluşturma, secret erişimi ve workflow tetikleme olayları için EDR/SOAR kuralları tanımlayın.
5) Kod depolarında secret scanning ve pre-commit kontrollerini zorunlu hale getirin.
6) İç dokümantasyon depolarını üretim sistemlerinden ve genel iş birliği alanlarından mantıksal olarak ayırın; ağ segmentasyonu ve Zero Trust yaklaşımını uygulayın.
7) Şüpheli npm bağımlılıklarını, lockfile değişikliklerini ve paket bütünlüğü kontrollerini düzenli inceleyin.
8) Olay müdahale planında GitHub, npm ve bulut sağlayıcıları için ayrı iletişim ve izolasyon adımları tanımlayın.
Kurumsal ortamlar için ne anlama geliyor?
Bu tür bir ihlal, özellikle SaaS sağlayıcıları, yazılım geliştirme ekipleri, fintech şirketleri ve bulut tabanlı hizmet sunan kurumlar için önemli bir uyarı niteliğinde. Kaynak kodu sızdığında, saldırganlar yalnızca ürün mantığını değil, aynı zamanda güvenlik kontrollerinin nerede zayıf olduğunu da öğrenebilir.
Örneğin bir e-ticaret platformunda GitHub deposuna düşen API anahtarları, webhook adresleri veya iç servis isimleri; sonraki aşamada e-posta güvenliği üzerinden yapılacak hedefli oltalama saldırılarını kolaylaştırabilir. Benzer şekilde, bir bulut güvenliği ekibinin kullandığı otomasyon token’ları ele geçirilirse, saldırganlar altyapı üzerinde kalıcı erişim kurmaya çalışabilir.
Benzer olaylarda öne çıkan savunma yaklaşımı
Bu vaka, sadece kod güvenliğini değil, kimlik ve erişim yönetimini de merkeze alıyor. Kurumların özellikle aşağıdaki alanlara yatırım yapması gerekiyor: kısa ömürlü kimlik bilgileri, güçlü MFA, repo bazlı yetki ayrımı, secret yönetimi, düzenli bağımlılık denetimi ve kapsamlı log korelasyonu.
Ayrıca, iç depoların hangi bilgiler için kullanıldığı netleştirilmeli; operasyonel notlar ile hassas iş verileri aynı yerde tutulmamalı. Böylece bir sızıntı yaşandığında etki alanı daraltılabilir ve saldırganın elde edeceği keşif değeri azaltılabilir.
Teknik özet
İlişkili kampanya: TanStack npm tedarik zinciri saldırısı
İlgili tehdit aktörü: TeamPCP
Etkilenen alan: GitHub organizasyonu, iç depolar, kaynak kodu, iş iletişim bilgileri
İlk fark edilme tarihi: 11 Mayıs 2026
Şantaj talebi: 16 Mayıs 2026
Öne çıkan savunma adımları: token rotasyonu, audit log incelemesi, secret scanning, SIEM korelasyonu, Zero Trust erişim modeli
Bu olayda herhangi bir CVE numarası paylaşılmadı; dolayısıyla zafiyet odaklı bir istismar yerine tedarik zinciri ve kimlik bilgisi ele geçirme temelli bir saldırı modeli öne çıkıyor. Benzer vakalarda kurumların en hızlı kazanımı, erişim anahtarlarını sıkılaştırmak ve depo görünürlüğünü azaltmak oluyor.