CVE-2025-66034, Bir Yazı Tipi Oluşturma Dosyası Keyfi Bir Yazma İlkeline Dönüştüğünde

CVE-2025-66034, birçok ekibin ilk okumada hafife aldığı türden bir güvenlik açığıdır. Etkilenen paket fontToolsfontlarla çalışmak için iyi bilinen bir Python kütüphanesidir. Etkilenen kod yolu şöyledir fontTools.varLib'den değişken fontlar oluşturmak için kullanılır. .designspace dosyalar. Hata belirsiz bir demo betiğinde değil. Yukarı akış, dağıtım ve kurumsal satıcı kanallarında gerçek belgeler, gerçek aşağı akış paketlemesi ve gerçek düzeltme notları ile gerçek bir derleme akışında yer alır. Resmi yukarı akış danışmanlığı, aşağıdaki sürümlerin savunmasız olduğunu söylüyor 4.33.0 aşağıdakiler dahil ancak bunlar hariç 4.60.2 keyfi dosya yazımı için kandırılabileceğini ve bunun kötü niyetli bir kişi tarafından uzaktan kod yürütülmesine yol açabileceğini .designspace dosyası işlenir. (GitHub)

Bunun önemli olmasının nedeni soyut olarak "yazı tipleri" değildir. Önemli çünkü modern yazılım sistemleri her şeyi otomatikleştiriyor. Yapı çalışanları tasarım varlıklarını derler. SaaS platformları kullanıcı tarafından sağlanan dosyaları alır. CI işleri depoları çeker ve artifaktlar oluşturur. Dahili araçlar güvenilmeyen yüklemeleri işler çünkü birileri bir tasarım dosyasının bir komut dosyası, şablon veya arşivden daha az tehlikeli olduğunu varsaymıştır. CVE-2025-66034 bu varsayımı yıkıyor. Yapılandırılmış bir tasarım eserinin nasıl bir dosya sistemi yazma ilkeline ve yanlış ortamda bir kod yürütme yoluna dönüşebileceğini göstermektedir. (fontTools Belgeleri)

Kamuoyu araştırması perspektifinden bakıldığında, saygın sonuçlar arasında en net, en çok tekrarlanan çerçeveleme teknik olarak da doğru olanıdır: bu bir fontTools varLib sağlayan hata keyfi dosya yazma'ye dönüşür ve bazı dağıtım koşulları altında bu yazı uzaktan kod yürütme. Bu, yukarı akış GitHub danışmanlığı, GitLab'ın danışmanlık veritabanı, NVD'nin açıklaması ve daha sonraki birçok ikincil açıklama tarafından kullanılan veya yankılanan çerçevedir. Doğrudan, doğru ve ipucunu belirsiz ifadelerin altına gömmekten daha iyidir. (GitHub)

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

Resmi açıklama ana yetkili kaynaklar arasında tutarlıdır. Savunmasız sürümlerde fontTools, the fonttools varLib komutunu veya kodunu çağıran fontTools.varLib.main(), kötü niyetli bir dosyayı işlediğinde kötüye kullanılabilir .designspace dosya. Kusur, sanitize edilmemiş dosya adı kullanımından kaynaklanmaktadır. Danışma belgesinde, saldırganların çıktı dosyalarını rastgele dosya sistemi konumlarına yazmak için yol geçiş dizilerini kullanabileceği ve ayrıca çıktı dosyalarına kontrollü içerik enjekte edebileceği açıklanmaktadır. Bu kombinasyon, dosya yazmadan kod yürütmeye giden yolu oluşturan şeydir. (GitHub)

Upstream'in danışmanlığı mekanik konusunda alışılmadık derecede açık. Güvenlik açığının "içerik enjeksiyonu ile birleştirilmiş sanitize edilmemiş dosya adı işleme" nedeniyle var olduğunu söylüyor. Birçok danışmanın yaptığından daha ileri gidiyor ve olası sonuçları açıkça listeliyor: yazı tipi dosyalarını rastgele dosya sistemi konumlarına yazma, yapılandırma dosyalarının üzerine yazma, uygulama dosyalarını ve bağımlılıkları bozma ve uzaktan kod yürütme elde etme. Bu dil önemlidir, çünkü bakımcıların bunu pratik patlama yarıçapı olmayan zararsız bir yol hatası olarak ele almadıklarını gösterir. (GitHub)

Yama buna uygun olarak küçük ve açıklayıcıdır. Yukarı akıştaki düzeltme davranışı değiştirir, böylece değişken bir yazı tipi dosya adı mevcut olduğunda, yalnızca os.path.basename(vf.filename) kullanılır. Başka bir deyişle, dizin bileşenleri çıktı yolu birleştirilmeden önce çıkarılır. Sürüm notları daha sonra bunu açık bir dille ifade eder: yol geçiş saldırılarını önlemek için yalnızca taban adını kullanın varLib.main. Bu, istismar hikayesi ile yama hikayesinin neredeyse bire bir örtüştüğü nadir durumlardan biridir. (GitHub)

Bu da güven sınırı hatasını açıklamayı kolaylaştırır. Savunmasız akış, saldırganın etkilediği bir dosya adını güvenli bir çıktı adıymış gibi ele alıyordu. Bu dosya adının geçiş işaretleri veya mutlak yol semantiği taşımasına izin verildiğinde, çıktı dizini bir sınır olmaktan çıkmış ve bir öneri haline gelmiştir. Bu noktada geriye kalan tek soru, hedef ortamın daha sonra önemli olacak bir dosyayı yazmak için anlamlı bir yere sahip olup olmadığıdır. Gerçek ortamlarda cevap genellikle evettir. (GitHub)

Designspace dosyası neden oyuncak bir girdi değildir?

