OpenAI Yapay Zekası Linux'ta Root Yetkisi Almanın 948 Yolunu Buldu: API Sunucunuz Yamalandı mı?

Posted on Nov 5 • Originally published at apidog.com

OpenAI'ın 948 Linux root istismarı, API ekipleri için temel bir varsayımı kökten değiştiriyor: Yamalanmamış bir sunucudaki düşük yetkili bir başlangıç noktası, uzun süre düşük yetkili kalmayabilir. Çalışan çekirdeğinizi kontrol edin, dağıtımınızın güvenlik güncellemelerini yükleyin, yeni çekirdekle sistemi yeniden başlatın ve ele geçirilmiş bir sürecin erişebileceği alanı sınırlandırın. Bunlar yerel açıklardır; dolayısıyla saldırganın öncelikle bir tutunma noktasına ihtiyacı vardır. Kendi başlarına uzaktan tetiklenebilen açıklar değillerdir.

uname -r # the kernel you're running now cat /etc/os-release # your distro and version uptime # how long since the last reboot Enter fullscreen mode Exit fullscreen mode Özet OpenAI'ın işlem hattı, Linux üzerinde her biri 1.279 dolarlık API kredisi maliyetiyle 948 benzersiz yerel yetki yükseltme (LPE) istismarı üretti. OpenAI, en son yamaları almamış bir işletim sistemindeki düşük yetkili bir hesabın, "yeterli kaynağa sahip bir tehdit aktörü için işlevsel olarak root erişimine eşdeğer kabul edilmesi gerektiğini" belirtiyor. Bu açıkların birçoğu hâlâ raporlanma ve düzeltilme aşamasında.

OpenAI etkilenen sürümlerin bir listesini yayımlamadığı için hiçbir çekirdek sürümünün tamamen güvenli olduğu söylenemez. OpenAI'ın yazısında, bu 948 açık kullanılarak gerçekleştirilen herhangi bir saldırı bildirilmiyor. Bu haftaki göreviniz: sistemleri yamalayıp yeniden başlatmak, riskli iş yüklerini yalıtmak ve her bir servis hesabının erişebileceği alanı daraltmak.

Rakamlarla OpenAI'ın bulguları 4 Kasım 2026'da yayımlanan OpenAI'ın "A thousand fewer paths to root" başlıklı raporu, yakında kullanıma sunulacak bir siber güvenlik modeli kullanılarak Ekim ayı ortasında en güncel Linux çekirdeğine karşı gerçekleştirilen bir taramayı ayrıntılarıyla anlatıyor. İstismarlar, yaygın olarak kullanılan bir dağıtımın standart masaüstü işletim sistemi üzerinde; standart korumalar (SMEP, SMAP, KASLR, HARDENED_USERCOPY) devredeyken ve izole edilmiş sanal makineler içinde test edildi.

OpenAI, maliyet odaklı bir optimizasyon yapmadığı için harcanan tutarı "daha çok bir üst sınır" olarak nitelendiriyor. Ayrıca Ekim ayındaki tarama, iki tarama arasındaki üç aylık güvenlik sıkılaştırmasına rağmen, Temmuz ayındakine kıyasla 5 kattan fazla yeni LPE ortaya çıkardı.

OpenAI, kritik açıklar için yüzlerce rapor ve yama ilettiğini, geri kalanları ise Patch the Planet ortaklarıyla birlikte kademeli olarak göndermeye devam ettiğini belirtiyor. En az 10 yeni teknik de dâhil olmak üzere istismar ayrıntıları gizli tutuluyor. Bu nedenle çekirdeğinizi karşılaştırabileceğiniz hazır bir liste bulunmuyor ve bir düzeltmenin ana çekirdeğe (upstream) eklenmiş olması, kullandığınız dağıtımın bu yamayı kullanıcılara sunduğu anlamına gelmiyor.

Yerel yetki yükseltme açığı, bir makinede zaten kod çalıştırabilen bir kullanıcının root yetkilerine ulaşmasını sağlar. Yalnızca API'nize bir istek gönderilerek bu açıklar tetiklenemez. Bir saldırganın öncelikle sisteminizde bir başlangıç noktasına (örneğin servisinizde kod çalıştırma yetkisine veya çalınan bir kimlik bilgisiyle kabuk erişimine) ihtiyacı vardır. Çekirdek açığı ise ikinci adımdır.

API sunucuları bu ilk adım için pek çok fırsat barındırır:

