CVE-2026-46511: HAX CMS Stored XSS Vulnerability

CVE-2026-46511 Overview

CVE-2026-46511 affects HAX CMS, a content management system that orchestrates microsite networks using PHP or Node.js backends. Versions prior to 26.0.0 contain a Stored Cross-Site Scripting (XSS) vulnerability [CWE-79] that chains with a token exposure flaw in the /system/api/connectionSettings endpoint. The endpoint writes active session tokens, including jwt, user_token, site_token, and appstore_token, into the global JavaScript variable window.appSettings. An authenticated attacker can leverage the XSS payload to extract these tokens from a victim's session and exfiltrate them to an attacker-controlled webhook. The result is a complete cross-tenant account takeover. Version 26.0.0 patches the issue.

Critical Impact

Authenticated attackers can hijack tokens belonging to any victim who renders attacker-controlled content, achieving full cross-tenant account takeover in HAX CMS deployments.

Affected Products

• HAX CMS (PHP backend) versions prior to 26.0.0
• HAX CMS (Node.js backend) versions prior to 26.0.0
• HAX CMS microsite tenants managed by vulnerable installations

Discovery Timeline

• 2026-06-05 - CVE-2026-46511 published to NVD
• 2026-06-08 - Last updated in NVD database

Technical Details for CVE-2026-46511

Vulnerability Analysis

The vulnerability combines two distinct weaknesses into a single exploitation chain. The first is a Stored XSS flaw that permits an authenticated attacker to persist malicious JavaScript inside HAX CMS content. The second is an authentication design flaw in the /system/api/connectionSettings endpoint, which returns active session tokens and assigns them to a browser-accessible global variable.

When a victim renders a microsite or component containing the attacker's payload, the script executes in the victim's authenticated context. The payload silently issues a request to /system/api/connectionSettings, parses the response, and reads window.appSettings to harvest the jwt, user_token, site_token, and appstore_token values. Tokens are then exfiltrated to an external endpoint controlled by the attacker.

Because the leaked tokens span multiple authentication boundaries, the attacker gains control over the victim's account across tenants, sites, and the appstore integration.

Root Cause

The root cause is twofold. First, HAX CMS fails to neutralize script content before storing and rendering user-supplied input, violating standard output encoding requirements for stored XSS prevention. Second, the /system/api/connectionSettings endpoint exposes high-value session tokens to client-side JavaScript through a global variable, breaking the principle of least privilege for token handling.

Attack Vector

Exploitation requires only low-privileged authenticated access. The attacker stores a script payload in a HAX CMS field that renders without sanitization. When a higher-privileged user, including users in other tenants, visits the affected content, the payload executes. The script issues an authenticated fetch to /system/api/connectionSettings, reads window.appSettings, and posts the captured tokens to an attacker-controlled webhook. The attacker then replays the tokens to impersonate the victim.

No verified public exploit code is associated with this CVE. See the GitHub Security Advisory for additional technical detail.

Detection Methods for CVE-2026-46511

Indicators of Compromise

• Outbound HTTP requests from user browsers to unrecognized webhook domains containing jwt, user_token, site_token, or appstore_token parameters
• Unexpected requests to /system/api/connectionSettings originating from rendered content pages rather than admin UI flows
• HAX CMS content fields containing <script>, event handler attributes such as onerror= or onload=, or encoded payloads referencing window.appSettings
• Authentication events where a single jwt is reused from multiple geographies or user agents within a short window

Detection Strategies

• Inspect HAX CMS content stores and database tables for persisted HTML containing inline script tags or DOM event handlers.
• Correlate /system/api/connectionSettings access logs with the referring URL to identify calls triggered from non-administrative pages.
• Monitor egress traffic for token-shaped strings posted to domains outside the HAX CMS allowlist.

Monitoring Recommendations

• Enable verbose access logging on the HAX CMS API gateway, focused on /system/api/connectionSettings.
• Forward authentication and API logs to a centralized analytics platform with OCSF normalization for cross-source correlation.
• Alert on reuse of the same jwt across mismatched client fingerprints or source IP ranges.

How to Mitigate CVE-2026-46511

Immediate Actions Required

• Upgrade all HAX CMS instances to version 26.0.0 or later without delay.
• Invalidate every active jwt, user_token, site_token, and appstore_token issued by vulnerable versions and force re-authentication.
• Audit stored content for malicious script payloads before re-enabling rendering on production tenants.
• Review API access logs for prior calls to /system/api/connectionSettings triggered from non-admin contexts.

Patch Information

The HAX CMS maintainers released version 26.0.0, which remediates both the Stored XSS sink and the token exposure in /system/api/connectionSettings. Refer to the GitHub Security Advisory GHSA-x3x5-7h4h-gwxg for upgrade guidance.

Workarounds

• Restrict access to authenticated content authoring roles until the upgrade is complete.
• Apply a strict Content Security Policy that blocks inline scripts and limits outbound connect-src destinations.
• Place the HAX CMS admin and API endpoints behind a web application firewall configured to inspect and reject script-bearing payloads.
• Disable or proxy the /system/api/connectionSettings endpoint at the reverse proxy layer until patched.

# Example reverse proxy rule to block the vulnerable endpoint during remediation
location /system/api/connectionSettings {
    return 403;
}

# Example Content-Security-Policy header to limit XSS impact
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; connect-src 'self'; object-src 'none'; base-uri 'self'" always;