Tailworm raporu Tailscale ve headscale'de 11 açık iddia ediyor

Tailscale ve headscale kullanıcıları bunu panikle değil dikkatle okumalı. Bağımsız bir araştırmacı, 25 Ekim’de Hacker News’e ulaşan uzun bir raporda Tailscale istemcisinde ve headscale kontrol sunucusunda 11 sorun iddia etti; kontrol ettiğimizde henüz bir düzeltme çıkmamıştı. Raporun tamamını okuduk, Tailscale’in herkese açık commit’lerine ve güvenlik bültenlerine baktık, Hacker News tartışmasını, bir Tailscale çalışanının yanıtı dahil, okuduk. Bu yazıda raporun ne iddia ettiği, Tailscale’in ne söylediği ya da yaptığı, iddialara şimdilik ne kadar güvenilebileceği ve operatörlerin neler yapabileceği var. Bulgularla ilgili her şey yazarın anlatımı. Hiçbirini çalıştırmadık ve nasıl yeniden üretileceğini bilerek dışarıda bırakıyoruz.

Tailworm raporu nedir?

Cyberdione Labs Corporation’dan Erica Windisch’in tailworm.com’da yayımladığı bir güvenlik değerlendirmesi. Tailscale istemcisi v1.104.2’yi (21 Ekim’de çıktı), headscale v0.29.5’i, ikisinin de kullandığı gliderssh kütüphanesini ve deneysel conn25 app-connector özelliğini kapsıyor. Test penceresi 22-24 Ekim; yazar her bulguyu laboratuvarda değiştirilmemiş yayımlanmış yazılımda yeniden ürettiğini söylüyor. Rapor kendini bağımsız ve ücretsiz olarak tanımlıyor ve Tailscale ile bağlantısı olmadığını belirtiyor. Ayrıca altyapının bugün savunmasız olduğunu ve hızlı farkındalığın düzeltmeyi hızlandıracağını savunuyor; yazarın bir düzeltme çıkmadan yayımlama gerekçesi bu. 11 bulgu CVE numarası değil, yazarın kendi etiketlerini taşıyor.

Ne iddia ediyor?

Raporun kendi gruplamasıyla:

• Tailscale SSH (bulgu 1-3): unix-socket yönlendirmesi (ssh -L ve ssh -R) yol kontrollerini ve dosya işlemlerini root olarak yapıyor; rapor yarışların sıradan bir oturumun ayrıcalıklı kaynakları değiştirmesine, bunlara bağlanmasına ya da silmesine izin verdiğini söylüyor. Üçünü de High olarak derecelendiriyor. Belirtilen gereksinim bir onaylı cihaz ve bir SSH politika kuralı; yönlendirme headscale’de otomatik, Tailscale’in barındırılan hizmetinde kural başına veriliyor. İddia edilen sonuçlar arasında hedefte root ve yeni cihazları kaydeden anahtarların ele geçirilmesi var.
• App connector’lar (bulgu 4): deneysel connector, saldırganın seçtiği hedefleri doğrulamadan kabul ediyor ve gerçek hedef için ağ ACL’leri kontrol edilmiyor. Rapor bunun bulut metadata servislerine, iç ağlara ve Kubernetes’te her küme servisine ulaştığını söylüyor. Yazar Hacker News’te en çok bundan endişe duyduğunu söylüyor.
• Bellek tüketimi (bulgu 5 ve 6): root tailscaled’in belleğinin tükenmesine yol açabilen bir gliderssh oturum davranışı; ayrıca headscale’de kimlik doğrulamasız bellek büyümesi ve röle (DERP) istemcisinin sınırsız okuması. Bunlar erişilebilirlik sorunları. Rapora göre headscale olanı yalnızca internetten erişilebilirlik gerektiriyor.
• tailscale serve (bulgu 7-11): bir unix socket’e TCP yönlendirmesi HTTP yolundaki bir korumadan yoksun ve yerel yönetim API’sini bir eşe açabiliyor, ilgili bir koruma yalnızca yapılandırma anında kontrol ediliyor, funnel yetkisi yalnızca yerel yapılandırma ve eş yeteneğiyle uygulanıyor, bir ortam değişkeni serve’ü tünelin dışına açabiliyor ve bir yarış bir bağlama noktasının yeteneklerinin diğerine sızmasına yol açıyor. Derecelendirmeler High’dan bir yapılandırma notuna kadar uzanıyor.

