CVE-2025-66034, fontTools varLib Bir Designspace Dosyasını Yazma İlkeline Dönüştürdüğünde

Güvenlik ekipleri ayrıştırıcılar, görüntü kütüphaneleri, arşiv çıkarıcılar, şablon motorları ve PDF oluşturucular hakkında endişelenmeyi öğrendi. Daha az sayıda ekip yazı tipi oluşturma araçlarını aynı listeye koyuyor. CVE-2025-66034, yapmaları gereken bir hatırlatmadır. Sorun şunları etkiliyor fontTools.varLibyaygın olarak kullanılan Python'un bir parçası fonttools paketi ve görünüşte sıradan bir tasarım eserini, bir .designspace dosyasını, keyfi dosya yazma için bir araca dönüştürür. Doğru koşullar altında, bu ilkel yazma işlemi uzaktan kod çalıştırmaya dönüşebilir. Bunun önemli olmasının nedeni sadece hatanın kendisi değildir. Dokunduğu sistemler sınıfıdır: otomatik varlık boru hatları, font oluşturma hizmetleri, CI işleri, tasarımdan web'e iş akışları ve tamamen oluşturmadığı ve güvenmediği font kaynaklarını işleyen herhangi bir arka uç. (GitHub)

Kamu kayıtları temel mekanikler konusunda alışılmadık derecede açık. GitHub'ın danışmanlığı, savunmasız kod yolunun şu olduğunu söylüyor main() yolu fontTools.varLibtarafından kullanılan fonttools varLib CLI ve çağıran herhangi bir kod fontTools.varLib.main(). Saldırganların yol geçişi yoluyla dosyaları rastgele dosya sistemi konumlarına yazmasına ve XML kontrollü içerik yoluyla çıktı dosyalarına kötü amaçlı kod enjekte etmesine olanak tanıyan sanitize edilmemiş dosya adı işleme artı içerik enjeksiyonunu açıklar. NVD kaydı aynı etkilenen aralığı doğrulamaktadır 4.33.0 kadar ancak hariç 4.60.2'yi kullanacak şekilde uygulamayı değiştiren yamayı bağlar. basename(vf.filename) tam olarak verilen yola güvenmek yerine. (GitHub)

CVE-2025-66034'ü tam bir teknik incelemeye değer kılan şey, savunucuların genellikle hafife aldığı üç şeyin kesiştiği noktada yer almasıdır. Birincisi, yazı tipi ardışık düzenleri genellikle düşmanca girdi işlemcileri olarak değil, derleme altyapısı olarak ele alınır. İkincisi, savunmasız dosya türü geleneksel anlamda bir "çalıştırılabilir" değildir, bu da birçok ekibin duygusal olarak riski düşük değerlendirmesine neden olur. Üçüncüsü, kamuya açık şiddet verileri bölünmüş durumdadır. GitHub ve Canonical bunu yerel saldırı vektörü ve gerekli kullanıcı etkileşimi ile 6.3 Orta sorun olarak tanımlarken, NVD zenginleştirme daha sonra 9.8 Kritik ağ tarzı bir değerlendirme kaydeder. Her iki pozisyon da kamuya açık kayıtlarda görülebilir ve arkalarındaki varsayımları anlarsanız her ikisi de yararlıdır. (NVD)

CVE-2025-66034'ün gerçekte ne olduğu

Pratik düzeyde, CVE-2025-66034 "sadece XML enjeksiyonu" ya da "sadece yol geçişi" değildir. Bu bir zincirdir. Savunmasız mantık, değişken yazı tipi meta verilerinden bir dosya adını kabul eder, bunu bir çıktı dizinine birleştirir ve oluşturulan bir dosyayı buraya yazar. Savunmasız yolda, dosya adı çapraz diziler içerebilir, böylece yazma işlemi amaçlanan hedeften kaçabilir. GitHub'ın danışmanlığı daha da ileri giderek, saldırganların etiket alanlarına XML ekleme yoluyla çıktı içeriklerini de kontrol edebileceklerini belirtiyor; bu da sorunu dosya yerleştirmeden, yazılan dosya çalıştırılabilir veya yorumlanabilir bir yere ulaştığında potansiyel kod yürütmeye taşıyor. (GitHub)

