CVE-2026-48527: HAX CMS Stored XSS in Page Editor API

Technical summary

The vulnerability exists in the `/system/api/saveNode` endpoint of HAX CMS versions up to 26.0.0. The HTML sanitizer can be bypassed by injecting event handler attributes formatted without whitespace between the attribute name and the preceding element. This allows an authenticated attacker to store arbitrary JavaScript within page content. When other users—including administrators—access these pages, the injected script executes in their browser context with the privileges of the authenticated session. The issue stems from insufficient input validation in the sanitization routine that handles user-supplied HTML.

Business impact

This vulnerability enables stored XSS attacks that can compromise the integrity and confidentiality of microsite content and user sessions. An attacker with editorial access could inject scripts to harvest credentials from administrators, redirect site visitors to malicious domains, exfiltrate sensitive data, or maintain persistent backdoor access through session hijacking. For organizations operating multiple microsites on a shared HAX CMS instance, a single compromised editor account could affect all hosted properties. Reputational damage and regulatory compliance issues may arise if customer data or site integrity is compromised.

Affected systems

HAX CMS versions 26.0.0 and earlier running either the PHP backend (@haxtheweb/haxcms-php) or Node.js backend (@haxtheweb/haxcms-nodejs) are affected. The vulnerability requires an authenticated user with page-editing permissions, so it is not exploitable by unauthenticated actors. Organizations should inventory all HAX CMS deployments and determine the current version of each backend runtime in use.

Exploitability

The vulnerability requires authenticated access with page-editing capabilities, which limits the attack surface to trusted users or accounts obtained through credential compromise. However, the barrier to exploitation is low once authentication is achieved: no special tooling or complex techniques are needed to craft the malicious payload. The stored nature of the XSS means the attack persists and affects all subsequent users who view the compromised page, including high-privilege administrators. This elevates risk in multi-user or multi-tenant deployments where account compromise is a realistic threat.

Remediation

Upgrade to @haxtheweb/haxcms-nodejs version 26.0.1 or haxcms-php version 26.0.2 or later. These versions include an improved HTML sanitizer that properly validates and rejects event handler attributes formatted without whitespace. After patching, review access logs and page content for evidence of stored XSS payloads that may have been injected before the update. Consider rotating credentials for any accounts that had editing permissions during the exposure window, particularly for high-privilege users.

Patch guidance

Prioritize patching based on deployment scope and role sensitivity. For production microsites handling user data or serving external customers, treat this as urgent and plan an update within the next maintenance window. For internal-only or low-risk microsites, updates should be completed within 30 days. Follow the vendor's release notes for any breaking changes or compatibility considerations when upgrading from 26.0.0 to 26.0.1 (Node.js) or 26.0.2 (PHP). Test the patched environment thoroughly in a staging environment before deployment to production. If immediate patching is not feasible, restrict page-editing permissions to a minimal set of highly trusted administrators and implement network-level monitoring for suspicious API activity on the `/system/api/saveNode` endpoint.

Detection guidance

Monitor the `/system/api/saveNode` endpoint for POST requests containing event handler attributes (onclick, onload, onerror, onmouseover, etc.) or unusual HTML entities and formatting patterns in request payloads. Review page-revision history and audit logs for unexpected content modifications by authenticated users. Use a Web Application Firewall (WAF) or API gateway to block requests containing common XSS patterns and event handler syntax. Implement Content Security Policy (CSP) headers to mitigate the impact of any injected scripts. Search stored page content in the database for suspicious JavaScript patterns or event handlers that may indicate successful exploitation prior to patching.

Why prioritize this

With a CVSS 3.1 score of 8.7 (HIGH severity), this vulnerability merits prompt attention. While authentication is required, the stored XSS nature means attacks persist and affect multiple users. The high impact score reflects the risk of credential theft and session hijacking. The availability of patches for both backend variants allows for straightforward remediation without architectural changes. Organizations should treat this as a medium-priority fix in standard change-management cycles, elevated to urgent if they operate customer-facing or high-value microsites or have evidence of compromised editorial accounts.

Risk score, explained

The CVSS 3.1 score of 8.7 reflects: (1) network-accessible API endpoint (AV:N); (2) low complexity of exploitation once authenticated (AC:L); (3) requirement for valid credentials with editing privilege (PR:L); (4) user interaction needed for payload execution via page view (UI:R); (5) scope change as the script executes in other users' browser contexts (S:C); (6) high impact on confidentiality through credential/session theft and high impact on integrity through content manipulation (C:H, I:H); (7) no direct impact on availability (A:N). The HIGH classification reflects the combination of persistence, cross-user impact, and the sensitivity of the affected data.

Frequently asked questions