CVE-2026-19434: maalfer Pentestify XSS Vulnerability

CVE-2026-19434 Overview

CVE-2026-19434 is a stored Cross-Site Scripting (XSS) vulnerability in maalfer Pentestify before version 2.3.1. The flaw resides in the finding renderer, which interpolates the severity field of a finding directly into HTML class and style attributes without escaping. Authenticated users can inject arbitrary HTML markup that executes JavaScript in the application origin when a report is rendered. The issue is tracked as CWE-79: Improper Neutralization of Input During Web Page Generation.

Critical Impact
Authenticated attackers can execute arbitrary JavaScript in the browser context of any user viewing a rendered pentest report, enabling session theft, action spoofing, and further account compromise.

Affected Products

maalfer Pentestify versions prior to 2.3.1
Pentestify frontend finding renderer component
Pentestify backend schemas.py severity handling

Discovery Timeline

2026-08-11 - CVE-2026-19434 published to the National Vulnerability Database
2026-08-12 - Last updated in NVD database

Technical Details for CVE-2026-19434

Vulnerability Analysis

The vulnerability exists in the Pentestify finding renderer, where the severity value of a finding is interpolated directly into HTML class and style attributes at render time. The frontend expects a constrained set of severity keywords such as crit, high, med, low, or info, and uses them to build attribute values like severity-<x> and var(--severity-<x>). Because no escaping or allow-list validation was applied server-side, an attacker with authenticated access can submit crafted markup in the severity field. When any user renders the associated report, the injected payload breaks out of the attribute and executes as script within the Pentestify origin.

Root Cause

The root cause is missing output encoding and missing input allow-listing on the severity field of the finding schema. Attribute-context interpolation of untrusted data violates the standard XSS defense of contextual output encoding. Because the field was assumed to be constrained to a small vocabulary but never enforced, malicious values were stored and later reflected unescaped into the DOM.

Attack Vector

Exploitation requires an authenticated user with permission to create or modify findings. The attacker submits a finding with a crafted severity value containing attribute-breaking HTML markup. The payload is persisted in the backend and executes when a legitimate operator or reviewer opens the rendered report, enabling stored XSS in the application origin.

python

# Patch from backend/schemas.py — sanitizes the severity field on input and output.
# Source: https://github.com/ccyl13/Pentestify/commit/8e81053d490f0ba188543b7de3e5edf87112291a

# Caracteres permitidos en el nombre de usuario (sin comillas ni metacaracteres).
_USERNAME_RE = re.compile(r'^[A-Za-z0-9_.\-]{3,32}$')

# Únicos valores de severidad admitidos. El frontend los interpola directamente
# en atributos `class`/`style` (severity-<x>, var(--severity-<x>)), por lo que
# cualquier otro valor permitiría romper el atributo e inyectar HTML/JS (XSS).
# Se sanea aquí (entrada y salida) para neutralizar también datos ya guardados.
SEVERITY_LEVELS = ("crit", "high", "med", "low", "info")


def sanitize_severity(value) -> str:
    v = (value or "").strip().lower() if isinstance(value, str) else ""
    return v if v in SEVERITY_LEVELS else "info"


def is_safe_image_src(value) -> bool:
    return isinstance(value, str) and bool(_DATA_IMAGE_RE.match(value.strip()))

Source: GitHub commit 8e81053. The patch introduces sanitize_severity(), which coerces any value outside the fixed SEVERITY_LEVELS tuple to the safe default info, neutralizing both new submissions and previously stored payloads.

Detection Methods for CVE-2026-19434

Indicators of Compromise

Finding records with a severity value that is not one of crit, high, med, low, or info.
Stored severity values containing angle brackets, quotes, on*= event handlers, javascript: URIs, or style expressions.
Unexpected outbound requests from browsers viewing Pentestify reports, indicating exfiltration by injected script.

Detection Strategies

Query the Pentestify database for any finding where severity NOT IN ('crit','high','med','low','info') to surface tampered records.
Review web server and application logs for POST/PUT requests to finding endpoints with oversized or non-standard severity payloads.
Inspect rendered report HTML for injected <script> tags, event-handler attributes, or CSS expression() usage that should never appear inside severity-derived attributes.

Monitoring Recommendations

Enable a strict Content Security Policy (CSP) on the Pentestify frontend and monitor CSP violation reports for inline script attempts.
Log and alert on authenticated finding-creation and finding-update events, correlating spikes with unusual severity values.
Track browser telemetry for report-viewer sessions that spawn unexpected DOM modifications or network calls to attacker-controlled hosts.

How to Mitigate CVE-2026-19434

Immediate Actions Required

Upgrade Pentestify to version 2.3.1 or later, where the sanitize_severity() allow-list is enforced.
Audit existing findings and reset any severity value outside the approved set to info.
Rotate session tokens and credentials for accounts that may have viewed reports containing untrusted findings.

Patch Information

The fix is delivered in the Pentestify v2.3.2 release and applied in commit 8e81053. The patch adds server-side sanitization of the severity field in backend/schemas.py, restricting values to a fixed allow-list. Additional analysis is available in the secur0.com CVE-2026-19434 write-up.

Workarounds

Restrict finding creation and editing permissions to a minimal set of trusted authenticated users until the patch is applied.
Deploy a reverse-proxy or WAF rule that rejects finding submissions whose severity field does not match ^(crit|high|med|low|info)$.
Apply a strict Content Security Policy that blocks inline scripts and unsafe styles to reduce the impact of any residual injection.

bash

# Upgrade Pentestify to the patched release
git fetch --tags
git checkout v2.3.2

# Verify the sanitize_severity function is present in the deployed code
grep -n "sanitize_severity" backend/schemas.py

# Identify any stored findings with tampered severity values (example: PostgreSQL)
psql -d pentestify -c "SELECT id, severity FROM findings \
  WHERE severity NOT IN ('crit','high','med','low','info');"