CVE-2025-66034 - Lorsque fontTools varLib transforme un fichier Designspace en une primitive d'écriture

Les équipes de sécurité savent déjà qu'il faut se méfier des bibliothèques d'images, des extracteurs d'archives, des moteurs de modèles, des moteurs de rendu PDF et des analyseurs de documents bureautiques. Beaucoup moins d'équipes placent les outils de création de polices de caractères dans le même panier de risque. CVE-2025-66034 leur rappelle qu'elles devraient le faire. Le composant vulnérable est fontTools.varLibqui fait partie du langage Python largement utilisé fonttools et l'entrée vulnérable est un .designspace que de nombreux ingénieurs ne considéreraient pas instinctivement comme hostiles. Le résultat n'est pas un vague bogue d'analyse. Il s'agit d'une primitive d'écriture du système de fichiers avec une influence de l'attaquant à la fois sur le chemin et le contenu, et dans un mauvais déploiement, c'est exactement le genre de primitive qui cesse d'être "juste un problème d'outil local" et commence à devenir un incident. (NVD)

Les documents publics sont exceptionnellement clairs sur l'essentiel. La NVD affirme que les versions de 4.33.0 jusqu'à, mais non compris 4.60.2 sont affectés, et que le chemin d'accès vulnérable est le fonttools varLib ou tout chemin de code qui invoque fontTools.varLib.main(). L'avis de GitHub va plus loin et dit que le problème combine la gestion des noms de fichiers non nettoyés avec l'injection de contenu, permettant des écritures arbitraires dans les emplacements du système de fichiers via la traversée de chemin et l'injection de contenu de sortie via des champs contrôlés par XML. C'est le cœur du bogue, et tout le reste de cet article en découle. (NVD)

Il y a une autre raison pour laquelle ce CVE mérite un meilleur article que le résumé habituel "mettez à jour et passez à autre chose". L'image publique de la gravité est divisée. GitHub, l'ANC pour mémoire, attribue un score moyen de 6,3 avec un vecteur local, une complexité élevée et une interaction utilisateur nécessaire. La NVD enrichit plus tard le même CVE à 9.8 Critique avec un vecteur réseau et aucune interaction avec l'utilisateur. Il ne s'agit pas là de futilités. C'est la véritable histoire. Si vous comprenez pourquoi ces deux scores peuvent coexister, vous comprenez comment les vulnérabilités de la chaîne d'approvisionnement des logiciels modernes se comportent réellement en production. (NVD)

Essayez AI Hacker Tool gratuitement >>

Ce qu'est réellement CVE-2025-66034

Au niveau factuel, CVE-2025-66034 affecte fontTools.varLibqui fait partie de la fonttools Paquet Python utilisé pour manipuler les polices et construire des polices variables à partir des définitions de l'espace de conception. La documentation officielle décrit varLib comme le composant qui construit des polices variables à partir d'un fichier designspace et de ses masters. L'interface vulnérable n'est pas une aide interne obscure. Il s'agit de l'interface main() utilisé par le flux de la ligne de commande et par les programmes qui appellent directement ce point d'entrée. (PyPI)

C'est important parce que .designspace ne sont pas des blocs aléatoires. Dans le flux de travail des polices, il s'agit de documents XML structurés qui décrivent les axes, les maîtres, les instances et les sorties de polices variables. La documentation de l'espace de conception de fontTools explique que le fichier <variable-font> peut inclure un élément nom de fichier indiquant aux outils où stocker la police construite sur le disque. Après la correction, la documentation indique maintenant explicitement que cette valeur doit être un simple nom de base ou une tige, et non un chemin absolu ou relatif, et que les outils de construction ignoreront les séparateurs de répertoires pour des raisons de sécurité. La raison pour laquelle la documentation dit cela maintenant est simple : avant la correction, le chemin du code ne l'appliquait pas de manière cohérente. (fontTools Documentation)

Le meilleur modèle mental n'est donc pas celui d'un "bug d'analyse de police". Il s'agit d'une "entrée structurée contrôlée par l'attaquant et influencée par un outil de construction dorsal qui a écrit un fichier de sortie". Une fois que l'on pense en ces termes, le bogue cesse d'avoir l'air d'une niche. Il commence à ressembler à la même classe de défaillance des limites de confiance que les défenseurs comprennent déjà dans les bogues d'extraction de tar, les décompacteurs d'archives, les moteurs de rendu markdown, les flux de travail PDF et les générateurs d'artefacts CI. L'extension du fichier change. Le problème de contrôle ne change pas. (GitHub)

Pourquoi il s'agit d'un bogue d'écriture de fichier avant d'être un bogue RCE

Une grande partie de la couverture publique comprime CVE-2025-66034 en "fontTools RCE". Ce titre est compréhensible parce qu'il est court et attire l'attention, et vous voyez ce cadrage dans les pages publiques visibles. Mais la meilleure description technique commence un peu plus tôt : il s'agit d'un écriture arbitraire dans un fichier qui peut devenir un RCE lorsque l'environnement transforme cette écriture en exécution. Cette distinction n'est pas une question de sémantique. C'est la façon dont vous décidez si votre environnement est légèrement exposé, sérieusement exposé ou pas du tout matériellement exposé. (SentinelOne)

