Source
ghsa
The express-xss-sanitizer (aka Express XSS Sanitizer) package through 2.0.0 for Node.js has an unbounded recursion depth in sanitize in lib/sanitize.js for a JSON request body.
A Regular Expression Denial of Service (ReDoS) vulnerability was discovered in the Hugging Face Transformers library, specifically within the `normalize_numbers()` method of the `EnglishNormalizer` class. This vulnerability affects versions up to 4.52.4 and is fixed in version 4.53.0. The issue arises from the method's handling of numeric strings, which can be exploited using crafted input strings containing long sequences of digits, leading to excessive CPU consumption. This vulnerability impacts text-to-speech and number normalization tasks, potentially causing service disruption, resource exhaustion, and API vulnerabilities.
Liferay Portal 7.4.0 through 7.4.3.101, and Liferay DXP 2023.Q3.0 through 2023.Q3.4, 7.4 GA through update 92 and 7.3 GA though update 35 does not limit the number of objects returned from a GraphQL queries, which allows remote attackers to perform denial-of-service (DoS) attacks on the application by executing queries that return a large number of objects.
Open redirect vulnerability in the System Settings in Liferay Portal 7.1.0 through 7.4.3.101, and Liferay DXP 2023.Q3.1 through 2023.Q3.4 , 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions allows remote attackers to redirect users to arbitrary external URLs via the _com_liferay_configuration_admin_web_portlet_SystemSettingsPortlet_redirect parameter. Open redirect vulnerability in the Instance Settings in Liferay Portal 7.1.0 through 7.4.3.101, and Liferay DXP 2023.Q3.1 through 2023.Q3.4 , 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions allows remote attackers to redirect users to arbitrary external URLs via the _com_liferay_configuration_admin_web_portlet_InstanceSettingsPortlet_redirect parameter. Open redirect vulnerability in the Site Settings in Liferay Portal 7.1.0 through 7.4.3.101, and Liferay DXP 2023.Q3.1 through 2023.Q3.4 , 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions...
### Summary A flaw in the `bodyLimit` middleware could allow bypassing the configured request body size limit when conflicting HTTP headers were present. ### Details The middleware previously prioritized the `Content-Length` header even when a `Transfer-Encoding: chunked` header was also included. According to the HTTP specification, `Content-Length` must be ignored in such cases. This discrepancy could allow oversized request bodies to bypass the configured limit. Most standards-compliant runtimes and reverse proxies may reject such malformed requests with `400 Bad Request`, so the practical impact depends on the runtime and deployment environment. ### Impact If body size limits are used as a safeguard against large or malicious requests, this flaw could allow attackers to send oversized request bodies. The primary risk is denial of service (DoS) due to excessive memory or CPU consumption when handling very large requests. ### Resolution The implementation has been updated to alig...
### Summary HMAC signature comparison is not timing-safe and is vulnerable to timing attacks. ### Details `SharedKey::sign()` returns a `Vec<u8>` which has a non-constant-time equality implementation. `Hmac::finalize()` returns a constant-time wrapper ([`CtOutput`](https://docs.rs/digest/0.10.7/digest/struct.CtOutput.html)) which was discarded. Alternatively, `Hmac` has a constant-time `verify()` method. The problem reported here is due to the following lines in `SharedKey::sign()` of the previous code: ```rust let mut mac = HmacSha256::new_from_slice(key).unwrap(); mac.update(data); Ok(mac.finalize().into_bytes().to_vec()) ``` and the merged update changes the third line to directly verify with `verify_slice`. ### Impact Anyone who uses HS256 signature verification is vulnerably to Timing Attack that allows the attacker to forge a signature.
### Summary The `forgot-password` endpoint in Flowise returns sensitive information including a valid password reset `tempToken` without authentication or verification. This enables any attacker to generate a reset token for arbitrary users and directly reset their password, leading to a complete **account takeover (ATO)**. This vulnerability applies to **both the cloud service (`cloud.flowiseai.com`) and self-hosted/local Flowise deployments** that expose the same API. **CVSS v3.1 Base Score:** **9.8 (Critical)** **Vector String:** `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` --- ### Details * The endpoint `/api/v1/account/forgot-password` accepts an email address as input. * Instead of only sending a reset email, the API **responds directly with sensitive user details**, including: * User ID, name, email, hashed credential, status, timestamps. * **A valid `tempToken` and its expiry**, which is intended for password reset. * This `tempToken` can then be reused immediately...
A Stored cross-site scripting vulnerability in the Liferay Portal 7.4.0 through 7.4.3.132, and Liferay DXP 2025.Q3.0, 2025.Q2.0 through 2025.Q2.12, 2025.Q1.0 through 2025.Q1.17, 2024.Q4.0 through 2024.Q4.7, 2024.Q3.0 through 2024.Q3.13, 2024.Q2.0 through 2024.Q2.13 and 2024.Q1.1 through 2024.Q1.20 allows an remote authenticated attacker to inject JavaScript through the organization site names. The malicious payload is stored and executed without proper sanitization or escaping.
A Regular Expression Denial of Service (ReDoS) vulnerability was discovered in the Hugging Face Transformers library, specifically affecting the MarianTokenizer's `remove_language_code()` method. This vulnerability is present in version 4.52.4 and has been fixed in version 4.53.0. The issue arises from inefficient regex processing, which can be exploited by crafted input strings containing malformed language code patterns, leading to excessive CPU consumption and potential denial of service.
JSON Web Services in Liferay Portal 7.4.0 through 7.4.3.119, and Liferay DXP 2024.Q1.1 through 2024.Q1.9, 7.4 GA through update 92 published to OSGi are registered and invoked directly as classes which allows Service Access Policies to get executed.