Source
ghsa
### Summary 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](https://github.com/haxtheweb/haxcms-nodejs/blob/main/src/lib/HAXCMS.js#L1614) 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.
### Summary 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](https://github.com/haxtheweb/haxcms-nodejs/blob/main/src/routes/listFiles.js#L22) listFiles() • [saveFile.js:52](https://github.com/haxtheweb/haxcms-nodejs/blob/main/src/routes/saveFile.js#L52) saveFile() • system/api/listFiles • system/api/saveFile ### PoC 1. Targeting an instance of instance of [HAX CMS NodeJS](https://github.com/haxtheweb/haxcms-nodejs), send a request without parameters to `listFiles` or `saveFiles`. The following screenshot shows the request in Burp Suite. . 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](https://github.com/haxtheweb/haxcms-nodejs/blob/b1f95880b42fea6ed07855b5804b29b182ec5e07/src/app.js#L52) ### PoC To reproduce this vulnerability, [install](https://github.com/haxtheweb/haxcms-nodejs) 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](https://cheats...
### Summary 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, ‘HAXCMS_DISABLE_JWT_CHECKS‘ would be set to ‘true‘ and their deployment would lack session authentication.  #### Affected Resources - [package.json:13](https://github.com/haxtheweb/haxcms-nodejs/blob/a4d2f18341ff63ad2d97c35f9fc21af8b965248b/package.json#L13) ### PoC To reproduce this vulnerability, [install](https://github.com/haxtheweb/haxcms-nodejs) 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.
## Summary Nokogiri v1.18.9 patches the vendored libxml2 to address CVE-2025-6021, CVE-2025-6170, CVE-2025-49794, CVE-2025-49795, and CVE-2025-49796. ## Impact and severity ### CVE-2025-6021 A flaw was found in libxml2's xmlBuildQName function, where integer overflows in buffer size calculations can lead to a stack-based buffer overflow. This issue can result in memory corruption or a denial of service when processing crafted input. NVD claims a severity of 7.5 High (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) Fixed by applying https://gitlab.gnome.org/GNOME/libxml2/-/commit/17d950ae ### CVE-2025-6170 A flaw was found in the interactive shell of the xmllint command-line tool, used for parsing XML files. When a user inputs an overly long command, the program does not check the input size properly, which can cause it to crash. This issue might allow attackers to run harmful code in rare configurations without modern protections. NVD claims a severity of 2.5 Low (CVSS:3.1/AV:L/...
### Summary When parsing a multi-part form with large files (greater than the [default max spool size](https://github.com/encode/starlette/blob/fa5355442753f794965ae1af0f87f9fec1b9a3de/starlette/formparsers.py#L126)) `starlette` will block the main thread to roll the file over to disk. This blocks the event thread which means we can't accept new connections. ### Details Please see this discussion for details: https://github.com/encode/starlette/discussions/2927#discussioncomment-13721403. In summary the following UploadFile code (copied from [here](https://github.com/encode/starlette/blob/fa5355442753f794965ae1af0f87f9fec1b9a3de/starlette/datastructures.py#L436C5-L447C14)) has a minor bug. Instead of just checking for `self._in_memory` we should also check if the additional bytes will cause a rollover. ```python @property def _in_memory(self) -> bool: # check for SpooledTemporaryFile._rolled rolled_to_disk = getattr(self.file, "_rolled", True) return ...
# Summary The Dolibarr backend provides the function of adding Menu, and supports setting permissions for the added Menu:  This is the trigger point of the vulnerability. The submitted permission can be php code, and it will be executed when viewing the created Menu: - htdocs/admin/menus/edit.php  As you can see, in edit.php, if the created menu is set to `$menu->perms`, the `dol_eval()` method will be called. Following the `dol_eval()` method, we can see that it will filter the dangerous php functions in `$menu->perms` through the blacklist set in `$forbiddenphpfunctions`:  However, the blacklist here is not comprehensive. For example, the `include_once` and `require_once` functions can easily pass the bla...
### Summary Log output includes authentication token that provides full account access ### Details The post job action prints the contents of `config/config.vdf` which holds the saved authentication token and can be used to sign in on another machine. This means any public use of this action leaves authentication tokes for the associated steam accounts publicly available. Additionally, `userdata/$user_id$/config/localconfig.vdf` contains potentially sensitive information which should not be included in public logs. ### PoC Use the following workflow step ``` steps: - name: Setup SteamCMD uses: buildalon/setup-steamcmd@v1.0.4 - name: Sign into steam shell: bash run: | steamcmd +login ${{ secrets.WORKSHOP_USERNAME }} ${{ secrets.WORKSHOP_PASSWORD }} +quit ``` ### Impact Anyone who has used this workflow action with a steam account is affected and has had valid authentication tokens leaked in the job logs. This is particularly bad for publ...
### Summary Log output includes authentication token that provides full account access ### Details The post job action prints the contents of `config/config.vdf` which holds the saved authentication token and can be used to sign in on another machine. This means any public use of this action leaves authentication tokes for the associated steam accounts publicly available. Additionally, `userdata/$user_id$/config/localconfig.vdf` contains potentially sensitive information which should not be included in public logs. ### PoC Use the following workflow step ``` steps: - name: Setup SteamCMD uses: buildalon/setup-steamcmd@v1.0.4 - name: Sign into steam shell: bash run: | steamcmd +login ${{ secrets.WORKSHOP_USERNAME }} ${{ secrets.WORKSHOP_PASSWORD }} +quit ``` ### Impact Anyone who has used this workflow action with a steam account is affected and has had valid authentication tokens leaked in the job logs. This is particularly bad for publ...
A vulnerability was discovered in the marshmallow-packages/nova-tiptap Laravel Nova package that allows unauthenticated users to upload arbitrary files to any Laravel disk configured in the application. The vulnerability is due to: • Missing authentication middleware (Nova and Nova.Auth) on the /nova-tiptap/api/file upload endpoint • Lack of validation on uploaded files (no MIME/type or extension restrictions) • Ability for an attacker to choose the disk parameter dynamically This means an attacker can craft a custom form and send a POST request to /nova-tiptap/api/file, supplying a valid CSRF token, and upload executable or malicious files (e.g., .php, binaries) to public disks such as local, public, or s3. If a publicly accessible storage path is used (e.g. S3 with public access, or Laravel’s public disk), the attacker may gain the ability to execute or distribute arbitrary files — amounting to a potential Remote Code Execution (RCE) vector in some environments.