GitHub, 2 Aralık 2026'dan itibaren herkese açık depolarda pull_request_target workflow'larını engelleyecek

6 Kasım'da yayımlanan bir dev.to yazısına göre GitHub Actions, 2 Aralık 2026'dan itibaren herkese açık her depoda pull_request_target tetikleyicisini kullanan workflow'ları varsayılan olarak engelleyecek. 9 ve 16 Kasım'daki iki iki saatlik brownout, engelleme kalıcı hale gelmeden önce bakımcıların sorunları bulabilmesi için bloku geçici olarak devreye sokacak.

Ne değişiyor ve ne zaman

Yazıya göre GitHub değişikliği 2 Kasım 2026'da duyurdu ve aynı zamanda yaptırım tarihini bir ay, 2 Kasım'dan 2 Aralık'a geri itti. O tarihe kadar kural evaluate modunda çalışıyor: GitHub hangi workflow çalıştırmalarını engelleyeceğini engellemeden günlüğe kaydediyor ve bu bulgular deponun Insights sekmesinde görünüyor.

Brownoutlar bir prova niteliğinde. 9 Kasım Pazartesi ve 16 Kasım Pazartesi günleri, 16:00–18:00 UTC arasında GitHub bloku iki saat boyunca devreye alacak; etkilenen bir depodaki herhangi bir pull_request_target workflow'u bir hata notuyla başarısız olacak ve çalışmayacak. Bu pencerelerin dışında kural evaluate moduna dönecek. 2 Aralık'tan itibaren blok, bir Actions olay politikası tetikleyiciyi açıkça izin vermedikçe kalıcı olacak; GitHub da istisnayı genel olarak tetikleyiciye değil, belirli workflow dosyalarına kapsam olarak vermenizi öneriyor.

Kapsam dar: yalnızca GitHub Free, Team ve Enterprise Cloud'daki herkese açık depolar etkileniyor. Private, internal ve GitHub Enterprise Server depoları muaf.

Tetikleyici neden riskli

Bir fork'tan gelen sıradan bir pull_request olayı salt okunur bir token ile çalışır ve depo sırlarına (secret) erişemez; bu yüzden kötü niyetli fork kodunun çalacağı pek bir şey yoktur. pull_request_target bunun istisnasıdır: temel deponun bağlamında, yazma token'ı ve sırlara erişimle çalışır; botların fork pull request'lerine etiket yapmasına, yorum yazmasına ve triyaj etmesine olanak sağlayan da budur.

Zayıflık tetikleyicinin kendisinde değil, o ayrıcalıklı bağlamın güvenilmeyen kodla birleşmesindedir. Yazının anlattığı klasik senaryoda bir workflow, pull request'in head commit'ini checkout eder ve ortamda bir sır varken build veya test adımlarını çalıştırır; bir katkıda bulunan package.json dosyasını sessizce düzenleyerek kurulumun bir post-install betiği çalıştırmasını sağlar ve betik sırrı harici bir sunucuya gönderir. Workflow dosyası temel dalda bulunduğu için güvenilirdir, oysa çalıştırdığı her şey fork'tan gelir.

Yazarın tavsiyesi, pull request yoluyla gelen her şeyi güvenilmeyen girdi olarak ele almaktır. Bir fork'un kodunu çalıştırmak için ayrı bir pull_request workflow'u ya da pull_request artı workflow_run desenini kullanın; bu desende ayrıcalıksız bir workflow kodu çalıştırır, ayrıcalıklı olan ise bir bakımcı onayladıktan sonra artefaktları üzerinde işlem yapar.

Büyük projelerin taranması ne buldu

Yazar tahmin etmek yerine ölçmüş; 6 Kasım 2026'da küçük bir Python betiğiyle beş büyük herkese açık depodaki 202 workflow dosyasını taramış. Yirmi yedi workflow, yani yaklaşık yüzde 13'ü pull_request_target kullanıyor ve manuel inceleme sonrası hiçbiri fork kodu çalıştırmıyor.

Dağılım şöyle: github/docs'ta 101 workflow'un 11'i bu tetikleyicide, nodejs/node'da 45'in 5'i, facebook/react'ta 26'nın 4'ü, python/cpython'da 23'ün hiçbiri ve actions/checkout'ta 7'nin hiçbiri. Node ve React örnekleri, asla fork kodu çalıştırmayan etiket, yorum ve bildirim botlarıdır.

İşaretlenen workflow'lardan biri, github/docs'taki review-comment.yml, yanlış pozitif çıktı: head SHA'sına başvuruyor ve run adımları içeriyor, ancak ref'i geçersiz kılmadan temel depoyu checkout ediyor ve head SHA'sını yalnızca veri olarak geçiyor. Yazarın varılan sonucu şu: otomatik tarama bir başlangıç noktasıdır, hüküm değildir — işaretlenen her dosya manuel olarak okunmayı hak eder.

Nasıl hazırlanılır

9 Kasım brownout'undan önce iki kontrol öneriliyor. Birincisi, deponun Insights sekmesini açıp evaluate modunda şimdiden toplanmış workflow yürütme koruması bulgularını okuyun — bu, başarısız olan bir buildden çok daha sakin bir sinyaldir. İkincisi, workflow dosyalarını doğrudan tarayın; yazıda, bir deponun varsayılan dalını GitHub API üzerinden gezinen ve hem pull request head'ine başvuran hem de run adımları içeren her workflow'u işaretleyen kısa bir kimlik doğrulamasız betik var.

Neden önemli

pull_request_target, bir deponun sırlarını rastgele fork koduna teslim edebilir ve varsayılan olarak engellenmesi, açık kaynak dünyasındaki bir bütün sır sızdırma olayları sınıfını kapatıyor. Maliyet, tetikleyiciye meşru olarak bağımlı olan azınlıktaki workflow'lara — örneklenen depolarda kabaca sekizde bir — ve özellikle ayrıca fork kodu çalıştıran, yeniden yazılmak zorunda olanlara düşüyor. Herkese açık depoların bakımcılarının tanımlı bir penceresi var: evaluate modu bulgularını şimdi okuyun, ilk brownout'tan önce denetleyin ve 2 Aralık'tan önce ya daha güvenli olan pull_request ve workflow_run desenine geçin ya da dar kapsamlı bir politika istisnası çıkarın.