Le résumé de l'avis de GitHub est explicite. Il indique que la vulnérabilité existe en raison d'une gestion non aseptisée des noms de fichiers combinée à une injection de contenu. Les attaquants peuvent écrire des fichiers à des emplacements arbitraires du système de fichiers via des séquences de traversée de chemin et injecter du code malveillant dans les fichiers de sortie via l'injection XML en nom de l'étiquette éléments. L'avis explique même la condition d'escalade en langage clair : lorsque ces fichiers sont placés dans des emplacements accessibles par le web et exécutés, il en résulte une exécution de code à distance. En d'autres termes, la primitive est "écrire ce que l'on veut". Le résultat dépend de l'emplacement du "où" et de la manière dont l'environnement cible traite le contenu écrit. (GitHub)

C'est également la raison pour laquelle le disque semble un peu bizarre si l'on essaie de le faire figurer sur une seule étiquette de faiblesse. NVD porte CWE-91MITRE définit le CWE comme une neutralisation incorrecte des éléments spéciaux utilisés dans le XML, ce qui permet aux attaquants de modifier la syntaxe, le contenu ou les commandes du XML avant qu'il ne soit traité par un système final. C'est en partie ce qui se passe ici. Mais d'un point de vue opérationnel, les défenseurs devraient réfléchir à un problème complexe : Entrée contrôlée par XML, traversée de chemin, écriture arbitraire de fichier, et potentiel d'exécution spécifique au déploiement. Le correctif lui-même rend cela évident. La mise à jour de la documentation le rend encore plus évident. (NVD)

CVE-2025-66034

Obtenir un PoC en un clic >>

La limite de confiance exacte qui a échoué

Le correctif amont est l'un de ces rares correctifs qui racontent toute l'histoire en quelques lignes. Avant le correctif, le chemin de code vulnérable prenait effectivement la forme suivante vf.filename lorsqu'il est présent et l'associe à un répertoire de sortie. Après la correction, si vf.filename est présent, le code le réduit d'abord à os.path.basename(vf.filename) et ne le joint qu'ensuite au répertoire de sortie. Il ne s'agit pas d'un nettoyage générique. C'est une réponse directe à la traversée de chemin. Le message de validation le dit clairement : "n'utiliser que le nom de base" pour éviter les attaques par traversée de chemin. (GitHub)

Une version simplifiée de l'échec de la confiance se présente comme suit :

# Logique simplifiée du préfixe
si vf.filename n'est pas None :
    filename = vf.filename
else :
    nom_de_fichier = nom_de_vf + ".{ext}"

chemin_de_sortie = os.path.join(dossier_de_sortie, nom_de_fichier)
vf.save(output_path)

Le renforcement de la sécurité se présente comme suit :

# Logique simplifiée de post-fixation
si vf.filename n'est pas None :
    filename = os.path.basename(vf.filename)
else :
    filename = vf.name + ".{ext}"

output_path = os.path.join(output_dir, filename)
vf.save(output_path)

Ce changement est directement reflété dans le commit amont, où le code supprime désormais les composants de répertoire de la base de données vf.filename et la documentation indique que seul un nom de base doit être respecté. (GitHub)

Ce qui a échoué, ce n'est pas os.path.join() même. L'hypothèse erronée était qu'un fichier d'entrée structuré décrivant les métadonnées de sortie des polices de caractères pouvait être considéré comme transportant en toute sécurité les valeurs relatives au chemin. Cette hypothèse est courante dans les outils de construction. Les ingénieurs traitent les fichiers de type configuration comme s'ils étaient rédigés par des outils conviviaux et révisés par des humains bienveillants. Les attaquants les considèrent comme une surface d'entrée. CVE-2025-66034 se situe entre ces deux mentalités. (GitHub)

Comment un fichier d'espace de conception devient une primitive d'écriture

La documentation officielle de designspace indique que le <variable-font> de l'élément nom de fichier indique aux outils de construction où stocker la police construite sur le disque, et que le nom de fichier peut inclure une extension telle que .ttf tandis que l'outil de construction peut remplacer cette extension si nécessaire. Dans un flux de travail bénin, c'est exactement ce que vous voulez. Dans un flux de travail hostile, cela signifie qu'un fichier d'entrée malveillant influence le placement de la sortie. À partir du moment où les séparateurs de répertoires sont honorés au lieu d'être supprimés, l'attaquant ne se contente plus de nommer une police. L'attaquant dirige une cible d'écriture. (fontTools Documentation)

Le texte du PoC de GitHub rend concret le chemin de contrôle sans qu'il soit nécessaire de reproduire l'exploit complet ici. L'avis public indique que les attaquants peuvent spécifier une séquence de parcours dans la variable-font nom de fichieret peut également injecter du code malveillant dans le contenu de la sortie par l'intermédiaire de la fonction nom de l'étiquette des éléments. L'exemple de l'avis utilise ce deuxième canal pour montrer que le contenu contrôlé est écrit dans un fichier de sortie. Cela suffit à expliquer le modèle d'escalade sans transformer cet article en un tutoriel sur l'exploitation. (GitHub)