Yama aynı hikayeyi daha derli toplu bir şekilde anlatıyor. NVD tarafından bağlanan commit mantığı değiştirir, böylece eğer vf.dosyaadı mevcutsa, yalnızca os.path.basename(vf.filename) kullanılır. Düzeltmenin tüm fikri budur: saldırgan kontrollü girdiden gelen dizin bileşenlerini onurlandırmayı durdurmak. Ekteki dokümantasyon değişiklikleri, dosya adının mutlak veya göreceli bir yol değil, basit bir taban adı veya kök olması gerektiğini ve derleme araçlarının güvenlik nedeniyle dizin ayırıcılarını yok sayacağını açıkça belirtmektedir. Bu kombinasyon, kod düzeltmesi ve dokümantasyonun güçlendirilmesi, güvenlik açığının gerçekten de tasarım alanı belgesindeki yol taşıyan meta verilere duyulan güvenle ilgili olduğuna dair güçlü bir işarettir. (GitHub)

Sürüm geçmişi de önemlidir, çünkü halka açık ilk referanslar sabit sürümle ilgili bazı karışıklıklar yaratmıştır. Danışma ve NVD şunları işaret etmektedir 4.60.2 yamanmış satır olarak ve deponun sürüm geçmişinde artık 4.60.2 'de Python-sürüm desteği değişikliğini almadan güvenlik düzeltmesini kullanabilmeleri için 9 Aralık 2025'te yayınlanan bir backport sürümü olarak açıkça oluşturulmuştur. 4.61.0. Bir sorun açıldı çünkü kullanıcılar başlangıçta 4.60.2ancak mevcut sürüm sayfası ve NEWS dosyası artık her ikisini de gösteriyor 4.61.0 ve daha sonra 4.60.2 backport. (GitHub)

Kamu ciddiyet skorları neden aynı fikirde değil?

Yalnızca tek bir veritabanına bakarsanız, yanlış operasyonel çıkarımlarda bulunabilirsiniz. Ubuntu'nun da yansıttığı GitHub'ın CNA tarafından sağlanan orijinal puanlaması şöyledir CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:C/C:N/I:H/A:L6.3 Orta. Bu model şuna daha yakın bir şeyi ifade eder: kurban kötü amaçlı bir tasarım alanı dosyasını işlemelidir, kullanıcı etkileşimi söz konusudur, saldırganın savunmasız koda doğrudan bir ağ yolu olması gerekmez ve en acil etki, bir miktar kullanılabilirlik etkisiyle birlikte bütünlük hasarıdır. Bu, masaüstü iş akışları, çevrimdışı derleme adımları veya yerel araç çağrıları için gerçekçi bir modeldir. (NVD)

Bununla birlikte, NVD'nin daha sonraki zenginleştirmesi, aşağıdaki hususlara ilişkin ayrı bir değerlendirme eklemektedir AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H9,8 Kritik. Modern dağıtımları düşünürseniz bu skoru anlamak daha kolaydır. varLib bir hizmete gömülüdür, bir API'ye sarılmıştır veya kullanıcı tarafından gönderilen tasarım dosyalarını anlamlı bir insan incelemesi olmadan işleyen otomatik bir iş akışı aracılığıyla açığa çıkar. Bu ortamda "yerel" varsayımı çökmektedir. Kötü amaçlı dosya ağ üzerinden gelir, işleme otomatiktir ve çıktı, dosya yazmayı kod yürütmeye dönüştüren bir konuma düşebilir. NVD, her kurulumun varsayılan olarak uzaktan istismar edilebilir olduğunu söylemiyor. Dağıtım bağlamının çeşitli "yerel" varsayımları çökertebileceğini etkin bir şekilde kabul etmektedir. (NVD)