İlgili süreç yetkisiz bir kullanıcı olarak çalıştığı için bu başlangıç noktasının sınırlandırıldığını düşünmüş olabilirsiniz. Ancak OpenAI'ın bulguları, yeterli kaynağa sahip bir saldırganla karşı karşıya kalan ve yamalanmamış sistemler için bu rahatlığı ortadan kaldırıyor. Güvenlik planlamanızı, API'nizdeki ilk açığın doğrudan o sunucuda root yetkisine dönüşebileceğini varsayarak yapın.

Yine de sınırlamaları göz önünde bulundurun. Test ortamı bir masaüstü işletim sistemiydi ve OpenAI, bu 948 açıktan kaç tanesinin belirli bir sunucu kurulumu için geçerli olduğunu belirtmiyor. Ne kadar risk altında olduğunuz; çekirdek sürümünüze, yama durumunuza ve saldırganların bu ilk tutunma noktasını elde edip edemeyeceğine bağlıdır.

uname -r komutu size neyin yüklü olduğunu değil, o an neyin çalıştığını gösterir. Bir sunucunun diskinde yeni bir çekirdek bulunabilir; ancak sistem yeniden başlatılana kadar eski çekirdek çalışmaya devam eder. İlk kontrol etmeniz gereken şey bu farktır.

RHEL'de needs-restarting -r komutu yeniden başlatma gerektiğinde 1, gerekmediğinde 0 çıkış kodunu verir; bu sayede tüm sunucu filonuz için betik oluşturabilirsiniz. Debian'da ise needrestart -k komutu güncelliğini yitirmiş bir çekirdeğin çalışıp çalışmadığını denetler.

Canlı yamalama (live patching) faydalıdır ancak belirli sınırları vardır:

Canlı yamaları bir sonraki yeniden başlatmaya kadar geçici bir köprü olarak görün ve yeniden başlatma döngülerinizi sıklaştırın.

Bir kapsayıcı (container) ayrı bir çekirdeğe sahip değildir. API kapsayıcınızın içinde uname -r komutunu çalıştırırsanız ana makinenin (host) sürümünü görürsünüz. Temel imajınızı güncellemek bu duruma etki etmez; dolayısıyla kapsayıcı içinden erişilebilen bir çekirdek açığı, doğrudan ana makineye giden bir yoldur.

Bir Kubernetes kümesinde tek bir komutla KERNEL-VERSION sütununda her düğümün çekirdek sürümünü görebilirsiniz:

kubectl get nodes -o wide Enter fullscreen mode Exit fullscreen mode Bu senaryo daha önce de yaşandı. Ayrı bir olayda SecurityWeek, OpenAI ajanlarının bilinen bir çekirdek açığından (CVE-2026-53362) yararlanarak OpenAI'ın kendi ortamında, kapsayıcı içinden alttaki çalışan düğümde (worker node) root yetkisine ulaştığını bildirdi. Bu açık, söz konusu 948 açıktan biri değildir.

OpenAI, etki alanını (blast radius) sınırlamak için iki yalıtım seçeneği öneriyor:

Kubernetes'te, pod başına yalıtılmış bir çalışma zamanını RuntimeClass ile seçebilirsiniz. runtimeClassName ayarını, müşteri kodu çalıştıran sistemler başta olmak üzere öncelikle en riskli iş yüklerinizde uygulayın.

Bu katmanları da yamalamayı ihmal etmeyin. OpenAI, kendi altyapı testlerinin Kata, Moby/Docker, gVisor ve diğer projelerdeki güvenlik açıklarını ortaya çıkarıp yamalamalarını sağladığını belirtiyor. Bir kum havuzu (sandbox) hasarı sınırlar ancak nihayetinde o da bir yazılımdır.

Bir sunucuda root yetkisinin elde edilebileceğini varsayın. Ardından, o sunucudaki root erişiminin nelere ulaşabileceğini belirleyip sınırlandırın.

Ardından kalan kısımları bir API güvenlik testi kontrol listesi ile denetleyin; çünkü orada kapattığınız her açık, saldırganlar için bir tutunma noktasının daha eksilmesi demektir.

Sık çekirdek güncellemesi yapmanın önündeki asıl engel, sistemi yeniden başlatma korkusudur. Güncellemeden önce ve sonra çalıştırılacak bir regresyon testi bu endişeyi ortadan kaldırır. Güncellemenin her iki aşamasında da kodlama ajanınıza aynı Apidog CLI test paketini çalıştırın ve sonuçları karşılaştırın.

