Vercel İhlali: OAuth saldırısı, platform ortam değişkenlerinin gizli riskini ortaya çıkardı

• OAuth tedarik zinciri ihlali, Vercel’in iç sistemlerine erişime yol açtı ve sınırlı sayıdaki bazı müşteri projelerinde ortam değişkenlerinin açığa çıkmasına neden oldu
• Başlangıç noktası, bir Context.ai çalışanının Lumma Stealer enfeksiyonu oldu; sızdırılan Google Workspace OAuth token’ları Vercel çalışanı hesabına ve iç sistemlere erişmek için kullanıldı
• Saldırganlar, müşteri projelerinin ortam değişkenlerini listeleme yetkisi elde etti; özellikle non-sensitive olarak işaretlenmiş değişkenler, alt hizmet kimlik bilgilerinin açığa çıkma olasılığını artırdı
• Açıklanan bulgulara göre en az bir vakada, Vercel açıklama yapmadan önce sızdırılmış API anahtarı tespiti vardı; tespit ile bildirim arasındaki zaman farkı önemli bir risk faktörü olarak öne çıktı
• Bu ihlal, OAuth güven ilişkileri ile platform ortam değişkeni saklama yöntemlerinin birlikte, tedarik zinciri genelinde kimlik bilgisi yayılımına yol açabileceğini gösterdi

---

Temel çıkarımlar

• OAuth büyütme etkisi doğrulandı
  • Tek bir OAuth güven ilişkisinin bozulması, bir tedarikçiden Vercel’in iç sistemlerine kadar zincirleme yayılım yarattı
  • İhlale uğrayan tedarikçiyle doğrudan ilişkisi olmayan müşteri proje ortam değişkenleri de sınırlı biçimde açığa çıktı
• Yapay zeka ile hızlandırılmış saldırı davranışı olasılığı gündeme geldi
  • CEO, saldırganın alışılmadık hızını yapay zeka desteğiyle ilişkilendiren bir kamu açıklaması yaptı
  • Ancak bu değerlendirme, resmî adli bilişim sonucu değil, kamuya açık bir beyan düzeyinde
• Tespitten açıklamaya kadar olan gecikme öne çıktı
  • Kamuya açık en az bir müşteri bildiriminde, Vercel’in açıklamasından 9 gün önce sızdırılmış anahtar tespiti olduğuna dair emare var
  • Platform ihlallerinde tespit sonrası bildirim gecikmesi önemli bir risk faktörü olarak işaret edildi
• 2026’daki daha geniş örüntüyle bağlantı
  • LiteLLM, Axios, Codecov ve CircleCI ile birlikte, geliştirici tarafından saklanan kimlik bilgilerini hedef alan tedarik zinciri eğilimiyle örtüşüyor

Olay zaman çizelgesi

• Yaklaşık Şubat 2026’da bir Context.ai çalışanı Lumma Stealer ile enfekte oldu; kurumsal kimlik bilgileri, oturum token’ları ve OAuth token’ları sızdırıldı
• Yaklaşık Mart 2026’da saldırganlar Context.ai’nin AWS ortamına erişerek son kullanıcı OAuth token’larını ele geçirdi
  • Bunlar arasında bir Vercel çalışanının Google Workspace token’ı da vardı
• Mart 2026’da, çalınan OAuth token’ı ile bir Vercel çalışanının Google Workspace hesabına erişim sağlandı
• Mart-Nisan 2026 arasında, Vercel’in iç sistemlerine geçildikten sonra müşteri ortam değişkenleri listelenmeye başlandı
• Yaklaşık Nisan 2026’da, ShinyHunters bağlantılı bir aktörün Vercel verisi satmaya başladığı iddiası ortaya atıldı
• 10 Nisan 2026’da bir Vercel müşterisi, OpenAI’dan sızdırılmış API anahtarı uyarısı aldığını kamuya açıkladı
• 19 Nisan 2026’da Vercel güvenlik duyurusunu yayımladı ve X başlığını paylaştı
• 19 Nisan 2026’dan sonra müşteri bildirimleri, kimlik bilgilerini döndürme yönlendirmeleri ve dashboard değişiklikleri devreye alındı
• Nispeten kısa olan yaklaşık 2 aylık kalıcılık süresine rağmen, üçüncü taraf tedarikçi enfeksiyonundan müşteri ortam değişkeni sızıntısına uzanan hız doğrulandı
• Google Workspace OAuth denetim log’larının varsayılan saklama süresi birçok planda 6 aydır
  • Bu yaklaşık 2 aylık kalıcılık süresinin saklama penceresi içinde kalmış olması muhtemel
  • Daha uzun süreli benzer ihlallerin varsayılan saklama süresini aşabileceği de vurgulandı

Saldırı zinciri

• 1. aşama: Üçüncü taraf OAuth ihlali

  • Context.ai, Vercel çalışanı tarafından yetkilendirilmiş bir Google Workspace OAuth uygulamasına sahipti
  • Bu uygulamanın ihlali, yaklaşık Şubat 2026’da bir Context.ai çalışanının Lumma Stealer enfeksiyonuna kadar izleniyor
  • Hudson Rock ve CyberScoop haberlerine göre, ilgili çalışanın bir Roblox oyun exploit script’i indirdikten sonra enfekte olduğu bildirildi
  • Çalınan kimlik bilgileriyle saldırganlar Context.ai’nin AWS ortamına erişti ve Haziran 2025’te piyasaya sürülen Context AI Office Suite’in son kullanıcılarına ait OAuth token’larını sızdırdı
  • Context.ai, Mart 2026’da AWS ortamına yönelik yetkisiz erişimi tespit edip durdurduğunu duyurdu
  • Ancak OAuth token sızıntısının kendisinin, Vercel soruşturmasına kadar tespit edilmediği özellikle belirtildi
  • Yetkilendirilmiş OAuth uygulamaları şu özelliklere sahiptir
    • Kullanıcı parolası gerektirmez
    • Parola değişikliğinden sonra da geçerliliğini sürdürebilir
    • E-posta, Drive, Takvim gibi geniş izin kapsamlarına sıkça sahiptir
    • İlk onaydan sonra nadiren denetim konusu olur

• 2. aşama: Workspace hesabının ele geçirilmesi

  • İhlale uğramış OAuth uygulamasına erişim, Vercel çalışanının Google Workspace hesabına geçiş sağladı
  • Bu sayede e-postalara erişim, Google Drive’daki iç belgelere erişim, takvim ve bağlı kaynakların görünürlüğü ile diğer OAuth bağlantılı hizmetlere erişim olasılığı elde edildi

• 3. aşama: İç sistemlere erişim

  • İhlale uğrayan Workspace hesabından Vercel’in iç sistemlerine daha ileri geçiş yapıldı
  • Rauch, yükseltmenin bir iş arkadaşının ihlale uğramış Vercel Google Workspace hesabından başlayan bir dizi işlemle gerçekleştiğini söyledi
  • Yanal hareketin spesifik tekniği açıklanmadı
    • SSO entegrasyonu
    • E-posta veya Drive’dan toplanan kimlik bilgileri
    • OAuth ile bağlı diğer iç araçlar
    • Bunlardan hangisi olduğu açıklanmadı