Doğru sonuç, bir kaynağın doğru, diğerinin yanlış olduğu değildir. Doğru sonuç şudur çevre ciddiyete karar verir. Kuruluşunuz yalnızca güvenilir kurum içi tasarım varlıklarını derlemek için bir geliştirici iş istasyonunda fontTools kullanıyorsa, GitHub veya Ubuntu görünümü riskinize daha yakın olabilir. Yüklenen tasarım alanı projelerini kabul eden bir hizmet veya üçüncü taraf yazı tipi kaynaklarını alan bir CI şeridi ya da çıktıları web erişimli konumlara yazan bir içerik platformu çalıştırıyorsanız, NVD tarzı değerlendirme gerçeğe daha yakın olabilir. CVE-2025-66034'ü "GitHub öyle dediği için Orta" olarak değerlendirmek, istismar ön koşullarını kontrol etmeden "her zaman Kritik" olarak değerlendirmek kadar tehlikelidir. (GitHub)

Aynı önem derecesi ayrımı aşağı yönde de görülmektedir. IBM'in Watson Konuşma Hizmetleri Kartuşu için hazırladığı güvenlik bülteni NVD çerçevesini benimseyip sorunu CVSS 9.8 olarak listelerken, Canonical daha düşük puanı koruyor ve yerel vektörü ve kullanıcı etkileşimi varsayımlarını açıkça kaydediyor. Bu aşağı akış tavsiyeleri faydalıdır çünkü satıcıların aynı temel hatayı, savunmasız bileşene ürünlerinin içinde nasıl ulaşılabileceğini düşündüklerine bağlı olarak farklı şekilde sınıflandırdıklarını göstermektedir. (IBM)

Bu hatayı çerçevelemenin en faydalı yolu

En çok indekslenen sayfalar ve kamuya açık yazılar arasında dikkat çekmesi en muhtemel görünen çerçeve "fontTools RCE" veya "fontTools keyfi dosya yazma". Bu, doğrudan bir tıklama veri kümesi değil, başlık kalıplarından yapılan bir çıkarımdır, ancak temellendirilmiş bir çıkarımdır. GitHub'ın kendi tavsiye başlığında keyfi dosya yazma ve XML enjeksiyonu vurgulanmaktadır fontTools.varLibdiğer önde gelen dizinlenmiş sayfalar ise hikayeyi "fontTools RCE güvenlik açığı" şeklinde sıkıştırmaktadır. Tıklama dostu versiyon daha kısa ve duygusal açıdan daha güçlüdür. Daha kesin versiyon aynı zamanda daha iyi bir mühendislik tanımıdır, çünkü okuyucuyu gerçek ilkel ve onu uygulamaya dönüştürmek için gereken çevresel koşullara odaklanmış tutar. (GitHub)

Bu ayrım teknik doğruluk açısından önemlidir. İlkel olan dosya yazma işlemidir. RCE, dosya daha sonra çalıştırılacak, yorumlanacak veya ayrıcalıklı bir yolda yüklenecek bir yere düştüğünde ortaya çıkan sonuçtur. Savunucular bu orta adımı atlarsa, ya soyut "Her yerde kritik" diliyle aşırı tepki verirler ya da "yazı tipi hizmetimiz bir kabuk değil" diye düşündükleri için yetersiz tepki verirler. Daha iyi model şudur: CVE-2025-66034, bir yapı bileşenindeki bir ne-nereye-yazma sorunudur ve yürütme, ortamınızdaki "nereye" işaret ettiğine bağlıdır. (GitHub)

Basit mühendislik terimleriyle temel neden

Yama farkı, güvenlik açığını neredeyse kendi başına açıklayacak kadar basittir. Düzeltmeden önce, türetilen kod dosya adı itibaren vf.dosyaadı varsa, daha sonra output_dir. Düzeltmeden sonra, önce yolu bir temel ada indirger ve ancak ondan sonra birleştirir. Bu, yol taşıyan girdiye güvenmek ile onu güvenli bir yaprak adına indirgemek arasındaki klasik farktır. Başka bir deyişle, hata şu değildir os.path.join() güvenli değildir. Hata şu ki join() saldırgan kontrollü dizin yapısı içermesine izin verildi. (GitHub)

Tavsiye ikinci parçayı ekliyor: içerik enjeksiyonu. Saldırganın etkileyebileceği tek şey çıktı dosya adı değildir. Danışman, PHP de dahil olmak üzere kötü amaçlı kodların XML enjeksiyonu yoluyla yazılı çıktı dosyalarına enjekte edilebileceğini belirtiyor etiketadı unsurlar. Bu da demek oluyor ki saldırgan sadece nerede dosya gider ancak aynı zamanda ne içine girer. Bu iki kontrol birlikte kullanılabilir olduğunda, keyfi dosya yazmadan uzaktan kod yürütmeye kadar dağıtıma bağlı bir yükseltme için gerekli malzemeye sahip olursunuz. (GitHub)

Bu aynı zamanda, derli toplu bir etiket beklediğinizde zayıflık sınıflandırmasının biraz tatmin edici görünmemesinin nedenidir. NVD, CWE-91, XML Enjeksiyonunu kaydeder, çünkü saldırgan kontrolünün bir kısmı XML içeriğinden gelir. Ancak savunucular CWE etiketinin düşüncelerini daraltmasına izin vermemelidir. Operasyonel olarak bu, yol geçişi, keyfi dosya yazma ve bir arka uç oluşturma aracı tarafından kullanılan yapılandırılmış girdiye tehlikeli güven içeren bileşik bir sorundur. Dosya adı işlemeyi düzelten yama, güven sınırının gerçekte nerede kırıldığına dair en güçlü kanıttır. (NVD)

Bunun gerçek bir olaya dönüştüğü yer

Bariz yüksek riskli durum, kullanıcı tarafından sağlanan tasarım alanı projelerini kabul eden ve fontTools.varLib bir API'nin arkasında. Bu tasarımda, saldırı ilk atlamadan itibaren etkili bir şekilde uzaktadır. Hizmet, çıktıları daha sonra web katmanı tarafından sunulan bir dizine veya başka bir alt sistem tarafından taranan ve alınan bir konuma yazarsa, istismar yolu çok daha güvenilir hale gelir. NVD'nin daha yüksek puanı, bu tür bir mimaride en mantıklı olanıdır. (NVD)

İkinci yaygın durum ise CI/CD'dir. Pek çok ekip CI'ın "dahili" olduğu için açığa çıktığını düşünmez, ancak CI sıklıkla depolardan, çekme isteklerinden, sorun eklerinden, tasarım satıcısı aktarımlarından veya oluşturulan paketlerden üçüncü taraf varlıklarını alır. Eğer bir yazı tipi oluşturma aşaması kötü niyetli bir .designspace dosyasının bir CI çalıştırması sırasında rastgele yazılması, çalışma alanı dosyalarını, derleme eserlerini veya çalıştırıcıdaki bitişik dizinleri hedefleyebilir. Modern boru hatlarında bu, çıktıların zehirlenmesi, dağıtım paketlerinin değiştirilmesi veya daha sonra bir alt aşamada yürütülecek eserlerin yerleştirilmesi anlamına gelebilir. Saldırı yüzeyi genel bir web uç noktasından daha küçüktür, ancak patlama yarıçapı daha büyük olabilir. İşte tam da bu nedenle yapı zinciri güvenlik açıkları, ön uç ayrıştırıcı hatalarıyla aynı titizliği hak etmektedir. Kamuya açık belgeler her CI senaryosunu sıralamamaktadır, ancak etkilenen yol ve ilkel yazım, bunu resmi kayıtlardan doğrudan ve makul bir çıkarım haline getirmektedir. (GitHub)

Üçüncü vaka ise gömülü bağımlılık maruziyetidir. IBM, yığınındaki ürünlerin savunmasız fontTools sürümleri içerdiğini ve düzeltme gerektirdiğini kabul eden bültenler yayınladı. Bu, fontTools'a bağlı olan tüm yazılımlarda evrensel istismar edilebilirliği kanıtlamaz, ancak önemli bir şeyi kanıtlar: bu, yalnızca tipograflar tarafından kullanılan niş bir komut satırı yardımcı programıyla sınırlı izole bir sorun değildir. Kurumsal ürünlere ve hizmet çalışma zamanlarına, satıcıların tavsiye ve düzeltilmiş sürümler göndermek zorunda kalacağı kadar ulaştı. (IBM)

İşte çoğu ekibin kullanması gereken pratik risk matrisi:

CVE-2025-66034 fontTools'taki ilk uyarı işareti değil

Savunucuların bunu ciddiye almasının bir nedeni, fontTools'un zaten ayrıştırıcıyla ilgili kayda değer bir sorun yaşamış olmasıdır: CVE-2023-45139. Daha önceki güvenlik açığında, alt küme oluşturma modülünde, OT-SVG tablosu içeren bir aday yazı tipini ayrıştırırken keyfi varlık çözümlemesine izin veren bir XML Harici Varlık sorunu vardı. GitHub bunu Yüksek olarak sınıflandırdı ve NVD etkilenen aralığı şu şekilde kaydetti 4.28.2 kadar ancak hariç 4.43.0. Etki farklıydı, ancak tema farklı değildi: yapılandırılmış, saldırganın etkilediği yazı tipi verileri ayrıcalıklı ayrıştırma mantığına bir sınırı geçiyordu. (NVD)

Bu geçmiş, ekiplerin iyileştirme konusundaki düşüncelerini değiştirmelidir. Doğru ders "bu CVE'yi düzelt ve yoluna devam et" değildir. Doğru ders, yazı tipi işleme bileşenlerinin diğer güvenilmeyen içerik işlemcilerle aynı risk ailesine ait olduğudur. Uygulamanız tasarım varlıkları, medya varlıkları, şablonlar veya paketleme girdileri gibi görünen dosyaları kabul ediyorsa, bunları ayrıştıran arka uç bileşeni kum havuzu, kısıtlı dosya sistemi erişimi, ağ çıkış incelemesi ve bağımlılık izlemeyi hak eder. Dosya uzantısının .designspace yerine .zip, .svgveya .pdf mesele bu değil. Mesele güven sınırının aşılmasıdır. (NVD)

Savunucuların öncelikle kontrol etmesi gerekenler

İlk soru çok basit: şu ürünleri kullanıyor musunuz? fonttools çevrenizdeki herhangi bir yerde, doğrudan veya geçişli olarak. Etkilenen aralık >= 4.33.0 ve < 4.60.2ve proje şimdi her ikisini de yayınladı 4.61.0 ve bir backport 4.60.2 özellikle düzeltmeyi taşımak için. Eğer o pencerenin içindeyseniz, harekete geçmeniz gerektiğini varsaymalısınız. (GitHub)

İkinci soru ilkinden daha önemlidir: Güvenlik açığı olan koda nereden erişilebilir? Bir kütüphane bağımlılık ağacınızda aylarca kalabilir ve saldırgan kontrolündeki tasarım alanı girdisini hiç işlemiyorsa çok az önem taşıyabilir. Aynı kütüphane, bir yükleme hattına veya değişken yazı tiplerini talep üzerine derleyen bir hizmete güç sağlıyorsa acil bir olay olabilir. Genel önem derecesi ayrımı tam da bu nedenle vardır. Sürümler size prensipte açık olup olmadığınızı söyler. Ulaşılabilirlik size ne kadar hızlı hareket etmeniz gerektiğini söyler. (NVD)

Üçüncü soru ise dosya sistemi düzenidir. Savunmasız işlem yalnızca yürütme semantiği ve daha sonra yorumlayıcı yolu olmadan monte edilmiş izole bir çalışma dizinine yazıyorsa, en kötü durum sonucunuz bozulma veya iş akışı kesintisi olabilir. Aynı işlem web üzerinden erişilebilen bir dizine, bir şablon yoluna, bir içe aktarma dizinine, bir eklenti yoluna veya bir dağıtım artifakt paketine yazabiliyorsa, risk keskin bir şekilde yukarı doğru hareket eder. GitHub'ın danışmanlığı, saldırganın çıktının konumunu, uzantısını ve içeriğini kontrol edebileceğini açıkça belirtiyor. Üzerinde durulması gereken ayrıntı budur. (GitHub)

Hemen şimdi yapabileceğiniz güvenli kontroller

Hızlı bir yerel sürüm kontrolü hala en hızlı ilk geçiştir:

python - <<'PY'
import sys
deneyin:
    import fontTools
    print("fontTools sürümü:", getattr(fontTools, "__version__", "unknown"))
except Exception as e:
    print("fontTools içe aktarılamaz:", e, file=sys.stderr)
PY

Tek bir virtualenv yerine ortamları tarıyorsanız, bağımlılık araçları daha kullanışlıdır:

pip list | grep -i fonttools
pip show fonttools
pipdeptree | grep -i -A3 fonttools

Kapsayıcılı iş yükleri için paketi imajların içinde arayın ve katmanları oluşturun:

python -m pip freeze | grep -i fonttools
syft . | grep -i fonttools
grype . | grep -i fonttools

Bu komutlar istismar edilebilirliği kanıtlamaz, ancak ilk operasyonel soruyu hızlı bir şekilde yanıtlar: savunmasız paket mevcut mu ve varsa nerede. Paket, etkilenen sürümler ve düzeltilen sürümlerin tümü danışma ve sürüm kayıtlarında belgelenmiştir. (GitHub)

Daha hedefli bir erişilebilirlik incelemesi, aşağıdaki noktalara bakmalıdır fontTools.varLib.main() ya da fonttools varLib CLI çağrıldığında veya hizmetlerin .designspace dosyalar. Bu dizeleri aramak zarif değildir, ancak genellikle gerçeğe giden en kısa yolu bulur:

grep -R "fontTools.varLib.main" .
grep -R "fonttools varLib" .
bul . -iname "*.designspace"

GitHub danışmanlığı, savunmasız yolun şu olduğunu açıkça söylüyor main() CLI tarafından ve aşağıdaki kodları çağıran kod tarafından kullanılan yol fontTools.varLib.main(). Bu nedenle bu dizeler doğru ilk arama hedefleridir. (GitHub)

Sorumlu bir çözüm neye benzer

Minimum düzeltme basittir: şu sürüme yükseltin 4.60.2 veya daha sonra veya 4.61.0 ve ortamınız zaten daha yeni temel çizgiyi destekliyorsa daha sonra. Projenin sürüm notları ve NEWS dosyası şunu açıkça belirtmektedir 4.60.2 güvenlik backport'udur ve 4.61.0 aynı yol işleme sertleştirmesini içerir. (GitHub)

Ancak iş akışı mimariniz hala "tasarım dosyalarının zararsız olduğunu" varsayıyorsa yama tek başına yeterli değildir. Olgun bir düzeltmenin üç katmanı vardır. Birincisi sürüm iyileştirme. İkincisi, girdi güveninin azaltılmasıdır: işlem yapmayın .designspace veya uygulama kodu veya dağıtılabilir yapılarla aynı güven bölgesinde güvenilmeyen kullanıcılardan bitişik font proje varlıkları. Üçüncüsü sınırlama: font derlemesini, özel bir çıktı dizini olan, web kökleriyle yol çakışması olmayan, sınırlı yazma izinleri olan ve yazdığı herhangi bir şeyi yürütmek için hiçbir neden olmayan kısıtlı bir çalışana koyun. Bu mimari adımlar tavsiyelerde kelimesi kelimesine belirtilmemiştir, ancak doğrudan yazma ilkelinden ve yama tasarımından kaynaklanmaktadır. (GitHub)

Sertleşmiş bir işçi modeli genellikle şöyle görünür:

hizmet: font-build-worker
çalışma zamanı:
  kullanıcı: nonroot
  read_only_root_filesystem: true
  allow_network_egress: false
dosya sistemi:
  input_mount: /srv/input
  output_mount: /srv/output
  temp_mount: /tmp
politika:
  output_mount_not_served_by_web: true
  no_shared_mounts_with_app_code: true
  no_plugin_or_template_paths: true
bağımlılıklar:
  fonttools: ">=4.60.2"

Mesele tam olarak bu YAML'nin yığınınıza ait olması değildir. Mesele, savunmasız bileşenin, keyfi bir yazmanın bir uygulama tehlikesinden ziyade içerilen bir kusur olduğu bir dosya sistemi sınırı içinde yaşaması gerektiğidir. Ayrıştırıcı hatalarının tüm sınıflarını bu şekilde daha az pahalı hale getirirsiniz. Kamu kayıtları, temel ad uygulaması ve güvenli çıktı işleme ihtiyacını güçlü bir şekilde desteklemektedir; sınırlama mantıksal bir uzantıdır. (GitHub)

