CVE-2026-48118: NukeViet Cross-Site Scripting Vulnerability

HIGH
Advisory Identifier: GHSA-mxpf-qgg6-v3ff
CVSS 8.2
CWE-79
Published
Advisory Summary

CVE-2026-48118 is a HIGH (CVSS 8.2) cross-site scripting vulnerability (CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')) affecting NukeViet libraries in the Packagist ecosystem. The issue involves unauthenticated reflected xss in comment module. Remediation is available by upgrading affected packages to version 4.6.00.

CVE-2026-48118 at a Glance

CVE Identifier CVE-2026-48118
GHSA Identifier GHSA-mxpf-qgg6-v3ff
Severity HIGH
CVSS v3.1 Base Score 8.2
CWE Classification CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Affected Product NukeViet
Package Ecosystem Packagist
Published Date
Last Updated

Security Impact

CVSS: 8.2

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction Required (UI:R)
Scope Changed (S:C)
Confidentiality High (C:H)
Integrity Low (I:L)
Availability None (A:N)

How to Fix CVE-2026-48118

To remediate this vulnerability, upgrade all affected NukeViet dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

nukeviet/nukeviet fixed: 4.6.00
Upgrade nukeviet/nukeviet to 4.6.00
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for nukeviet/nukeviet

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-48118, inspect your project dependencies for NukeViet:

inspect dependencies for nukeviet/nukeviet

Analyze the terminal output to locate any version of NukeViet in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 4.6.00), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), where the product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users. In NukeViet, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## 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 1. Attacker opens any article with a comment block and reads the `checkss` value from the HTML source. 2. Attacker constructs a payload (e.g. a credential-phishing overlay) and base64-encodes it. 3. 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> ``` 4. 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](https://cwe.mitre.org/data/definitions/79.html): Improper Neutralization of Input During Web Page Generation (Cross-site Scripting) - [CWE-565](https://cwe.mitre.org/data/definitions/565.html): Reliance on Cookies without Validation and Integrity Checking (contributing factor — session-independent token)

CVE-2026-48118 Affected NukeViet Versions

1 component(s)
Fixed Versions:
4.6.00
Product / Package Ecosystem Affected Versions Fixed Version
nukeviet/nukeviet
Packagist
< 4.6.00
4.6.00

References

Frequently Asked Questions

What is CVE-2026-48118?
CVE-2026-48118 is a security vulnerability in NukeViet involving Unauthenticated Reflected XSS in Comment Module under CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting').
Which NukeViet versions are affected?
Affected versions include releases prior to 4.6.00 across affected packages: nukeviet/nukeviet.
What version fixes CVE-2026-48118?
Upgrading to 4.6.00 (or the latest patched release for your respective branch) resolves the vulnerability.
Is nukeviet/nukeviet affected?
Yes, nukeviet/nukeviet is affected in releases prior to 4.6.00. Upgrade your dependency to 4.6.00 or later.
What is the CVSS score of CVE-2026-48118?
CVE-2026-48118 has a CVSS v3.1 base score of 8.2 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N.
What CWE is associated with CVE-2026-48118?
CVE-2026-48118 is classified under CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.).
How can I check Packagist dependencies for CVE-2026-48118?
Run the dependency tree command: 'inspect dependencies for nukeviet/nukeviet'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-mxpf-qgg6-v3ff",
  "modified" : "2026-07-13T17:21:07Z",
  "published" : "2026-07-13T17:21:07Z",
  "aliases" : [ "CVE-2026-48118" ],
  "summary" : "NukeViet: Unauthenticated Reflected XSS in Comment Module",
  "details" : "## Summary\n\nReflected 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.\n\n## Details\n\n### Vulnerability 1 — Reflected XSS via `status_comment`\n\n**Affected components:**\n- `modules/comment/funcs/main.php` — parameter ingestion\n- `modules/comment/comment.php` — decode and template assignment\n- `themes/*/modules/comment/comment.tpl` — raw render\n\nThe `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>`.\n\nThe 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.\n\n### Vulnerability 2 — Session-independent `checkss` token\n\n**Affected components:**\n- `modules/comment/comment.php` — token validation in comment-load and comment-module functions\n- `modules/comment/funcs/post.php` — token validation when posting\n- All caller modules that generate a `checkss` before invoking the comment system (e.g. `modules/news`, `modules/page`)\n\nThe `checkss` token required to load the comment block was computed by hashing the resource parameters together with `NV_CACHE_PREFIX`:\n\n```\ncheckss = md5(module + area + id + allowed + NV_CACHE_PREFIX)\n```\n\n`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.\n\nThis 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.\n\nThe correct pattern, used consistently elsewhere in the codebase (e.g. `modules/contact`, `modules/banners`), is to derive the token from `NV_CHECK_SESSION`:\n\n```\nNV_CHECK_SESSION = md5(NV_CACHE_PREFIX + session_id)\n```\n\nThis binds the token to the current session, so a token obtained by the attacker is invalid for any other user's session.\n\n## Attack scenario\n\n1. Attacker opens any article with a comment block and reads the `checkss` value from the HTML source.\n2. Attacker constructs a payload (e.g. a credential-phishing overlay) and base64-encodes it.\n3. Attacker delivers the following URL to the victim:\n   ```\n   https://<target>/index.php?language=vi&nv=comment&comment_load=1\n     &module=news&area=<area>&id=<id>&allowed=<allowed>\n     &checkss=<value_from_step_1>\n     &status_comment=<base64_payload>\n   ```\n4. 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.\n\n**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.\n\n**CSP note:** NukeViet's Content-Security-Policy includes `script-src 'unsafe-inline'` and does not restrict navigation, so the policy does not prevent exploitation.\n\n## CVSS 3.1\n\n**Vector:** `AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N`\n**Base Score:** **8.2 (High)**\n\n| Metric | Value | Rationale |\n|--------|-------|-----------|\n| Attack Vector | Network | Exploitable remotely via crafted URL |\n| Attack Complexity | Low | `checkss` readable from public HTML; no special setup required |\n| Privileges Required | None | No authentication needed |\n| User Interaction | Required | Victim must open the crafted URL |\n| Scope | Changed | JavaScript executes in victim's browser, crossing the application security boundary |\n| Confidentiality | **High** | Full plaintext credential capture demonstrated via phishing overlay |\n| Integrity | Low | DOM manipulation and authenticated requests possible; no direct backend write access |\n| Availability | None | No denial-of-service impact |\n\n## Patches\n\nBoth root causes are addressed:\n\n**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.\n\n**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.\n\nFix 1 alone eliminates the exploitability of this specific vector. Fix 2 is a necessary defence-in-depth layer that closes the underlying sink.\n\n## CWE\n\n- [CWE-79](https://cwe.mitre.org/data/definitions/79.html): Improper Neutralization of Input During Web Page Generation (Cross-site Scripting)\n- [CWE-565](https://cwe.mitre.org/data/definitions/565.html): Reliance on Cookies without Validation and Integrity Checking (contributing factor — session-independent token)",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Packagist",
      "name" : "nukeviet/nukeviet"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "4.6.00"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "< 4.5.09"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/nukeviet/nukeviet/security/advisories/GHSA-mxpf-qgg6-v3ff"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/nukeviet/nukeviet"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-79" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-07-13T17:21:07Z",
    "nvd_published_at" : null
  }
}