CVE-2026-49259 — nukeviet/nukeviet
HIGHCVE-2026-49259 is a high-severity (CVSS 8.7) vulnerability in nukeviet/nukeviet. A fix is available for nukeviet/nukeviet — see the affected versions and patch details below.
NukeViet: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Real-World Exposure
nukeviet/nukevietReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
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
HttpOnlyflag, so they are not directly readable viadocument.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 <strong class="cm_item"> 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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | nukeviet/nukeviet | all versions | 4.6.00composer require nukeviet/nukeviet:^4.6.00 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for nukeviet/nukeviet, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update nukeviet/nukeviet to 4.6.00 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-49259 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-49259 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-49259. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-49259 in your dependencies?
O3 Security finds CVE-2026-49259 across Packagist dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.