deniz.in

Piyasalar

Hava durumu

Hava durumu yükleniyor

· kaynak dev.to (home feed)

Chainlit 2.12.0, MCP endpoint'lerindeki kimlik doğrulamasız RCE ve SSRF açıklarını yamaladı

Chainlit 2.12.0, MCP stdio transport'u üzerinden kimlik doğrulamasız bir RCE olan CVE-2026-45018 ile bir SSRF açığı olan CVE-2026-45019'u düzeltiyor; her ikisi de varsayılan olmayan MCP bayrağı gerektiriyor.

Chainlit 2.12.0, MCP endpoint'lerindeki kimlik doğrulamasız RCE ve SSRF açıklarını yamaladı

Ne oldu

Chainlit, 25 Ağustos 2026'da 2.12.0 sürümünü yayınladı ve Model Context Protocol (MCP) endpoint'lerindeki iki kimlik doğrulamasız açığı kapattı. dev.to'daki bir yazıya göre sürüm, MCP stdio transport'unda satıcı CVSS 3.1 puanı 9.8 olan kimlik doğrulamasız bir uzaktan kod yürütme açığı olan CVE-2026-45018'i ve SSE ile streamable-http transport'larında 7.2 puan alan bir server-side request forgery sorunu olan CVE-2026-45019'u düzeltiyor. Her ikisi de Chainlit 2.7.0'dan beri varsayılan olarak kapalı olan features.mcp.enabled bayrağının arkasında yer alıyor; dolayısıyla MCP'yi hiç açmamış dağıtımlar kapsam dışı.

SPL Security'den araştırmacılar Vipin ve Stephen sorunları bildirdi ve dev.to gönderisine göre Chainlit 2.11.0'a karşı çalışan proof of concept'ler sergiledi. Etkilenen aralık, MCP etkin şekilde 2.4.0rc0'dan 2.12.0 altındaki tüm sürümler. GitHub advisories GHSA-w3fx-mc44-mf6j ve GHSA-hvfh-5mj3-5f3j iki açığı takip ediyor.

Komut yürütme nasıl çalışıyordu

MCP açıkken, /mcp'ye yapılan bir POST isteği, istemci tipi stdio olduğunda istemciden gelen bir fullCommand alanını kabul ediyordu. backend/chainlit/mcp.py içindeki doğrulama fonksiyonu bu string'i parçalara ayırıyor ve yürütülebilir dosyanın yalnızca basename'i npx ve uvx gibi launcher'lardan oluşan bir allowlist ile karşılaştırıyordu. Argümanlar hiç incelenmiyordu.

Bu boşluk önemliydi, çünkü yaygın Node launcher'ları rastgele bir shell string'i çalıştıran kısa bir bayrak alabiliyor. Saldırganın tek yapması gerektiği komutun başına allowlist'teki bir binary adı koymaktı; ondan sonrası tamamen onun kontrolündeydi. Komut Chainlit kullanıcısı olarak çalışıyor ve MCP handshake'i başarısız olmadan önce yürütülüyordu.

dev.to yazısı bir uyarı ekliyor: allowlist tek başına bir güvenlik ağı değil. allowed_executables kaldırılıp değeri None olursa doğrulama her yürütülebilir dosyaya izin veriyor. Listeyi daraltmak da hatayı düzeltmiyor. 2.12.0'daki asıl düzeltme, istemcinin verdiği komutları tamamen kabul etmeyi bırakmak.

SSRF kardeşi

CVE-2026-45019 aynı /mcp endpoint'inde yaşıyor. sse ve streamable-http istemci tipleri için Chainlit, çağırandan şema kontrolü, host allowlist'i ve header denylist'i olmadan ham bir URL ve isteğe bağlı header'lar alıyordu. Süreç ardından, çağıranın göndermeyi seçtiği auth header'ları dahil, iç host'lara ve link-local bulut metadata endpoint'lerine giden giden HTTP istekleri yapıyordu.