• 4. aşama: Ortam değişkenlerinin listelenmesi

  • Saldırganlar, müşteri proje ortam değişkenlerini listeleyebilecek düzeyde yetkiyle Vercel’in iç sistemlerine erişti
  • Vercel, müşteri ortam değişkenlerini saklarken “non-sensitive” olarak işaretleme özelliği sunuyor
  • Kamuya açık açıklamalara göre, müşteri ortam değişkenlerinin tamamı aynı şekilde korunmuyordu ve duyarlı olarak işaretlenmemiş değişkenlerin listelenmesi ek erişim sağladı

• 5. aşama: Alt hizmetlerin kötüye kullanılma olasılığı

  • Açığa çıkan ortam değişkenleri genellikle alt hizmetlere ait kimlik bilgileri içerir
  • Andrey Zagoruiko’nun 19 Nisan 2026 tarihli kamuya açık bildirimine göre, 10 Nisan’da OpenAI’dan sızdırılmış anahtar uyarısı aldı
  • Söz konusu anahtar, bildirimi yapan kişinin iddiasına göre Vercel dışında başka hiçbir yerde bulunmuyordu
  • Bu durum, en az bir açığa çıkan kimlik bilgisinin Vercel açıklama yapmadan önce dışarıdan tespit edilmiş olabileceğini düşündürüyor

Açıklama zamanındaki 9 günlük boşluk

• Guillermo Rauch’un 19 Nisan tarihli X başlığı yanıtında, müşteri Andrey Zagoruiko 10 Nisan 2026’da OpenAI’dan sızdırılmış anahtar uyarısı aldığını kamuya açıkladı
• OpenAI’ın sızdırılmış kimlik bilgisi tespiti genellikle GitHub, paste siteleri gibi açık konumlarda bulunduğunda çalışır
• Haberde, Vercel ortam değişkenlerinden OpenAI uyarısına uzanan yolun basit olmadığı değerlendiriliyor
• Tarihlere bakıldığında, kamuya açık en erken maruziyet kanıtı ile Vercel’in açıklaması arasında 9 günlük bir pencere bulunuyor

• Bu 9 günlük boşluğun anlamı ve anlamına gelmeyenler

  • Bu, tek bir kamuya açık bildirimdir ve adli bilişim tarafından kesinleştirilmiş bir sonuç değildir
  • Vercel’in 10 Nisan’da ihlali zaten bildiğine dair kanıt olarak yorumlanmamalıdır
  • Buna karşılık, en az bir kimlik bilgisinin müşterilerin sır değiştirme bildirimi almadan önce dışarıda tespit edilmiş olduğuna dair anlamlı bir gösterge sunar

• Paydaşlara göre çıkarımlar

  • Düzenleyiciler
    • GDPR kapsamında 72 saatlik bildirim sayacı, veri sorumlusunun ihlali fark ettiği andan itibaren başlar
    • Vercel’in bunu ne zaman fark ettiği, kamuya açık bir tartışma konusu olarak öne çıktı
  • Denetçiler
    • SOC 2 ve ISO 27001 değerlendiricileri, tespit-bildirim gecikmesini sürekli izleme kanıtı olarak inceleyebilir
  • Müşteriler
    • Maruziyet penceresinin 19 Nisan’da başladığı varsayılamaz
    • Habere göre bundan önce de aktif kötüye kullanım yaşanmış olabilir
  • Sağlayıcı tarafından gönderilen sızdırılmış kimlik bilgisi uyarılarının ön erken uyarı kanalı olarak önemi artıyor
  • OpenAI, Anthropic, GitHub, AWS, Stripe gibi örnekler buna dahil

Yapay zeka hızlandırmalı saldırı faaliyetleri

• Guillermo Rauch, 19 Nisan 2026'da X'te saldırı grubunun son derece sofistike olduğunu ve yapay zeka ile önemli ölçüde hızlandırıldığından güçlü biçimde şüphelendiğini söyledi
• Makale, bu ifadeyi etkilenen platformun CEO'sunun kamusal kayıtlardaki değerlendirmesi olarak ele alıyor ve dikkatli inceleme gereğine değiniyor

• Adli bilişim kanıtlarında beklenebilecek işaretler

  • Manuel hızın ötesine geçen listeleme hızı
    • Kısmen yalnızca script kullanımıyla açıklanabilir
    • LLM tabanlı keşif; şema keşfini, endpoint yoklamasını ve kimlik bilgisi biçimi tanımayı paralelleştirebilir
  • Bağlam farkındalıklı sorgu oluşturma
    • Belirgin bir ön keşif olmadan bile Vercel'e özgü terminolojiyi, proje slug'larını, deployment hedef adlarını ve env var adlandırma kurallarını biliyormuş gibi görünen sorgular
  • Hata yanıtına uyum sağlama
    • API hataları ve rate limit sonrasında strateji değiştirme, statik script'lere göre daha esnek
  • Yerelleştirilmiş görünen sosyal mühendislik çıktıları
    • Phishing yönlendirmeleri, commit mesajları ve destek ticket'ları; çeviri metni ya da şablondan ziyade yerel bağlama yakın kalite gösteriyor

• Vercel olayının ötesindeki önemi

  • Bu değerlendirmenin resmi adli incelemede korunup korunmamasından bağımsız olarak, yapay zeka destekli saldırı operasyonları kategorisi artık yalnızca varsayım değil
  • Microsoft'un Nisan 2026 açıklaması; yapay zeka tabanlı device-code phishing, dinamik kod üretimi, aşırı kişiselleştirilmiş oltalar ve backend otomasyon orkestrasyonu örneklerini belgeliyor
  • İnsan hızına göre ayarlanmış telemetri baseline'larının, yapay zeka ile hızlandırılmış operatörler için false negative üretebileceğine dikkat çekiliyor

• Tespit mühendisliği çıkarımları

  • Listeleme ve yanal hareket sıkıştığında, mevcut kalış süresi ve hız eşiğine dayalı kurallar yetersiz alarm üretebilir
  • Şu öğelerin yeniden gözden geçirilmesi gerektiği belirtiliyor
    • Oturum başına benzersiz kaynak listeleme hızı
    • Hata-karşısında başarı toparlanma eğrisi
    • Kısa süre içinde sorgu deseni çeşitliliği

Ortam değişkeni tasarımındaki temel zafiyet

• Makaledeki en kritik yön, ilk erişim vektörünün kendisinden çok Vercel'in ortam değişkeni hassasiyet modeli

• O dönemde Vercel ortam değişkenleri nasıl çalışıyordu

  • Projeler, serverless function'lara ve build sürecine ortam değişkenleri enjekte ediyor
  • Her değişken için bir sensitive bayrağı bulunuyor
  • Varsayılan değer non-sensitive
  • sensitive açıkça etkinleştirilmeli
  • non-sensitive değişkenler dashboard'da gösteriliyor
  • sensitive değişkenler oluşturulduktan sonra maskeleniyor
  • Internal API üzerinden erişim non-sensitive için mümkün, sensitive için sınırlı
  • Kamuya açık beyanlara göre şifreli saklama non-sensitive için uygulanmıyordu; sensitive için ek kısıtlarla birlikte uygulanıyordu
  • Bu ihlalde saldırganların erişebildiği öğeler non-sensitive olarak işaretlenmişti