Bu CVE, ne olduğunu anladığınızda daha da zorlaşır. .designspace uygulamada. fontTools dokümantasyon açıklar designspaceLib tasarım alanı dosyalarını okuma, yazma ve düzenleme bileşeni olarak tanımlamakta ve bu dosyaların eksenleri, kaynakları, değişken yazı tiplerini, örnekleri ve ilgili verileri tanımladığını açıklamaktadır. Tasarım Alanı varLib dokümantasyonu kendisini değişken yazı tipi verilerini işleme, oluşturma ve enterpolasyon paketi olarak tanımlamaktadır. Dokümanlar ayrıca, bir designspace dosyasının aşağıdakilerle değişken bir yazı tipi oluşturmada kullanılabileceğini açıkça göstermektedir varLib. Bu teorik bir tesisat değildir. Bu bir üretim iş akışıdır. (fontTools Belgeleri)

Belgeler ayrıca dosya adlarının ve yolların neden designspace modelinin bir parçası olduğunu da açıklamaktadır. Designspace dosyaları sistemler ve depolar arasında hareket ettiğinden, bir designspace dosyası diğer dosyalara referansları genellikle göreceli yollarla saklar. Bu tamamen makul bir işlevselliktir. Sorun dosyaların yol içermesi değildir. Sorun, çıktı tarafında yanlış yol semantiğine güvenilmiş olmasıdır. Bir saldırgan üretilen çıktının nereye gideceğini etkileyebildiği anda, bir veri açıklama dosyası yapılandırmadan çok bir yazma talimatı gibi görünmeye başlar. (fontTools Belgeleri)

Bu, birçok mühendisin gözden kaçırdığı daha geniş bir derstir. Olgun otomasyonda veri formatları pasif değildir. Genellikle adlar, yollar, hedefler, referanslar, şablonlar, kurallar, dahil etme yönergeleri ve serileştirme davranışı taşırlar. İşlem hattınız bunları okur, çözümler ve bunlardan artifaktlar çıkarırsa, format siz isteseniz de istemeseniz de bir kontrol sınırına oturur. CVE-2025-66034 aslında bu sınırın yanlış sınıflandırılmasıyla ilgili bir hikayedir. (fontTools Belgeleri)

Basitleştirilmiş bir kod yolundaki güvenlik açığı

Yukarı akış danışmanlığı, temel hassas hatları içerir. Kavramsal olarak, eski mantık bunu yapıyordu:

# basitleştirilmiş, kavramsal
filename = attacker_controlled_filename
output_path = os.path.join(output_dir, filename)
save(output_path)

Sabit mantık bunun yerine etkili bir şekilde bunu yapar:

# basitleştirilmiş, kavramsal
filename = os.path.basename(attacker_controlled_filename)
output_path = os.path.join(output_dir, filename)
save(output_path)

Ne olduğunu hatırlayana kadar bu fark önemsiz görünüyor ../, iç içe göreli yollar veya mutlak stil yol içeriği otomasyon içinde yapabilir. Tek bir taban adı normalleştirme adımı, bir dosya sistemi kaçışını normal bir yapıt yazımına dönüştürmek için yeterlidir. İşte tam da bu yüzden düzeltme çok küçük ve çok önemli. (GitHub)

Yukarı akış danışmanlığı ayrıca içerik enjeksiyonunun risk resminin bir parçası olduğuna işaret etmektedir. Bu sadece "bir yere bir dosya yazmak" değildir. Saldırgan ne yazılacağını da etkileyebilir. RCE'yi belirli dağıtımlarda gerçekçi bir sonuç haline getiren de budur: anlamlı bir konuma kontrollü yazma ve kontrollü içerik, yalnızca genel bir bozulma hatasından çok daha tehlikeli bir ilkeldir. (GitHub)

Puanlama anlaşmazlığı sayıdan daha önemlidir

CVE-2025-66034'ün en ilginç kısımlarından biri, kamu kaynaklarının ciddiyet konusunda hemfikir olmamasıdır. NVD sayfası şu anda NVD tarafından atanan CVSS 3.1 puanını şu şekilde göstermektedir 9,8 Kritik vektör ile AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HGitHub'daki CNA girişi ise şunları göstermektedir 6,3 Orta vektör ile AV:L/AC:H/PR:N/UI:R/S:C/C:N/I:H/A:L. Bunlar birbirine yakın değil. Bunlar istismar edilebilirlik ve çevre hakkında çok farklı varsayımları temsil etmektedir. (NVD)

Bu görüş ayrılığı, dinsel bir merak değildir. Operasyonel açıdan önemlidir. GitHub'ın puanlaması, sorunu daha çok yerel bir araç zinciri yolunun kullanıcı destekli, iş akışına bağlı bir kötüye kullanımı gibi ele alıyor. NVD'nin zenginleştirmesi ise daha çok ağ üzerinden ulaşılabilen, düşük sürtünmeli bir RCE gibi ele alıyor. Her iki sayı da körü körüne bir gösterge tablosuna kopyalanmamalı ve "gerçek" olarak adlandırılmamalıdır. Asıl soru, ortamınızın güvenilmeyen tasarım alanı girdisini otomatik bir şekilde işleyip işlemediği ve çıktı yolunun yürütülebilir, dağıtılabilir, web'de sunulan veya güvenlik açısından hassas bir şeyle kesişip kesişmediğidir. Bazı ortamlarda GitHub'ın düşük puanı pratik riski daha iyi tanımlayacaktır. Diğerlerinde ise NVD'nin daha sert görüşü gerçeğe daha yakın olacaktır. (NVD)

