NukeViet: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Summary
A stored cross-site scripting (XSS) vulnerability exists in NukeViet CMS versions 4.x through 4.5.08. A low-privileged authenticated user can store a JavaScript payload in their profile's display name fields. The payload executes in the browser of any visitor — including administrators — who clicks the Reply ("Answer") link on a comment posted by that user.
Affected Component
The {COMMENT.post_name} template variable is interpolated without JavaScript-context escaping into an inline onclick handler in both comment block positions:
themes/default/modules/comment/comment.tplline 27 (top-level comments)themes/default/modules/comment/comment.tplline 64 (nested/reply comments)
onclick="nv_commment_feedback(event, {COMMENT.cid}, '{COMMENT.post_name}')"Root Cause
The first_name and last_name profile fields are sanitized with HTML numeric character references (' → ', ( → (, ) → ), / → /) via Request::_get_title() with $specialchars = true. This encoding is correct for plain HTML attribute and element contexts, but insufficient for a JavaScript string literal embedded inside an HTML attribute.
Browsers decode HTML entities in attribute values before the JavaScript engine parses the string. As a result, ' is decoded back to ', which terminates the JS string early and allows the remainder of the value to be executed as JavaScript.
The combined display name (nv_show_name_user(first_name, last_name)) is what reaches the template, giving an attacker up to ~200 encoded characters across both fields — sufficient for any practical payload.
Proof of Concept
Set first_name to the following value in profile settings (/index.php?nv=users&op=editinfo), then post any comment:
a');alert(document.domain);//The value is stored as a');alert(document.domain);//.
When a visitor clicks the Reply link on the comment, the browser renders:
nv_commment_feedback(event, 1, 'a');alert(document.domain);// Tester')causing alert(document.domain) to execute in the visitor's browser context.
A data-exfiltration variant (split across both name fields) navigates the victim's browser to an attacker-controlled URL carrying document.cookie as a query parameter. End-to-end verification was performed using a local listener.
Exploitation Conditions (default configuration)
| Condition | Default value | Effect |
|---|---|---|
| captcha_area_comm | 1 | No CAPTCHA for logged-in users — payload delivery requires no CAPTCHA solve |
| auto_postcomm | enabled | Comments are published immediately without moderation |
| active_editinfo_censor | 0 | Profile edits take effect immediately without admin review |
| CSP script-src | 'unsafe-inline' | Inline onclick handlers execute normally |
Any registered member can set the payload and post a comment with no additional steps.
If captcha_area_comm is set to 0, the name field of anonymous comments (modules/comment/funcs/post.php) is processed by the same get_title(..., 1) call, making exploitation possible without authentication.
Impact
An attacker with a regular user account can execute arbitrary JavaScript in the browser of any visitor who interacts with the Reply button on their comment, including site administrators.
Practical consequences include:
- Privilege escalation via admin session hijacking — forging administrative actions (content modification, account manipulation) in the context of an authenticated admin.
- Credential phishing — injecting a fake login form into the page.
- Data exfiltration — reading page content and non-
HttpOnlycookies.
> Note: NukeViet session cookies carry the HttpOnly flag, so they are not directly readable via document.cookie; however, the above attack vectors remain fully viable.
Remediation
Preferred fix: Remove post_name from the inline handler entirely. Pass only cid to nv_commment_feedback and have the function retrieve the display name from the already-rendered DOM (e.g., the adjacent ` element).
Alternative fix: If the value must be passed inline, encode it with json_encode($post_name) (PHP) so that the output is a properly escaped JavaScript string literal, not an HTML-entity-encoded one. HTML numeric character references must not be relied upon for JavaScript string escaping.
As a general note, the result of get_title(..., $specialchars=true)` is safe for HTML element content and quoted HTML attribute values, but unsafe when placed inside a JavaScript string literal within an attribute. Other locations in the codebase using the same pattern should be audited.
Resources
- OWASP: Cross Site Scripting Prevention — Rule 2: Attribute Encoding is Not Sufficient for JS Contexts
- CWE-79: Improper Neutralization of Input During Web Page Generation
- CWE-116: Improper Encoding or Escaping of Output