• Belirleyici tasarım tercihi

  • sensitive bayrağı varsayılan olarak kapalı
  • Geliştiricinin açıkça etkinleştirmediği tüm DATABASE_URL, API_KEY, STRIPE_SECRET_KEY, AWS_SECRET_ACCESS_KEY değerleri, Vercel'in dahili erişim modelinde şifrelenmemiş biçimde saklanıyordu
  • Her bir sır için açık opt-in gerektiren ve varsayılan koruma ile guardrail'ler içermeyen güvenlik kontrollerinin, pratikte düşük benimsenme oranına sahip olduğu değerlendiriliyor

• Vercel'in yanıtı

  • Ortam değişkeni genel bakış sayfasında ve hassas değişken oluşturma/yönetim arayüzünde iyileştirmeler yayımlandığı doğrulandı
  • Görünürlük tarafında iyileşmeler olsa da, yazının kaleme alındığı an itibarıyla bu varsayılan değişikliği anlamına gelmiyor
  • Hâlâ değişken başına opt-in gerekiyor
  • Varsayılanların değiştirilip değiştirilmeyeceği açık bir soru olarak duruyor

• Sektör karşılaştırması

  • Sektör, Vault, AWS Secrets Manager, Doppler ve Infisical gibi özel secret depolarına yöneliyor
  • Olayın, Vercel'in ortam değişkeni tabanlı yaklaşımına kıyasla özel secret yönetimi mimarilerinin tercih edilmesini desteklediği değerlendiriliyor
  • Karşılaştırma tablosuna göre
    • Vercel, non-sensitive varsayılanına sahip ve otomatik tespit yok
    • AWS SSM Parameter Store, SecureString desteği sunuyor
    • HashiCorp Vault, tüm secret'lar için şifreleme ve ACL sağlıyor
    • GitHub Actions, tüm secret'ları log'larda maskeliyor
    • Netlify, secret toggle içeren ortam değişkeni yaklaşımını kullanıyor

Kimlik bilgisi fan-out'u ve aşağı akış riski

• Credential fan-out, tek bir platform ihlalinin, o platformda saklanan kimlik bilgileriyle doğrulanan tüm aşağı akış servislerine zincirleme maruziyet yaratması olgusudur
• Vercel proje ortam değişkenlerinde sıkça bulunabilecek öğeler ve aşağı akış etkileri
  • Veritabanı
    • DATABASE_URL, POSTGRES_PASSWORD
    • Tüm verilere erişim olasılığı
  • Bulut
    • AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY
    • Bulut hesabının ihlal edilme olasılığı
  • Ödeme
    • STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET
    • Finansal veri ve sahte iade riski
  • Kimlik doğrulama
    • AUTH0_SECRET, NEXTAUTH_SECRET
    • Oturum sahteciliği ve hesap ele geçirme olasılığı
  • E-posta gönderimi
    • SENDGRID_API_KEY, POSTMARK_TOKEN
    • Güvenilir alan adı üzerinden phishing olasılığı
  • İzleme
    • DATADOG_API_KEY, SENTRY_DSN
    • Telemetri manipülasyonu olasılığı
  • Kaynak kod ve paketler
    • GITHUB_TOKEN, NPM_TOKEN
    • Tedarik zincirine enjeksiyon olasılığı
  • AI/ML
    • OPENAI_API_KEY, ANTHROPIC_API_KEY
    • API kötüye kullanımı ve maliyet oluşma olasılığı
• Tek bir Vercel projesi genellikle 10 ila 30 ortam değişkeni içerir
• Organizasyon ölçeğinde 50 projelik bir portföy, platformda 500 ila 1.500 kimlik bilgisinin bulunması anlamına gelebilir
• Bu olayda yalnızca sınırlı sayıdaki bazı müşteri projelerine erişildiği belirtilse de, açığa çıkan her kimlik bilgisi ayrı bir sisteme geçiş noktası olabilir
• Makale, bu noktayı platform ihlalinin yalnızca bir gizlilik olayı değil, yazılım tedarik zinciri geneline yayılan çarpan etkisi olarak tanımlıyor

OAuth güven ilişkileri ve sınır savunmalarını atlatma

• OAuth tabanlı sızmalar, geleneksel kimlik bilgisi tabanlı saldırıları tespit edip engelleyen çok sayıda kontrolü baypas eder
• Makalede yaklaşık 22 ay ifadesi yer alsa da, üstteki düzeltmede kalıcılık süresinin yaklaşık 2 ay olarak düzeltildiği belirtiliyor
• Güvenlik ekiplerinin soldaki sütunda dayandığı savunma kontrollerinin, OAuth uygulaması ihlal yolunda ya anlamsız kaldığı ya da zaten karşılanmış koşullar olduğu anlatılıyor
• Bu asimetri nedeniyle OAuth yönetişimi, IAM'den ayrı bir güvenlik alanı olarak öne çıkıyor

• OAuth yönetişimi bir tedarikçi riski işlevidir

  • Birçok organizasyon OAuth onaylarını geliştirici self-service meselesi olarak görüyor
  • Bu durum, çalışan bazında gerekli araç onayı ve asgari merkezi incelemeyle sınırlı kalıyor
  • Bu olay, onaylanmış OAuth uygulamalarının kalıcı erişim yetkisine sahip üçüncü taraf tedarikçiler olarak ele alınması gerektiğine kanıt olarak sunuluyor
  • Tedarikçi incelemesi, periyodik yeniden onay ve anomali kullanım izleme gerekiyor

Tehdit aktörü iddiaları ve atıf

• Yeraltı forumlarındaki tehdit aktörü iddialarının doğası gereği güvenilmesinin zor olduğu varsayımı
• Buradaki bilgiler doğrulanmış olgular değil, farkındalık ve takip amacıyla derlenmiştir

• ShinyHunters bağlantısı iddiası

  • BreachForums gönderisini paylaşan kişi, ShinyHunters bağlantısı olduğunu ve Vercel verilerine sahip olduğunu iddia etti
  • İddia edilen veri kalemleri
    • Yaklaşık 580 çalışan kaydı
    • Kaynak kod depoları
    • API anahtarları ve dahili token'lar
    • GitHub ve NPM token'ları
    • Dahili iletişimler
    • Linear workspace erişimi
  • Yukarıdaki sayıların ve kapsamın tamamı doğrulanmamıştır

• Atfı zorlaştıran unsurlar

  • Bilinen ShinyHunters üyeleri, BleepingComputer'a olaya karıştıklarını reddetti
  • Telegram üzerinden 2 milyon dolarlık fidye talebinde bulunulduğu yönünde iddialar var
  • ShinyHunters markası, ilk kampanyadan sonra birden fazla ya da ilgisiz aktör tarafından kullanılageldi
  • Vercel güvenlik duyurusunda ilgili forum iddialarından söz edilmiyor
  • Rauch'un paylaşım dizisi saldırı zincirini ele alıyor, ancak forum gönderilerini doğrudan ele almıyor

