EUVD-2026-30296
GHSA-prv3-g5c7-jrxh
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from Vendor (vulncheck) · only source for this CVE.
CVSS VectorVendor: vulncheck
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
4DescriptionCVE.org
Vvveb before 1.0.8.3 contains a stored cross-site scripting vulnerability in the customer signup flow where the Signup::addUser() controller copies raw POST username values into the display_name field before sanitization occurs. Attackers can submit HTML and script markup in the username field during signup, which gets stripped from the username column but persisted verbatim in the display_name column, allowing stored XSS execution when display_name is rendered without encoding in vulnerable views.
AnalysisAI
Stored cross-site scripting in Vvveb before 1.0.8.3 allows unauthenticated attackers to inject arbitrary HTML and JavaScript via the username field during customer signup, which persists in the display_name column and executes when rendered without encoding in vulnerable views. The vulnerability requires user interaction (visiting a page displaying the attacker's injected display_name) and affects confidentiality and integrity with CVSS 5.3. No public exploit code or active exploitation has been reported at time of analysis.
Technical ContextAI
Vvveb is a PHP-based website builder using a controller-based architecture. The vulnerability exists in the Signup::addUser() controller, which copies raw POST request data into user database fields without proper sanitization order. The root cause (CWE-79: Improper Neutralization of Input During Web Page Generation) stems from the application sanitizing the username field for database storage but failing to apply equivalent sanitization to the display_name field before persistence. The display_name field then renders without HTML encoding in user-facing templates, allowing injected script tags and event handlers to execute in the browser context of users viewing the attacker's profile or user list. The fix introduced the stripChars() utility function to remove dangerous characters (parentheses, braces, colons, angle brackets) from user input fields before storage, and applied sanitizeHTML() to bio fields to encode special characters while preserving safe HTML markup.
RemediationAI
Upgrade Vvveb to version 1.0.8.3 or later, which includes the stripChars() sanitization function and applies it to user input fields during signup and profile updates (commit fefac290a8c85d3c87fe80ffed68b6c5bc50e93c provides the fix). If immediate upgrade is not possible, implement output encoding on all display_name field renders by applying HTML entity encoding (e.g., htmlspecialchars()) in templates before display. Additionally, restrict public visibility of user display names to authenticated users only, or render display names in a sandboxed iframe context to contain XSS scope. The VulnCheck advisory (https://www.vulncheck.com/advisories/vvveb-stored-xss-via-signup-controller) provides vendor confirmation and remediation details.
Same weakness CWE-79 – Cross-site Scripting (XSS)
View allShare
External POC / Exploit Code
Leaving vuln.today