GHSA-9jr9-8ff3-m894 CVE-2025-54378
HAX CMS API Lacks Authorization Checks
High
Packagistnpm
- Severity
- 8.3 / 10
- High · CVSS 3.1
- Exploit chance (EPSS)
- 0.57%
- Chance of exploitation in the next 30 days. Higher than 47.22% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Fix
- Available
- 2 packages have a fixed version
Description
Summary
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 other users' sites and nodes.
Additionally, an authenticated attacker can use the 'getConfig' endpoint to pull the application's configuration, which may store cleartext credentials.
PoC - /deleteNode
- Browse to the 'site.json' file for a target site, and note the ID of the item to delete.
- Make a POST request to the 'deleteNode' endpoint with a valid JWT and the target object ID.
Site before editing:
Site after editing:
Affected versions
Packagist
| Package | Vulnerable | Fixed in |
|---|---|---|
| elmsln/haxcms | < 11.0.14 |
11.0.14 |
npm
| Package | Vulnerable | Fixed in |
|---|---|---|
| @haxtheweb/haxcms-nodejs | < 11.0.14 |
11.0.14 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
elmsln/haxcms Packagist → 11.0.14
- composer
composer require elmsln/haxcms:^11.0.14
@haxtheweb/haxcms-nodejs npm → 11.0.14
- npm
npm install @haxtheweb/haxcms-nodejs@11.0.14- yarn
yarn add @haxtheweb/haxcms-nodejs@11.0.14- pnpm
pnpm add @haxtheweb/haxcms-nodejs@11.0.14
Severity breakdown
CVSS 3.1 8.3
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- Low
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- Low
- Integrity
- High
- Availability
- High
Weakness
CWE-285: Improper Authorization
The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.
How to prevent it
- Architecture and Design: Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
- Architecture and Design: Ensure that you perform access control checks related to your business logic. These checks may be different than the access control checks that you apply to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor.
- Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
- Architecture and Design: For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
- System Configuration, Installation: Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
CWE-862: Missing Authorization
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
How to prevent it
- Architecture and Design: Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
- Architecture and Design: Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
- Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
- Architecture and Design: For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
- System Configuration, Installation: Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
References
Advisories
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-g2g8-95qg-v35h HaxCMS has a stored Cross-Site Scripting (XSS) bypass in its saveNode endpoint | High | Also affects @haxtheweb/haxcms-nodejs |
| GHSA-9r33-xhw8-4qqp HAX CMS: Denial of Service using Malicious Import Request | Medium | Also affects @haxtheweb/haxcms-nodejs |
| GHSA-x3x5-7h4h-gwxg HAXcms: Mass Token Exfiltration and Cross-Tenant Hijack | High | Also affects @haxtheweb/haxcms-nodejs |
| GHSA-jh3h-rpxg-fr36 Stored XSS via <iframe> in HAX CMS allows access to sensitive client-side data and account takeover | High | Also affects @haxtheweb/haxcms-nodejs |
| GHSA-6c8g-9hfh-pq5h HAXcms: Private Key Disclosure via Broken HMAC Implementation | Critical | Also affects @haxtheweb/haxcms-nodejs |
| GHSA-2m6p-hm3w-6jm3 HAX CMS: Stored XSS via '<video-player>' component allows arbitrary JavaScript execution and token theft | Medium | Also affects @haxtheweb/haxcms-nodejs |
| GHSA-q862-gcgq-5m6g HAXcms createSite SSRF Enables Arbitrary File Read | High | Also affects @haxtheweb/haxcms-nodejs |
| GHSA-3fm2-xfq7-7778 HAXcms Has Stored XSS Vulnerability that May Lead to Account Takeover | Medium | Also affects @haxtheweb/haxcms-nodejs |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor