PT-2026-58978 — XSS in Packagist Nukeviet/Nukeviet

PT-2026-58978 · Packagist · Nukeviet/Nukeviet

Published

2026-07-13

Updated

2026-07-13

CVSS v3.1

8.2

High

Vector

AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N

Summary

Reflected XSS in the Comment module via the status comment URL parameter. The parameter accepts attacker-controlled base64-encoded HTML/JavaScript that is decoded server-side and rendered unescaped into the page. Compounded by a second flaw: the checkss anti-forgery token was derived from a site-wide static value (NV CACHE PREFIX) instead of a per-session value, making the token reusable across all users and allowing the attack to be delivered via a simple crafted URL.

Details

Vulnerability 1 — Reflected XSS via `status comment`

Affected components:

modules/comment/funcs/main.php — parameter ingestion
modules/comment/comment.php — decode and template assignment
themes/*/modules/comment/comment.tpl — raw render

The status comment GET/POST parameter is sanitised with get title(), which applies strip tags(). Because the parameter is intended to carry a base64-encoded string, its character set ([A-Za-z0-9- ,]) passes through strip tags() unchanged. The value is later decoded with nv base64 decode() and assigned to the template variable STATUS COMMENT without any escaping, which the template then renders raw inside a <div>.

The fundamental flaw is ordering: the filter is applied to the encoded form of the data, before decoding, so it is entirely ineffective against whatever the decoded content contains. Any HTML or JavaScript payload, once base64-encoded, survives the filter and executes in the victim's browser.

Vulnerability 2 — Session-independent `checkss` token

Affected components:

modules/comment/comment.php — token validation in comment-load and comment-module functions
modules/comment/funcs/post.php — token validation when posting
All caller modules that generate a checkss before invoking the comment system (e.g. modules/news, modules/page)

The checkss token required to load the comment block was computed by hashing the resource parameters together with NV CACHE PREFIX:

checkss = md5(module + area + id + allowed + NV CACHE PREFIX)

NV CACHE PREFIX is a static, site-wide constant — identical for every visitor — derived at install time from the site key and server name. The token therefore has the same value for all users viewing the same article and never changes between sessions.

This token is printed into the public HTML of every page that includes a comment block (as a data-checkss attribute on the comment container). Because the token is not session-bound, an attacker can read it from the page source and reuse it in a crafted URL targeting any other user.

The correct pattern, used consistently elsewhere in the codebase (e.g. modules/contact, modules/banners), is to derive the token from NV CHECK SESSION:

NV CHECK SESSION = md5(NV CACHE PREFIX + session id)

This binds the token to the current session, so a token obtained by the attacker is invalid for any other user's session.

Attack scenario

Attacker opens any article with a comment block and reads the checkss value from the HTML source.
Attacker constructs a payload (e.g. a credential-phishing overlay) and base64-encodes it.
Attacker delivers the following URL to the victim:

https://<target>/index.php?language=vi&nv=comment&comment load=1
 &module=news&area=<area>&id=<id>&allowed=<allowed>
 &checkss=<value from step 1>
 &status comment=<base64 payload>

When the victim opens the URL, the decoded payload renders in their browser within the site's origin, with access to cookies, session storage, and the ability to make authenticated requests.

Verified impact: A phishing overlay form was confirmed to transmit captured plaintext credentials to an attacker-controlled server. No authentication is required at any step.

CSP note: NukeViet's Content-Security-Policy includes script-src 'unsafe-inline' and does not restrict navigation, so the policy does not prevent exploitation.

CVSS 3.1

Vector: AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N Base Score: 8.2 (High)

Metric	Value	Rationale
Attack Vector	Network	Exploitable remotely via crafted URL
Attack Complexity	Low	`checkss` readable from public HTML; no special setup required
Privileges Required	None	No authentication needed
User Interaction	Required	Victim must open the crafted URL
Scope	Changed	JavaScript executes in victim's browser, crossing the application security boundary
Confidentiality	High	Full plaintext credential capture demonstrated via phishing overlay
Integrity	Low	DOM manipulation and authenticated requests possible; no direct backend write access
Availability	None	No denial-of-service impact

Patches

Both root causes are addressed:

Fix 1 — Bind checkss to user session: Replace NV CACHE PREFIX with NV CHECK SESSION in all locations that generate or validate the comment checkss token — both inside the comment module itself and in any caller module that constructs the token before invoking the comment system. With a session-bound token, a value obtained by the attacker is invalid for any other user's session, removing the delivery mechanism for this attack.

Fix 2 — Escape decoded output before rendering: Apply nv htmlspecialchars() to the result of nv base64 decode($status comment) before assigning it to the template. This closes the XSS sink as an independent defence-in-depth measure, remaining effective regardless of how the code path is reached.

Fix 1 alone eliminates the exploitability of this specific vector. Fix 2 is a necessary defence-in-depth layer that closes the underlying sink.

CWE

CWE-79: Improper Neutralization of Input During Web Page Generation (Cross-site Scripting)
CWE-565: Reliance on Cookies without Validation and Integrity Checking (contributing factor — session-independent token)

Fix

XSS

Found an issue in the description? Have something to add? Feel free to write us 👾

dbugs@ptsecurity.com

Weakness Enumeration

CWE-79

Related Identifiers

GHSA-MXPF-QGG6-V3FF

Affected Products

Nukeviet/Nukeviet