Ubuntu'nun güvenlik uyarısı burada kullanışlıdır çünkü riski somut operasyonel bir dille ifade etmektedir. Eğer bir kullanıcı ya da otomatik sistem kandırılarak özel olarak hazırlanmış bir .designspace dosyasına saldıran bir saldırgan, hedef dizinin dışına rastgele dosyalar yazarak uzaktan kod yürütülmesine neden olabilir. Bu ifade olgun orta zemini yakalar: hata gerçektir, etkiye giden yol gerçektir ve dağıtım bağlamı dosya yazmadan RCE'ye geçmenin ne kadar kolay olduğuna karar verir. (Ubuntu)

Deneyimli güvenlik ekipleri böyle bir CVE'yi tam olarak bu şekilde okumalıdır. Önem derecesi tek başına tanımlayıcının bir özelliği değildir. İlkelin, tetikleme yolunun, çevredeki otomasyonun ve saldırgan tarafından kontrol edilen baytların sonunda indiği yerin ürünüdür. En iyi savunma programları sadece "Bu Kritik mi?" diye sormaz. "Bu, gerçek boru hattımızdaki bir güven sınırını geçebilir mi?" diye sorarlar. CVE-2025-66034, ikinci sorunun neden daha önemli olduğuna dair güçlü bir örnektir. (NVD)

Bu hatanın üretimde gerçeğe dönüştüğü yer

Gerçek dünyada maruz kalmanın birkaç makul yolu vardır. İlki bariz olanıdır: kullanıcı tarafından sağlanan bilgileri kabul eden herhangi bir hizmet veya iş .designspace dosyaları ve bunları fonttools varLib veya fontTools.varLib.main(). İkincisi, bir çekme isteği, paket içe aktarma, senkronize edilmiş varlık paketi veya tasarım aktarımının, güvenilir bir derleme çalışanının daha sonra derleyeceği kötü amaçlı bir dosya sunduğu depo tabanlı otomasyondur. Üçüncüsü ise dolaylı bağımlılık kullanımıdır; burada daha büyük bir platform fontTools Çalışma zamanında bir yerde ve güvenlik ekibi bir bülten gelene kadar bir yazı tipi işleme yolunun var olduğunu fark etmiyor. Resmi dokümantasyon ve alt satıcı bildirimleri bu senaryoların zorlama soyutlamalar olmadığını göstermektedir. (fontTools Belgeleri)

IBM bültenleri, aşağı yönlü erişimi gösterdikleri için özellikle değerlidir. IBM'in Maximo Application Suite Visual Inspection Component bülteninde, bileşenin bir fontTools bağımlılığı CVE-2025-66034'e karşı savunmasızdır ve sürümü tanımlar 9.1.10 etkilenen için iyileştirilmiş salım olarak 9.1.x versiyonlar. IBM'in Watson Konuşma Hizmetleri Kartuşu bülteninde şöyle deniyor fontTools hizmet çalışma zamanlarında da kullanılır, sürümleri etkiler 4.0.0 aracılığıyla 5.3.0'de iyileştirme ile 5.3.1. Bunlar, savunucuların dikkat etmesi gereken türden bağımlılık zinciri örnekleridir. (IBM)

Dağıtım paketleri de benzer bir hikaye anlatıyor. Debian'ın kaynak paket izleyicisi, sorunu yeni paketlerde düzeltilmiş olarak gösterirken, daha eski olanlar bazı parçalarda bir DSA olmadan savunmasız kalmaktadır. Ubuntu'nun USN-7917-1'i düzeltmelerin yayınlandığını söylüyor ve özellikle CVE-2025-66034'ün Ubuntu'yu etkilediğini belirtiyor 24.04 LTS, 25.04ve 25.10ve ilgili paket sürümleri düzeltme için yayınlandı. Bu, bunun sadece bir PyPI hijyen sorunu olmadığı anlamına gelir. Ekiplerin ayrıca işletim sistemiyle paketlenmiş kopyaların envanterini çıkarması gerekir. (security-tracker.debian.org)

Buradan çıkarılacak pratik sonuç basittir. "Maruz kaldık mı?" sorusuna sadece şu hususları kontrol ederek cevap veremezsiniz gereksinimler.txt. Temel imajlarınıza, dağıtım paketlerinize, hizmet çalışma zamanlarınıza, satıcı ürünlerinize ve aşağıdakileri çağıran tüm dahili araçlara bakmanız gerekir varLib doğrudan. Kuruluşunuz tasarım otomasyonuna, belge dönüştürmeye, marka varlık işlemeye veya yazı tipi paketlemeye dokunuyorsa, bu envanter çalışması isteğe bağlı değildir. (security-tracker.debian.org)

Güvenlik ekiplerinin kullanabileceği hızlı bilgiler

Aşağıdaki tablo, yukarı akış tavsiyeleri, NVD, sürüm notları, dağıtım bildirimleri ve aşağı akış satıcı bültenlerinden en yararlı bilgileri bir araya getirmektedir. (GitHub)

Öğe	Önemli olan ne
Hassas bileşen	fontTools.varLibözellikle de main() kod yolu
Tetikleyici	Kötü niyetli bir kişinin işlenmesi .designspace dosya
Etkilenen sürümler	>= 4.33.0 ve < 4.60.2
Yukarı akış sürümü düzeltildi	4.60.2
Güvenlik değişikliği	Saldırganın etkilediği dosya adı değerlerinin yalnızca temel adını kullanın
Yukarı akış sorunu çerçeveleme	Potansiyel olarak RCE'ye yol açan keyfi dosya yazma artı içerik enjeksiyonu
NVD CVSS	9,8 Kritik
GitHub CNA CVSS	6,3 Orta
Ubuntu notu	Etkilenen 24.04 LTS, 25.04, 25.10; sabit paket sürümleri yayınlandı
Debian notu	Yeni süitlerde düzeltildi, eski süitler izleyici durumunda savunmasız kalmaya devam ediyor
Aşağı akış örnekleri	IBM Maximo Görsel Denetim, IBM Watson Konuşma Hizmetleri Kartuşu

Bazı ortamlarda dosya yazma neden RCE olur?

Her rastgele dosya yazma işlemi hemen RCE değildir. Bunu açıkça söylemekte fayda var. Ancak savunucular aşırı düzeltme yapmamalı ve "her zaman RCE değildir" ifadesini "çoğunlukla zararsızdır" şeklinde değerlendirmemelidir. Otomatik ortamlarda, çıktı dört yerden birine ulaşabildiğinde bir yazma ilkeli son derece tehlikeli hale gelir: çalıştırılabilir bir yer, içe aktarılan bir yer, sunulan bir yer veya zincirdeki bir sonraki adım tarafından güvenilen bir yer. Buna uygulama kodu dizinleri, Python modül yolları, eklenti klasörleri, şablon dizinleri, derleme bağlamları, dağıtım paketleri ve içerik türünü yürütme davranışıyla eşleştiren web erişimli konumlar dahildir. Yukarı akış danışmanlığının yapılandırmanın üzerine yazma ve kötü amaçlı kod enjeksiyonundan bahsetmesi burada önemli bir ipucudur. (GitHub)

Daha ince bir nokta da vardır. Yazma işlemi kod yürütme haline gelmese bile, yine de yüksek güvenirlikli bir bütünlük olayı haline gelebilir. Bağımlılıkları bozmak, gelecekteki derlemeleri zehirlemek, uygulama varlıklarını değiştirmek veya yapılandırmayı daha sonraki davranışları değiştirecek şekilde değiştirmek, büyük güvenlik etkisine neden olmak için yeterli olabilir. Birçok ekip yalnızca "anlık kabuk" sonuçlarına aşırı değer verir ve kalıcı eser zehirlenmesini göz ardı eder. CI/CD ve derleme sistemlerinde, zehirli çıktı yoluyla kalıcılık da aynı derecede tehlikeli olabilir. (GitHub)

Bu nedenle NVD ve GitHub puanlama ayrımı sizi mühendislik sorusundan uzaklaştırmamalıdır. Yazı tipi işleme çalışanınız yalnızca yürütme yolu olmayan, hassas bağlantıları bulunmayan ve üretime giden bir yolu olmayan yalıtılmış bir karalama dizinine yazıyorsa, patlama yarıçapı daha düşüktür. Aynı çalışan geniş dosya sistemi erişimiyle çalışıyorsa veya paketleme, dağıtım veya web katmanıyla durum paylaşıyorsa, risk tablosu hemen değişir. Bu bir teori değildir. Modern yazılım tedarik zincirleri bu şekilde inşa edilir. (NVD)

Zaman çizelgesi ve iyileştirme, kaynaklar ne diyor

GitHub danışmanlığı 28 Kasım 2025 tarihinde yayınlanmıştır. NVD kaydı aynı tarihte yayınlandığını ve daha sonra NVD analizinin kendi CVSS yorumunu eklediğini gösterir. Yukarı akış sürüm notları şunları göstermektedir 4.61.0 28 Kasım 2025 tarihinde, şu açık notla birlikte varLib.main artık yol geçiş saldırılarını önlemek için yalnızca taban adını kullanıyor ve bu CVE-2025-66034'ü düzeltiyor. Daha sonra bir backport sürümü gösteriyorlar, 4.60.2'deki daha geniş destek değişikliğine zorlamadan güvenlik düzeltmesini taşımak için 9 Aralık 2025'te özellikle Python 3.9 kullanıcılarını 4.61.0. Bu iyi idare edilmiş bir tahliye yanıtıdır. (GitHub)

Ubuntu'nun 9 Aralık 2025 tarihli kamu duyurusu, CVE-2025-66034'ü daha eski sürümlerle birlikte paketleyerek fontTools XXE hatası, CVE-2023-45139. Bu eşleştirme yararlıdır çünkü ekiplere bunun ilk kez olmadığını hatırlatır fontTools güvenlikle ilgili yollarla girdi-güven sınırını aşmıştır. Debian'ın izleyicisi daha sonra paketler arasında karışık bir durumu yansıtmaktadır; bu da "yukarı yönde yamalandı" ifadesinin "her yerde yamalandı" anlamına geldiğini varsaymak yerine paket kaynağının envanterini çıkarma ihtiyacını bir kez daha güçlendirmektedir. (Ubuntu)

2026 yılının başlarına gelindiğinde, alt kurumsal satıcılar hala güvenlik açığı olan bağımlılığı barındıran etkilenen ürünler hakkında bültenler yayınlıyordu. IBM'in Maximo Visual Inspection için Mart 2026 ve Watson Speech Services için Şubat 2026 tarihli bildirimleri buna örnektir. Bu gecikme gerçek ekosistemlerde tipiktir. Ayrıca, büyük ürün yığınları ve konteyner görüntüleri söz konusu olduğunda "doğrudan bağımlılığımızı aylar önce yükselttik" ifadesinin neden yeterli bir güvence olmadığını da açıklıyor. (IBM)

Kendi kod tabanınızda nelere bakmalısınız?

Belirlenmesi gereken ilk şey, kuruluşunuzun aşağıdakileri kullanıp kullanmadığıdır fontTools hiç. İkincisi ise, bu yöntemin varLibve üçüncüsü de herhangi bir güvenilmeyen veya yarı-güvenilen .designspace dosyalar bu yola ulaşabilir. Ekipler genellikle ilk soruda durur ve asıl sorunu gözden kaçırır. Bir modda kullanılan güvenli bir bağımlılık başka bir modda güvensiz olabilir. Bu CVE bir akışa özgüdür. Hem bağımlılık envanterine hem de kullanım envanterine ihtiyacınız vardır. (GitHub)

