Çalınmış bir GitHub OAuth token'ı, 22 depoda gizli loader taşıyan sahte commit'ler oluşturmak için kullanıldı

22 depoya yayılan sahte commit'ler

dev.to'daki birinci ağızdan anlatıma göre bir geliştirici, bir saldırganın en yeni commit'lerinin sahte kopyalarını 22 depoya ve 42 dal'a force-push ettiğini, sonrasında dört dalda daha eski bir varyant taşıyan kopyalar bulduğunu fark etti. Sahte commit'ler mesaj, yazar adı ve tarih açısından orijinalleriyle eşleşiyordu ve GitHub'ın güvenlik günlüğü push'ları geliştiricinin kendi hesabına atfediyordu.

Aktivite betiklenmiş görünüyordu: gönderi, 2026-10-22'de yaklaşık 03:58 UTC ve 2026-11-05'te yaklaşık 08:00 UTC civarında iki dalga push olduğunu, her birinin yaklaşık iki dakika içinde kabaca 30 depaya isabet ettiğini anlatıyor.

Başarısız bir build ilk ipucuydu

Küçük bir faturalama uygulamasının Netlify deployment'i güncel olmayan lockfile hatasıyla başarısız oldu ve package.json, geliştiricinin hiç eklemediği iki bağımlılık içeriyordu: dotenv ve node-fetch. Alışılmış düzeltme, yani lockfile'ı yeniden oluşturup tekrar push etmek, o paketleri kuracak ve build sırasında enjekte edilen kodu çalıştıracaktı. Bozuk build, kodun çalışmasını engelleyen tek şeydi.

Belirleyici kanıt Git'in ham commit verisindeydi. Git her commit'te hem bir yazar hem de bir committer kaydeder ve GitHub'ın arayüzü yalnızca yazarı gösterir. Saldırgan yazar kimliğini birebir kopyalamıştı, ancak sahtelerdeki committer zaman damgaları -0800 veya -0700 saat dilimlerini taşırken Lagos'ta yaşayan geliştirici +0100 ile commit yapıyordu. GitHub'daki commit SHA'ları da yerel klonlarla eşleşmiyordu.

Sahte commit'ler ne yerleştirdi

Her sahte commit, rutin geliştirici eylemlerine bağlanmış bir loader ekliyordu:

