What is the CVSS score of EUVD-2026-34883?

EUVD-2026-34883 has a CVSS 3.1 base score of 8.7 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N. EPSS exploitation probability: 0.0%.

Which versions of HAX CMS are affected by EUVD-2026-34883?

HAX CMS PHP versions before 26.0.0 contain a stored cross-site scripting vulnerability that allows low-privilege users to upload files containing malicious code executable by all website visitors,…. A patch is available.

How to fix or mitigate EUVD-2026-34883?

Within 24 hours: Restrict HAX CMS file upload permissions to administrative users only. Within 7 days: Configure web application firewall rules to block file uploads with extensions .HTML, .Html, .HTM, and enforce MIME type validation beyond extension checking. Within 30 days: Obtain patch availability timeline from HAX CMS vendor; escalate for alternative CMS evaluation if no patch is committed by day 60.

HAX CMS EUVD-2026-34883

| CVE-2026-46392 HIGH

Improper Handling of Case Sensitivity (CWE-178)

2026-06-05 GitHub_M

PHP Information Disclosure

8.7

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

8.7 HIGH

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

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

Required

Scope

Changed

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Patch available

Jun 05, 2026 - 20:02 EUVD

Analysis Generated

Jun 05, 2026 - 19:21 vuln.today

DescriptionGitHub Advisory

HAX CMS helps manage microsite universe with PHP or NodeJs backends. Prior to version 26.0.0 of HAX CMS PHP, the saveFile endpoint validates upload extensions case-insensitively and writes the filename to disk verbatim, but the .htaccess rule that forces Content-Disposition: attachment on HTML files is case-sensitive. An HTML file uploaded with an uppercase extension (.HTML, .Html, .HTM) is still served as text/html but the forced-download header never applies, so the browser renders it inline and executes any embedded JavaScript in the HAXcms origin. This bypasses the mitigation shipped for CVE-2026-22704. Version 26.0.0 contains a fix.

AnalysisAI

Stored cross-site scripting in HAX CMS PHP before 26.0.0 lets authenticated low-privilege users upload HTML files with uppercase extensions (.HTML, .Html, .HTM) that bypass the case-sensitive .htaccess Content-Disposition: attachment rule, causing browsers to render the file inline and execute embedded JavaScript in the HAXcms origin. The flaw defeats the mitigation shipped for CVE-2026-22704 and carries a CVSS 8.7 score driven by scope change (S:C) into the victim browser context. No public exploit identified at time of analysis, though the GitHub Security Advisory describes the bypass technique in enough detail to reproduce.

Technical ContextAI

HAX CMS is a microsite/content management platform with both PHP and Node.js backends; this issue affects the PHP backend (CPE haxtheweb:haxcms-php). The root cause maps to CWE-178 (Improper Handling of Case Sensitivity): the saveFile upload endpoint normalizes the extension check to be case-insensitive (blocking .html in any case), yet the Apache .htaccess rule that forces Content-Disposition: attachment for HTML responses matches only lowercase .html. Because Apache's content-type negotiation still maps .HTM/.HTML/.Html to text/html while the regex-based attachment rule misses them, the file is served inline and the embedded script runs in the HAXcms same-origin context - exactly the outcome the original CVE-2026-22704 mitigation was meant to prevent.

RemediationAI

Vendor-released patch: upgrade haxcms-php to version 26.0.0 or later, which corrects the extension/htaccess case mismatch (see https://github.com/haxtheweb/issues/security/advisories/GHSA-hg33-w4j2-95qp). If upgrading immediately is not possible, edit the site's .htaccess to match HTML extensions case-insensitively - for example replace any \.html$ rule with (?i)\.html?$ or add explicit FilesMatch directives covering .HTM, .HTML, .Htm, .Html - which forces the Content-Disposition: attachment header on all casings; the side effect is purely cosmetic (HTML downloads instead of rendering, which is the intended behavior for uploaded files). Additionally, tighten the saveFile endpoint to reject any extension whose lowercased form is in the blocklist before writing to disk, and restrict the upload role to trusted authors only as a defense-in-depth measure while patches are rolled out.