GitHub etiketleri nasıl bir kimlik avı deposuna dönüştürüldü
22 Mayıs 2026'de saat 22:32 UTC ile gece yarısı arasında, bir saldırgan Laravel Lang organizasyonundaki dört PHP paketinin tüm git etiketlerini yeniden yazdı. Tek bir org-wide push yetkisini suistimal ederek, laravel-lang/lang (7.800 GitHub yıldızı), laravel-lang/http-statuses, laravel-lang/attributes ve laravel-lang/actions deposundaki 500'den fazla sürümü etkiledi. Saldırgan yeni bir kötü amaçlı sürüm yayınlamadı. Bunun yerine, GitHub'ın etiket mekanizmasındaki bir özelliği kullandı: bir tag, kendi deposundaki commit yerine bir fork'taki commit'e yönlendirilebilir ve Composer bu durumu ayırt edemez.
Saldırganın yöntemi basittir: kontrol altındaki fork deposunda kötü amaçlı commit'ler oluşturdu ve laravel-lang organizasyonunun resmi deposundaki mevcut tüm etiketleri (v1.0.0, v2.5.1, v3.4.5 vb.) force-push yaparak bu fork commit'lerine yönlendirdi. Aikido'nun analizi, laravel-lang/lang'daki 502 etiketin, laravel-lang/attributes'taki 86 etiketin ve laravel-lang/actions'taki 46 etiketin tamamının bu şekilde zehirlendiğini doğruladı.
Composer gibi bağımlılık yöneticileri GitHub etiketlerini sürüm kaynağı olarak kullanır ve etiketin hangi fork'a işaret ettiğini kontrol etmez. composer update komutu çalıştırıldığında, ^3.4 veya ~2.0 gibi aralık tanımlarına sahip projeler otomatik olarak en yüksek sürüm numarasına sahip etikete çözümlenir. Artık o etiket resmi kaynak kodunu değil kötü amaçlı fork'u işaret ediyordu. Tek bir kimlik bilgisinin suistimalı milyonlarca geliştiricinin kullandığı bir güven mekanizmasını geçersiz kılmıştı.
Composer autoload.files mekanizması otomatik yürütmeyi nasıl tetikledi
Etkilenen sürümlere enjekte edilen kötü amaçlı kod src/helpers.php adında görünüşte masum bir dosyaydı. Bu dosyanın kritik özelliği, Composer'ın composer.json dosyasındaki autoload.files bölümüne eklenmiş olmasıydı. Composer'ın autoload mekanizması iki farklı modda çalışır: autoload.psr-4 sınıf ismine göre lazy loading yaparken, autoload.files listedeki dosyaları vendor/autoload.php require edildiği anda koşulsuz olarak çalıştırır.
``json "autoload": { "files": ["src/helpers.php"] } ``
Bu ayar, her Laravel veya PHP projesinin başlangıç noktasında yer alan require __DIR__.'/../vendor/autoload.php'; satırının yürütüldüğü an kötü amaçlı PHP kodunun otomatik olarak çalışmasını sağladı. Hiçbir sınıf çağrısına, method kullanımına veya kullanıcı etkileşimine gerek yoktu. StepSecurity, izole ortamda laravel-lang/http-statuses v3.4.5'i bir GitHub Actions runner'ına kurduğunda, composer install komutundan sadece saniyeler sonra /tmp dizinine gizli PHP ve ELF binary'lerinin yazıldığını gözlemledi.
Saldırganın seçtiği bu yöntem, supply chain saldırılarında nadir görülen bir etkiye sahipti: kod hiçbir zaman resmi GitHub deposuna commit edilmedi, dolayısıyla kod incelemeleri veya otomatik güvenlik tarayıcıları tehlikeyi tespit edemedi. Packagist üzerindeki paket meta verileri de normal görünüyordu çünkü sürüm numaraları ve tarihler değişmemişti – yalnızca etiketlerin işaret ettiği commit SHA'ları sessizce değiştirilmişti.
Kimlik avı malwarısı hangi verileri çalışıyor ve nasıl davranıyor
src/helpers.php dosyası bir dropper rolü oynadı: makineyi parmak izine aldı, çalışma ortamını doğruladı ve ardından flipboxstudio[.]info adresinden ikinci aşama payload'unu indirdi. Bu domain, meşru Endonezya yazılım danışmanlık şirketi flipboxstudio.com sitesinin typosquat versiyonuydu. Aikido'nun tersine mühendislik, dropper kodunun C2 sunucu adresini bir integer dizisi içine gizlediğini ve SSL sertifika doğrulamasını devre dışı bırakarak tespit edilmeyi zorlaştırdığını gösterdi. Dropper ayrıca parmak izi alma ve tek sefer çalıştırma mantığı içeriyordu; aynı makinede birden fazla yürütülmesi engellendi.
İkinci aşama payload, ~5.900 satırlık bir PHP kimlik avı aracıydı ve 15 uzman koleksiyoncu modül içeriyordu:
- Bulut kimlik bilgileri: AWS (~/.aws/credentials, ortam değişkenleri), Google Cloud (gcloud auth list, ADC), Azure CLI, DigitalOcean API anahtarları - CI/CD sırları: GITHUB_TOKEN, GitLab CI token'ları, Kubernetes secrets, HashiCorp Vault token'ları, Docker registry kimlik bilgileri - SSH anahtarları: ~/.ssh/ dizinindeki tüm private key'ler ve known_hosts dosyaları - Tarayıcı verileri: 17 farklı Chromium tabanlı tarayıcı (Chrome, Brave, Edge, Opera, Vivaldi), Firefox, Tor Browser profilleri; çerezler, oturum token'ları, kaydedilmiş şifreler - Şifre yöneticileri: KeePass, 1Password, Bitwarden vault dosyaları - Kriptografi cüzdanları: MetaMask, Exodus, Electrum, Ledger Live anahtarları - Ortam dosyaları: .env dosyalarındaki tüm değişkenler (veritabanı parolaları, API anahtarları, Stripe secret'lar, Slack webhook'ları)
Windows sistemlerinde, payload ek olarak DebugElevator adında bir binary çalıştırdı. Bu executable, Chrome 127 ile tanıtılan App-Bound Encryption mekanizmasını bypass etmek için tasarlanmıştı; Chrome, Brave ve Edge tarayıcılarının şifrelenmiş kimlik bilgisi veritabanlarını açmak için gereken kriptografik anahtarları Windows'un hafızasından çıkardı.
Toplanan tüm veriler AES-256 ile şifrelendi ve bir POST isteği ile exfiltrasyon sunucusuna gönderildi. StepSecurity'nin gözlemi, başlangıçtan silmeye kadar tüm sürecin 3,16 saniye sürdüğünü ve malware'in orphan process olarak init'e reparent edilerek GitHub Actions workflow step sınırlarını atlayarak hayatta kaldığını gösterdi.
Etkilenen geliştirici ve CI/CD ortamları için risk profili
Aikido 233 doğrulanmış kötü amaçlı sürüm tespit ederken, Socket yaklaşık 700 sürümün potansiyel olarak etkilendiğini tahmin ediyor.
Risk altındaki sistemler şu özelliklere sahipti:
Geliştirici makineleri: Composer bağımlılıklarını düzenli güncelleyen herhangi bir Laravel geliştiricisi, özellikle composer update komutunu sürüm aralıklarıyla (^, ~, *) kullanıyorlarsa ve composer.lock dosyalarını 22 Mayıs öncesi commit SHA'larına kilitlemedilerse riskli durumda.
CI/CD pipeline'ları: GitHub Actions, GitLab CI, CircleCI, Travis CI gibi otomatik derleme sistemleri en yüksek risk altındaydı. Bu sistemler genellikle composer install --no-dev veya composer update komutlarını temiz ortamlarda çalıştırır ve GITHUB_TOKEN, AWS kimlik bilgileri, Kubernetes API token'ları gibi yüksek yetkili sırları ortam değişkeni olarak enjekte eder. StepSecurity'nin deneyi, malware'in bu ortamlarda saniyeler içinde token'ları topladığını ve exfiltrate ettiğini gösterdi.
Konteyner ve üretim ortamları: Docker image'ları veya production sunucuları composer install çalıştırıyorsa ve bağımlılık kilitleri güncellenmiş olması halinde, üretim sistemlerine de sızma mümkün. Çoğu production deployment stratejisi lock dosyalarını kullandığından, bu riskler daha sınırlı olabilir – eğer lock dosyası 22 Mayıs öncesi oluşturulduysa.
Versiyon pinleme durumu: composer.json dosyasında "laravel-lang/lang": "3.4.5" gibi tam sürüm numarası belirtilmiş olsa bile, Composer o etiketi çözümlerken artık kötü amaçlı fork commit'ini indiriyordu. Güvenli tek senaryo, composer.lock dosyasının 22 Mayıs 2026 saat 22:32 UTC öncesinde oluşturulmuş ve hiç güncellenmemiş olmasıydı.
Ancak tüm Laravel projeleri etkilenmedi. Sadece bu dört paketi doğrudan veya dolaylı olarak bağımlılık olarak kullanan ve 22 Mayıs sonrası Composer işlemi çalıştıran projeler risk altındaydı. Laravel Lang paketleri çoğunlukla çok dilli içerik yönetimiyle ilgili olduğundan, İngilizce dışında dil desteği olmayan veya bu paketleri kullanmayan projeler etkilenmedi.
Packagist ve Laravel Lang organizasyonunun yanıtı
Packagist, PHP ekosisteminin merkezi paket deposu olarak, kötü amaçlı sürümleri kaldırdı ve etkilenen paketleri geçici olarak listeden çıkardı. Bu müdahale yeni kurulumları durdurdu ancak zaten etkilenen sistemleri otomatik olarak temizlemedi.
Laravel Lang maintainer'ları, saldırganın org-wide push erişimine sahip tek bir kimlik bilgisini suistimal ettiğini belirttiler. Ancak bu kimlik bilgisinin nasıl veya ne zaman ele geçirildiğine dair bilgi paylaşılmadı. Organizasyon saldırıya yanıt olarak tüm erişim token'larını iptal etti ve iki faktörlü kimlik doğrulama (2FA) gereksinimini zorunlu hale getirdi.
Güvenlik araştırmacıları, bu olayın GitHub'ın etiket mekanizmasındaki tasarım zayıflığını gözler önüne serdiğini vurguladılar. Bir tag'in fork'a işaret edebilmesi GitHub'ın fork network yönetimi için bir özelliktir, ancak bağımlılık yöneticilerinin bu durumu algılayamaması bir güvenlik boşluğu oluşturuyor. Composer, npm, pip gibi araçlar etiket çözümlemesi sırasında commit'in orijin repo'suna mı yoksa fork'a mı ait olduğunu doğrulamıyor.
Why automatic execution during package install creates unique supply chain risk
Bu saldırı birkaç önemli güvenlik dersini vurguluyor:
Otomatik yükleme mekanizmalarının tehlikeleri: Composer'ın autoload.files özelliği, runtime'da lazy loading yerine projenin başlangıç noktasında koşulsuz dosya yürütme imkanı veriyor. Bu, yazılım mühendisliği pratiğinde yaygın olarak kullanılan bir özellik olsa da, güvenilir olmayan kaynaklarda ciddi bir saldırı vektörü oluşturuyor. Benzer mekanizmalar npm'in preinstall hook'ları, Python'un setup.py dosyaları ve Ruby'nin extconf.rb scriptlerinde de mevcut.
Etiket sabitliğinin yanıltıcı güveni: Geliştiriciler genellikle v3.4.5 gibi bir etiketin immutable (değiştirilemez) olduğunu varsayar. Ancak Git etiketleri aslında mutable referans'lardır ve force-push ile yeniden yazılabilir. Commit SHA'ları değiştirilemez ancak pratikte çoğu bağımlılık yöneticisi ve geliştirici SHA yerine etiket kullanır çünkü okunabilir ve anlamlıdırlar.
Fork ağı üzerinden güven ihlali: GitHub'ın fork modeli upstream ve downstream repo'lar arasında gevşek bir bağlantı kurar. Saldırgan, fork'unda kötü amaçlı kod yazıp upstream repo'daki etiketleri bu fork commit'lerine yönlendirerek, resmi repo'nun güvenilirliğini kullanabildi. Packagist ve diğer paket kayıtları, etiketin işaret ettiği commit'in hangi repo'ya ait olduğunu doğrulamıyor.
Sessiz veri toplama: Modern credential stealer'lar geleneksel antivirüs yazılımlarının tespit edebildiği executable payload'lar yerine script tabanlı koleksiyoncular kullanıyor. PHP, Python, Node.js gibi betik dilleri zaten development ortamlarında çalıştığı için şüphe uyandırmıyor.
How to verify if your project was compromised and remediate
Eğer Laravel veya başka bir PHP framework'ü kullanıyorsan ve laravel-lang paketlerine doğrudan veya dolaylı bağımlılığın varsa, şimdi yapman gereken:
1. Composer.lock dosyasını kontrol et: 22 Mayıs 2026 saat 22:32 UTC sonrasında oluşturulmuş veya güncellenmiş composer.lock dosyaları risk altında. git log composer.lock komutu ile son değişiklik tarihini kontrol et.
2. Bağımlılık ağacını tara: composer show -t | grep laravel-lang komutuyla laravel-lang paketlerinin doğrudan veya dolaylı olarak kullanıldığını doğrula.
3. Ortam değişkenlerini ve token'ları döndür: Eğer etkilenmiş olma ihtimalin varsa, şu kimlik bilgilerini derhal iptal et ve yenile: - GitHub personal access token'ları ve SSH anahtarları - AWS IAM access key'leri ve secret key'leri - Heroku, DigitalOcean, Google Cloud API token'ları - Veritabanı parolaları ve .env dosyasındaki tüm sırlar - CI/CD sistemlerindeki tüm secret değişkenler
4. Tarayıcı oturumlarını sonlandır: Tüm tarayıcılardaki aktif oturumları kapat, özellikle bulut hizmetleri, GitHub, GitLab, AWS Console gibi kritik platformlarda.
5. CI/CD log'larını incele: GitHub Actions, GitLab CI veya diğer otomasyonlarda 22 Mayıs sonrası çalışan workflow'larda beklenmedik network bağlantıları, /tmp dizini yazımı veya flipboxstudio.info domain'ine yapılan istekleri ara.
6. Composer.lock'u sabit commit SHA'larına kilitle: İleride benzer saldırıları önlemek için, kritik bağımlılıkları etiket yerine doğrudan commit SHA'sına kilitlemeyi düşün. Ancak bu, güvenlik güncellemelerini almayı zorlaştırır; alternatif olarak composer.lock dosyasını sıkı version control altında tut ve güncellemeleri manuel olarak gözden geçir.
7. İki faktörlü kimlik doğrulamayı etkinleştir: GitHub, Packagist, npm ve tüm paket kayıtları için 2FA kullan.
8. Bağımlılık imza doğrulamasını kullan: Sigstore, in-toto gibi çözümler ve PHP ekosisteminde gelişmekte olan paket imzalama standartları, gelecekte bu tür saldırıları algılamaya yardımcı olabilir.
Eğer laravel-lang paketlerine bağımlılığın varsa ve 22 Mayıs 2026 sonrası composer update çalıştırdıysan: tüm kimlik bilgilerini ve token'ları derhal döndür; composer.lock dosyasını 22 Mayıs öncesi bir commit'e geri döndür; güvenli bir yedekten bağımlılıkları yeniden yükle ve tüm sırlarını sıfırla.
