Plex2Shell: Plex Media Server Kimlik Doğrulamasız RCE Zinciri

Selamlar,

Ev sunucusu kuranların çoğu Plex'i internete açıyor; port 32400 açıkken "sadece medya" diye düşünüyor. 16 Ekim 2026'da kamuoyuna çıkan Plex2Shell zinciri bu varsayımı bozdu. CISA 20 Ekim'de dört CVE'yi KEV kataloğuna aldı: CVE-2026-96652, 96654, 96655 ve 96656. Kimlik doğrulaması olmadan RCE. Bu yazıda zinciri, neden loopback güveninin kırıldığını ve ev/ofis labında ne yapmanız gerektiğini özetliyorum.

Konuda anlatılacaklar

1. Plex Media Server'ın auth modeli (WAN / LAN / loopback / owner token)
   
2. Beş aşamalı zincir: SSRF -> loopback pivot -> owner token -> transcoder -> dlopen
   
3. Kimler etkileniyor, yama ve varsayılan sızdırma kontrolü
   
4. Beyaz şapka perspektifi: kendi sunucunuzda risk azaltma
   

Neden bu kadar kritik?
PMS büyük bir C++ ikili + gömülü Python eklenti çerçevesi. İnternetten gelen istekler token ister; 127.0.0.1'den gelenlere ise /system/agents/* gibi aileler token olmadan açılır. Üstüne, eklenti çerçevesi http://127.0.0.1 ile başlayan dış isteklere sahibin local-* admin token'ını otomatik ekler. Bu iki davranış ayrı ayrı "mantıklı" görünür; zincirlenince internetteki saldırgan owner token çalıp transcoder üzerinden kod çalıştırabiliyor.

Zincir özeti (yüksek seviye)
Araştırmacı zmain'in yazdığı akış kabaca şöyle (PoC depozitosu GitHub'da code-zm/plex2shell):

1. /player/timeline: X-Plex-Token başlığının varlığı kontrol ediliyor, değeri değil. junk token yeterli.
   
2. Companion abonelik akışında protocol/host/port ile callback URL üretiliyor; protocol temizlenmiyor. Unsubscribe anında sunucu kendi loopback'ine POST atıyor (gerçek 127.0.0.1 kaynağı).
   
3. /system/agents/.../searchOne[/b] loopback'te tokensuz. identifier enjeksiyonu ile herhangi bir eklenti fonksiyonuna sahte çağrı.
   
4. TheTVDB ajanındaki GetResultFromNetwork, http://127.0.0.1 öneki gördüğünde owner token ekliyor. sslip.io tarzı DNS ile önek geçer, çözüm saldırgan IP'sine gider; token dinlenir.
   
5. Owner token ile /video/:/transcode/universal ve TranscoderH264Options=dump-yuv yolu: taşıyıcı video bit-exact olarak .so yazar; sonraki transcode dlopen ile constructor çalıştırır (uid=plex).
   

Bu bir "tek CVE" değil; dört CVE'nin zinciri. Sömürü saha raporlarında aktif görünüyor; internete açık PMS'yi varsayılan olarak ele geçirilmiş kabul etmek mantıklı.

Hızlı kontrol listesi (kendi sunucunuz)

• Plex'in yayınladığı güvenlik güncellemesini uygulayın; yama öncesi internete açık sunucuda compromise assessment yapın.
  
• Remote Access'i kapatın veya VPN/Tailscale arkasına alın; CGNAT arkasında bile "kolay erişim" tuzağına düşmeyin.
  
• Admin token'ları döndürün; paylaşılan kütüphane hesaplarını gözden geçirin.
  
• Transcoder dizinlerini (Codecs) bütünlük açısından izleyin; beklenmeyen .so dosyaları kırmızı bayraktır.
  

Savunma dersi
"Loopback güvenli" varsayımı SSRF ile birleşince çöker. Token kontrolünde varlık ≠ geçerlilik klasik bir anti-pattern. Pref'e yazılabilen encoder bayrakları (dump-yuv gibi) debug özelliğinin üretimde kalmasının bedelidir. Benzer mimariyi kendi araçlarınızda görürseniz: loopback API'lerini tokensuz bırakmayın, outbound URL önek kontrollerini hostname parse ile yapın, debug seçeneklerini production build'den çıkarın.

Yasal uyarı
Bu yazı bilgilendirme amaçlıdır. Plex veya üçüncü taraf sistemlerde izinsiz deneme TCK 243-245 kapsamında suçtur. Testleri yalnızca kendi laboratuvarınızda veya yazılı izinle yapın. PoC'yi internette rastgele hostlara karşı çalıştırmayın.

Kaynaklar

• https://zmain.info/blog/plex2shell
  
• https://www.cisa.gov/news-events/alerts/...es-catalog
  
• https://github.com/code-zm/plex2shell (araştırmacı PoC deposu; yalnızca kendi labınız)
  

Sizde PMS internete açık mıydı, yoksa baştan VPN arkasında mı tutuyordunuz? Deneyimi yorumda yazın.

Ev kullanıcısı için ekstra sertleştirme
Plex'i yalnızca Tailscale/WireGuard arkasından açın. Shared kullanıcıları düzenli ayıklayın. Transcoder'ı gerekmiyorsa sınırlayın. NAS üzerinde PMS çalıştırıyorsanız NAS web arayüzünü de aynı VPN disiplinine alın. "Arkadaşlar uzak izlesin" ihtiyacı için ayrı, zayıf yetkili hesap kullanın; owner hesabını paylaşmayın.