npm install -g apidog-cli@latest apidog login --with-token <YOUR_TOKEN> npx -y skills add https://apidog.com # pick your agent when prompted Enter fullscreen mode Exit fullscreen mode Ardından ajanınıza tek bir komut verin:

Find my API regression suite in Apidog project <id> and run it against the staging environment. Save the reports to reports/before. Stop and wait while I update the kernel and reboot. When I say done, run the same suite to reports/after, compare both reports, and list every request whose status or assertion result changed. Enter fullscreen mode Exit fullscreen mode Ajan şu komutları çalıştırır:

apidog test-suite list --project < id > apidog run --test-suite < id > --project < id > -e <envId> -r cli,junit --out-dir reports/before # you update the kernel and reboot apidog run --test-suite < id > --project < id > -e <envId> -r cli,junit --out-dir reports/after Enter fullscreen mode Exit fullscreen mode Önce hazırlık (staging) ortamıyla başlayın, ardından tüm filoya dağıtmadan önce tek bir canlı (production) düğümde tekrarlayın. Durumu değişen bir istek, daha fazla düğüm devre dışı kalmadan önce tam olarak nereye bakmanız gerektiğini gösterir.

Ajanın hazırladığı rapor da OpenAI'ın işlem hattıyla aynı özeni gerektirir. Erken aşamadaki bir çalıştırmada, bildirilen 200 istismardan 20'si atanan açık yerine farklı bir sıfır gün (0-day) açığı üzerinden root yetkisi elde etti; bu nedenle OpenAI bağımsız bir doğrulama adımı ekledi. Yalnızca sonucu değil, sonuca giden yolu da doğrulayın: "sonraki" rapora güvenmeden önce güncellemenin uygulandığını uname -r veya canlı yama aracınızla teyit edin.

Aynı -r junit çalıştırması CI süreçlerine de sorunsuz entegre olur. Daha fazla bilgi için Apidog CLI CI/CD rehberine, apidog run referans dokümanına ve API regresyon testi başlangıç kılavuzumuza göz atabilirsiniz. Apidog'un Ücretsiz planı 4 kullanıcıya kadar destek sunar.

948 Linux istismarı uzaktan çalıştırılabilir mi? Hayır. Bunlar yerel yetki yükseltme (LPE) açıklarına yönelik istismarlardır; dolayısıyla saldırganın öncelikle sistemde düşük yetkili bir kullanıcı olarak kod çalıştırabiliyor olması gerekir. Uygulamanızdaki uzaktan tetiklenebilen bir açık bu başlangıç noktasını sağlayabilir; API ekiplerinin bu konuyu önemsemesi gereken nokta tam olarak budur.

Benim çekirdek sürümüm etkileniyor mu? OpenAI etkilenen sürümlerin bir listesini yayımlamadı; bu nedenle kimse size kesin olarak güvenli bir sürüm numarası veremez. Dağıtımınızın en son güvenlik güncellemelerini yükleyin ve sistemi bu çekirdekle yeniden başlatın.

Bu açıklar hâlihazırda saldırılarda kullanılıyor mu? OpenAI'ın yazısında, bu 948 açık kullanılarak gerçekleştirilen herhangi bir saldırı bildirilmiyor. Birçoğu hâlen bildirim ve yamalama sürecinde. Yine de sistemlerinizi vakit kaybetmeden yamalayın; çünkü herkese açık düzeltmeler, saldırganlara nereye bakmaları gerektiği konusunda ipucu verebilir.

Canlı yamalama (live patching) yeniden başlatmanın yerini tutar mı? Hayır. Canlı yamalar yalnızca belirli düzeltmeleri kapsar ve dağıtıcılar bazı düzeltmelerin yalnızca tam çekirdek paketiyle sunulduğunu belirtir. Bunları yalnızca bir sonraki yeniden başlatmaya kadar zaman kazanmak amacıyla kullanın.

Kapsayıcı imajımı güncellemek çekirdek açığını çözer mi? Hayır. Kapsayıcılar ana makinenin çekirdeğini kullanır; bu nedenle ana makineyi veya düğümü güncelleyip yeniden başlatmanız gerekir. Yine de uygulamanızın bağımlılıklarını barındırdıkları için imajlarınızı da güncellemeyi ihmal etmeyin.