GrandNode 2 EUVD-2026-104569

Requires a privileged back-office account (store manager or vendor) with rights to edit product descriptions, since the XSS payload must be stored in product description rich-text fields that Grand.Web renders unencoded through Html.Raw in Product.Layout.Simple.cshtml on versions up to 2.3.0. Exploitation is further gated by victim interaction (UI:P): a separate user must view the affected product page for the stored script to execute. Limiting factors: PR:H means anonymous/unprivileged attackers cannot inject the payload, confining risk to deployments with multiple partially-trusted operators (e.g., multi-vendor marketplaces); the flaw is fully remediated in 2.4.0, which introduces allowlist-based HtmlSanitizer processing of this rich-text content.

This is a genuine but low-to-moderate priority issue, best characterized as a high-confidence-but-limited-impact flaw rather than an urgent threat. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:P/VC:N/VI:L) scores 4.8 (medium), and the key moderating signals are consistent and credible: PR:H means an attacker must already hold a privileged account, and the source-code evidence in the fix PR confirms this precisely - the affected fields are 'Vendor/Store-manager-editable rich text rendered unencoded via Html.Raw', so this is a stored XSS injectable only by a store manager or vendor, not an anonymous visitor. UI:P further requires a victim to simply view the affected product page. There is no KEV listing and no public POC (reported solely by VulDB), so exploitation status is 'no public exploit identified at time of analysis' - this is not evidence of active exploitation, only of a disclosed, patched weakness. The signals do not conflict: network vector is real (the payload is served over HTTP), but the PR:H privilege gate and limited integrity-only impact (VC:N/VI:L) keep real-world risk contained to environments with multiple, partially-trusted back-office operators. One caveat: the vendor rated VC:N (no confidentiality impact), which is arguably optimistic for XSS, since script execution in a victim's authenticated session can realistically enable session/cookie theft - defenders should not assume zero confidentiality exposure.

A user with store-manager or vendor privileges (PR:H) edits a product and embeds a malicious script into the product description, which is stored and later rendered unencoded via Html.Raw in Product.Layout.Simple.cshtml. When another user - such as a shopper or an admin reviewing the catalog - views that product page (UI:P), the script executes in their browser, enabling actions like session hijacking or defacement in the victim's context. No public exploit code has been identified at time of analysis, though the trivial nature of stored XSS makes exploitation straightforward once privileged access is obtained.