ghsa

Affected versions append `root` to group listings, unless the correct listing has exactly 1024 groups. This affects both: - The supplementary groups of a user - The group access list of the current process If the caller uses this information for access control, this may lead to privilege escalation. This crate is not currently maintained, so a patched version is not available. Versions older than 0.8.0 do not contain the affected functions, so downgrading to them is a workaround. ## Recommended alternatives - [`uzers`](https://crates.io/crates/uzers) (an actively maintained fork of the `users` crate) - [`sysinfo`](https://crates.io/crates/sysinfo)

### Impact A vulnerability in Multer versions >=1.4.4-lts.1, <2.0.1 allows an attacker to trigger a Denial of Service (DoS) by sending an upload file request with an empty string field name. This request causes an unhandled exception, leading to a crash of the process. ### Patches Users should upgrade to `2.0.1` ### Workarounds None ### References https://github.com/expressjs/multer/commit/35a3272b611945155e046dd5cef11088587635e9 https://github.com/expressjs/multer/issues/1233 https://github.com/expressjs/multer/pull/1256

### Summary An **unauthenticated information disclosure vulnerability** exists in the PSU deployment of HAX CMS via the `haxPsuUsage` API endpoint. This allows **any remote unauthenticated user** to retrieve a full list of PSU websites hosted on HAX CMS. When chained with other authorization issues (e.g., HAX-3), this could assist in targeted attacks such as unauthorized content modification or deletion. --- ### Details The endpoint [`https://open-apis.hax.cloud/api/services/stats/haxPsuUsage`](https://open-apis.hax.cloud/api/services/stats/haxPsuUsage) returns a list of websites on the PSU instance of HAX CMS. This endpoint is exposed without any authentication or authorization checks. The source of the issue is in the `haxPsuUsage.js` file, which appears to directly serve the site listing without verifying user identity or access level. This enables anyone with the endpoint URL to enumerate all site instances under the PSU deployment. This endpoint may have originally been used f...

The following functions in the anon-vec crate are unsound due to insufficient checks on their arguments:: - `AnonVec::get_ref()` - `AnonVec::get_mut()` - `AnonVec::remove_get()` The crate was built as a learning project and is not being maintained.

When verifying signatures with X509 certificate validation turned off and HMAC shared secret set (`signxml.XMLVerifier.verify(require_x509=False, hmac_key=...`), prior versions of SignXML are vulnerable to a potential algorithm confusion attack. Unless the user explicitly limits the expected signature algorithms using the `signxml.XMLVerifier.verify(expect_config=...)` setting, an attacker may supply a signature unexpectedly signed with a key other than the provided HMAC key, using a different (asymmetric key) signature algorithm. Starting with signxml 4.0.4, specifying `hmac_key` causes the set of accepted signature algorithms to be restricted to HMAC only, if not already restricted by the user.

When verifying signatures with X509 certificate validation turned off and HMAC shared secret set (`signxml.XMLVerifier.verify(require_x509=False, hmac_key=...`), prior versions of SignXML are vulnerable to a potential timing attack. The verifier may leak information about the correct HMAC when comparing it with the user supplied hash, allowing users to reconstruct the correct HMAC for any data.

### Impact This vulnerability may lead to: * Information disclosure, such as API keys for LLM providers, account passwords, and other sensitive data. ### Reproduce Follow these steps to set up a test environment for reproducing the vulnerability: 1. Install dependencies and clone the repository: ```bash pip install uv git clone https://github.com/AstrBotDevs/AstrBot && cd AstrBot uv run main.py ``` 2. Alternatively, deploy the program via pip: ```bash mkdir astrbot && cd astrbot uvx astrbot init uvx astrbot run ``` 3. In another terminal, run the following command to exploit the vulnerability: ```bash curl -L http://0.0.0.0:6185/api/chat/get_file?filename=../../../data/cmd_config.json ``` This request will read the `cmd_config.json` config file, leading to the leakage of sensitive data such as LLM API keys, usernames, and password hashes (MD5). ### Patches The vulnerability has been addressed in [Pull Request #1676](https://github.com...

### Impact Via a manipulated API request it's possible to upload a file that doesn't adhere with the configured allowable file extensions. ### Patches Patched in 15.4.2 and 16.0.0. ### Workarounds None available.

**Overview** In Auth0 Next.js SDK versions 4.0.1 to 4.6.0, __session cookies set by auth0.middleware may be cached by CDNs due to missing Cache-Control headers. **Am I Affected?** You are affected by this vulnerability if you meet the following preconditions: 1. Applications using the NextJS-Auth0 SDK, versions between 4.0.1 to 4.6.0, 2. Applications using CDN or edge caching that caches responses with the Set-Cookie header. 3. If the Cache-Control header is not properly set for sensitive responses. **Fix** Upgrade auth0/nextjs-auth0 to v4.6.1.

## Summary It is possible to bypass Deno's read/write permission checks by using `ATTACH DATABASE` statement. ## PoC ```js // poc.js import { DatabaseSync } from "node:sqlite" const db = new DatabaseSync(":memory:"); db.exec("ATTACH DATABASE 'test.db' as test;"); db.exec("CREATE TABLE test.test (id INTEGER PRIMARY KEY, name TEXT);"); ``` ``` $ deno poc.js ```