Kurumsal BYOD riski
Çalışan laptop'unda PMS açıp Remote Access işaretlemek, kurumsal VPN ile birleşince beklenmedik lateral yüzey üretebilir. MDMde kişisel medya sunucusu politikası net olsun. SOC tarafında 32400/TCP internete çıkan iç host'ları periyodik bulun.

Göstergeler (yüksek seviye)
Beklenmeyen /player/* abonelik gürültüsü, loopback'e giden garip POST'lar, Codecs dizininde tanımsız .so, ani transcoder tercih değişikliği. Bunlar tek başına suçlama değildir; yama öncesi dönem için inceleme tetikleyicisidir.



Uygulamada sık gördüğüm hatalar
Birçok ekip yamayı "planlandı" diye işaretleyip internete açık yüzeyde günlerce bekletiyor. İkinci sık hata: yalnızca CVE numarasına bakıp zincir etkisini görmemek. Üçüncü hata: yama sonrası log ve dosya bütünlüğüne bakmamak; oysa yama öncesi sömürü olmuş olabilir. Bu üç noktayı kendi kontrol listenize eklemenizi öneririm.

Ekip içi iletişim şablonu
Yönetime veya müşteriye yazarken teknik jargonu azaltın: hangi varlık etkilendi, internete açık mı, yama var mı, geçici azaltma ne, doğrulama nasıl yapılacak. Tek paragrafta risk + eylem + sahiplik yazmak, uzun CVE özetinden daha hızlı karar aldırır.

Lab not defteri
Bu konuyu kendi defterime şu başlıklarla işliyorum: tarih, kaynak URL, etkilenen ürün/sürüm, internete açık mı, yama komutu, geri alma planı, IOC listesi, kime haber verildi. Siz de benzer basit bir şablon tutarsanız bir ay sonra "ne yapmıştık?" sorusu cevapsız kalmaz.

İzleme ve doğrulama
Değişiklikten sonra en az bir negatif ve bir pozitif kontrol tanımlayın. Negatif: alarm boş yere düşmemeli. Pozitif: bilinen kötü örneği veya beklenen log satırını yakalamalı. İkisini de kaydedin; aksi halde "sanırım düzeldi" ile yetinirsiniz.

Sonuç
Özetle: kaynağı okuyun, kendi envanterinize bağlayın, yama veya azaltmayı uygulayın, sonra doğrulayın. TurkTeam'de yorumlarda kendi ortamınızdan (ürün adı ve sürüm yeter, hassas IP yazmayın) kısa deneyim paylaşırsanız herkes faydalanır.


Adım adım kontrol listesi (kopyala-yapıştır)

1. Kaynak duyuruyu ve varsa üretici güvenlik sayfasını arşivleyin (PDF/HTML).
   
2. Envanterde etkilenen ürün var mı diye CMDB / agent raporu / netscan ile bakın.
   
3. İnternete açık mı, yoksa yalnızca iç ağda mı? Buna göre SLA seçin.
   
4. Yama veya yapılandırma azaltmasını stagingde deneyin.
   
5. Üretim penceresinde uygulayın; değişiklik kaydı açın.
   
6. Servis sağlık kontrolü + log doğrulaması yapın.
   
7. Gerekliyse IOC avı veya compromise assessment planlayın.
   
8. Kapanış notunu yazın: sürüm, tarih, kim onayladı.
   

Sık sorulanlar
Sadece okumak yeter mi? Hayır. Okuduktan sonra envanter satırına bağlanmayan bilgi operasyonel değildir.
PoC çalıştırmalı mıyım? Yalnızca izole lab ve yazılı izinle. İnternette rastgele deneme hem etik dışı hem yasadışı olabilir.
WAF / EDR tek başına kurtarır mı? Katmanlı savunma işe yarar ama yamanın yerini tutmaz; özellikle kimlik doğrulamasız RCE sınıflarında.
Ne zaman yönetime çıkmalıyım? İnternete açık kritik yüzey, aktif sömürü istihbaratı veya veri sızıntısı şüphesi varsa gecikmeden.

Örnek komut defteri
Bu komutlar tanı koymaz; değişiklik öncesi/sonrası basline almak için kullanın.

İlgili TurkTeam bölümleri
Bu yazıyı okuduktan sonra aynı kategorideki komşu konulara ve Soru-Cevap bölümüne kendi lab çıktınızı (hassas veri olmadan) taşıyabilirsiniz. Kısa ekran görüntüsü veya komut çıktısı, uzun teoriden daha çok işe yarar.

Kapanış ve yasal çerçeve
TurkTeam white-hat bir topluluktur. Anlatılan teknikler eğitim, savunma ve izinli test içindir. Başkalarının sistemlerinde izinsiz tarama, sömürü, veri çalma veya "hack hizmeti" sunmak forum kurallarına ve TCK 243, 244, 245 maddelerine aykırıdır. Kendi laboratuvarınızı izolasyonla kurun; üretim verisi kullanmayın. Kaynaklardaki bağlantıları birincil referans kabul edin; bu yazı özet ve yol göstericidir, üretici duyurusunun yerini tutmaz.