
Hands-on vulnerability management case study: how Wazuh flagged a real SSRF (CVE-2025-68616) in WeasyPrint, and how I reproduced and patched it.
During a personal practice exercise with Wazuh (open source SIEM/XDR) on a Kali Linux machine, the Vulnerability Detection module identified a High (CVSS 7.5) severity vulnerability in the WeasyPrint package: an SSRF protection bypass (CVE-2025-68616). I investigated the finding, reproduced the issue with a local proof of concept, applied the patched version of the project, and verified that exploitation no longer works. This repository documents the full process: detection, analysis, PoC, and remediation.
Wazuh is an open source security platform (SIEM + XDR) that combines, among other things, log collection, file integrity monitoring (FIM), anomaly detection, and vulnerability detection for software installed on monitored hosts, cross-referencing the package inventory against CVE databases (NVD, among others).
In this exercise, the Wazuh agent ran on a Kali GNU/Linux 2025.4 machine, with the manager, indexer, and dashboard also running locally. Before reaching the finding, the environment already had active monitoring working correctly: PAM login sessions, sudo executions, listening port changes, and rootcheck anomaly events, all visible in the module.
The Vulnerability Detection module in Wazuh reported 1 High severity vulnerability on the Kali agent, associated with the weasyprint package.
WeasyPrint is a Python library that converts HTML/CSS into PDF documents, widely used to generate reports, invoices, and dynamic documents from web applications.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:Ncpe:2.3:a:kozea:weasyprint:*:*:*:*:*:*:*:*, up to excluding 68.0)Description: prior to version 68.0, an SSRF protection bypass exists in WeasyPrint's default_url_fetcher. The vulnerability allows an attacker to access internal network resources (such as localhost services or cloud metadata endpoints) even when the developer implemented a custom url_fetcher to block such access. This happens because the underlying urllib library automatically follows HTTP redirects without re-validating the new destination against the developer's security policy. Version 68.0 contains a patch for the issue.
References:
To confirm the real-world impact before patching, I set up a local exploitation scenario against the vulnerable version installed on the system.
1. Cloned the repository with the patch applied (main branch, which already includes the fix from version 68.0):
git clone https://github.com/Kozea/WeasyPrint.git
2. Reviewed the fixed code, specifically weasyprint/urls.py, where the default_url_fetcher logic and redirect handling live:
3. Built a malicious HTML file that attempts to exfiltrate a local system file through an iframe, simulating the SSRF / unauthorized resource access vector described in the CVE (note: file names and file contents below are kept exactly as executed, matching the terminal output in the screenshots):
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. Result: when opening the generated PDF, the iframe pointing to file:///etc/passwd appears empty, with no content from the system file. This confirms that, on the patched version, the attempt to access an unauthorized resource is correctly blocked.
git clone of the official repository (branch including the patch commit b6a14f0...).file:///etc/passwd resource via the iframe.url_fetcher bypass) before attempting to reproduce it.Practice conducted in a personal, isolated environment (Kali Linux + Wazuh running locally) for educational purposes. No third-party systems were accessed.