• Tedarik zinciri yayın yoluna ilişkin Vercel'in tutumu

  • Rauch, Next.js, Turbopack ve çok sayıda açık kaynak projesinin tedarik zincirini incelediğini ve bunların topluluk için güvenli olduğunu belirtti
  • Yazım anı itibarıyla bağımsız doğrulama sürüyor
  • Next.js, Turbopack ve diğer Vercel açık kaynak projelerini kullanan kuruluşlara; checksum, imza ve provenance attestation gibi paket bütünlüğü sinyallerini incelemeyi sürdürmeleri öneriliyor
  • Forumda iddia edilen veriler için bağımsız doğrulama bulunmadığından bunlara doğrulanmamış bilgi olarak yaklaşmak gerekiyor
  • Vercel'in açıkladığı OAuth tabanlı saldırı zincirinin tek başına olayı teknik olarak açıklamaya yeterli olduğu, forum gönderisini paylaşan kişinin iddia ettiği geniş erişim kapsamının ise zorunlu bir koşul olmadığı değerlendirmesi yapılıyor

MITRE ATT&CK eşlemesi

• Doğrulanmış saldırı zinciri, mevcut MITRE ATT&CK teknikleriyle doğal biçimde eşleşiyor
• Eşleme kalemleri
  • Initial Access / Trusted Relationship / T1199
    • Context.ai OAuth uygulamasının güvenilen üçüncü taraf olarak kullanılması
  • Persistence / Application Access Token / T1550.001
    • OAuth token'larının parola değişikliğinden sonra da geçerliliğini koruması
  • Credential Access / Valid Accounts / T1078
    • Ele geçirilmiş çalışan Workspace kimlik bilgileri
  • Discovery / Account Discovery / T1087
    • Dahili sistemlerin ve projelerin envanterinin çıkarılması
  • Credential Access / Unsecured Credentials: Credentials in Files / T1552.001
    • non-sensitive ortam değişkenlerine erişim imkanı
  • Lateral Movement / Valid Accounts: Cloud Accounts / T1078.004
    • Açığa çıkan bulut kimlik bilgilerinin kullanılma ihtimali
  • Collection / Data from Information Repositories / T1213
    • Projeler genelinde ortam değişkenlerinin listelenmesi
• Bu eşlemede en yüksek değerli tespit noktası, OAuth uygulaması erişiminden dahili sistem erişimine geçilen bölüm
• Kuruluşların, beklenen kapsamın dışına çıkan veya beklenmeyen IP aralıklarından kaynaklara erişen OAuth uygulamalarındaki anormal davranışları izlemesi gerekiyor

Tedarik zincirinin kuşatılması: LiteLLM, Axios, Vercel

• Vercel olayı tek başına yaşanmış bir olay değil; 2026 Mart-Nisan döneminde yoğunlaşan tedarik zinciri saldırıları akışının içinde yer alıyor
• Haberde bunun koordineli bir kampanya olabileceği, ancak daha olası yorumun; birden fazla saldırganın paket depoları, CI/CD, OAuth sağlayıcıları ve dağıtım platformları arasındaki güven sınırları gibi aynı yapısal zayıflıkları eşzamanlı olarak keşfetmiş olması olduğu belirtiliyor

• 24 Mart 2026: LiteLLM PyPI tedarik zinciri ihlali

  • Kötü amaçlı PyPI paketleri litellm 1.82.7 ve 1.82.8 yayımlandı
  • Aqua Security'nin güvenlik açığı tarayıcısı Trivy'den çalınan CI/CD dağıtım kimlik bilgileri kullanıldı
  • LiteLLM, günlük yaklaşık 3,4 milyon indirme alan bir LLM proxy'si
  • Üç aşamalı arka kapı, büyük bulut sağlayıcıları genelinde 50'den fazla kimlik bilgisi türünü hedefledi
  • Kubernetes DaemonSet kalıcılığı da içeriyordu
  • Tespit edilmeden kalma süresi, kaldırılmadan önce yaklaşık 40 dakika ila 3 saatti
  • İlgili CVE: CVE-2026-33634

• 31 Mart 2026: Axios npm tedarik zinciri ihlali

  • npm paketi axios haftada 70 milyon ila 100 milyon indirme alıyor
  • Maintainer hesabının ele geçirilmesiyle kötü amaçlı 1.14.1 ve 0.30.4 sürümleri dağıtıldı
  • plain-crypto-js@4.2.1 bağımlılığı enjekte edildi; platformlar arası RAT içeriyordu
  • Enfekte olmuş 135 endpoint'in saldırgan C2 altyapısıyla iletişim kurduğu tespit edildi
  • Ortamda kalma süresi 2 ila 3 saatti
  • Microsoft bu saldırıyı Kuzey Kore destekli tehdit aktörü Sapphire Sleet'e atfetti

• Yakınsayan örüntü

  • 3 haftada 3 saldırı
  • Farklı vektörler
  • Ortak hedef, geliştiricilerin araç zincirinde depoladığı kimlik bilgileri ve sırlar
  • Tablo özetinde şunlar sunuluyor
    • LiteLLM: CI/CD kimlik bilgisi hırsızlığı → PyPI, geliştirici kimlik bilgileri ve API anahtarları, 40 dakika-3 saat
    • Axios: Maintainer hesabının ele geçirilmesi → npm, geliştirici iş istasyonlarında RAT, 2-3 saat
    • Vercel: OAuth uygulaması ihlali → platform, müşteri ortam değişkenleri, tabloda yaklaşık 22 ay olarak geçse de üstteki düzeltme ve metinde yaklaşık 2 ay olarak düzeltilmiş

Önceki platform ihlalleriyle ortak örüntü

• Vercel ihlali, platform düzeyindeki ihlallerin müşteri sırlarını açığa çıkardığı tekrar eden örüntüyle bağlantılı

• Codecov Bash Uploader ihlali, Ocak-Nisan 2021

  • Saldırganlar Bash Uploader betiğini değiştirerek müşteri CI ortamlarındaki ortam değişkenlerini sızdırdı
  • Yaklaşık 2 ay boyunca tespit edilemedi
  • Twitch, HashiCorp ve Confluent dahil 29 binden fazla müşterinin potansiyel olarak etkilendiği belirtildi
  • Vercel ile ortak nokta, platform ihlali yoluyla müşteri ortam değişkenlerinin açığa çıkması

• CircleCI güvenlik olayı, Ocak 2023

  • Çalışanın kişisel cihazındaki kötü amaçlı yazılım nedeniyle çalışan SSO oturum token'ları çalındı
  • Dahili sistemlere erişimin ardından müşteri sırları ve şifreleme anahtarları sızdırıldı
  • CircleCI, tüm müşterilere platformda depolanan tüm sırları döndürmelerini tavsiye etti
  • Vercel ile neredeyse aynı yapı
    • Çalışan hesabının ele geçirilmesi
    • Dahili sistem erişimi
    • Müşteri sırlarının sızdırılması

• Snowflake müşteri kimlik bilgisi saldırıları, Mayıs-Haziran 2024

  • UNC5537, infostealer ile elde edilen kimlik bilgilerini ve MFA uygulanmayan hesapları kullandı
  • 165'ten fazla kuruluş etkilendi
  • Ticketmaster, Santander Bank ve AT&T dahil

• Okta destek sistemi ihlali, Ekim 2023

  • Çalınmış kimlik bilgileriyle müşteri destek vaka yönetim sistemine erişildi
  • HAR dosyaları içindeki oturum token'ları görüntülendi
  • Etkilenen müşteriler arasında Cloudflare, 1Password ve BeyondTrust yer aldı

