ghsa

### 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 ```

### Summary The [Deno.env.toObject](https://docs.deno.com/api/deno/~/Deno.Env.toObject) method ignores any variables listed in the `--deny-env` option of the `deno run` command. When looking at the [documentation](https://docs.deno.com/runtime/fundamentals/security/#environment-variables) of the `--deny-env` option this might lead to a false impression that variables listed in the option are impossible to read. ### PoC ``` export AWS_SECRET_ACCESS_KEY=my-secret-aws-key # Works as expected. The program stops with a "NotCapable" error message echo 'console.log(Deno.env.get("AWS_SECRET_ACCESS_KEY"));' | deno run \ --allow-env \ --deny-env=AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY - # All enviroment variables are printed and the --deny-env list is completely disregarded echo 'console.log(Deno.env.toObject());' | deno run \ --allow-env \ --deny-env=AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY - ``` The first example using `get` exits with the following error: ``` error: Uncaught (in p...

### Summary `deno run --allow-read --deny-read main.ts` results in allowed, even though 'deny' should be stronger. Same with all global unary permissions given as `--allow-* --deny-*`. ### Details Caused by the fast exit logic in #22894. ### PoC Run the above command expecting no permissions to be passed. ### Impact This only affects a nonsensical combination of flags, so there shouldn't be a real impact on the userbase.