Ce qui est important pour la défense, c'est qu'il ne s'agit pas simplement d'une "entrée malformée qui fait planter l'analyseur syntaxique". Il s'agissait d'une "entrée malveillante qui modifie la sémantique de la sortie". Il s'agit de classes de risque radicalement différentes. Les pannes d'analyseur syntaxique sont souvent des problèmes de disponibilité. La manipulation de la sémantique de sortie est ce qui permet aux attaquants d'influencer le comportement futur du système. Si le fichier écrit atterrit sous une racine web, un répertoire de plugin, un répertoire d'artefact de construction, un chemin de recherche d'interprète ou un paquet de déploiement ultérieur, alors l'écriture arbitraire cesse d'être un événement de corruption isolé et commence à devenir un tremplin vers l'exécution ou la persistance. Cette conséquence n'est pas spéculative ; c'est la condition exacte décrite par GitHub lorsqu'il explique comment l'écriture arbitraire peut se transformer en RCE. (GitHub)

CVE-2025-66034

Essayez AI Hacker Tool >>

Pourquoi le désaccord sur le score public est réel

Le score divisé est la partie de ce CVE que la plupart des rédactions superficielles ne comprennent pas. Ils reprennent soit le 6.3 Medium de GitHub, soit le 9.8 Critical de NVD et agissent comme si l'autre score était manifestement erroné. La vérité est plus utile que cela. GitHub a évalué la vulnérabilité comme suit AV:L/AC:H/PR:N/UI:R/S:C/C:N/I:H/A:Lqui suppose un modèle dans lequel une victime traite un fichier malveillant localement, une interaction avec l'utilisateur existe et l'effet immédiat est principalement une atteinte à l'intégrité avec un certain effet sur la disponibilité. Ce modèle correspond à l'utilisation d'outils locaux, aux flux de travail de construction de bureau ou à d'autres contextes dans lesquels un humain ou un travail contrôlé alimente explicitement un fichier en varLib. (NVD)

Le score enrichi de NVD est de AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hce qui est un monde complètement différent. Les notes du CVMAP montrent comment la NVD a ajusté ses hypothèses : elle a traité le vecteur comme un réseau, réduit la complexité, supprimé l'interaction avec l'utilisateur et augmenté l'impact sur la confidentialité et la disponibilité. Les notes de la NVD ne disent pas que chaque installation est directement accessible depuis l'internet par défaut. Elles montrent que l'analyste de la NVD a estimé que le dossier public était cohérent avec un scénario de transmission par réseau et de traitement automatique, sans qu'aucun facteur limitatif significatif ne soit mentionné. (NVD)

Les deux modèles sont défendables en fonction du déploiement. Si vous n'utilisez fontTools que sur le poste de travail d'un concepteur local qui compile des ressources internes fiables, le score de GitHub peut être plus proche de la réalité pour vous. Si vous exécutez un service ou un travail automatisé qui ingère le contenu de l'espace de conception externe via HTTP, à partir de demandes d'extraction, de remises de fournisseurs ou de téléchargements de clients, le modèle NVD devient beaucoup plus facile à justifier. Dans cet environnement, l'"invocation d'un outil local" n'est plus la limite opérationnelle. L'entrée malveillante est arrivée par le réseau, le traitement a été automatique et l'écriture du fichier qui en résulte peut affecter les données ou le code qui comptent. C'est pourquoi un seul CVE peut honnêtement paraître moyen dans une organisation et critique dans une autre. (NVD)

La situation des fournisseurs en aval renforce ce point. L'avis public d'Ubuntu reprend le raisonnement de moindre gravité et décrit le problème comme un cas où un utilisateur ou un système automatisé est piégé pour traiter un message d'erreur spécialement conçu. .designspace ce qui conduit à l'écriture arbitraire de fichiers en dehors du répertoire cible et potentiellement à un RCE. IBM, dans un bulletin de produit qui inclut CVE-2025-66034 parmi les vulnérabilités regroupées, adopte le score NVD 9.8. Ces documents ne se contredisent pas tant qu'ils ne révèlent pas des hypothèses de produit différentes. (Ubuntu)

Une façon pratique de lire la partition

La manière la plus sûre d'utiliser le désaccord sur le score est la suivante : considérez le 6.3 de GitHub comme le base minimale crédible pour tout environnement vulnérable, et considérer la version 9.8 de la NVD comme la version de référence. limite supérieure des déploiements automatisés atteignables lorsque l'entrée hostile traverse une frontière de réseau et que le chemin de sortie peut influencer des fichiers significatifs. Si vous ne savez pas de quel côté vous vous situez, cette incertitude est en soi une raison d'étudier la joignabilité et le risque lié au chemin de sortie avant de dévaloriser mentalement la question. (NVD)

Où cela devient un véritable incident

Le modèle à haut risque évident est un service dorsal qui accepte les projets de l'espace de conception fournis par l'utilisateur et qui exécute fonttools varLib ou un code équivalent dans le cadre d'un flux de travail API. Dans cette architecture, le vecteur de diffusion est effectivement distant, même si la fonction vulnérable elle-même est un appel Python local. Le service reçoit le fichier designspace malveillant sur le réseau, l'analyse automatiquement et écrit les sorties sur le disque sans examen humain significatif. Si le répertoire de sortie est diffusé sur le web, synchronisé dans un pipeline d'actifs, analysé par un autre service ou consommé ultérieurement, le passage de l'écriture arbitraire d'un fichier au RCE ou à la persistance devient beaucoup plus réaliste. C'est le scénario pour lequel la NVD semble être évaluée. (fontTools Documentation)

