Iliaal

**Name of the Vulnerable Software and Affected Versions** Grav version 2.0.1 **Description** A decompression-bomb size-cap bypass exists in ZipArchiver and GPMInstaller. The system calculates the uncompressed size by summing the values declared in each entry's ZIP central-directory header via `ZipArchive::statIndex()['size']` and compares this against `system.gpm.archive.max uncompressed size` before extraction. Since the declared size can be forged and is not verified against the actual inflated stream, a specially crafted archive with small declared per-entry sizes can bypass the limit. When `extractTo()` is called, the actual larger content is written, which can lead to disk exhaustion or inode depletion. This requires the archive to be provided by a package source or an administrator upload. **Recommendations** Update Grav to version 2.0.2.

**Name of the Vulnerable Software and Affected Versions** Grav versions prior to 2.0.2 **Description** A Twig sandbox bypass allows a page author, specifically any user with `admin.pages` permissions or those capable of writing to `user/pages`, to exfiltrate configuration secrets. While the sandbox attempts to redact the `config` variable and remove `Config::get` and `toArray` from the method allowlist, the actual Config object is still accessible through the allow-listed `grav.offsetGet('config')` method. By using allow-listed object-dumping filters such as `json encode`, `print r`, or `yaml encode`, an attacker can serialize the object at the PHP level, bypassing the sandbox method gate. This exposes the complete configuration tree, including sensitive data like SMTP credentials, API keys, and plugin database credentials. **Recommendations** Update Grav to version 2.0.2 or later.

**Name of the Vulnerable Software and Affected Versions** Composer versions prior to 2.2.29 Composer versions prior to 2.10.2 **Description** Composer, a dependency manager for the PHP language, fails to correctly validate package names from untrusted repositories other than Packagist.org or Private Packagist. This allows a maliciously crafted package to cause the application to write attacker-controlled files outside the vendor directory and outside the project during install or update operations. **Recommendations** Update to version 2.2.29 or later. Update to version 2.10.2 or later.

**Name of the Vulnerable Software and Affected Versions** Composer versions prior to 2.2.29 Composer versions prior to 2.10.2 **Description** When run with -vvv debug verbosity, the software may print credentials embedded in the username slot of a repository or package URL (for example, a GitHub Personal Access Token in https://TOKEN@host/) to the debug output. This occurs because the `AuthHelper`, `Url::sanitize`, and `ProcessExecutor` functions do not sanitize username-only URL credentials. **Recommendations** Update to version 2.2.29 or later. Update to version 2.10.2 or later.

**Name of the Vulnerable Software and Affected Versions** Composer versions prior to 2.2.29 Composer versions prior to 2.10.2 **Description** A flaw in the binary installation flow allows a package bin entry containing `..` path segments to resolve outside the package installation directory. This can lead to the system changing the permissions of an existing host file to world-readable and world-executable modes during the execution of composer install, update, or require operations. **Recommendations** Update to version 2.2.29 or later. Update to version 2.10.2 or later.

**Name of the Vulnerable Software and Affected Versions** guzzlehttp/psr7 versions prior to 2.12.1 **Description** guzzlehttp/psr7 fails to reject Carriage Return (CR) and Line Feed (LF) characters in specific HTTP start-line fields, including the request method, protocol version, and response reason phrase. This occurs when attacker-controlled data is placed in these fields and subsequently serialized as raw HTTP/1.x using functions such as `Message::toString()` or equivalent serializers. The issue can also be triggered via `Message::parseRequest()` or `Message::parseResponse()` when malformed raw messages are parsed into PSR-7 objects and then re-serialized. For exploitation to occur, the malformed message must be serialized and processed by software that does not independently reject malformed start lines. This may lead to header injection, response splitting, request smuggling, or cache poisoning. Applications using standard Guzzle HTTP client APIs are not expected to be affected; the risk is higher for those manually serializing messages, forwarding raw HTTP, or implementing custom transports, proxying, and webhooks. **Recommendations** Update to version 2.12.1 or later. As a temporary workaround, reject CR/LF characters in untrusted method, protocol version, and reason phrase values before constructing or modifying PSR-7 messages. Validate the raw start line before calling `Message::parseRequest()` or `Message::parseResponse()` and avoid reparsing untrusted raw messages. Validate `REQUEST METHOD` and `SERVER PROTOCOL` before calling `ServerRequest::fromGlobals()` if the application operates with attacker-controlled synthetic `$ SERVER` values.

**Name of the Vulnerable Software and Affected Versions** Guzzle versions prior to 7.12.1 **Description** CookieJar incorrectly accepts cookies with a dot-only `Domain` attribute (such as `Domain=.`, `Domain=..`, `Domain=...`) and whitespace-padded variants. The `SetCookie::matchesDomain()` function removes leading dots, normalizing dot-only values to an empty string. Because `SetCookie::validate()` only rejected strictly empty domains, these cookies were stored and the empty normalized domain was treated as matching any request host. An attacker-controlled origin requested by an application using a shared cookie jar can set a cookie that is subsequently sent to unrelated hosts. This can lead to cookie injection or session fixation against downstream services. This issue affects applications using Guzzle's cookie support, such as `new Client(['cookies' => true])` or an explicit shared `CookieJar`, when the same jar is reused across attacker-controlled and trusted origins. **Recommendations** Update to version 7.12.1 or later. As a temporary workaround, do not reuse the same `CookieJar` instance across untrusted and trusted origins. Use separate cookie jars per origin or trust boundary. Disable cookie handling for requests to untrusted hosts. Avoid using `new Client(['cookies' => true])` for clients that may contact unrelated hosts with different trust levels.