SveltyCMS EUVD-2026-82932

Requires an authenticated account with permission to upload media (PR:L) and specifically exercises the SVG media upload feature via its large-file/streaming path, which bypassed the sanitizeSvg/bufferAndSanitizeSvg routine and MAX_SVG_BYTES enforcement. Exploitation further requires victim interaction (UI:P/UI:R) - a user or admin must open/view the stored malicious SVG for the payload to fire. Limiting factors: not remote-unauthenticated (an upload-capable login is needed), payload only executes on view, and it is confined to SveltyCMS 0.0.6 before the referenced patch commit.

This is a stored cross-site scripting flaw (CWE-79) in SveltyCMS 0.0.6's SVG media upload path (src/utils/media/media-service.server.ts). The vendor CVSS 4.0 vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:L/VA:N (score 5.1, Medium) is internally consistent with a low-privilege, user-interaction-dependent XSS: network-reachable, low attack complexity, but requiring an authenticated low-privilege account able to upload media (PR:L) and a victim who subsequently views the malicious SVG (UI:P). The GitHub commit evidence corroborates the mechanism - the note 'large-file path was a stored-XSS bypass; always buffer + sanitizeSvg / bufferAndSanitizeSvg, never pure-stream unsanitized SVG' confirms the root cause is an unsanitized large-SVG streaming path that stored active script content. Signals are consistent but modest: no EPSS score is provided, the CVE is not in CISA KEV, and no public exploit code is referenced (only VulDB submission/analysis pages), so exploitation status is 'no public exploit identified at time of analysis.' Net assessment: a genuine but bounded issue - real integrity/session risk in the browser of a viewing user, gated behind needing an upload-capable account and victim interaction, in a pre-1.0 niche CMS. It is a patch-when-convenient issue rather than an emergency, and the vendor's VC:N/SC:N (no confidentiality impact, no scope change) arguably understates typical stored-XSS session-theft potential.

An attacker with a low-privilege authenticated account that can upload media crafts an SVG file containing embedded JavaScript and uploads it through the SVG media upload feature, exploiting the large-file streaming path that bypassed sanitization. When an administrator or another user later views that SVG in the CMS, the script executes in their browser session. No public exploit code is referenced - only VulDB analysis pages and the vendor patch commit.