SVXportal version 2.5 and prior contain a stored cross-site scripting vulnerability in the user registration workflow (index.php submitting to admin/user_action.php). User-supplied fields such as Firstname, lastname, and email are stored in the backend database without adequate output encoding and are later rendered in the administrator interface (admin/users.php), allowing an unauthenticated remote attacker to inject arbitrary JavaScript that executes in an administrator's browser upon viewing the affected page.
Security readout for executives and security teams
Plain-English summary
SVXportal 2.5 and earlier can store unsafe registration data that later runs as script in an administrator's browser. A public registration form can become the delivery point, so compromise risk centers on administrators who review user records.
Executive priority
Treat this as a moderate priority for exposed portals. It is not described as actively exploited, but it can turn routine administrator review into browser-side compromise risk.
Technical view
This is stored XSS in the registration workflow from index.php to admin/user_action.php, later rendered in admin/users.php. Unauthenticated users can place script-bearing content in fields such as firstname, lastname, or email. Execution requires an administrator to view the affected user page.
Likely exposure
Internet-facing SVXportal sites with public registration enabled and administrator review of registered users are the likely exposed systems. The bundle identifies SVXportal 2.5 and prior, but vendor fix status is not stated.
Exploitation context
The CVE is not marked KEV, and the provided sources do not state active exploitation. The attack path is plausible because it is unauthenticated, low complexity, and targets an administrator through stored content.
Researcher notes
The bundle supports CWE-79 stored XSS in the user registration to admin review path. It does not name a patched version, workaround, or exploitation in the wild. Avoid assuming impact beyond browser-side execution in an admin session.
Mitigation direction
Check SVXportal vendor guidance for a fixed release or official patch.
Restrict or disable public registration if it is not operationally required.
Limit admin interface access to trusted networks or authenticated administrative paths.
Apply contextual output encoding for stored user fields if maintaining a fork.
Validate and normalize registration fields before database storage.
Validation and detection
Inventory SVXportal deployments and identify versions 2.5 or earlier.
Confirm whether public registration is enabled on each deployment.
Review admin rendering of user fields for contextual output encoding.
Use benign test markers to confirm stored fields render as text, not active content.
Check logs for unusual registration values awaiting administrator review.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · medium confidence lookup
CWE-79: User-session and phishing behavior lookup
Client-side and session-facing weaknesses should be reviewed alongside initial-access and user-execution behaviors. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references database injection or access, so collection and exfiltration review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.