• Depo kökünde ve monorepo paketlerinin içinde init adlı bir dosya. İlk 30 satırı geçici bir klasör oluşturuyor; gerçek payload ise son satırda yaklaşık 13.000 boşluktan sonra yerleştirilmiş, editörlerde ve diff'lerde görünmez obfuscate edilmiş JavaScript. Önceki dalga aynı hileyle api.js adlı bir dosya kullanmıştı.
• Yeniden yazılmış package.json script'leri; dev ve build gibi komutlara node init && öneki eklenmişti, böylece her çalıştırma önce loader'ı çalıştırıyordu.
• Aynı boşlukla gizlenmiş kod, postcss.config.mjs, astro.config.mjs, eslint.config.js ve tailwind.config.js dahil build zamanı yapılandırma dosyalarının sonuna eklenmişti; her biri sıradan ESM boilerplate'i gibi okunan bir createRequire import başlığı kazanmıştı.
• Bir Vite uygulamasında, sona eklenen bir async bloğu, depoya commit edilmiş bir .env dosyasında base64 olarak saklanan bir URL'yi fetch edip indirilen metni evaluate ediyordu. Decode edildiğinde info.anondrop[.]net adresine işaret ediyordu; yani canlı payload hiçbir zaman depoda bulunmuyordu.
• FolderOpen'da çalışacak şekilde ayarlanmış bir .vscode/tasks.json shell görevi; çıktıyı gizleyip otomatik görevleri etkinleştirerek, font (.lfk) olarak kamufle edilmiş bir dosyayı node ile çalıştırıyordu. Klasörü VS Code veya Cursor'da açmak bunu tetikleyebilirdi, çünkü Workspace Trust insanların kendi depolarına güvenmesini nadiren engeller.
• .env* ve .vscode/* kurallarını çıkaran yeniden yazılmış bir .gitignore — dosyaların depoya girmesi böylece mümkün oldu — ve saldırganın Windows push araçlarının görünürde kalıntıları olan temp_auto_push.bat ve branch_structure.json gibi girdiler kazanmıştı. Birçok dosya ayrıca Windows satır sonlarına dönüştürülmüş, gerçek değişiklikler büyük diff'lerin içine gömülmüştü.

Kod nerede çalıştı

Gönderiye göre bir GitHub Actions workflow'u sahte commit'leri başarıyla build etti. Build komutu önce loader'ı çalıştırdığından yeşil onay işareti, kodun CI'da, geliştiricinin o zamandan beri döndürdüğü bir Convex deploy key barındıran bir ortamda çalıştığı anlamına geliyordu. node_modules'ü hâlihazırda mevcut olan eski bir yerel worktree de payload'ı bir dev komutu üzerinden çalıştırmış olabilir.

Muhtemel giriş yolu

Hesapta kişisel erişim token'ı (personal access token) yoktu ve SSH anahtarı yoktu; geriye OAuth token'ı olası kimlik bilgisi olarak kalıyordu. Git Credential Manager, VS Code ve Cursor gibi editörlerin içindeki GitHub oturum açma akışı ve GitHub CLI'nin tümü makinede bir token saklar ve bulaşmış bir bilgisayardan çalınan bir token, o kullanıcı olarak push yapmak için yeterlidir. Geliştirici yeni edinilen bir Windows iş istasyonundan şüpheleniyor, bunu kanıtlayamıyor ve makineyi ne olursa olsun silmeyi planlıyor.

Yazarın altını çizdiği nokta şu: şifreyi değiştirmek hiçbir şeyi değiştirmeyecekti; OAuth token'ları şifre değişikliklerinden sonra da varlığını sürdürür, iki faktörlü doğrulama adımlarını atlar ve doğrudan iptal edilmeleri gerekir.

Remediation süreci, Netlify, Vercel ve CloudCannon hariç tüm OAuth ve GitHub App yetkilendirmelerini iptal etmeyi, tüm oturumları kapatmayı, bir depoyu gerçek yerel commit'lerden geri yüklemeyi ve diğer dalları, geçmişi yeniden yazmak yerine üst üste kaldırma commit'leriyle temizlemeyi içeriyordu; bu işlem doğrudan Git objeleri üzerinde yapıldı, böylece bulaşmış kod hiç checkout edilmedi veya çalıştırılmadı. Sahteler geçmişte durmaya devam ediyor ve ayrı bir AI agent, her lockfile'ın hâlâ kurulup kurulmadığı dahil 42 temizlik commit'inin tümünü inceledi.

Neden önemli

Bu saldırı egzotik bir şey gerektirmiyordu: tek bir çalınmış token, kopyalanmış commit metaverisi ve boşluklarla ile yapılandırma dosyalarına gizlenmiş payload'lar. Çıkarımlar genellenebilir. Şifre döndürme ve 2FA, OAuth yetkilerini iptal etmez; dolayısıyla gerçek denetim aracı token hijyenidir. GitHub arayüzündeki yazar metaverisinin sahtelenmesi son derece kolaydır; bu da committer saat dilimlerini ve yerel klonlarla SHA karşılaştırmalarını pratik kontroller hâline getirir. Lockfile hatasının ardında tanıdık olmayan bir bağımlılık, sıradan bir iş değil bir güvenlik sinyalidir. Ve teslim vektörleri — bir dev komutu, bir CI build'i, bir editörde klasör açmak — geliştiricilerin sorgusuz her gün gerçekleştirdiği eylemlerdir; saldırganın onları tam da bu yüzden seçti.