• Örüntü özeti

  • Güven ilişkileri veya kimlik bilgileri üzerinden ilk erişim
  • Dahili sistemlere yanal hareket
  • Müşteri sırlarının sızdırılması
  • Hedef kapsamı, bazı seçili hedeflerden platform geneline kadar değişiyor
  • Tabloda olay bazında ilk vektör, açığa çıkan varlıklar ve tespit gecikmesi özetleniyor
    • Codecov yaklaşık 2 ay
    • Okta birkaç hafta
    • CircleCI birkaç hafta
    • Snowflake birkaç ay
    • Vercel yaklaşık 2 ay

Hâlâ açıklanmayan noktalar

• Çok sayıda kamuya açık haber ve yönetici açıklaması var, ancak temel boşluklar hâlâ duruyor
• Kamuya açık kayıtlarda yanıtı bulunmayan sorular
  • Vercel'in olağandışı etkinliği ilk ne zaman tespit ettiği
  • Kamuya açık ilk kimlik bilgisi kötüye kullanımı kanıtı ile açıklama arasında neden 9 günlük bir fark bulunduğu
  • Etkilenen müşteri sayısı
    • Rauch bunu “quite limited” diye nitelendirdi, ancak somut sayı paylaşılmadı
  • ShinyHunters forum iddialarının aynı saldırgan tarafından mı ortaya atıldığı
  • Context.ai'nin mevcut durumu ve aşağı akış müşterilerine bildirim yapılıp yapılmadığı
  • Vercel içindeki erişimin toplam kapsamı
    • Etkilenen ekip sayısı, proje sayısı ve ortam değişkeni sayısı açıklanmadı
    • Müşteri ortam değişkenleri dışında başka dahili sistemlere erişilip erişilmediği de doğrulanmadı
• Haberde, yalnızca bilinen olguları değil, kamuya açıklanmayan noktaları da açıkça kabul eden bir yaklaşımın titiz analiz için gerekli olduğu vurgulanıyor

Tespit ve avcılık rehberi

• Vercel müşterileri için acil eylemler

  • Tüm proje ortam değişkenlerinin denetlenmesi gerekiyor
  • Makalede şu CLI örnekleri yer alıyor
    • vercel env ls --environment production
    • vercel env ls --environment preview
    • vercel env ls --environment development
  • CLI şu anda sensitive bayrağını doğrudan göstermediğinden, kontrol için dashboard veya API gerekli

• Sızan kimlik bilgilerinin yetkisiz kullanımını araştırma

  • Bulut sağlayıcısı denetim günlüklerini arayın
    • AWS CloudTrail
      • sts.amazonaws.com, iam.amazonaws.com, s3.amazonaws.com içeren eventSource filtresi
      • Döndürülen Vercel’de kayıtlı access key ile eşleşen userIdentity.accessKeyId arayın
      • Kurumun bilinen CIDR’larının dışındaki sourceIPAddress, python-requests, curl, Go-http-client, tanıdık olmayan otomasyon dizeleri userAgent tespiti
      • Zaman aralığı Şubat 2026’dan günümüze
    • GCP Audit Logs
      • Vercel’de kayıtlı anahtarı kullanan servis hesabının protoPayload.authenticationInfo.principalEmail değerini arayın
      • Bilinen aralığın dışındaki callerIp
      • storage.objects.get, compute.instances.list, iam.serviceAccountKeys.create gibi metotları kontrol edin
    • Azure Activity Logs
      • Vercel env var’larında bulunan uygulama kimliği veya service principal temelinde filtreleyin
      • Beklenen aralığın dışındaki callerIpAddress
      • Öncelikle Microsoft.Storage/storageAccounts/listKeys, Microsoft.Compute/virtualMachines/write, Microsoft.Authorization/roleAssignments/write denetleyin
  • Veritabanı erişim günlüklerini arayın
    • Bağlantı dizesi Vercel ortam değişkenlerinde bulunan tüm DB hedefleri
    • Şubat 2026–Nisan 2026 arasındaki tam pencereyi analiz edin
    • Vercel edge IP’leri, VPN, ofis gibi bilinen egress aralıkları dışındaki IP’leri kontrol edin
    • Normal dağıtım pencereleri dışında sızan kimlik bilgileriyle yapılan bağlantıları tespit edin
    • PostgreSQL için pg_stat_activity, log_connections
    • MySQL için general log veya audit plugin
    • MongoDB Atlas için Project Activity Feed içindeki DATA_EXPLORER, CONNECT olayları
  • Ödeme işleme günlüklerini arayın
    • Stripe Dashboard → Developers → Logs
    • Beklenen sunucular dışındaki source_ip
    • /v1/charges, /v1/transfers, /v1/payouts, /v1/customers
    • Braintree ve Adyen’deki eşdeğer günlükleri kontrol edin
    • Henüz döndürülmemiş, non-sensitive env var’da saklanan API anahtarlarına öncelik verin
    • E-posta gönderim hizmeti günlüklerinde beklenmeyen gönderimleri de inceleyin
  • OpenAI, Anthropic, GitHub, AWS, Stripe ve benzerlerinden gelen kendiliğinden olmayan sızmış kimlik bilgisi bildirimleri kontrol edilmeli

• Rotasyon ve yeniden dağıtım birlikte gerekli

  • Vercel dokümantasyonuna göre yalnızca ortam değişkenlerini döndürmek, geçmiş dağıtımlardaki mevcut kimlik bilgisi değerlerini geçersiz kılmaz
  • Önceki dağıtımlar, yeniden dağıtılana kadar eski kimlik bilgilerini kullanmaya devam eder
  • Bu nedenle her rotasyonda, ilgili değişkeni kullanan tüm ortamların yeniden dağıtılması veya eski dağıtımların açıkça devre dışı bırakılması gerekir
  • Öncelik sırası şu şekilde olmalı
    • Bulut sağlayıcısı kimlik bilgileri
    • Veritabanı bağlantı dizeleri
    • Ödeme işleme anahtarları
    • Kimlik doğrulama sırları
    • Üçüncü taraf API anahtarları
    • İzleme ve günlükleme token’ları

• Güvenlik ekipleri için önleyici yanıt

  • Google Workspace Admin Console → Security → API Controls → Third-party app access altında onaylı tüm OAuth uygulamalarını inceleyin
  • Drive, Gmail, Calendar gibi geniş kapsamlı scope’lara sahip uygulamaları işaretleyin
  • Aktif ticari ilişkisi olmayan tedarikçi uygulamalarını araştırın
  • Beklenmeyen IP aralıklarından OAuth token kullanımını izleyin
  • Bilinen kötü amaçlı OAuth Client ID için arama gerekli
    • 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

SIEM tespit mantığı

• OAuth uygulaması anormallikleri, aşama 1–2

  • Bilinen kötü amaçlı OAuth Client ID ile ilişkili token refresh veya authorization olayları için anında alarm üretin
  • Tüm posta erişimi, Drive okuma/yazma, takvim erişimi gibi geniş scope yetki verme olaylarını mevcut tedarikçi listesiyle karşılaştırın
  • Artık iş amaçlı kullanılmayan uygulamalar geri çekme adayı olmalı
  • Onaylı OAuth uygulamalarının token kullanımı şirket ve tedarikçi için beklenen CIDR aralıkları dışındaki IP’lerden geliyorsa araştırılmalı