Le deuxième modèle majeur est l'automatisation de l'intégration et de la construction. Les équipes de sécurité sous-estiment souvent l'exposition au CI parce que le pipeline est "interne". Mais les pipelines ingèrent régulièrement du contenu extérieur : demandes d'extraction, pièces jointes de problèmes, fichiers de fournisseurs, transferts de conception, dépôts miroirs et actifs générés. Si une étape de construction de polices traite un .designspace l'écriture résultante peut cibler les fichiers de l'espace de travail, les dépendances mises en cache, les répertoires d'artefacts ou les chemins adjacents utilisés dans les étapes ultérieures. Dans une chaîne moderne de construction, d'empaquetage, de déploiement et de publication, l'empoisonnement d'un artefact peut être plus significatif d'un point de vue opérationnel que l'obtention d'un shell sur l'agent de construction lui-même. L'avis n'énumère pas tous les cas d'abus de CI, mais la primitive d'écriture qu'il décrit en fait une déduction technique directe. (GitHub)

Le troisième modèle est l'exposition transitive des produits. Le bulletin d'IBM est utile car il prouve que le paquet vulnérable était présent suffisamment profondément dans une pile de produits livrés pour que les clients aient besoin d'en être informés et d'y remédier. Les systèmes de suivi des paquets Debian et Ubuntu racontent une histoire similaire du côté de la distribution. Il ne s'agissait pas d'un problème ponctuel isolé des personnes exécutant manuellement l'outil de police à partir d'un terminal. Il s'est propagé à travers les écosystèmes d'empaquetage et les dépendances des produits, ce qui signifie que certaines organisations peuvent être exposées sans jamais s'en rendre compte fonttools se trouve à l'intérieur de leur logiciel. (IBM)

Le tableau ci-dessous est le modèle de risque le plus pratique pour la plupart des équipes. Il consolide l'exploit primitif de l'avis GitHub avec le contexte de la distribution et du produit Ubuntu, Debian et IBM. (GitHub)

Modèle de déploiement	Exposition probable	Pourquoi c'est important
Poste de travail local du concepteur, entrées de confiance uniquement	Plus bas	Le déclenchement nécessite généralement la manipulation d'un `.designspace` dans un flux de travail par ailleurs contrôlé
Traitement des actifs de conception externes dans le cadre d'une tâche CI	Moyenne à élevée	L'écriture arbitraire de fichiers peut empoisonner les fichiers de l'espace de travail, les artefacts ou les résultats d'un déploiement ultérieur.
API dorsale ou service de génération de polices SaaS	Haut	Les designspace malveillants arrivent par le réseau et peuvent être traités automatiquement
Chemin de sortie sous la racine du site web ou le chemin d'accès à l'exécutable	Critique dans la pratique	L'écriture arbitraire d'un fichier peut se transformer en exécution de code lorsque le fichier écrit est ensuite interprété ou exécuté.
Dépendance transitive à l'intérieur d'un produit plus large	Variable mais significatif	L'exposition dépend de la possibilité d'atteindre le chemin vulnérable, et pas seulement de la présence du paquet.

CVE-2025-66034

Essayez AI Hacker Tool gratuitement >>

Ce que la correction nous apprend sur la classe de vulnérabilité

L'une des raisons pour lesquelles ce bogue mérite d'être étudié est que la correction est d'une simplicité presque embarrassante. La principale correction du code consiste à utiliser basename(vf.filename) et ignorent les séparateurs de répertoires. La documentation indique maintenant que l'option nom de fichier est destiné à être un simple nom de base ou une tige seulement, et les notes de publication lient explicitement ce changement au CVE. Cette combinaison vous indique quelque chose de plus large que "patch appliqué". Elle indique que les responsables du projet considèrent désormais le champ du nom de fichier de l'espace de conception comme un nom de la feuille ne faisant pas autoritéet non une instruction de cheminement. Il s'agit d'une décision de confiance, et non d'une simple correction de bogue. (GitHub)

Les ingénieurs en sécurité devraient tirer des leçons de ce choix de conception. Si vous traitez des entrées structurées qui décrivent des sorties, ne laissez pas l'entrée spécifier la structure du répertoire à moins que vous n'ayez une raison impérieuse et une validation solide. Utilisez les noms de fichiers générés, associez les entrées à des identifiants opaques ou normalisez les noms de feuilles avant toute opération de jointure. Si vous devez préserver la sémantique du chemin, forcez le résultat à revenir sous une racine autorisée et échouez lorsque la canonisation l'échappe. CVE-2025-66034 est un exemple typique de la raison pour laquelle "ce ne sont que des métadonnées" n'est pas un contrôle de sécurité. (GitHub)

Comment savoir si votre pile est réellement exposée

Le moyen le plus rapide de mal gérer CVE-2025-66034 est de s'arrêter à la vérification de la version. Le contrôle de version est important, mais il ne répond qu'à une seule question : "Le code vulnérable pourrait-il être présent ?" Il ne répond pas à la question qui vous préoccupe réellement : "Une entrée hostile peut-elle atteindre le chemin vulnérable de manière significative ?" Les sources officielles fournissent suffisamment d'informations pour définir un test d'exposition en quatre parties. Vous devez savoir si un code vulnérable fonttools existe, qu'il s'agisse d'une version fontTools.varLib.main() est joignable, qu'il s'agisse d'un .designspace traverse ce chemin, et si le répertoire de sortie a de l'importance. (NVD)