Bariz statik kontrollerle başlayın. Şunları arayın fontTools.varLib, varLib.main, python3 -m fontTools.varLibve fonttools varLib depolarınız, derleme komut dosyalarınız, Docker dosyalarınız, CI tanımlarınız ve dahili araçlarınız arasında. Şunlar için de arama yapın .designspace artifact boru hatlarını besleyen repoların altındaki dosyalar. Amaç sadece paketi bulmak değildir. Bir dosyanın bir eyleme dönüştüğü güven sınırını bulmaktır. İşte bu kırılganlık burada yaşıyor. (GitHub)

Basit bir kabuk denetimi sizi şaşırtıcı derecede ileriye götürebilir:

rg -n "fontTools\\.varLib|varLib\\.main|fonttools varLib|python3 -m fontTools\\.varLib" .
find . -type f -name "*.designspace"
python - <<'PY'
import importlib.metadata as m
try:
    print("fonttools sürümü:", m.version("fonttools"))
Exception dışında:
    print("fonttools bu ortamda yüklü değil")
PY

Kapsayıcılı iş yükleri çalıştırıyorsanız, aynı mantığı yalnızca ana bilgisayarda değil, imajların ve temel imajların içinde de tekrarlayın. Birçok ekip, birincil uygulama bağımlılıkları temizlendikten çok sonra yardımcı program kapsayıcılarında, çalışan görüntülerinde veya not defteri ortamlarında savunmasız kopyalar keşfeder. Bu özellikle aşağıdaki gibi kütüphaneler için olasıdır fontTools Çekirdek uygulama kodu yerine tasarım, görselleştirme, makine öğrenimi veya raporlama araç zincirleri aracılığıyla ortamlara giren. (security-tracker.debian.org)

Şüpheli tasarım alanı girdisi için savunmacı bir ayrıştırıcı kontrolü

Anında yama yapamıyorsanız, yine de maruziyeti derhal azaltmalısınız. Basit kontrollerden biri de .designspace dosya adıyla ilgili alanların dizin ayırıcıları, geçiş işaretçileri veya açıkça güvenli olmayan çıktı adları içerdiği girdi. Bu, yamalamanın yerini almaz. Zaman kazandırır ve siz envanter çıkarıp düzeltme yaparken en belirgin kötüye kullanım yollarını daraltır. Yukarı akış düzeltmesinin kendisi temel olarak bu ilkeyi kod düzeyinde uygulamaktadır. (GitHub)

Aşağıdaki gibi küçük bir Python kapısı, CI veya alım hizmetlerinde yardımcı olabilir:

from pathlib import PurePosixPath, PureWindowsPath
import xml.etree.ElementTree as ET

def is_unsafe_filename(value: str) -> bool:
    eğer değer değilse:
        return False
    bad_markers = ["..", "/", "\\\\", "\\x00"]
    if any(m in value for m in bad_markers):
        True döndür
    # ayrıca mutlak benzeri isimleri de reddeder
    if PurePosixPath(değer).is_absolute():
        True döndür
    if PureWindowsPath(value).is_absolute():
        True döndür
    return False

def validate_designspace(path: str) -> liste[str]:
    ağaç = ET.parse(yol)
    root = tree.getroot()
    bulgular = []
    for eleman in root.iter():
        for attr in ("dosya adı", "yol"):
            val = elem.attrib.get(attr)
            if val and is_unsafe_filename(val):
                findings.append(f "unsafe {attr}={val!r} in ")
    geri dönüş bulguları

# kullanımı
issues = validate_designspace("candidate.designspace")
if issues:
    raise SystemExit("Reddedilen tasarım alanı:\\n" + "\\n".join(issues))

Bu kasıtlı olarak muhafazakârdır. Bazı meşru iş akışlarında belge içinde göreli kaynak referanslarına izin vermeniz gerekebilir. Ancak çıktı adlandırma ve oluşturulan eser yerleşimini etkileyen herhangi bir yol için, katı doğrulama doğru duruştur. CVE-2025-66034'ten çıkarılacak temel ders, dosya sistemi amacının kullanılmadan önce normalleştirilmesi gerektiğidir; çevredeki dosya biçimi "veri gibi göründüğü" için güvenilmemelidir. (fontTools Belgeleri)

İzleme ve tespit, savunucuların gerçekte neyi araçsallaştırması gerektiği

İzlenmesi en kolay şey CVE'nin varlığı değil, istismarın üreteceği davranıştır. Şunları izleyin fonttools varLib veya python3 -m fontTools.varLib onaylanmış derleme çıktı dizinleri dışında yazma işlemleri. Uygulama dizinlerinde yeni oluşturulan yazı tipi benzeri veya beklenmedik dosyalara dikkat edin, site-paketleri, dağıtım çalışma alanları veya font işleme işleri sırasında web üzerinden hizmet verilen konumlar. Şuna dikkat edin .designspace çapraz işaretleyiciler içeren girdiler veya şüpheli uzantılara sahip çıktı adları. Bunlar mükemmel göstergeler değildir, ancak pratik göstergelerdir. (GitHub)

Dosya bütünlüğü izlemeniz varsa, bu genel uyarı yerine hedeflenen ilke için iyi bir durumdur. A varLib süreci çok sıkıcı bir yazma profiline sahip olmalıdır. Yalnızca bilinen bir çıktı kökünde eserler oluşturmalıdır. Bu kökün dışındaki her şey varsayılan olarak şüphelidir. Bu tür dar bir davranışsal beklenti, CVE ID'den bahseden bir imza beklemekten çok daha faydalıdır. (GitHub)

Basit bir Linux auditd kural seti, bir çalışanı araştırırken veya geçici olarak güçlendirirken size yardımcı olabilir:

# /srv/font-build/out öğesini onayladığınız çıktı köküyle değiştirin
auditctl -w /srv/font-build/out -p wa -k fontbuild_out
auditctl -a always,exit -F arch=b64 -S openat,creat,rename,unlink,unlinkat \\
  -F exe=/usr/bin/python3 -k py_file_ops