• İç sistem erişimi ve yanal hareket, aşama 3

  • Olağandışı SSO/SAML kimlik doğrulama olayları
    • Ele geçirilmiş Workspace hesabının daha önce görülmemiş IP, bölge veya cihaz parmak iziyle iç uygulamalarda oturum açması
  • E-posta ve Drive tabanlı kimlik bilgisi toplama
    • API key, secret, token, password, .env gibi anahtar kelimelerle toplu aramalar
    • Paylaşılan kimlik bilgisi depoları, mühendislik runbook’ları, altyapı dokümanlarına erişim
    • Posta yönlendirme kuralı oluşturulması
  • OAuth bağlantılı iç araç erişimi
    • Slack, Jira, GitHub, iç dashboard’lar gibi sistemlerde olağan dışı saatlerde veya farklı altyapıdan oturum oluşturma ya da API etkinliği
  • Yetki yükseltme girişimleri
    • Yeni grup veya rol üyelikleri
    • Kullanılmayan yönetici konsollarına erişim
    • Google Workspace’te Directory API çağrıları, delegation değişiklikleri, diğer kullanıcıların OAuth token’larını listeleme girişimlerini izleyin

• Ortam değişkeni numaralandırması, aşama 4

  • Vercel ekip denetim günlüklerinde env read, list, decrypt niteliğindeki çağrıların anormal hacim ve sıklık kalıplarını tespit edin
  • Önce normal CI/CD build zamanları için bir baseline oluşturulmalı
  • Ardından hacim, zamanlama ve kaynak öznesi baseline dışına çıktığında erişim alarmı üretin
  • Servis hesabı olmayan kullanıcı hesaplarından gelen erişimlere ve normalde projeyle etkileşime girmeyen hesapların erişimlerine dikkat edin

• Alt akış kimlik bilgisi kötüye kullanımı, aşama 5

  • Şubat 2026–Nisan 2026 penceresi boyunca non-sensitive Vercel ortam değişkenlerinde saklanmış tüm kimlik bilgilerine ait hedef servis günlüklerini inceleyin
  • AWS’de belirli access key ID temelinde CloudTrail arayın
  • GCP ve Azure’da servis hesabı veya uygulama kimliği temelinde denetim günlüklerini arayın
  • Stripe, OpenAI, Anthropic, SendGrid, Twilio gibi SaaS API’lerinde dashboard veya API günlüklerinden tanınmayan IP’ler ve çalışma dışı saat kullanımı olup olmadığını kontrol edin
  • Kendi altyapınıza atfedilemeyen kullanım, derhal ele geçirilmiş kimlik bilgisi olarak değerlendirilmeli; rotasyon yapılmalı ve davranış analizi başlatılmalı

• Üçüncü taraf kimlik bilgisi sızıntı uyarıları

  • GitHub secret scanning partner program, AWS compromised key detection, OpenAI, Anthropic, Stripe, Google Cloud gibi kaynaklardan gelen otomatik secret tarama uyarıları izlenmeli
  • Yalnızca dağıtım platformunda bulunan anahtarlara ilişkin uyarılar, basit bir hijyen uyarısı değil, platform ihlali göstergesi olarak ele alınmalı

Tehdit avcılığı için manuel prosedürler

• Google Workspace Admin Console’da manuel arama

  • Admin Console → Reports → Audit and Investigation → OAuth Log Events
  • Application Name = Context.ai veya Client ID = 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
  • Zaman aralığı: Şubat 2026’dan günümüze
  • Sonuç varsa erişimi derhal iptal edin ve olay incelemesini başlatın

• Geniş kapsamlı üçüncü taraf OAuth uygulamalarını gözden geçirme

  • Admin Console → Security → API Controls → Third-party app access → Manage Google Services
  • App access değeri Unrestricted olan uygulamaları sıralayın
  • Her uygulama için kontrol edilecekler
    • Aktif bir tedarikçi ilişkisinin bulunup bulunmadığı
    • Kapsamların iş açısından gerekçesi
    • Son kullanım tarihi
  • 90 günden uzun süredir kullanılmayan uygulamalar geri çekilmelidir

Savunma önerileri

• Anında yapılacaklar, 0~48 saat

  • sensitive olarak işaretlenmemiş tüm Vercel ortam değişkenlerini döndürün
  • Döndürme sonrasında tüm ortamları yeniden deploy edin
  • Kimlik bilgisi, token, anahtar ve secret içeren tüm ortam değişkenlerinde sensitive bayrağını etkinleştirin
  • Google Workspace veya Microsoft Entra yönetici konsolunda OAuth uygulama onaylarını denetleyin
  • Artık aktif olarak kullanılmayan uygulama erişimlerini geri çekin
  • Şubat 2026’dan günümüze kadar, Vercel ortam değişkenlerinde saklanan kimlik bilgilerinin kullanıldığı tüm servislerin erişim günlüklerini inceleyin

• Kısa vadeli güçlendirme, 1~4 hafta

  • HashiCorp Vault, AWS Secrets Manager, Doppler, Infisical gibi özel secret yöneticilerine geçin
  • Platform ortam değişkenlerinde saklamak yerine çalışma zamanında enjeksiyon yaklaşımını kullanın
  • Desteklenen yerlerde uzun ömürlü kimlik bilgilerini kaldırmak için OIDC tabanlı kimlik doğrulama kullanın
  • OAuth uygulama izlemeyi devreye alın
    • Nudge Security, Grip Security, Valence Security veya Google Workspace’in yerleşik yönetim özellikleri
  • Kimlik bilgisi döndürme otomasyonunu kurun
    • 30~90 günlük periyot önerilir
  • OAuth onaylarını, sözleşmeli tedarikçiler gibi üçüncü taraf risk envanteri kapsamına dahil edin

• Yapısal değişiklikler, 1~6 ay

  • Ortam değişkenleri için Zero Trust yaklaşımını benimseyin
    • Deploy platformunda saklanan tüm secret’ların, platform ihlali durumunda açığa çıkabileceğini varsayın
  • En az ayrıcalık kapsamını uygulayın
    • Veritabanı hesaplarında en az ayrıcalık
    • API anahtarlarında işlem kapsamı sınırlandırması
    • Bulut kimlik bilgilerinde uzun ömürlü access key yerine rol tabanlı geçici kimlik bilgileri
  • Kurumsal kimlik sistemlerine erişen tüm OAuth uygulamaları ve entegrasyonlar için üçüncü taraf güvenlik incelemesi ve periyodik yeniden inceleme yapın
  • PaaS platformlarını SBOM/ASPM envanterine dahil edin
    • Harici servis olarak değil, birinci sınıf tedarik zinciri bağımlılığı olarak ele alınmalıdır

• Önerilen izleme

  • Google Workspace Admin Console’da yukarıdaki OAuth Client ID için denetim yapın
  • Vercel denetim günlüklerinde beklenmeyen env.read, env.list API çağrılarını izleyin
  • Şubat~Nisan 2026 arasında Vercel env vars içinde saklanan kimlik bilgilerinin beklenmedik IP veya user agent kullanımı olup olmadığını CloudTrail, GCP Audit Logs, Azure Activity Logs üzerinden inceleyin
  • Bağımlılık ağacında LiteLLM veya Axios varsa, ilgili tavsiyelerde belirtilen IOC’leri de birlikte izleyin
  • Maruz kalma süresi boyunca başlıca API sağlayıcılarının istem dışı sızdırılmış kimlik bilgisi bildirimlerini takip edin

Düzenleyici ve uyumluluk etkileri