dev.to gönderisi bunu kör SSRF olarak tanımlıyor: yanıt gövdeleri doğrudan saldırgana dönmek yerine MCP istemcisinin içinde kalıyor. Bu yoldaki header iletimi Chainlit 2.6.4'te geldi ve çağıranın erişebileceği alanı genişletti.

Kimler harekete geçmeli

Operatörler pip show chainlit ile veya uygulamayı gerçekten sunan ortamda chainlit.__version__ yazdırarak kontrol edebilir. .chainlit/config.toml içinde features.mcp.enabled satırına bakın. Bu bayrak set edilmiş 2.12.0 altı bir sürüm açığa maruz demektir. Gönderi, yükseltme sonrası yeniden başlatmanın önemini vurguluyor; böylece eski bir süreç hâlâ savunmasız kodu çalıştırmaz.

Hemen yükseltemeyen ekipler için önerilen hafifletmeler features.mcp.enabled'i false yapmak, host'un giden trafiğini kısıtlamak ve kimlik doğrulama kaydederek /mcp'nin anonim olmamasını sağlamaktır. Kimlik doğrulama tek başına, savunmasız bir sürümde oturum açmış bir kullanıcı için kod yürütmeyi ortadan kaldırmaz; yalnızca anonim yolu kapatır.

2.12.0'daki kırıcı değişiklikler

Yükseltme yapılandırma işi gerektiriyor. Eski [features.mcp.sse], [features.mcp.stdio] ve [features.mcp.streamable-http] bölümleri, allowed_executables ile birlikte artık MCP açıkken başlatmayı durduruyor. Stdio sunucuları [[features.mcp.servers]] altında bildirilmeli ve istemciler onlara isimle bağlanmalı. Kullanıcının sağladığı SSE ve HTTP sunucuları için enabled = true ve boş olmayan bir allowed_urls listesi içeren [features.mcp.user_servers] gerekiyor; ayrıca yönlendirmeler takip edilmiyor, bu yüzden nihai HTTPS URL'i yapılandırmaya yazılmalı. Değişiklikten sonra anonim istemciler auth kapalıyken geliştiricinin isimlendirdiği stdio sunucularını yine başlatabiliyor; bu da istemcinin seçtiği kod yürütme değil, sabitlenmiş komutla başlatmadır.

Bir tutarsızlığa değinmekte fayda var: dev.to gönderisi, araştırma sırasında GitHub advisory sayfalarında yamalanmış sürüm alanlarının hâlâ boş göründüğünü söylerken, 2.12.0 sürümü ve Chainlit'in deposundaki MCP advisory'si düzeltme olarak 2.12.0'ı gösteriyor.

Neden önemli

Chainlit, AI uygulamalarının çevresine sohbet arayüzleri inşa etmek için popüler bir framework'tür ve MCP, bu uygulamaların dış araçlara erişme biçimi giderek daha çok bu oluyor. AI dağıtımlarının yaygın olarak açtığı bir yolda kimlik doğrulamasız, 9.8 puanlı bir kod yürütme deliği, etki alanını bu özelliği etkinleştirmeyi seçen operatörlerle sınırlayan varsayılan-kapalı bayrakla hafifletilen, neredeyse en kötü senaryodur. Hatalar ayrıca MCP ekosisteminde tekrarlanması muhtemel bir kalıbı gözler önüne seriyor: bir launcher binary'sini allowlist'e almak, launcher'ın argümanlarından rastgele kod yürüttüğü durumlarda pek bir şey ifade etmez ve istemcinin verdiği URL'leri fetch hedefi olarak görmek, iç ağlara ve bulut metadata servislerine karşı SSRF'yi davet eder. MCP etkin şekilde 2.12.0 altında Chainlit çalıştıran herkes bunu acil bir yükseltme olarak görmeli.

  • #chainlit
  • #mcp
  • #security
  • #vulnerability
  • #python

İlgili yazılar