Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
16 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
HaxCMS is affected by a stored cross-site scripting (XSS) vulnerability in the /system/api/saveNode endpoint. An authenticated user with a permission to edit pages can bypass the HTML sanitizer by injecting an event handler attribute without whitespace before the attribute name. For example, the sanitizer misses: The important bypass is: The payload is stored in the generated page files and executes when a user clicks the injected link. Details The issue is caused by regex-based HTML sanitization that expects whitespace before event handler attributes. Because the sanitizer expects a pattern like: It fails to remove an event handler when it is written without whitespace: Browsers still parse onclick as a valid event handler attribute, so the JavaScript executes when the element is clicked. Affected endpoint: Affected parameter: PoC 1. Log in to HaxCMS and edit any existing page. 2. Capture the page save request in Burp Suite: 3. In the JSON request body, modify only the…
Recommended action: Upgrade to 26.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. 2.…
Recommended action: Upgrade to 26.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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, usertoken, sitetoken, and appstoretoken) 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…
Recommended action: Upgrade to 26.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A stored cross-site scripting (XSS) vulnerability exists in HAX CMS due to improper sanitization of <iframe 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: <img width="2446" height="1319" alt="image"…
Recommended action: Upgrade to 26.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 26.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A stored cross-site scripting (XSS) vulnerability exists in HAX CMS due to improper sanitization of the <video-player 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 <video-player 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: 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…
Recommended action: Upgrade to 26.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 filegetcontents(). The data flow is as follows: - User input (build.files) is processed via objecttoarray() 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: Here, tmpname is attacker-controlled and may contain: - External URLs (http://attacker.com) - Internal services (http://127.0.0.1) -…
Recommended action: Upgrade to 26.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Stored XSS Leading to Account Takeover Details The Exploit Chain: 1.Upload: The attacker uploads an .html file containing a JavaScript payload. 2.Execution: A logged-in administrator is tricked into visiting the URL of this uploaded file. 3.Token Refresh: The JavaScript payload makes a fetch request to the /system/api/refreshAccessToken endpoint. Because the administrator is logged in, their browser automatically attaches the haxcmsrefreshtoken cookie to this request. 4.JWT Theft: The server validates the refresh token and responds with a new, valid JWT access token in the JSON response. 5.Exfiltration: The JavaScript captures this new JWT from the response and sends it to an attacker-controlled server. 6.Account Takeover: The attacker now possesses a valid administrator JWT and can take full control of the application. Vulnerability recurrence: <img width="1198" height="756" alt="image" src="https://github.com/user-attachments/assets/7062d542-702e-4cbe-8493-da0f71e790c3" /…
Recommended action: Upgrade to 25.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The HAX CMS 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. Details The API endpoints within the HAX CMS application check if a user is authenticated, but don't check for authorization before performing an operation. Affected Resources - Operations.php: 760 createNode() - Operations.php: 868 saveNode() - Operations.php: 1171 deleteNode() - Operations.php: 1789 listSites() - Operations.php: 1890 createSite() - Operations.php: 2196 getConfig() - Operations.php: 2389 cloneSite() - Operations.php: 2467 deleteSite() - Operations.php: 2524 downloadSite() - Operations.php: 2607 archiveSite() Note: This may not include all affected endpoints within the application. Impact An authenticated attacker can make requests to interact with other users' sites. This can be used to enumerate, modify, and delete…
Recommended action: Upgrade to 11.0.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
All pages within the HAX CMS application do not contain headers to stop other websites from loading the site within an iframe. This applies to both the CMS and generated sites. PoC To replicate this vulnerability, load the target page in an iframe and observe the rendered content. Impact 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.
Recommended action: Upgrade to 11.0.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The NodeJS version of the HAX CMS application is distributed with hardcoded default credentials for the user and superuser accounts. Additionally, the application has default private keys for JWTs. Users aren't prompted to change credentials or secrets during installation, and there is no way to change them through the UI. Affected Resources - HAXCMS.js HAXCMSClass Impact An unauthenticated attacker can read the default user credentials and JWT private keys from the public haxtheweb GitHub repositories. These credentials and keys can be used to access unconfigured self-hosted instances of the application, modify sites, and perform further attacks.
Recommended action: Upgrade to 11.0.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The HAX CMS NodeJS application crashes when an authenticated attacker provides an API request lacking required URL parameters. This vulnerability affects the listFiles and saveFiles endpoints. Details This vulnerability exists because the application does not properly handle exceptions which occur as a result of changes to user-modifiable URL parameters. Affected Resources • listFiles.js:22 listFiles() • saveFile.js:52 saveFile() • system/api/listFiles • system/api/saveFile PoC 1. Targeting an instance of instance of HAX CMS NodeJS, send a request without parameters to listFiles or saveFiles. The following screenshot shows the request in Burp Suite. 2. The server will crash with ERRINVALIDARGTYPE. Impact An authenticated attacker can deny access to the HAX CMS NodeJS application by crashing the backend server. This prevents all users from accessing the backend system. If the backend system is hosting websites, those websites will be unavailable.
Recommended action: Upgrade to 11.0.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The NodeJS version of HAX CMS has a disabled Content Security Policy (CSP). This configuration is insecure for a production application because it does not protect against cross-site-scripting attacks. Details The contentSecurityPolicy value is explicitly disabled in the application's Helmet configuration in app.js. Affected Resources - app.js:52 PoC To reproduce this vulnerability, install HAX CMS NodeJS. The application will load without a CSP configured. Impact In conjunction with an XSS vulnerability, an attacker could execute arbitrary scripts and exfiltrate data, including session tokens and sensitive local data. Additional Information - OWASP: Content Security Policy
Recommended action: Upgrade to 11.0.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The NodeJS version of HAX CMS uses an insecure default configuration designed for local development. The default configuration does not perform authorization or authentication checks. Details If a user were to deploy haxcms-nodejs without modifying the default settings, ‘HAXCMSDISABLEJWTCHECKS‘ would be set to ‘true‘ and their deployment would lack session authentication. Affected Resources - package.json:13 PoC To reproduce this vulnerability, install HAX CMS NodeJS. The application will load without JWT checks enabled. Impact Without security checks in place, an unauthenticated remote attacker could access, modify, and delete all site information.
Recommended action: Upgrade to 11.0.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The 'gitImportSite' functionality obtains a URL string from a POST request and insufficiently validates user input. The ’setremote’ function later passes this input into ’procopen’, yielding OS command injection. Details The vulnerability exists in the logic of the ’gitImportSite’ function, located in ’Operations.php’. The current implementation only relies on the ’filtervar’ and 'strpos' functions to validate the URL, which is not sufficient to ensure absence of all Bash special characters used for command injection. Affected Resources • Operations.php:2103 gitImportSite() • \<domain\/\<user\/system/api/gitImportSite PoC To replicate this vulnerability, authenticate and send a POST request to the 'gitImportSite' endpoint with a crafted URL in the JSON data. Note, a valid token needs to be obtained by capturing a request to another API endpoint (such as 'archiveSite'). 1. Start a webserver. 2. Initiate a request to the ’archiveSite’ endpoint. 3. Capture and modify the request…
Recommended action: Upgrade to 11.0.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Affected Resources - Operations.php:868 - https://<site/<user/system/api/saveNode PoC 1. Set the URL in an iframe pointing to an attacker-controlled server running Responder 2. Once another user visits the site, they are prompted to sign in. 3. If a user inputs credentials, the username and password hash are outputted in Responder. Impact 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.
Recommended action: Upgrade to 11.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.