Yama sonrasında nelerin izlenmesi gerekir?

CVE-2025-66034, "yükselt ve unut" varsayımında bulunmanız gereken türden bir sorun değildir. Güvenlik açığı olan işleme, düzeltmeden önce güvenilmeyen girdilere dokunduysa, olay incelemesi makuldür. Dış kaynaklı verilerin geçmişte işlenip işlenmediğine bakın .designspace dosyaları, özellikle de dağıtım dizinlerine, eklenti konumlarına veya web tabanlı depolama alanına erişimi olan hizmetlerde veya işlerde. Ayrıca, amaçlanan çıktı köklerinin dışında beklenmedik şekilde oluşturulan dosyalar, derleme çıktı alanlarında şüpheli dosya uzantıları veya yazı tipi işleme işlerinin etrafındaki yapılandırma ve uygulama dosyalarındaki değişiklikleri de arayın. Bu sinyaller tek bir resmi kontrol listesinden alınmamıştır, ancak doğrudan danışmanlığın saldırganların yazılı dosyaların konumunu, uzantısını ve içeriğini kontrol edebileceği yönündeki uyarısından türetilmiştir. (GitHub)

Merkezi günlük kaydı olan ekipler için en değerli korelasyon, dosya işleme olayları ile normal derleme hedefi dışındaki dosya sistemi yazımları arasındadır. Boru hattı telemetrisiniz size hangi işin bir dosyayı işlediğini söyleyebiliyorsa .designspace dosyasını ve o işin hangi dizinlere yazdığını bulmak için bu verileri kullanın. Yamanın kendisi, temel kötüye kullanım yolunun bir çıktı dizininden kaçan güvenilmeyen dosya adı bileşenleri olduğunu göstermektedir. Adli soru, bu kaçışın düzeltmeden önce ortamınızda mümkün olup olmadığı veya gözlemlenip gözlemlenmediğidir. (GitHub)

Bu CVE neden yazı tipi araçlarının ötesinde önem taşıyor?

CVE-2025-66034'ün kalıcı dersi dar anlamda "yazı tipi yığınınızı denetleyin" değildir. Modern yazılımın, kullanıcılar ve otomasyon adına güven sınırlarını sessizce aşan çok sayıda küçük, özel işlemci biriktirmiş olmasıdır. Bir tasarım alanı dosyası geleneksel bir silah yükü gibi görünmez, ancak bir arka uç hizmeti onu yorumladığı, derlediği, dosya sistemi yollarıyla birleştirdiği ve sunucu tarafı çıktıları yaydığı anda, yürütme yüzeyinizin bir parçası haline gelir. Bu, güvenlik ekiplerinin görüntü dönüştürücüler, PDF araç zincirleri, markdown oluşturucular, arşiv çıkarıcılar ve ofis belgesi dönüştürücülerle öğrenmek zorunda kaldığı genel dersin aynısıdır. Uzantı değişir. Kontrol problemi değildir. (GitHub)

Ayrıca bir tedarik zinciri açısı da var. IBM'in satıcı tavsiyeleri, fontTools'taki bir kütüphane sorununun daha büyük kurumsal tekliflere yayıldığını ve ürün sürümlerinde düzeltilmesi gerektiğini göstermektedir. Geçişli riskin pratik anlamı budur. Hiçbir zaman fonttools varLib ve yine de başka birinin çalışma zamanına bağladığı bir hizmetin içinde göndermeye devam edebilirsiniz. Bu nedenle bağımlılık envanterleri ve SBOM farkındalı inceleme, temel iş mantığınızdan uzak görünen paketler için bile önemlidir. (IBM)