Commencez par l'inventaire des dépendances. OSV liste la gamme de versions en amont affectées et fournit des références en aval pour Ubuntu et Debian. Le tracker de Debian montre que bullseye et bookworm sont toujours marqués comme vulnérables au moment de l'enregistrement public actuel, tandis que trixie et unstable ont des correctifs. L'avis d'Ubuntu indique des correctifs pour les versions 24.04 LTS, 25.04 et 25.10, la version 24.04 étant livrée via Ubuntu Pro ESM pour le paquet en question. PyPI indique 4.60.2 existe et a été publié le 9 décembre 2025 en tant que backport de sécurité, tandis que 4.61.0 a porté la fixation de la sécurité d'origine au 28 novembre 2025. (OSV)

Vérifiez ensuite l'accessibilité du code. La documentation officielle et l'enregistrement de la NVD indiquent tous deux que le chemin affecté est le suivant fontTools.varLib.main()Cela signifie que vous ne devez pas vous contenter de rechercher des fonttools varLib mais aussi les importations directes de Python et les wrappers autour de ce point d'entrée. Un simple balayage des sources comme celui ci-dessous est souvent suffisant pour identifier le premier ensemble de points d'accessibilité probables. Les faits qui justifient ces schémas proviennent directement de la NVD et de la documentation en amont, qui identifient le chemin vulnérable et le comportement de la CLI. (NVD)

rg -n "fontTools\.varLib\.main|fonttools varLib|varLib\.main" .
rg -n "designspace" .
rg -n "subprocess.*fonttools" .

Cette recherche ne vous indique que l'endroit où le code est référencé. L'étape suivante est l'examen des limites de confiance. Demandez si ces références peuvent traiter des fichiers de l'espace de conception qui ont été téléchargés par des utilisateurs, extraits de référentiels externes, remis par des fournisseurs de conception, joints à des tickets ou générés dans des flux de travail partiellement non fiables. Si la réponse est négative, vous devrez peut-être encore appliquer des correctifs, mais votre exploitabilité immédiate est moindre. Si la réponse est oui, le problème devient beaucoup plus urgent car l'avis de GitHub lie spécifiquement l'exploitation à des fichiers malveillants. .designspace le traitement et l'injection de contenu à partir de champs contrôlés par XML. (GitHub)

La dernière étape est l'examen du chemin de sortie. Une écriture primitive ne devient vraiment dangereuse que lorsque le fichier écrit atterrit dans un endroit significatif d'un point de vue opérationnel. Il peut s'agir d'un répertoire d'actifs servis sur le web, d'un chemin d'accès à un plugin, d'une sortie de compilation d'un paquet, d'un paquet de déploiement ultérieur ou d'un répertoire surveillé par un autre service. C'est là que de nombreuses organisations sont surprises. Elles identifient correctement un paquetage vulnérable et même une fonction accessible, puis supposent que le risque est contenu parce que le travailleur lui-même n'est "pas public". Mais si ce travailleur écrit des artefacts auxquels d'autres systèmes font confiance, le rayon d'action en aval peut être beaucoup plus large que le nœud de calcul d'origine. (GitHub)

Une meilleure liste de contrôle que "avons-nous le paquet" ?

La liste de contrôle suivante est celle que j'utiliserais dans le cadre d'un examen technique. Elle est directement dérivée du dossier public, mais elle oblige la conversation à s'éloigner de la gravité abstraite de CVE et à s'intéresser à l'accessibilité concrète. (NVD)

Question	Pourquoi c'est important
Gérons-nous un groupe vulnérable ? `fonttools` version	Pas de paquet vulnérable, pas de chemin vulnérable
Invoquons-nous `fontTools.varLib.main()` ou l'interface de programmation (CLI)	Le dossier officiel indique qu'il s'agit du chemin de code affecté
Peut ne pas être fiable `.designspace` contenu l'atteindre	En l'absence de contribution hostile, l'exposition pratique peut être limitée
Le processus a-t-il accès au système de fichiers au-delà d'un répertoire scratch ?	L'écriture arbitraire a besoin de cibles significatives pour avoir de l'importance
Les résultats sont ensuite interprétés, déployés ou servis.	C'est ici que l'écriture arbitraire se transforme en exécution ou en persistance.

CVE-2025-66034

Obtenir AI Hacker Tool >>

Chemins d'accès aux correctifs et pièges à versions

La réponse en amont est simple : passez à la version suivante 4.60.2 ou plus récente, ou à une version plus récente de la ligne principale telle que 4.61.0 ou plus. Les notes de mise à jour indiquent que 4.61.0 a introduit le correctif de sécurité et que 4.60.2 était la version de rétro-portage créée spécifiquement pour que les projets en aval utilisant encore Python 3.9 puissent recevoir le correctif sans prendre le changement de support de Python intégré à 4.61.0. PyPI confirme que 4.60.2 a été publié le 9 décembre 2025 et que des versions plus récentes existent. (GitHub)

Ce dernier point est important parce que les premières discussions publiques ont brièvement confondu les gens sur la question de savoir si les 4.60.2 a réellement existé. D'après les informations publiques actuelles, c'est le cas. Si vous épinglez directement depuis PyPI, pip install fonttools==4.60.2 est un chemin d'accès valide, et toute version corrigée ultérieure est également acceptable du point de vue de la vulnérabilité. (PyPI)