• Bu ihlal nedeniyle kimlik bilgileri açığa çıkmış olabilecek kuruluşların aşağıdaki yükümlülükleri değerlendirmesi gerekir

• GDPR

  • Açığa çıkan kimlik bilgileri, AB kişisel verilerinin bulunduğu sistemlere erişim sağladıysa, 72 saatlik bildirim süresi maruziyetin doğrulanmasıyla başlayabilir
  • 10 Nisan’daki OpenAI bildirimi, bazı kuruluşlar için farkındalık zamanının 19 Nisan’daki kamuya açıklamadan daha erken olabileceği sorusunu gündeme getiriyor

• CCPA/CPRA

  • Tüketici verilerine erişim sağlayan kimlik bilgilerinin açığa çıkması, bildirim yükümlülüğünü tetikleyebilir

• PCI DSS

  • Stripe, Braintree, Adyen gibi ödeme işleme kimlik bilgilerinin açığa çıkması, olay müdahale süreci ve adli inceleme gereksinimlerini doğurabilir

• SOC 2

  • Olay kayıtları, kimlik bilgisi döndürme adımları ve güncellenmiş kontroller, sürekli izleme kanıtlarına yansıtılmalıdır

• SEC Cybersecurity Rules 8-K

  • Önemli kabul edilmesi durumunda, halka açık şirketler için 4 iş günü içinde açıklama yükümlülüğü vardır
  • Haberde, gerçek yetkisiz erişim kullanımının henüz bilinmiyor olabileceği; buna rağmen birçok düzenleyici çerçevenin istismarın doğrulanmasına değil, maruziyetin kendisine göre işleyebileceği belirtiliyor

İhlal göstergeleri

• Doğrulanmış IoC

  • OAuth Client ID
    • 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
    • Tehlikeye atılmış Context.ai OAuth uygulamasıyla ilişkili değer

[GN⁺]

Hacker News görüşleri

• Vercel’in environment variable arayüzünü ilk sunduğu dönemde sensitive seçeneğinin hiç olmadığını hatırlatıyor. Bu özelliğin gelmesi neredeyse 2 yıldan fazla sürmüştü. İlgili tartışmalar GitHub discussion ve Vercel changelog içinde duruyor

  • Arayüzde sensitive bayrağı olsa da bunun runtime davranışını değiştirmediği düşünülüyor. Değer build sırasında process.env içine girdikten sonra, ortalığı tarayan bir bağımlılık varsa onu okuyabilir. Asıl sorun, tüm sırların tek bir env kesesine doldurulup build araçlarına topluca verilmesi gibi görünüyor. Cloudflare’ın scoped bindings yaklaşımı ya da Fly bunu zaten ayırıyor; diğer platformların yavaş kaldığı yorumu yapılıyor
  • sensitive’in okunamaz anlamına gelmediği, sadece arayüzde göstermeme seviyesinde bir anlam taşıdığı düşünülüyor. action fonksiyonu ya da route içinde props biraz fazla döndürülse bile kolayca sızabilir. Bu tür sorunları gerçekten önlemek için environment değerlerini uygulamanın kendi anahtarıyla şifrelemek gerektiği, ayrıştırma imkânı sınırlı olduğundan bazı sırların source içine baked-in edilmesinin geçici bir çözüm olabileceği söyleniyor. Bu durumda saldırganın yalnızca environment değerlerini okumakla kalmayıp build çıktısını indirip çözme anahtarını da bulması gerekir; bu da çıtayı biraz yükseltir. İdeal değil ama geçici çözüm olarak işe yarayabilir deniyor

• Bunun bu şekilde yakalanmış olması gerçekten utanç verici bir olay gibi geliyor. Alıntılanan bilgiye göre Lumma Stealer bulaşmasının Context.ai çalışanının Roblox exploit script’i indirmesiyle başlamış olması özellikle şaşırtıcı bulunuyor

• CEO’nun saldırganların hızlı hareketini açıkça yapay zeka ile hızlanmış saldırı tekniklerine bağlaması, bazılarına göre neredeyse hiç kanıta dayanmıyor. Bu yüzden ortada somut olarak görülen bilginin de çok az olduğu hissi var

  • Günümüzde yapay zekanın saçma mazeretler piyasasını bile sarstığı ve medyanın bunu doğrulamadan tekrar ediyor gibi göründüğü yönünde alaycı bir yorum var
  • Öte yandan vibe coded çözümlerin Vercel’i sık önermesi de akla geliyor. Bunun, geçmişteki Axios önerme modasına benzediği söyleniyor

• Stage 2 açıklaması bazılarına pek anlaşılır gelmemiş. ContextAI uygulaması Google mail, drive, calendar gibi yetkilerin hepsini istediyse bunun aşırı olduğu düşünülüyor. Küçük bir şirket de değilken bunun kendi environment’ı dışında çalıştırılmasına onay verilmiş olması inanılmaz bulunuyor. Ancak Context.ai’nin güvenlik güncellemesi yazısı, bunun Vercel çalışanlarından birinin kişisel olarak kendi Google Workspace’ine tam erişim verdiği bir tercih gibi okunmasına yol açıyor

• Bu akışın tam olarak nasıl işlediği hâlâ net gelmiyor. Buradaki OAuth token’ın, Sign in with Google sonrası alınan token olup olmadığı soruluyor. Normalde bunun belirli bir Google App’in client id ve client secret’ına bağlı olması gerekmez mi deniyor. Saldırgan kullanıcı OAuth token’ını ve client bilgilerini bilse bile Drive gibi servislere erişmesi anlaşılabilir, ama oradan Vercel’in control plane girişine nasıl geçildiği hâlâ ikna edici gelmiyor. Sonunda Google Drive içinde credential mı bulunduğu merak ediliyor

  • Raporun bu kısmı net anlatmadığı düşünülüyor. Bu yüzden aslında daha da utanç verici bir hata olmuş ve bunun üstü örtülüyor olabilir diye tahmin ediliyor. Drive ya da Gmail içindeki bir parola da olabilir, başka bir yorumda denildiği gibi passwordless login link de olabilir
  • OAuth süreci tamamlandıktan sonra nihayetinde bir session token alındığı ve bununla API isteği atılabildiği açıklamasının kritik nokta olduğu düşünülüyor. Verilen token’ın kurbanın inbox erişimini de kapsıyor olma ihtimali yüksek; saldırgan da e-postaları okuyup tek kullanımlık parola, magic link veya başka hassas bilgileri ele geçirmiş olabilir deniyor
  • Bazıları da aynı şekilde karışık buluyor. Gerçekten Context.ai’nin OAuth uygulaması mı ele geçirildi, dolayısıyla Context.ai’nin görebildiği tüm müşteri workspace’lerini saldırgan da mı görmeye başladı diye soruluyor. Ama neden sorumluluğun özellikle tek bir çalışanda toplandığı da anlaşılmıyor. Kilit noktanın, o Vercel çalışanının Context.ai’ye Vercel’in tüm workspace’ini okuyacak onayı verip vermediği olduğu düşünülüyor

