Server-Side Request Forgery in Pentestify allows authenticated users to trigger outbound server requests via unvalidated image URLs
Description
Server-Side Request Forgery (CWE-918) in the PDF export component (generate_pdf, backend/main.py) and in the FindingBase and ReportBase input schemas (backend/schemas.py), exposed at GET /api/reports/{report_id}/pdf and fed from POST /api/reports/{report_id}/findings, in Pentestify 1.0.0, which allows an authenticated user to cause outbound HTTP GET requests from the server to arbitrary attacker-chosen destinations (loopback, internal network or external hosts) via URLs stored in a finding's images field (and equivalently in a report's client_logo field), because both fields are declared as List[str] with no validator at all (backend/schemas.py:48 and backend/schemas.py:85), are persisted verbatim and are interpolated unsanitized into <img src="${img}"> when the report is built (js/app.js:1336 and js/app.js:1113), while PDF generation renders that same page in a server-side headless Chromium using page.goto(target_url, wait_until="networkidle") (backend/main.py:379), a wait condition that requires the browser to complete every subresource fetch from inside the server perimeter, unlike the handling the project already applied to the navigation target itself, which was pinned to the APP_BASE_URL constant rather than derived from the request precisely so the headless browser could not be sent to an attacker-controlled destination (commit 3b78e92), a criterion that was not extended to subresources loaded by the rendered page. This results in an attacker-controlled outbound request being issued by the target server, verified by that request arriving at an external listener under the attacker's control. The issue is a blind SSRF: the <img> context does not return the response body to the attacker, and the proof of concept does not demonstrate reading or exfiltration of internal content.
Vulnerability type (CWE)
CWE-918: Server-Side Request Forgery (SSRF)
Affected versions
Pentestify before 1.1.0 (fixed in 1.1.0 by commit a058a22, dated 2026-06-23). The version is read from the APP_VERSION constant in js/app.js: it first appears in commit 2a1551b with the value 1.0.0 and moves to 1.1.0 in the fixing commit itself; earlier commits carried no version identifier. Neither 1.0.0 nor 1.1.0 carries a git tag. The earliest tag in the repository is v1.1.1, which already contains the fix, so no tagged release shipped in a vulnerable state and 1.0.0 is the only version-labelled state affected. The server-side sink has existed since Playwright rendering was introduced (commit 7e7d53f, 2026-05-02). Default status: unaffected.
Score (CVSS 4.0)
Medium (5.3)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N
Solution
Upgrade to version 1.1.0 or higher. The fix was not tagged: the earliest tagged release containing it is v1.1.1.
Patch
Commit a058a22
Credits
- Marcos Turrión García (marcosturriongarcia2005) - finder
- Xoán M. Otero Jorge - analyst
- Cristian Fernandez Cornejo - analyst
- Secur0 CNA - coordinator
- Mario Álvarez Fernández (maalfer) - remediation developer Discovery source: External Official record: CVE-2026-59231
