rauljvc8/cve-2025-68616-detecting-and-patching-an-ssrf-in-weasyprint-with-wazuhÉtude de cas pratique de gestion des vulnérabilités : comment Wazuh a signalé une véritable SSRF (CVE-2025-68616) dans WeasyPrint, et comment je l'ai reproduite et corrigée.
Lors d'un exercice personnel avec Wazuh (SIEM/XDR open source) sur une machine Kali Linux, le module Vulnerability Detection a identifié une vulnérabilité de sévérité Haute (CVSS 7.5) dans le package WeasyPrint : un contournement de protection SSRF (CVE-2025-68616). J'ai investigué la découverte, reproduit le problème avec une preuve de concept locale, appliqué la version patchée du projet, et vérifié que l'exploitation ne fonctionne plus. Ce dépôt documente le processus complet : détection, analyse, PoC et remédiation.
Wazuh est une plateforme de sécurité open source (SIEM + XDR) qui combine, entre autres, la collecte de logs, la surveillance de l'intégrité des fichiers (FIM), la détection d'anomalies et la détection de vulnérabilités pour les logiciels installés sur les hôtes surveillés, en recoupant l'inventaire des packages avec les bases de données CVE (NVD, entre autres).
Dans cet exercice, l'agent Wazuh s'exécutait sur une machine Kali GNU/Linux 2025.4, avec le manager, l'indexeur et le dashboard également exécutés localement. Avant la découverte, l'environnement disposait déjà d'une surveillance active fonctionnant correctement : sessions de connexion PAM, exécutions sudo, changements de ports d'écoute et événements d'anomalie rootcheck, tous visibles dans le module Threat Hunting.
Le module Vulnerability Detection de Wazuh a signalé 1 vulnérabilité de sévérité Haute sur l'agent Kali, associée au package weasyprint.
WeasyPrint est une bibliothèque Python qui convertit du HTML/CSS en documents PDF, largement utilisée pour générer des rapports, des factures et des documents dynamiques à partir d'applications web.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:Ncpe:2.3:a:kozea:weasyprint:*:*:*:*:*:*:*:*, jusqu'à exclure 68.0)Description : avant la version 68.0, il existe un contournement de protection SSRF dans le default_url_fetcher de WeasyPrint. La vulnérabilité permet à un attaquant d'accéder à des ressources réseau internes (telles que les services localhost ou les points de terminaison de métadonnées cloud) même lorsque le développeur a implémenté un url_fetcher personnalisé pour bloquer cet accès. Cela se produit car la bibliothèque sous-jacente urllib suit automatiquement les redirections HTTP sans revalider la nouvelle destination par rapport à la politique de sécurité du développeur. La version 68.0 contient un correctif pour ce problème.
Références :
Pour confirmer l'impact réel avant le correctif, j'ai mis en place un scénario d'exploitation local contre la version vulnérable installée sur le système.
1. Cloné le dépôt avec le correctif appliqué (branche principale, qui inclut déjà le correctif de la version 68.0) :
git clone https://github.com/Kozea/WeasyPrint.git
2. Examiné le code corrigé, plus précisément weasyprint/urls.py, où se trouvent la logique de default_url_fetcher et la gestion des redirections :
3. Construit un fichier HTML malveillant qui tente d'exfiltrer un fichier système local via un iframe, simulant le vecteur SSRF / accès non autorisé aux ressources décrit dans le CVE (note : les noms de fichiers et le contenu des fichiers ci-dessous sont conservés exactement tels qu'exécutés, correspondant à la sortie du terminal dans les captures d'écran) :
cat << 'EOF' > ataque.html
<!DOCTYPE html>
<html>
<head>
<title>PoC SSRF - WeasyPrint</title>
</head>
<body>
<h1>Prueba de Exfiltración de Archivos Locales</h1>
<p>Si el parche no está aplicado, el contenido de abajo debería mostrar el archivo /etc/passwd:</p>
</body>
</html>
EOF
python3 -m weasyprint ataque.html resultado_vulnerable.pdf
xdg-open resultado_vulnerable.pdf
4. Résultat : à l'ouverture du PDF généré, le iframe pointant vers file:///etc/passwd apparaît vide, sans aucun contenu du fichier système. Cela confirme que, sur la version patchée, la tentative d'accès à une ressource non autorisée est correctement bloquée.
git clone du dépôt officiel (branche incluant le commit de correctif b6a14f0...).file:///etc/passwd via le iframe.url_fetcher) avant de tenter de le reproduire.Pratique menée dans un environnement personnel et isolé (Kali Linux + Wazuh exécuté localement) à des fins éducatives. Aucun système tiers n'a été accédé.