Athuljayaram

The `roadiz/openid` package fails to properly implement the OIDC nonce validation process. While the `OAuth2LinkGenerator::generate()` function creates a nonce and includes it in the authorization request sent to the identity provider, the value is not stored or validated during the callback. Specifically, the `OpenIdJwtConfigurationFactory` validation chain lacks a nonce constraint, and the `OpenIdAuthenticator::authenticate()` function does not verify the nonce claim in the returned ID token against a stored value. This allows for ID token replay attacks, where intercepted tokens are reused for authentication, and token injection attacks, where a compromised identity provider can inject tokens across sessions.

The software fails to validate cookie names within the `setCookie()`, `serialize()`, and `serializeSigned()` functions. When an application uses a user-controlled cookie name, invalid characters such as control characters (e.g., `r` or ` `) can be included, leading to malformed Set-Cookie header values. In runtimes like Node.js and Cloudflare Workers, these invalid values are rejected, causing runtime errors that impact availability and robustness, although header injection and response splitting were not reproduced.

Name of the Vulnerable Software and Affected Versions phpMyFAQ versions prior to 4.1.1 Description pMyFAQ is an open source FAQ web application. The `searchCustomPages()` method in `phpmyfaq/src/phpMyFAQ/Search.php` uses `real escape string()` to sanitize search terms before embedding them in LIKE clauses. However, `real escape string()` does not escape SQL LIKE metacharacters `%` (match any sequence) and ` ` (match any single character). An unauthenticated attacker can inject these wildcards into search queries, causing them to match unintended records, resulting in information disclosure. The vulnerable code is located in `phpmyfaq/src/phpMyFAQ/Search.php`, lines 226–240. The attack vector involves submitting a search term containing ` ` or `%` as part of a word with a length of 3 or more characters, bypassing a length filter. For example, a search for ` % ` can match all custom pages. This allows an attacker to retrieve custom page content that would not appear in normal searches. Recommendations Update phpMyFAQ to version 4.1.1 or later.

Name of the Vulnerable Software and Affected Versions Ewe versions prior to 3.0.6 Description The `encode headers` function in `src/ewe/internal/encoder.gleam` directly interpolates response header keys and values into raw HTTP bytes without validating or stripping CRLF (`r `) sequences. This allows an attacker to inject arbitrary HTTP response content when user-controlled data is passed into response headers, potentially leading to response splitting, cache poisoning, and cross-site scripting. The issue stems from the lack of validation for outgoing response headers, while incoming request headers are validated via `validate field value()` in the HTTP/1.1 parser. The vulnerable code is located in the `encode headers` function, where both `key` and `value` are directly embedded into the output `BitArray` without sanitization. An example of exploitation involves setting a `Location` redirect header from a request parameter containing CRLF sequences. Recommendations Update to version 3.0.6 or later.

AVideo allows content owners to password-protect individual videos. The video password is stored in the database in plaintext, without hashing, salting, or encryption. An attacker gaining read access to the database—through methods like SQL injection, database backups, or misconfigured access controls—can obtain all video passwords in cleartext. The vulnerable setter is located in `objects/video.php` and is defined as: `public function setVideo password($video password)`. The vulnerable getter is also located in `objects/video.php` and is defined as: `public function getVideo password()`. The comparison of the entered password with the stored plaintext password occurs directly, using the following logic: `if ($video->getVideo password() === $ POST['password'])`. This poses a credential harvesting risk, as users often reuse passwords across multiple services.

AVideo is susceptible to a SQL injection issue in the `objects/like.php` file. The `getLike()` method uses a prepared statement placeholder for `users id` but directly concatenates `$this->videos id` into the SQL query string without proper parameterization. An attacker controlling the `videos id` value through a crafted request can inject arbitrary SQL code, bypassing the intended protection. The vulnerable code constructs a query like this: `SELECT * FROM likes WHERE users id = ? AND videos id = `.`$this->videos id` LIMIT 1;`. The `videos id` parameter originates from user input and is not validated before being included in the query. A proof-of-concept demonstrates that an attacker can submit a like request with a malicious `videos id` value, such as `1 UNION SELECT user,password,3,4,5,6,7,8 FROM users-- -`, to execute an arbitrary SQL query and potentially read the entire database, including user credentials and other sensitive information. The API endpoint `/objects/likeAjax.json.php` is used to submit like requests, and the vulnerable parameter is `videos id`.

The `fixCleanTitle()` static method in `objects/category.php` constructs a SQL SELECT query by directly interpolating the `$clean title` and `$id` variables into the query string without using prepared statements or parameterized queries. An attacker who can trigger category creation or renaming with a crafted title value can inject arbitrary SQL. The vulnerable code is located in the `fixCleanTitle()` function. The `$clean title` variable, derived from user input, and the `$id` variable are directly embedded into the SQL string without proper escaping or parameterization. An attacker can exploit this by providing a malicious title, such as `test' UNION SELECT username,password,3,4,5,6,7,8,9,10 FROM users-- -`, to exfiltrate credentials and other sensitive data from the `users` table. The API endpoint used for category creation or renaming is susceptible to this SQL injection.

The msgpack decoder does not correctly validate the input buffer length when processing truncated fixext data (format codes 0xd4-0xd8). This can result in an out-of-bounds read and a runtime panic, potentially leading to a denial of service attack.

A flaw exists in pgproto3 where a malicious or compromised PostgreSQL server can send a DataRow message containing a negative field length. This input validation issue can cause a denial of service (DoS) due to a slice bounds out of range panic.

A flaw exists in the `github.com/antchfx/xpath` component that allows a remote attacker to cause a Denial of Service (DoS) condition. This is achieved by submitting crafted Boolean XPath expressions that evaluate to true, triggering an infinite loop within the `logicalQuery.Select` function. This results in 100% CPU utilization, impacting the affected system.