Les paquets de distribution requièrent plus de précautions. L'avis d'Ubuntu indique que le problème affecte Ubuntu 24.04 LTS, 25.04 et 25.10 pour cette CVE, avec les versions de paquetage corrigées suivantes 4.55.3-2ubuntu0.25.10.1 et 4.55.3-2ubuntu0.25.04.1La version 24.04 LTS reçoit le correctif par le biais d'Ubuntu Pro ESM Apps sous la forme suivante 4.46.0-1ubuntu0.1~esm1. Cela signifie que la comparaison des versions par rapport à l'amont uniquement peut être trompeuse. Un paquet de distro avec une version numériquement inférieure peut toujours être corrigé parce que le correctif a été rétroporté. (Ubuntu)

Debian est encore plus utile pour illustrer le même point. Le tracker Debian montre que trixie est fixée à 4.57.0-1+deb13u1 et instable fixé en 4.61.1-1tandis que bullseye et bookworm restent marqués comme vulnérables sans DSA au moment de l'entrée dans le tracker public. Encore une fois, la leçon importante n'est pas "seule la version 4.60.2 est sûre". La leçon importante est "sachez si la version exacte de votre paquet contient le correctif". Les chaînes de version en amont n'expliquent pas tout dans les distributions. (Traqueur de sécurité Debian)

Pour les équipes chargées de l'application de Python, le chemin de correction le plus propre ressemble généralement à ceci :

python -m pip install --upgrade "fonttools>=4.60.2"
python - <<'PY'
import fontTools
print(fontTools.__version__)
PY

Pour les hôtes gérés par une distribution, la solution la plus sûre est d'utiliser le processus normal de mise à jour des paquets et de vérifier l'avis de la distribution plutôt que de forcer l'installation de pip dans le système Python. Ubuntu et Debian publient tous deux suffisamment de détails au niveau des paquets pour permettre cette vérification. (Ubuntu)

La défense en profondeur est plus importante que le titre de la rustine

Le rapiéçage est nécessaire. Il n'est pas suffisant en tant que réponse générale à la conception. La bonne leçon à tirer de CVE-2025-66034 est que les processeurs de ressources de conception structurées doivent être traités comme des gestionnaires de contenu non fiables. Si votre service accepte des fichiers d'espace de conception externes, exécutez le travailleur avec les autorisations de système de fichiers les plus étroites possibles. Conservez les sorties dans un répertoire scratch dédié. Ne placez pas les sorties de compilation avec des racines web, des répertoires de plugins ou des paquets de déploiement. N'accordez pas d'accès au réseau sortant au travailleur, à moins qu'il n'en ait réellement besoin. Et si vous le pouvez, exécutez l'étape de conversion dans un conteneur isolé ou un bac à sable qui peut être détruit après un travail. Ces recommandations découlent directement de la nature de la primitive d'écriture et du fait qu'un fichier malveillant doit être traité pour déclencher le problème. (GitHub)

Un modèle minimal de renforcement des conteneurs pour cette classe de flux de travail pourrait ressembler à ceci :

apiVersion : v1
kind : Pod
metadata :
  name : font-build-worker
spec :
  conteneurs :
    - name : worker
      image : your-font-build-image
      securityContext :
        runAsNonRoot : true
        readOnlyRootFilesystem : true
        allowPrivilegeEscalation : false
      volumeMounts :
        - name : scratch
          mountPath : /work/output
  volumes :
    - name : scratch
      emptyDir : {}

Cet extrait n'est pas une solution miracle, et il n'est pas spécifique à fontTools. Il s'agit d'un rappel que lorsque vous traitez un contenu hostile, le travailleur ne doit pas avoir de larges privilèges d'écriture partout où c'est important. CVE-2025-66034 en est une démonstration flagrante. Le correctif supprime une possibilité de traversée de chemin. L'isolation limite les dégâts si un futur parseur ou un bogue d'étape de construction apparaît quelque part dans la même chaîne. (GitHub)

Détection et télémétrie réellement utiles

De nombreux conseils défensifs concernant les CVE des bibliothèques sont trop génériques pour être utiles. "Surveiller les comportements suspects n'est pas suffisant. Pour ce problème, la question de la télémétrie est plus spécifique : est-ce qu'un processus manipulant un fichier .designspace écrire en dehors de son répertoire de sortie prévu, ou écrire un contenu qui ne devrait jamais apparaître dans un artefact de police généré ? L'avis, le correctif et la documentation vous indiquent exactement où vous devez vous concentrer. (GitHub)

La première couche de détection est l'examen des données d'entrée. Il n'est pas nécessaire de reproduire le PoC public pour savoir à quoi ressemblent les valeurs suspectes. L'examen .designspace fichiers pour les motifs de traversée de chemin dans les polices de caractères variables nom de fichier les chemins absolus, les préfixes de lecteur Windows, ou toute autre sémantique de chemin qui va au-delà d'un simple nom de base ou d'une tige. La documentation corrigée indique maintenant que les séparateurs de répertoires doivent être ignorés pour des raisons de sécurité, donc toute entrée de ce type doit déjà être considérée comme suspecte dans votre pipeline. (fontTools Documentation)

Un simple examen du référentiel ou de l'artefact peut permettre de détecter de nombreux cas avant l'exécution :

rg -n ']*filename="[^"]*(\.\./|/|\N-[A-Za-z]:\N)' .
rg -n '<labelname' .

Cela ne prouve pas l'exploitation. Cela vous donne une file d'attente pour le triage. Un projet bénin peut encore contenir des métadonnées bizarres. Mais un pipeline de production qui accepte l'entrée d'un espace de conception externe ne doit pas ignorer les noms de fichiers porteurs de chemins par hasard, parce que le correctif en amont existe précisément pour cesser d'honorer cette entrée. (fontTools Documentation)

