GitHub Actions pull_request_target pwn request'leri: fork PR'ları sırlarınıza nasıl ulaşır

GitHub Actions'taki pull_request_target tetikleyicisi, pull request güvenilmeyen bir fork'tan gelse bile workflow'u deponun varsayılan dalından tüm sırlarla ve okuma/yazma yetkili bir token ile çalıştırır. Bu kombinasyon yalnızca fork'tan gelen hiçbir şey çalıştırılmadığı sürece güvenlidir ve bir dev.to açıklaması bu çizginin ne sıklıkla aşıldığını, Ultralytics projesine ne olduğuna mal olduğunu ve GitHub'ın o zamandan bu yana sunduğu koruma önlemlerini adım adım anlatıyor.

Her tetikleyici gerçekte ne alıyor

Yazıda ortaya konduğu üzere, ayrım workflow dosyasının nereden geldiği ve kendisine ne verildiğidir. Sıradan bir pull_request olayı, workflow'u pull request'in merge commit'inde bulunan içerikten — yani fork'un kontrol ettiği içerikten — çalıştırır; bu nedenle GitHub ona salt okunur bir token verir ve sırları tamamen vermez. pull_request_target bunu tersine çevirir: workflow dosyası, maintainer'ın kontrolündeki taban deponun varsayılan dalından gelir; bu yüzden GitHub okuma/yazma yetkili bir GITHUB_TOKEN'ın yanı sıra depo ve organizasyon sırlarını da verir — makale bu gerçeği GitHub'ın kendi workflow sözdizimi belgelerine dayandırıyor. workflow_run da aynı ayrıcalıklı sırada yer alır; kendinden önceki workflow bunlara sahip olmasa bile varsayılan daldan, sırlara ve yazma yetkili token'lara erişerek çalışır. Önbellek davranışı da farklıdır: fork'tan tetiklenen bir pull_request önbellek yazımlarını merge ref içinde tutarken, ayrıcalıklı tetikleyiciler varsayılan dalın önbellek kapsamını görür.

Bir pwn request nasıl gerçekleşir

Klasik hata dört satırdır: pull request'in head SHA'sını checkout edin, ardından bir build veya test adımı çalıştırın. Yalnızca checkout hiçbir şey çalıştırmaz, ama bir sonraki adım çalıştırır — make test fork'un Makefile'ını, npm install fork'un package.json'ındaki lifecycle script'lerini çalıştırır; linter'lar ve test koşucuları fork'un kontrolündeki yapılandırma ve eklentileri yükler. Bunların tümü, deponun kimlik bilgilerini elinde tutan bir job içinde gerçekleşir. Yazıda alıntılanan GitHub rehberine göre bu şekilde checkout edilen kod veri olarak değerlendirilmeli ve asla çalıştırılmamalıdır. Aynı açık, actions/checkout olmadan da vardır: pull request ref'ini elle fetch etmek, gh pr checkout çalıştırmak veya bir fork'un pull_request çalıştırmasının yüklediği bir artifact'ı indirip çalıştırmak.

Ultralytics: checkout olmadan enjeksiyon

Aralık 2024'teki ultralytics Python paketi ihlali, sorunun script enjeksiyonu yarısını gösteriyor. Makalede atıf yapılan William Woodruff'un analizine göre, pull_request_target üzerinde çalışan bir biçimlendirme workflow'u, dal adının doğrudan bir shell komutuna yerleştirildiği bir git pull çalıştıran bir composite action çağırıyordu. #18020 numaralı pull request, boşluklar yerine ${IFS} kullanılan ve kendisi bir shell komutu olan bir dal adı kullandı ve bu, ayrıcalıklı bağlam içinde çalıştı. Ardından 8.3.41 ve 8.3.42 sürümleri projenin normal release workflow'u üzerinden yayımlandı ve #18027 numaralı issue, 8.3.41'in sessizce bir xmrig miner çalıştırdığını bildirdi. Woodruff'un kanıtları, release build'ine ulaşmak için zehirli bir önbelleğin kullanıldığına işaret ederken, PyPI'nin analizi 8.3.45 ve 8.3.46'nın workflow'un hâlâ erişebildiği, iptal edilmemiş bir PyPI API token'ı ile doğrudan yüklendiğini ortaya koydu. Hiçbir head checkout yaşanmadı — fork'un kontrolündeki veri, yine de güvenilir kimlik bilgileriyle çalıştı. Makale, Nx ihlalini de bu tetikleyici üzerinden gerçekleşen başka bir olay olarak anıyor.

GitHub neyi değiştirdi ve her değişiklik neleri kaçırıyor

Makaleye göre artık bir pwn request ile sırlarınız arasında dört değişiklik var. 8 Aralık 2025'ten beri workflow dosyası ve varsayılan checkout her zaman varsayılan daldan gelir; ancak varsayılan dal workflow'unun istediği her şeyi fetch etmesini engelleyen bir şey yok. actions/checkout v7.0.0, adım allow-unsafe-pr-checkout: true ile açıkça izin vermedikçe pull_request_target ve workflow_run içinde fork pull request kodunu checkout etmeyi reddediyor; ama v6 veya daha eski sürümlere sabitlenmiş workflow'lar, doğrudan git komutları, indirilen artifact'lar ve aynı depo içindeki dallar etkilenmiyor. 26 Haziran 2026'dan beri, bir job yazma yetkili bir önbellek modu bildirmediği sürece güvenilmeyen tetikleyiciler varsayılan dal önbelleğine yalnızca salt okunur erişim alıyor. Son olarak, varsayılan bir Actions politikası herkese açık depolarda pull_request_target'ı engelliyor; bu politika 9 ve 16 Kasım'daki brownout'ların ardından 2 Aralık 2026'da zorunlu kılınacak — özel ve dahili depolar, GitHub Enterprise Server ve politikayı kabul eden depolar ise etkilenmeyecek.

Ayakta kalan desen

Dayanıklı çözüm — originally 2021'de yayımlanıp 2026'da güncellenen GitHub Security Lab rehberinden — işi iki workflow'a bölmektir. Biri pull_request üzerinde çalışır, fork'un kodunu sırlar olmadan ve salt okunur bir token ile build eder ve test eder, sonuçlarını bir artifact'a yazar. İkincisi workflow_run üzerinde yalnızca gerçekten ihtiyaç duyduğu izinlerle çalışır, artifact'ı indirir ve onunla salt veri olarak ilgilenir — örneğin bir kapsam özeti veya bir pull request yorumu gönderir. Lab'ın kuralı şudur: güvenilmeyen pull request verisinden üretilen artifact'lar da güvenilmezdir; fork ilk workflow'un dosyasını düzenleyebilir, bu yüzden her alan doğrulanmalı, pull request numaraları yalnızca rakam olarak kontrol edilmeli ve rapor içerikleri asla çalıştırılmamalı veya source edilmemelidir.

Neden önemli

pull_request_target var, çünkü maintainer'ların fork katkılarında meşru olarak ayrıcalıklı adımlara ihtiyacı var — özel registry'lere erişmek, kapsam yükleme yapmak, pull request'lere yorum yapmak. Bu tetikleyici ortadan kalkmayacak ve en yeni politika yalnızca herkese açık depoları varsayılan olarak koruyor. Güvenilmeyen çalıştırma ile güvenilir takip işi arasındaki ayrımı anlamak ve fork'tan gelen her değeri — bir Makefile, bir dal adı veya bir artifact alanı olsun — düşmanca bir girdi olarak ele almak, kullanışlı bir CI ile release kimlik bilgilerinizi yabancılara teslim etmek arasındaki farktır.