• “OAuth uygulamalarını üçüncü taraf vendor gibi ele almak, uzun ömürlü platform sırlarını kaldırmak ve provider-side compromise varsayımıyla tasarlamak gerekir” fikrine katılınsa da, tedarikçi tarafı ihlalini baştan varsayarak sistem tasarlamanın gerçekten çok zor olduğu söyleniyor. Sonuçta güven zaten sistemin başlangıç noktası

  • Kendi SaaS ürünlerinde OAuth uygulamaları üzerine düşünenler için bunun çok zor bir problem olduğu belirtiliyor. Bunu iyi çözen bir marketplace olup olmadığı merak ediliyor. Cloudflare, Salesloft olayından sonra tüm üçüncü taraf OAuth ve API trafiğinin kendi üzerinden proxy edilmesini önermişti; ama bunun tehdit vektörünü sadece başka bir yere taşımak gibi hissettirdiği söyleniyor. scope’u daraltma, süreleri kısaltma, client secret rotation gibi temel kurallar dışında ne yapılabileceği konusunda belirsizlik var. Aklına gelen ek önlem olarak client bazlı çıkış IP allowlist’leri anılıyor
  • Bu tür örneklerin, uzun süredir anlatılan zero-trust yaklaşımının önemli ölçüde pazarlama dili olduğunu düşündürdüğü de söyleniyor. Gerçek security by design varsa, tedarik zinciri saldırısıyla üst sağlayıcının tamamen ele geçirilebileceği varsayımı daha en baştan sisteme dahil edilmeliydi deniyor

• İleride bu tür olayların çok daha fazla görüleceği düşünülüyor. Büyük şirketler de küçük firmalar da yapay zeka araçlarını geniş ölçekte denediği için oluşan risk borcunun artık tüm BT ekonomisini gecikmeli biçimde vurduğu söyleniyor. Bu yüzden olay, “AI-enabled tradecraft”ten çok, şirket yönetimlerinin hız uğruna tüm kuruma yapay zeka araçları kurdurup denettirmesinin sonucu gibi okunuyor. Saldırının kendisi çok sıradan; zorunlu bir yapay zeka kurulum allowlist’i olmayan hemen her şirket buna açık durumda. Context benzeri araçların yerelde ve SaaS genelinde ne kadar yaygın kurulu olduğunu bir IT yöneticisine sorarsanız muhtemelen sayı yüksek çıkacaktır. Sorun şu ki bu araçlar fiilen her şeye erişiyor ve bunları yönetecek güvenlik sağlayıcıları ya da RBAC ekosistemi ancak 18–24 ay sonra ciddi biçimde oluşacak gibi görünüyor. Vercel burada kömür madenindeki kanarya gibi duruyor ve hedefin yalnızca Context olmadığı düşünülüyor. Bir yerde patlarsa başkalarının da peş peşe ortaya çıkabileceği, bilinen ama göz ardı edilen bir tehdit vektörü olduğu söyleniyor. Önümüzdeki 6 ayın özellikle zor geçebileceği, herkesin şu anda yapay zeka kurulum envanterini denetliyor olması ya da denetlemesi gerektiği, saldırganların da erişimleri kesilmeden önce ellerindeki yetkiyle hareket edeceği tahmin ediliyor. Bunu söyleyen kişinin tech sektöründe güvenlik sorumlusu olduğu da ekleniyor

  • Bazıları da yıllardır haberlerde garip güvenlik olaylarının daha sık görüleceğini söylediğini belirtiyor
  • Aynı görüşü paylaşanlar, oldukça ilginç bir dönemin yaşandığını düşünüyor

• “OAuth güven ilişkisi tüm platformun açığa çıkmasına dönüştü, CEO saldırı hızını AI’a bağladı, tespitten açıklamaya kadar olan gecikme de soru işareti” özetine bakınca, bazılarına göre görülen asıl başarısızlık oldukça tanıdık. Aşırı yetkili kullanıcı hesapları vardı ve benzer başka hesaplar da olabilir. 2FA veya ZeroTrust ya hiç yoktu ya da çok sınırlıydı gibi görünüyor. Genel güvenlik hijyeninin de zayıf olduğu düşünülüyor

  • Gelecekte AI’ı suçlamanın, bir site çökünce otomatik olarak DDoS’u suçlamak gibi her olaya uyan genel bir güvenlik mazeretine dönüşebileceği söyleniyor

• İnsanların sık kaçırdığı bir nokta daha var. Vercel’de environment variable’ları rotate etmek eski deployment’ları otomatik olarak geçersiz kılmıyor; bu yüzden önceki deploy’lar yeniden deploy edilene ya da silinene kadar eski credential’larla çalışmayı sürdürüyor. Bu nedenle duyuru sonrası anahtarlar değiştirilmiş olsa bile tüm deployment’lar yeniden çıkarılmadıysa sızan değerler hâlâ aktif olabilir. Ayrıca Google Workspace içindeki OAuth onaylarını da mutlaka kontrol etmek gerektiği söyleniyor. Admin Console > Security > API Controls > Third-party app access yolunda, iki yıl önce bir demo için onaylanmış bir uygulamanın hâlâ mail ve Drive üzerinde tam yetki taşıdığı görülebilir

  • Bu yüzden bazı ekipler birden fazla Google hesabını ayrı kullanıyor. Ama birçok organizasyon Google Workspace’in kullanıcı başı maliyeti nedeniyle bunu yapamıyor. Bir yorumcu da eski iş yerinde bu tür OAuth onaylarının ana hesap yerine ayrı bir hesapla verilmesini önermiş ama başarılı olamamış
  • Normalde credential rotation denince insanların aklına eski credential’ların geçersiz kılınması da geliyor. Yenisini üretip eskisini açık bırakmak neredeyse hiç duyulmuş bir yaklaşım değil deniyor
  • Rapordaki o ifadenin kafa karıştırıcı olduğu da söyleniyor. Eski deployment’ın eski env var kullanması tek başına o credential’ın hâlâ geçerli olup olmadığını belirlemez. Bunun gizlilikten çok erişilebilirliği etkileyen bir footgun olduğu düşünülüyor. Rapordaki “Environment variable enumeration (Stage 4)” kısmı da tuhaf bulunuyor. Özellikle “service account yerine user account’tan veya normalde projeyle etkileşmeyen bir hesaptan environment variable erişimi olup olmadığına bakın” ifadesi, insanların gerçekten Vercel env var’larından credential çıkarıp başka sistemlerde kullandığını mı gösteriyor diye yabancı geliyor
  • Preview deploy konusu daha da ciddi bulunuyor. Her PR için aynı env var’larla bir tane oluşuyor ve kimse temizlemiyor. Anahtarları yenileyip production’ı yeniden deploy etseniz bile, içinde eski değerler olan yüzlerce zombi preview kalmış olabilir
  • rotation yapılırken elbette eski değişkenlerin de sona erdirilmesi gerektiği vurgulanıyor

• Bu rapordaki bazı ayrıntılar, özellikle 2024–2025’te başlayan zaman çizelgesi, başka yerlerde yaygın biçimde yer almamış gibi görünüyor. Örneğin “2024 sonu–2025 başında saldırganlar Context.ai OAuth erişiminden Vercel çalışanının Google Workspace hesabına pivot yaptı”, “2025 başı–ortasında iç Vercel sistemlerine erişim ve müşteri environment variable’larının listelenmesi başladı” gibi tarihler için kaynağın ne olduğu soruluyor

  • Bazılarına göre bu tarihler tamamen uydurulmuş ve büyük ihtimalle bir hallucination olabilir