La deuxième couche de détection est la télémétrie du système de fichiers. Si vous pouvez enregistrer les écritures du travailleur, alertez sur les travaux de construction qui écrivent en dehors de leur racine de sortie désignée. Il s'agit du signal comportemental le plus directement pertinent car l'enregistrement public indique que l'action vulnérable est une écriture de fichier arbitraire en dehors du répertoire cible. Même une surveillance de base de type EDR ou audit sur les travailleurs de conversion peut être utile si elle est limitée à "le processus de construction de polices a écrit en dehors du chemin scratch". (Ubuntu)

La troisième couche de détection est l'examen de l'accessibilité au niveau de l'application. Il s'agit de rechercher dans les journaux les points d'extrémité ou les tâches qui ont accepté des .designspace les téléchargements ou les références. Si le travailleur se trouve derrière un service HTTP, il faut corréler les événements de téléchargement avec les écritures dans le système de fichiers et avec toutes les étapes d'exécution ou de déploiement qui suivent. C'est là que le modèle de gravité supérieure de la NVD devient pertinent sur le plan opérationnel : une fois que le fichier hostile arrive sur le réseau et déclenche un traitement automatisé, la distinction entre le bogue de l'outil local et le problème du service distant commence à disparaître. (NVD)

CVE-2025-66034

Essayez AI Hacker Tool gratuitement >>

Les questions relatives à la réponse aux incidents méritent d'être posées

Si vous découvrez que vous étiez vulnérable, la première question n'est pas de savoir s'il y a eu une exploitation publique massive. Les documents publics que j'ai examinés ne l'établissent pas, et cet article ne prétendra pas le contraire. La première question est plus restreinte et plus facile à traiter : n'a pas fait confiance .designspace atteignent le chemin vulnérable avant que vous n'apportiez le correctif ? Si ce n'est pas le cas, il s'agit probablement d'un événement lié à l'application de correctifs et non d'un incident. Si c'est le cas, la question suivante est de savoir si ces tâches peuvent écrire ailleurs que dans un répertoire scratch jetable. (NVD)

Demandez ensuite quels répertoires le travailleur pouvait toucher et quels systèmes consommaient ces sorties. Si la réponse est "seulement un répertoire temporaire isolé effacé après chaque travail", votre rétrospective risque d'être courte. Si la réponse est "répertoire d'artefacts empaquetés et déployés ultérieurement", "répertoire sous les actifs servis par le web" ou "chemin lu par les étapes de construction ultérieures", vous avez besoin d'un examen plus sérieux. C'est exactement la chaîne contre laquelle l'avis de GitHub met en garde lorsqu'il décrit le chemin qui mène de l'écriture arbitraire à la RCE en passant par l'exécution du contenu écrit. (GitHub)

Pour les organisations disposant d'une journalisation centralisée, une bonne requête rétrospective se présente souvent comme suit : travaux traitant le contenu de l'espace de conception, corrélés avec des écritures dans le système de fichiers en dehors de la racine prévue, suivis par des lectures de fichiers, des déploiements ou l'exécution de processus impliquant ces chemins d'accès. Le correctif et la documentation vous indiquent quel aurait dû être le modèle de chemin légitime. Tout écart historique par rapport à ce modèle mérite une attention particulière. (GitHub)

CVEs connexes qui rendent ce bogue plus important, et non moins important

CVE-2025-66034 est plus facile à évaluer si vous le regardez de manière isolée. Elle ressemble à un problème étrange dans une bibliothèque spécialisée. Mais fontTools présentait déjà une autre vulnérabilité importante liée à XML, CVE-2023-45139. NVD décrit ce problème antérieur comme un problème d'entité externe XML dans le module de sous-ensemble qui pourrait permettre aux attaquants de résoudre des entités arbitraires lors de l'analyse du contenu des polices OT-SVG, en incluant potentiellement des fichiers arbitraires du système de fichiers ou en effectuant des requêtes web sortantes. L'avis de GitHub concernant ce problème indique que les versions affectées sont les suivantes >= 4.28.2, < 4.43.0 et lui attribue une gravité élevée de 7,5. (NVD)

Il ne s'agit pas de dire que les deux CVE sont identiques. Ils ne le sont pas. Le fait est que les deux vulnérabilités se situent dans la même famille plus large : des données structurées liées aux polices et influencées par l'attaquant traversent les chemins de traitement privilégiés du backend. CVE-2023-45139 concerne XXE et la confiance dans l'analyseur. CVE-2025-66034 concerne les métadonnées de sortie et l'injection de contenu. Ensemble, ils renforcent la nécessité de traiter l'infrastructure de traitement des polices comme une partie de la surface d'attaque du contenu non fiable plutôt que comme un utilitaire de construction inoffensif. L'avis 2025 d'Ubuntu corrige même les deux problèmes dans le même contexte de sécurité plus large de fontTools, ce qui souligne la continuité. (NVD)

Il s'agit également d'une leçon plus générale de génie logiciel. Tout système qui prend des données structurées décrivant ce qu'il faut générer et où le placer est un candidat à cette catégorie d'échec. Les extracteurs d'archives, les générateurs de code, les moteurs de modélisation, les créateurs de rapports, les générateurs de sites statiques, les décompacteurs de paquets et les pipelines de polices se situent tous dans cette zone. Ils se sentent différents parce que leurs formats de fichiers et leurs communautés d'utilisateurs diffèrent. Ils ne sont pas différents du point de vue des limites de confiance. (CWE)