Rapor ayrıca ölçtüğü olumsuz sonuçları da listeliyor: WireGuard’ın kendi yönlendirmesinin engellediği, diğer tailnet düğümlerine giden bir app-connector yolu, bellek tükenmesi durumlarından bellek bozulmasına giden bir yol bulunmaması ve yaklaşık 117 milyon fuzz çalıştırmasında çökme çıkmaması gibi. SSH yönlendirme sınıfını OpenSSH ve Dropbear ile karşılaştırıyor ve Dropbear’ın CVE-2025-14282’sini emsal olarak gösteriyor.

Tailscale ne söyledi ya da yaptı?

Şimdiye kadar kamuya açık çok az şey, bir kısmı da dolaylı. Bulduklarımız:

• Bülten ya da sürüm yok. Tailscale’in güvenlik bültenleri sayfasında en yeni kayıt 21 Ekim’deki TS-2026-013 (eMudhra sertifika sorunu); en son istemci sürümü, test penceresi bitmeden önce çıkan, 21 Ekim tarihli v1.104.2. 24 Ekim tarihli headscale v0.29.6 sürüm notları eMudhra reddini ve bağımlılık güncellemelerini anıyor, bu raporu değil.
• Hacker News’te bir yanıt. Tailscale’de çalıştığını belirten bir kullanıcı uzun bir gün geçirdiğini ve ayrıntıların geleceğini yazdı. Numaralandırma iddiası için bir kısmının headscale farkı olabileceğini, çünkü Tailscale kontrol düzleminin bir düğümün görünümünü budadığını, yani birbirine izin veren kuralı olmayan iki düğümün birbirini görmediğini söyledi. Bu tartışmanın iki tarafını da doğrulayamıyoruz.
• Commit’ler. 23-25 Ekim arasında tailscale/tailscale ana dalına tek bir iç kayda, tailscale/corp#50380’e atıf yapan bir dizi değişiklik girdi: ortam değişkeni sınırları ve host anahtarı dosya izinleri gibi SSH sertleştirmesi, zaman aşımlarındaki bir veri yarışını kaldıran gliderssh güncellemesi ve 25 Ekim’de “fix serve app caps leaking across mounts”. Son commit raporun 11. bulgusundaki aynı bağlamlar arası yetenek sızıntısını anlatıyor. Bulgu 1-3’teki unix-socket yönlendirmesi için başlığı eşleşen bir commit görmedik, ancak yalnızca commit başlıklarını ve birkaç tam mesajı okuduk. Ne commit’ler ne rapor birbirine atıf yapıyor ve tarihler test penceresiyle örtüşüyor; hangisinin önce geldiğini söyleyemeyiz.
• Okuyamadığımız bir Reddit yanıtı. Bir Hacker News yorumcusu Tailscale’in mühendislik başkan yardımcısının Reddit’te bir yanıt yayımladığını söylüyor. Reddit bize bir doğrulama sayfası gösterdi, bu yüzden okumadık.

Rapora şimdilik ne kadar güvenilebilir?

Okuduğumuz bölümlerde ayrıntılı ve kendi içinde tutarlı, ama hiçbir şey bağımsız olarak doğrulanmış değil. Yazar bulguların Tailscale’e bildirildiğini ama koordine edilmediğini söylüyor; Hacker News yorumcuları bunu, raporun uzunluğunu ve üslubunu eleştirdi, bazıları makine yazımı olduğunu söyledi. Diğerleri SSH yetki yükseltmesinin gerçekse önemli olduğunu, çünkü ele geçirilmiş tek bir düğümün çoğuna ulaşabileceğini savundu. Dışarıdan hangi tarafın haklı olduğuna karar veremeyiz. Raporun kendisinden iki uyarı: SSH bulguları saldırganın zaten onaylı bir cihaza sahip olduğunu varsayıyor, yazar bunun savunmasız bir web uygulaması ya da kötü niyetli bir bağımlılık gibi sıradan dayanaklarla olduğunu söylüyor; bir Hacker News yorumcusu da isimdeki “solucan”ın uymadığından şüphe etti, çünkü bir SSH dayanağı kendi başına çoğalmıyor.

Operatörler şimdi ne yapabilir?