Uygulama tarafında, her bir kaynağın günlüğünü .designspace dosyasını, çözümlenmiş çıktı dizinini, normalleştirmeden sonraki son eser adlarını ve kullanılan tam kütüphane sürümünü içerir. İyi bir olay müdahalesi, hangi çalışanın kandırılmış olabileceğini tahmin etmekle değil, bir derleme zincirini yeniden yapılandırmakla başlar. Bu, ilginç sorunun genellikle "hangi internete bakan uç nokta patladı?" yerine "dosyayı hangi güvenilir otomasyon işledi?" olduğu bu gibi hatalar için iki kat daha doğrudur (GitHub)

Önce yama yapın, ama doğru yama yapın

Temiz yukarı akış cevabı fonttools 4.60.2 veya daha sonra. Bu, danışmanlık, NVD ve GitLab tarafından adlandırılan sabit sürümdür. Aşağıdakileri alabilen bir daldaysanız 4.61.0 veya daha sonra uyumluluk sorunu olmadan, güvenlik değişikliğini de içerir. Önemli olan nokta, genel bir pip install -U ve filonun tamamlandığını varsayalım. Designspace girdisini işleyen her yerde çalışan tam sürümü doğrulamanız gerekir. (GitHub)

Doğrudan bir Python ortamı düzeltmesi basittir:

python -m pip install --upgrade "fonttools>=4.60.2"
python - <<'PY'
import importlib.metadata as m
print(m.version("fonttools"))
PY

İşletim sistemi tarafından paketlenmiş ortamların ayrı olarak ele alınması gerekir. Ubuntu, USN-7917-1'de etkilenen sürümler için sabit paket sürümleri yayınlamıştır. Debian'ın izleyicisi pakete göre karışık bir durum göstermektedir. IBM bültenlerinin açıkça ortaya koyduğu gibi, satıcı cihazları ve ticari yazılım yığınları, paket yöneticisi eylemlerinden ziyade ürüne özgü güncellemelere ihtiyaç duyabilir. İşte tam da bu nedenle bağımlılık düzeltme işlemleri provenans farkındalığına sahip olmalıdır. PyPI, apt, konteynerler ve ürün paketleri farklı hızlarda hareket eder. (Ubuntu)

Eğer bugün yama yapamıyorsanız

Bazı ekipler satıcı uyumluluğu, donmuş görüntüler, değişiklik pencereleri veya ürün destek sınırları nedeniyle sıkışıp kalacaktır. Eğer durumunuz buysa, hala faydalı kontrollere sahipsiniz. Yazı tipi işleme iş yüklerini mümkün olan en düşük dosya sistemi izinleriyle çalıştırın. Özel bir çıktı dizini oluşturun. Yazılabilir uygulama veya paket yollarını çalışanla paylaşmaktan kaçının. Güvenilmeyenleri reddedin veya karantinaya alın .designspace Giriş. Derleme çalışma alanını dağıtım eserlerinden ayırın. Yukarı akış düzeltmesi, güvenlik nedenleriyle yol bileşenlerini çıkarır; geçici hafifletmeleriniz aynı sınırı operasyonel olarak zorlamalıdır. (GitHub)

Konteyner izolasyonu burada özellikle etkilidir çünkü istismar yolu dosya yazmanın nereye ulaşabileceğine bağlıdır. Çalışanın yazılabilir görünümü dar ve tek kullanımlıksa, ilkel değerinin çoğunu kaybeder. İyi bir geçici duruş, salt okunur bir kök dosya sistemi artı açıkça bağlanmış yazılabilir bir karalama dizinidir, bu bağda hiçbir gizli bilgi, dağıtım bildirimi ve kod yolu yoktur. Başka bir deyişle, "rastgele dosya yazma", "çıkmaz bir çizik birimine işe yaramaz bir dosya yazma" anlamına gelir. (Ubuntu)

varLib için güvenli bir sarmalayıcı modeli

Ekipler ihtiyaç duyduğunda varLiben güvenli model, rastgele girdi üzerinde doğrudan çağırmak yerine açık sınır kontrolleri ile sarmaktır. Sarmalayıcı, yüklü sürümü doğrulamalı, gelen girdiyi doğrulamalı .designspacekısıtlı bir çalışma dizini içinde çalıştırın ve normalleştirmeden sonra oluşturulan her çıktı adını kaydedin. Bu, riskli bir alt düzey çağrıyı denetlenebilir bir işleme dönüştürür. Resmi düzeltme size hangi değişmezin önemli olduğunu söyler: son çıktı adlandırması saldırgan kontrollü girdiden dizin amacı taşımamalıdır. (GitHub)

Bir sarmalayıcı iskeleti şu şekilde görünebilir:

from pathlib import Path
import importlib.metadata as m
import alt süreç
import tempfile
import shutil

MIN_SAFE = (4, 60, 2)

def parse_version(v: str):
    return tuple(int(x) for x in v.split(".")[:3])

def ensure_safe_fonttools():
    version = m.version("fonttools")
    if parse_version(version) < MIN_SAFE:
        raise RuntimeError(f "Unsafe fonttools version: {version}")

def build_varfont(designspace: str, outdir: str):
    ensure_safe_fonttools()
    findings = validate_designspace(designspace)
    if findings:
        raise RuntimeError("Rejected designspace:\\n" + "\\n".join(findings))

    work = tempfile.mkdtemp(prefix="varlib-")
    try:
        safe_out = Path(outdir).resolve()
        safe_out.mkdir(parents=True, exist_ok=True)
        subprocess.run(
            ["python3", "-m", "fontTools.varLib", designspace, "--output-dir", str(safe_out)],
            cwd=work,
            check=True,
        )
    son olarak:
        shutil.rmtree(work, ignore_errors=True)