Manuel kod incelemesi ve tek seferlik bağımlılık taramalarından daha hızlı hareket etmeye çalışan ekipler için, bu tür bir sorun tam da yapay zeka odaklı bir doğrulama iş akışının yararlı hale geldiği yerdir. CVE-2025-66034 sadece bir sürüm dizesi ile ilgili değildir. Aynı zamanda erişilebilirlik, yürütme yolu, yazma konumu ve çevresel ön koşullar. İyi bir güvenlik iş akışı bu dört soruya da yanıt verebilmelidir: savunmasız paketin nerede olduğu, tehlikeli işlevin gerçekten çağrılıp çağrılmadığı, girdinin hangi güven sınırını aştığı ve sonuçta ortaya çıkan yazının operasyonel olarak anlamlı herhangi bir şeye dokunup dokunamayacağı. Bağımlılık farkındalığı ile istismar edilebilir yol farkındalığı arasındaki fark budur. (GitHub)

Bu aynı zamanda aşağıdaki gibi otomatik sızma testi platformlarının da nedenidir Penligent broşür tarayıcıları yerine kanıt motorları olarak kullanıldıklarında daha faydalı olurlar. Böyle bir durumda amaç, NVD yaptı diye "Kritik" diye bağırmak değildir. Amaç, gerçek bir uygulama yolunun doğru dosya türünü kabul edip etmediğini, savunmasız koda ulaşıp ulaşmadığını, amaçlanan dizinden kaçıp kaçmadığını ve önemli bir yola girip girmediğini doğrulamaktır. Güvenlik ekipleri yalnızca CVSS'ye dayanarak tartışmak yerine bu zinciri doğrulayabildiklerinde, daha iyi iyileştirme kararları alırlar ve yanlış aciliyete daha az zaman harcarlar. Operasyonel değer budur.

Alt satır

CVE-2025-66034, savunucuların her zaman ciddiye alması gereken üç şeyi bir araya getirdiği için dikkat çekmeyi hak ediyor: saldırgan kontrollü yapılandırılmış girdi, bu girdiden türetilen dosya sistemi yazmaları ve üretilen çıktıların daha sonra daha güçlü bileşenler tarafından tüketilebileceği dağıtım bağlamları. Resmi kaynaklar temel gerçekler konusunda tutarlıdır: fontTools.varLib etkilenir, sürümler 4.33.0 önce 4.60.2 güvenlik açığı varsa, düzeltme, yol taşıyan dosya adlarına güvenmeyi durdurmak ve yalnızca taban adını kullanmaktır ve sonuçta ortaya çıkan ilkel, ortam yazılı bir dosyayı yürütülebilir içeriğe dönüştürdüğünde uzaktan kod yürütülmesine yol açabilir. (GitHub)

Şiddet anlaşmazlığı gürültü değildir. Gerçek hikaye budur. Güvenilir dosyaların bulunduğu kapalı bir yerel iş akışında, bu durum kontrol altında tutulan bir Ortam gibi davranabilir. Tasarım varlıklarını dışarıdan alan ve tehlikeli yerlere yazan otomatik bir hizmette, NVD'nin kaydettiği ve alt tedarikçilerin benimsediği Kritik resme çok daha yakındır. Ekibiniz bunu okuduktan sonra tek bir eylemde bulunursa, bu şu olmalıdır: kararı tek bir puana indirgemeyin. Paketi yükseltin, erişilebilir yolların haritasını çıkarın, çalışanı izole edin ve çıktıların nereye inebileceğini doğrulayın. CVE girişini gerçek bir savunma tepkisine dönüştürmenin yolu budur. (NVD)

Önerilen iç ve dış okumalar

• CVE-2025-66034 için NVD girişi
• GitHub danışmanlığı, GHSA-768j-98cg-p3fv
• fontTools yama taahhüdü
• fontTools 4.60.2 ve 4.61.0'ı gösteren sürüm notları
• CVE-2025-66034 için Ubuntu CVE sayfası
• İlgili fontTools sorunu için NVD girişi, CVE-2023-45139
• 2026'da Pentest Yapay Zeka Araçları - Gerçekte Ne İşe Yarıyor, Ne Bozuluyor
• Yapay Zeka Aracı Güvenliğinin Geleceği - Openclaw Güvenlik Denetimi
• OpenClaw Güvenlik Denetimi, Bir Yapay Zeka Ajanı Dosyalarınıza, Araçlarınıza ve Hesaplarınıza Dokunabildiğinde Gerçekte Neler Bozulur?