Rapor geçici adımlar sunuyor; bunlar yazarın önerileri, Tailscale’in değil:

• SSH kurallarını daraltın. Bir cihazdan bir cihaza çiftler arası izinler kullanın, kimlik genelinde ve etiket genelinde kabul kurallarını bırakın, root ya da parolasız sudo’lu hedef hesaplardan kaçının. Rapor, headscale’de her SSH iznini root’a eşdeğer saymayı söylüyor. Tailscale’in barındırılan hizmetinde ihtiyaç yoksa yönlendirmeyi eylem başına reddedilmiş yapın.
• tailscale serve’ü denetleyin. unix socket’lere TCP yönlendirmelerini arayın ve ajanın kendi socket’ini ya da diğer ayrıcalıklı yolları hedefleyenleri kaldırın.
• App connector’ları kısıtlayın. İhtiyacı olmayan istemcilerden yeteneği kaldırın ve izin verilen hedefleri güvenlik duvarında ya da Kubernetes’te varsayılan reddeden bir çıkış politikasıyla uygulayın.
• Yönlendirme için check moduna güvenmeyin. Rapor SSH check kurallarının oturum kurulumunu denetlediğini, onaylı bir oturumun içindeki yönlendirmeyi denetlemediğini söylüyor.

Rapor ayrıca güvenlik duvarlarının unix-socket işlemlerini göremediğini ekliyor ve bunlar için izleme öneriyor. Resmî bir yanıt için Tailscale’in bültenlerini ve sürüm notlarını izleyin.

Henüz bilinmeyenler neler?

• Tailscale’in hangi bulguları doğruladığı, bunları nasıl derecelendirdiği ve düzeltmelerin ne zaman çıkacağı.
• 23-25 Ekim commit’lerinin rapora yanıt olup olmadığı, 11. bulguyla örtüşen tek commit dışında.
• Başkalarının yeniden üretmesi. Bağımsız bir doğrulama bulamadık.
• Gerçek kurulumların ne kadar açıkta olduğu. Bulgular SSH kuralları, yönlendirme ayarları ve app-connector kullanımı gibi politika tercihlerine bağlı.
• Bildirim geçmişi. Yazar bildirildiğini ama koordine edilmediğini söylüyor; bu bildirimin tarihleri ve içeriği kamuya açık değil.

Akılda tutulacaklar

Bunlar bizim gözlemlerimiz:

• Satıcı yanıt verene kadar bunu bir iddia olarak ele alın. Ayrıntılı bir rapor doğrulanmış bir açık değildir ve tek uzun bir belgeyi hızlıca kontrol etmek zor.
• Bildirim zamanlaması hikâyenin parçası. Satıcı yanıt veremeden yayımlamak kullanıcılara yalnızca yazarın önlemlerini bırakıyor. Aynı gerilimi PHP ambargo raporumuzda da gördük.
• Yapılandırma önerileri her iki durumda da geçerli. Dar SSH kuralları, root hedeflerin olmaması ve daha sıkı app-connector çıkışı, Tailscale ne sonuca varırsa varsın ucuz adımlar.
• Tailscale bu hafta başka bir nedenle de gündemdeydi. 21 Ekim tarihli eMudhra sertifika anahtarları bülteni, v1.104.2 ve sonrasının bunlara güvenmediğini söylüyor.

Editoryal inceleme: 25 Ekim 2026 (AI). tailworm.com’daki Tailworm raporunun tam metni (özet, bulgular, olumsuz sonuçlar, check modu bölümü ve düzeltme bölümleri dahil; yeniden üretim kitleri incelenmedi), 20-25 Ekim arası herkese açık tailscale/tailscale commit geçmişi (GitHub API; dört commit mesajı baştan sona, geri kalanı başlıkla okundu), Tailscale’in güvenlik bültenleri sayfası, headscale v0.29.6 sürüm notları ve Hacker News ileti dizisi (Algolia API üzerinden; ilk düzine üst düzey yorum) üzerinden hazırlandı. Hiçbir bulguyu test etmedik, hiçbir kavram kanıtı çalıştırmadık ve Tailscale ya da araştırmacıyla iletişime geçmedik. İleti dizisinde anılan Reddit yanıtları açılamadı. Rapor, ileti dizisi ve Tailscale sayfaları okumamızdan sonra değişmiş olabilir.