CVE-2026-46357: HAX CMS Denial of Service via Malformed Site Creation Request

Technical summary

HAX CMS versions prior to 26.0.0 fail to properly validate input on the createSite endpoint (CWE-20: Improper Input Validation). An authenticated attacker can send a specially crafted request that triggers an unhandled exception or resource exhaustion condition, causing the Node.js process to crash. The vulnerability requires authentication, meaning the attacker must already have valid credentials. Version 26.0.0 resolves the issue through input validation improvements.

Business impact

An internal or compromised user account can render the entire microsite management platform unavailable without any corrective action other than manual server restart. For organizations relying on HAX CMS for production microsite operations, this creates an unplanned downtime risk. The attack requires only a single request and no special timing or coordination, making it trivially easy to exploit once an attacker has user credentials.

Affected systems

HAX CMS NodeJS backend versions prior to 26.0.0 are vulnerable. The PHP backend variant is not affected. Organizations should verify their deployment architecture (NodeJS vs. PHP) and current version number. Affected versions span all releases before version 26.0.0.

Exploitability

Exploitability is straightforward for users with valid authentication credentials. The attack vector is network-based, requires no user interaction, and succeeds with a single HTTP request. No special tools, timing coordination, or advanced techniques are required. The barrier to entry is low—the attacker simply needs legitimate (or compromised) application credentials. The CVSS score of 6.5 (Medium) reflects the requirement for prior authentication and the availability-only impact (no confidentiality or integrity compromise).

Remediation

Upgrade HAX CMS NodeJS deployments to version 26.0.0 or later immediately. Before patching, restrict access to the createSite endpoint to a minimal set of trusted users. Monitor authentication logs for suspicious site creation attempts. PHP-based HAX CMS deployments require no action. Verify your backend type and version number in your deployment documentation or application settings.

Patch guidance

Apply version 26.0.0 or any subsequent patch release to your HAX CMS NodeJS installation. Verify against the official HAX CMS release notes that the patch addresses input validation on the createSite endpoint. Test the patch in a non-production environment first to ensure compatibility with your custom microsite configurations. Schedule the update during a maintenance window, as it will require an application restart.

Detection guidance

Monitor application logs and error reporting for crashes in the createSite endpoint handler. Look for HTTP POST requests to the createSite endpoint with unusual or malformed payloads, especially from authenticated accounts with unexpected request patterns. Implement alerting on Node.js process restarts or out-of-memory conditions that correlate with createSite requests. Review authentication logs for accounts making rapid or unusual createSite requests. If you observe a crash of the Node.js process after a createSite request from an authenticated user, preserve logs and memory dumps for forensic analysis.

Why prioritize this

Although rated CVSS 6.5 (Medium), this vulnerability merits rapid patching because: (1) it enables trivial denial of service with a single request, (2) it requires only low-privilege authentication, not admin credentials, (3) it completely disables the application (not partial degradation), and (4) no workaround exists other than access restriction. Organizations should prioritize this above other medium-severity issues that offer partial mitigation or require higher privilege levels.

Risk score, explained

CVSS 6.5 reflects a network-accessible vulnerability requiring authentication (PR:L), with no complexity barrier (AC:L), affecting only availability (A:H) with no confidentiality or integrity loss (C:N, I:N). The Medium rating is appropriate because authentication is a prerequisite. However, the real-world risk may feel higher because a single authenticated user can paralyze the entire service, and in environments with many internal users or shared credentials, the likelihood of exploitation increases.

Frequently asked questions