Bu, derleme zincirinizdeki her riski sihirli bir şekilde ortadan kaldırmaz, ancak doğru alışkanlıkları zorunlu kılar. Sürümü doğrulayın. Girdiyi doğrulayın. Çalışma dizinini daraltın. Çıktıyı köklü tutun. Aksi kanıtlanmadıkça tasarım eserlerini güvenilmez olarak değerlendirin. CVE-2025-66034, ekipleri tam olarak bu adımları atladıkları için cezalandıran bir hata türüdür. (GitHub)

Aynı dersi daha yüksek sesle veren ilgili CVE'ler

En ilgili kardeş CVE-2023-45139, başka bir fontTools kusur. NVD ve GitHub'ın danışmanlığı, saldırganların bir SVG tablosuyla aday bir yazı tipini ayrıştırırken rastgele varlıkları çözümlemesine izin veren, yerel dosya eklemeye veya sunucu tarafı web isteklerine olanak tanıyan alt küme modülündeki bir XXE sorunu olarak tanımlamaktadır. Bu sorun şu şekilde düzeltilmiştir 4.43.0. Burada önemli olan böceklerin aynı olması değildir. Her iki olay da gösteriyor ki fontTools dosya ve ayrıştırıcı güven sınırlarının ötesinde çalışan birçok ekip, bir CVE sorunu zorlayana kadar güvenlik açısından kritik olarak sınıflandırılmayacaktı. (NVD)

İlgili daha geniş bir model ise CVE-2025-4517NVD'nin, güvenilmeyen tar arşivleri belirli tar arşivleri ile ayıklandığında ayıklama dizininin dışına keyfi dosya sistemi yazmalarını tanımladığı tarfile Python 3.12+'da filtre ayarları. Bu farklı bir bileşen ve farklı bir formattır, ancak güvenlik dersi tanıdıktır: taşıma verisi gibi görünen bir format, yol semantiğini otomatik bir iş akışına kaçırır ve aniden kullanışlı bir API, bir dosya sistemi sınırı sorunu haline gelir. (NVD)

Aynı fikir şu kitapta da karşımıza çıkıyor CVE-2026-32060NVD'nin OpenClaw'daki bir yol geçişi açığını tanımladığı apply_patch Sandbox sınırlaması olmadığında yapılandırılmış çalışma alanı dizini dışında dosya yazılmasına veya silinmesine izin vermek. Farklı ekosistem, aynı mühendislik gerçeği: eğer bir otomasyon yüzeyi dosya adlarını veya yolları etkileyebiliyorsa, o zaman sadece özellik yüzeyinizin bir parçası değil, saldırı yüzeyinizin bir parçasıdır. (NVD)

Bunları birbirine bağlayan şey bir satıcı, dil ya da ürün kategorisi değildir. "Girdi verileri" ile "dosya sistemi hakkındaki talimatlar" arasındaki sınırın aşınmasıdır. Bu erozyon güvenilir bir otomatik sistem içinde gerçekleştiğinde, doğru önem derecesi sorusu "İstismar ne kadar süslü?" değildir. "Yapılandırılmış bir dosyaya yanlışlıkla hangi yetkiyi verdik?" sorusudur. CVE-2025-66034 için de doğru lens bu. (NVD)

Kırmızı ekip ve hata ödül avcıları nelere dikkat etmeli?

Saldırgan düşünen okuyucular için CVE-2025-66034'ün ilginç yanı sadece ilkel olması değil aynı zamanda dağıtım avıdır. En iyi hedefler genel geliştirici dizüstü bilgisayarları değildir. Bunlar, üçüncü taraf tasarım veya varlık dosyalarını otomatik olarak işleyen ve ardından çıktıları yığının geri kalanının güvendiği yerlere taşıyan sistemlerdir. Bu, yönetilen bir font hizmeti, tasarım varlıkları için bir CI işlem hattı, dahili bir marka oluşturucu, bir içerik platformu veya aşağıdakileri içeren bir makine öğrenimi/raporlama işlem hattı olabilir fontTools dolaylı olarak. Güvenlik açığının kendisi yukarı yönde belgelenmiştir; asıl iş bunun etrafındaki güven zincirini tanımlamaktır. (GitHub)

Bunu hata ödülü zihniyetiyle okuyan savunucular için, bu aynı zamanda önceliklendirmenin doğru yoludur. Hangi hizmetlerin kullanıcı kontrollü tasarımı veya yazı tipiyle ilgili girdileri dönüştürdüğünü sorun. Hangi depoların yüklenicilerden, müşterilerden veya harici işbirlikçilerden gelen tasarım varlıklarına izin verdiğini sorun. Hangi arka plan çalışanlarının "sadece dosya ürettikleri" için geniş yazma izinlerine sahip olduğunu sorun. Bu tür sistemler, bu tür bir CVE'nin bir kütüphane hijyeni sorunu olmaktan çıkıp bir çevre sorunu haline geldiği sistemlerdir. (fontTools Belgeleri)

Zaten sürekli doğrulama yapan ekipler için Penligent gibi bir platformun doğal yeri, sihirli bir "AI CVE'leri düzeltir" iddiası değil, CVE-2025-66034'ün sizi sormaya zorladığı soruları operasyonel hale getirmenin bir yoludur. Penligent kendisini yapay zeka destekli bir sızma testi platformu olarak sunuyor ve buradaki daha ilgili operasyonel kullanım kontrollü doğrulamadır: bir hedef ortamın güvenilmeyen eserleri işleyip işlemediğini belirlemek, oluşturulan dosyaların nereye ulaşabileceğini izlemek ve bir güven sınırı varsayımının pratikte gerçekten geçerli olup olmadığını doğrulamak. (Penligent)

