JeecgBoot SVG File CommonController.java cross site scripting

CVE-2026-8195 is a stored cross-site scripting flaw in the SVG file upload handler within CommonController.java in JeecgBoot 3.9.0 and 3.9.1. An attacker uploads a crafted SVG containing embedded JavaScript. When another user — ideally an admin — views or renders that SVG in the application, the script fires in the victim's browser session. The impact is standard stored-XSS fare: session hijacking, CSRF token theft, phishing overlays, or UI manipulation within the JeecgBoot application context. The fix ships in JeecgBoot 3.9.5.

The vendor's MEDIUM / 5.3 rating is *generous* for real-world risk. JeecgBoot is a Chinese-market low-code enterprise scaffolding framework with roughly 47k GitHub stars but vanishingly small Western enterprise adoption. Shodan surfaces approximately 80 internet-facing instances globally. The affected version window is just two point releases (3.9.0–3.9.1). The attack still requires a victim to interact with the malicious SVG — it is not a drive-by. Altogether, the exploitable population and blast radius are far smaller than the CVSS vector suggests.

Why this verdict

• Tiny exposure population: ~80 internet-facing instances globally per Shodan. Even accounting for unindexed instances behind corporate networks, JeecgBoot is a niche Chinese-market low-code framework with minimal Western enterprise adoption. The reachable target set is orders of magnitude smaller than mainstream enterprise software.
• Narrow version window: Only JeecgBoot 3.9.0 and 3.9.1 are affected. Version 3.9.5 was released in July 2026 with this fix included. Organizations on 3.8.x or ≤3.7.x are unaffected, further shrinking the vulnerable population.
• User interaction required: The CVSS vector confirms UI:P — a victim must navigate to and render the malicious SVG. This is not a drive-by or wormable condition. Stored XSS is more dangerous than reflected, but still requires social engineering or workflow-dependent viewing.
• Role multiplier: JeecgBoot is a *line-of-business application scaffolding platform*. It does not occupy any high-value-role position (not an IdP, hypervisor, PAM, backup, CI/CD, CA, network edge, or kernel-mode agent). Virtually 0% of installs serve a fleet-critical or identity-critical function. Compromise of a JeecgBoot session yields access to whatever business data the app manages — typically internal forms, dashboards, and workflow data. The blast radius is application-scoped, not domain- or fleet-scoped. The high-value-role floor does not apply.
• Low-impact XSS class: The CVSS vector shows VI:L (low integrity impact) with no confidentiality or availability impact. Even the vendor's own scoring acknowledges this is a minor integrity issue, not a data-breach or RCE vector.

Why not higher?

A MEDIUM rating would require either a larger exposed population, a path to chaining into RCE or privilege escalation, or deployment in a high-value role. JeecgBoot is not infrastructure — it's an application framework. The ~80 exposed instances and two-version window make even the vendor's MEDIUM generous. There is no evidence of active exploitation, no KEV listing, and the EPSS is bottom-quartile.

Why not lower?

An IGNORE rating would require the vulnerability to be purely theoretical or unexploitable. Here, a public PoC exists, the exploit is trivial (SVG with embedded JS), and stored XSS can still cause real harm (admin session hijack, data manipulation) in organizations that do run affected versions. The vendor's non-response to disclosure is also a concern — there's no indication of server-side SVG sanitization being added in the affected versions. It warrants tracking, just not urgency.

1. Set Content-Disposition: attachment on all user-uploaded files — Force the browser to download SVGs rather than render them inline. This completely neutralizes the XSS vector regardless of file content. Deploy via reverse proxy config (nginx add_header) or Spring Boot response filter. As a LOW-severity issue, no mitigation SLA applies — treat as backlog hygiene.
2. Deploy Content-Security-Policy headers with strict script-src — A CSP policy like script-src 'self' blocks inline scripts inside SVGs even if they render. This is a defense-in-depth measure that protects against the entire class of stored XSS, not just this CVE.
3. Strip or re-encode SVG uploads server-side — Use a library like DOMPurify (JS) or Apache Batik sanitizer (Java) to strip <script>, event handlers, and xlink:href from uploaded SVGs before storing them. This eliminates the attack at the source.
4. Upgrade to JeecgBoot 3.9.5 — The definitive fix. Version 3.9.5 addresses this CVE along with multiple other security issues (RCE, SQLi, SSRF). No mitigation SLA — go straight to the remediation window.

Run this on the JeecgBoot application server or any host with access to the JeecgBoot installation directory. Requires read access to the project's Maven POM or the deployed JAR. Example: bash check_cve_2026_8195.sh /opt/jeecgboot

#!/usr/bin/env bash
# check_cve_2026_8195.sh — Detect JeecgBoot versions vulnerable to SVG XSS (CVE-2026-8195)
# Usage: bash check_cve_2026_8195.sh /path/to/jeecgboot
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

INSTALL_DIR="${1:-}"
if [ -z "$INSTALL_DIR" ]; then
  echo "Usage: $0 /path/to/jeecgboot"
  exit 2
fi

# Try to find version from pom.xml
POM="$INSTALL_DIR/pom.xml"
if [ -f "$POM" ]; then
  VERSION=$(grep -oP '<version>\K[0-9]+\.[0-9]+\.[0-9]+' "$POM" | head -1)
elif ls "$INSTALL_DIR"/lib/jeecg-boot-base-core-*.jar 2>/dev/null 1>&2; then
  JAR=$(ls "$INSTALL_DIR"/lib/jeecg-boot-base-core-*.jar | head -1)
  VERSION=$(basename "$JAR" | grep -oP '[0-9]+\.[0-9]+\.[0-9]+')
else
  echo "UNKNOWN — could not determine JeecgBoot version from $INSTALL_DIR"
  exit 2
fi

if [ -z "$VERSION" ]; then
  echo "UNKNOWN — version string not found"
  exit 2
fi

echo "Detected JeecgBoot version: $VERSION"

# Affected: 3.9.0 and 3.9.1. Fixed in 3.9.5 (3.9.2-3.9.4 status unclear, treat as vulnerable)
MAJOR=$(echo "$VERSION" | cut -d. -f1)
MINOR=$(echo "$VERSION" | cut -d. -f2)
PATCH=$(echo "$VERSION" | cut -d. -f3)

if [ "$MAJOR" -eq 3 ] && [ "$MINOR" -eq 9 ]; then
  if [ "$PATCH" -ge 5 ]; then
    echo "PATCHED — version $VERSION is >= 3.9.5"
    exit 0
  elif [ "$PATCH" -ge 0 ] && [ "$PATCH" -le 4 ]; then
    echo "VULNERABLE — version $VERSION is in the affected range (3.9.0–3.9.4). Upgrade to 3.9.5+."
    exit 1
  fi
elif [ "$MAJOR" -gt 3 ] || { [ "$MAJOR" -eq 3 ] && [ "$MINOR" -gt 9 ]; }; then
  echo "PATCHED — version $VERSION is newer than 3.9.x"
  exit 0
else
  echo "PATCHED — version $VERSION predates the affected 3.9.0–3.9.1 range"
  exit 0
fi

echo "UNKNOWN"
exit 2

Sources

1. GHSA-9FGG-WXFC-5325 — Vulnerability-Lookup
2. CVE-2026-8195 — OffSeq Threat Radar
3. JeecgBoot v3.9.5 Release Notes
4. JeecgBoot v3.9.5 Patch Summary — Shenlong CVE Platform
5. JeecgBoot GitHub Repository
6. JeecgBoot CVEs — OpenCVE
7. VulnCheck Initial Access — JeecgBoot detections