Le tableau ci-dessous est un outil de comparaison utile. Il ne dit pas qu'il s'agit du même bogue. Il montre le modèle de conception que les défenseurs devraient reconnaître. Les lignes factuelles sur fontTools proviennent des enregistrements officiels pour CVE-2025-66034 et CVE-2023-45139. (NVD)

CVE	Composant	Défaut de base	Primitive immédiate	Pourquoi les défenseurs doivent-ils s'en préoccuper ?
CVE-2025-66034	`fontTools.varLib`	Traitement des noms de fichiers non titrés et injection de contenu contrôlé par XML	Écriture arbitraire dans un fichier	Peut devenir un RCE lorsque la sortie écrite atterrit dans un exécutable ou un chemin d'accès de confiance.
CVE-2023-45139	`fontTools` module de sous-ensemble	Traitement des entités externes XML dans l'analyse OT-SVG	Inclusion de fichiers et demandes de sortie	Prouve que l'outil d'analyse des polices de caractères fait partie du modèle de menace des analyseurs non fiables.

Transformer un CVE en preuves validées

C'est l'endroit naturel pour parler de Penligent sans forcer. CVE-2025-66034 est exactement le genre de problème qui met en évidence le fossé entre sensibilisation à la dépendance et sensibilisation à l'exploitabilité. Un scanner de colis peut vous dire que fonttools est présent. Un examinateur humain peut vous dire que l'avis mentionne l'écriture d'un fichier arbitraire. Ce à quoi la plupart des équipes ont encore du mal à répondre rapidement, c'est à la question opérationnelle suivante : mon application accepte-t-elle réellement le type de fichier concerné, atteint-elle le chemin du code vulnérable, écrit-elle en dehors du répertoire prévu et atterrit-elle à un endroit significatif ? (GitHub)

C'est là qu'un flux de validation piloté par l'IA est véritablement utile. Le produit public de Penligent et les pages de documentation le positionnent comme une plateforme de test de pénétration alimentée par l'IA qui peut exécuter des flux de travail de test à partir d'une interface orientée vers les tâches, et son matériel publié plus large insiste à plusieurs reprises sur le passage des résultats bruts à des chemins d'attaque validés et à des preuves reproductibles. Pour un CVE comme celui-ci, l'intérêt n'est pas de crier plus fort "Critique". L'intérêt est de prouver ou d'infirmer la chaîne d'accessibilité dans votre propre environnement. (Penligent)

Bien utilisée, une telle plateforme permet de répondre à quatre questions défendables : où se trouve le composant vulnérable, si le chemin dangereux est effectivement invoqué, si une entrée non fiable peut franchir cette limite et si l'écriture qui en résulte peut toucher tout ce qui compte. C'est la bonne norme opérationnelle pour CVE-2025-66034. Le désaccord sur le score public indique déjà que l'environnement est primordial. La validation est la façon de déterminer l'environnement dans lequel vous vivez réellement. (NVD)

L'enseignement le plus important en matière d'ingénierie

CVE-2025-66034 est important parce qu'il comprime plusieurs leçons de sécurité modernes en un seul petit bogue. Tout d'abord, les outils de construction spécialisés font toujours partie de votre surface d'attaque. Deuxièmement, les fichiers de conception structurés ne sont pas intrinsèquement plus sûrs que les types de fichiers "exécutables" lorsqu'un service dorsal les interprète et écrit des sorties en leur nom. Troisièmement, les arguments CVSS sont souvent des arguments de déploiement déguisés. La différence entre GitHub 6.3 et NVD 9.8 n'est pas un bruit. Il s'agit d'un avertissement selon lequel vous devriez cesser de demander "quel est le score" et commencer à demander "de quelles hypothèses ce score dépend-il". (NVD)

Le dossier officiel vous donne un plan d'intervention assez complet. Le chemin affecté est connu. Le correctif amont est connu. Le rétro-portage de la version est connu. La documentation indique maintenant la limite de sécurité correcte. Le guide de la distribution existe. La preuve du produit en aval existe. Ce qui reste, c'est le travail que vous seul pouvez faire : cartographier l'accessibilité, isoler les travailleurs, vérifier où atterrissent les sorties, et décider s'il s'agit d'un événement de correctif ou d'un incident dans votre environnement. (GitHub)

Si vous réduisez CVE-2025-66034 à une seule phrase, faites-en celle-ci : un fichier designspace malveillant n'aurait jamais dû pouvoir dire à votre backend où écrire un fichier généré, et une fois qu'il l'a pu, tout le reste est devenu une question d'environnement. C'est pourquoi ce bogue mérite d'être compris en détail, et pourquoi les équipes qui se contentent de corriger les chaînes de version sans vérifier l'accessibilité laissent le plus dur à faire. (GitHub)

Pour en savoir plus

Partager l'article :

Articles connexes

VS Code Copilot Co-Author, When AI Attribution Becomes a Supply Chain Trust Problem

On April 16, 2026, a small VS Code pull request landed with a large trust footprint. The PR, titled “Enabling

Claude Security Needs Source Code, Black Box Proof Still Matters

Claude Security is best understood as source-aware security review. It reads codebases, traces data flows across files, validates findings, and