Bu önemlidir çünkü bu CVE ortama duyarlıdır. Statik SBOM eşleştirmesi size güvenlik açığı olan sürümün mevcut olduğunu söyleyecektir. Size şu olup olmadığını söylemeyecektir .designspace girdiye erişilebilir olup olmadığı, bir çalışanın hassas yollara yazılabilir erişimi olup olmadığı, çıktıların çalıştırılabilir olup olmadığı veya telafi edici kontrollerinizin gerçekten patlama yarıçapını içerip içermediği. Doğrulama odaklı bir iş akışı bu soruları tek başına bir bağımlılık listesinden çok daha iyi yanıtlayabilir. İşte bu noktada yapay zeka destekli bir test platformu, yaptığı işi fazla abartmadan faydalı olabilir. (NVD)

Bu hafta güçlü bir yanıt nasıl görünüyor?

CVE-2025-66034'e karşı kısa vadeli güçlü bir müdahale karmaşık değildir, ancak bilinçli olması gerekir. Her yeri tanımlayın fontTools kurulmuştur. Her yeri tanımlayın varLib kullanılır. Yama PyPI kopyaları 4.60.2 veya daha sonra. İlgili yerlerde dağıtım ve ürün güncellemelerini uygulayın. Güvenilmeyenleri reddet .designspace filo düzeltilene kadar dosyalar. Çıktı dizinlerini kısıtlayın. Şüpheli yazmalar veya beklenmedik eserler için son font işleme işlerini denetleyin. Girdi dosyalarını çıktı yollarına bağlayan günlükleri saklayın. Bu, konuyu belirsiz bir "belki orta, belki kritik" meseleden somut, yönetilen bir mühendislik görevine dönüştürmek için yeterlidir. (GitHub)

Zayıf bir yanıtı tanımlamak da aynı derecede kolaydır. Doğrudan bir bağımlılığı güncellemek, dağıtım paketlerini göz ardı etmek, çalışanları aşırı yetkili bırakmak, tasarım dosyalarının iyi huylu olduğunu varsaymak ve NVD-GitHub CVSS bölünmesini eylemi ertelemek için bir neden olarak ele almak gibi görünüyor. Modern otomasyon hataları bu şekilde olgun kuruluşların elinden kaçmaya devam ediyor. Düzeltme zor olduğu için değil, başarısız olana kadar sınır kültürel olarak görünmez olduğu için. (NVD)

Nihai değerlendirme

CVE-2025-66034, yazı tiplerini içerdiği için ilginç değildir. Modern sistemlerde yinelenen bir güvenlik gerçeğini yakaladığı için ilginçtir: yapılandırılmış dosyalar etrafında ne kadar çok otomasyon oluşturursanız, bu dosyalar o kadar çok pasif içerik olmaktan çıkar ve kontrol yüzeyleri haline gelmeye başlar. İçinde fontTools.varLibiçinde bir dosya adı .designspace belgesine çok fazla güvenildi. Bu güven hatası, rutin bir derleme akışını keyfi bir dosya yazma ilkeline ve doğru ortamda RCE'ye dönüştürdü. (GitHub)

İyi haber ise bunun tüm yıl boyunca göreceğiniz en net düzeltmelerden biri olması. Savunmasız aralık herkese açık. Yama herkese açık. Sürüm notları herkese açık. Dağıtım bildirimleri herkese açık. Aşağı akış kurumsal bültenleri herkese açık. Asıl zorluk hatanın ne olduğunu anlamak değildir. Kendi boru hatlarınızın tasarım ve artifakt girdilerine hala "zararsız veri" muamelesi yaparken, onlara dosya sistemi üzerinde çok fazla yetki verdiği konusunda dürüst olmaktır. CVE-2025-66034'ün gerçek dersi budur ve tek bir paketten daha büyüktür. (GitHub)

Yetkili referanslar ve ilgili okumalar

• CVE-2025-66034 için NVD girişi. (NVD)
• Yukarı akış GitHub güvenlik danışmanlığı, GHSA-768j-98cg-p3fv. (GitHub)
• Yukarı akış yama taahhüdü basename Düzelt. (GitHub)
• fontTools için sürüm notları 4.61.0 ve backport 4.60.2. (GitHub)
• Ubuntu USN-7917-1, paket düzeltme ayrıntıları. (Ubuntu)
• CVE-2025-66034 ve paket durumu için Debian güvenlik izleyicisi. (security-tracker.debian.org)
• Düzeltilmiş sürüm ve etki özeti için GitLab danışma veritabanı girişi. (GitLab Danışma Veritabanı)
• IBM Maximo Application Suite Görsel Denetim bülteni. (IBM)
• IBM Watson Konuşma Hizmetleri Kartuş bülteni. (IBM)
• CVE-2023-45139, fontTools Alt küme modülünde XXE. (NVD)
• CVE-2025-4517, Python tarfile çıkarma dizini dışında keyfi dosya sistemi yazma. (NVD)
• CVE-2026-32060, OpenClaw apply_patch çalışma alanı sınırları dışında yol geçişi. (NVD)
• CVE-2025-66034, fontTools varLib Bir Designspace Dosyasını Yazma İlkeline Dönüştürdüğünde. (Penligent)
• CVE-2025-66034, Bir Yazı Tipi Oluşturma Aracı Neden Gerçek Bir Kod Yürütme Riskine Dönüştü?. (Penligent)
• Sızma Testi Nedir? Doğrulanmış Risk Mühendisliği. (Penligent)
• CVE-2025-4517, Gerçek Otomasyonda Güven Sınırlarını Aşan Python Katran Çıkarma Hatası. (Penligent)
• OpenClaw Security, Kontrolü Kaybetmeden Bir Yapay Zeka Ajanı Çalıştırmak İçin Ne Gerekir?. (Penligent)