GHSA-mxpf-qgg6-v3ff

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...