Albinowax

**Name of the Vulnerable Software and Affected Versions** Devise versions prior to 5.0.3 **Description** Devise, an authentication solution for Rails based on Warden, contains a flaw in its Confirmable module. A race condition can occur when the `reconfirmable` option is enabled, allowing an attacker to confirm an email address they do not own. This happens by desynchronizing the `confirmation token` and `unconfirmed email` fields through concurrent email change requests. The `confirmation token` is sent to an attacker-controlled email, while the `unconfirmed email` in the database points to a victim's email address. Using the token then confirms the victim's email on the attacker's account. The vulnerable component is the `Confirmable` module. The vulnerable method is `postpone email change until confirmation and regenerate confirmation token()`. **Recommendations** Versions prior to 5.0.3 should be upgraded to version 5.0.3 or later. As a workaround, applications can override the `postpone email change until confirmation and regenerate confirmation token` method from Devise models to force `unconfirmed email` to be persisted when unchanged. For applications using Mongoid, implement a workaround similar to Devise by setting `changed attributes["unconfirmed email"] = nil` to ensure the attribute is persisted.

**Name of the Vulnerable Software and Affected Versions** Camaleon CMS versions 2.7.0 through 2.7.3 **Description** The issue is related to a Server-Side Template Injection (SSTI) vulnerability. It occurs via the `formats` parameter. There is no information provided about the estimated number of potentially affected devices worldwide or details about real-world incidents where this issue was exploited. **Recommendations** For Camaleon CMS versions 2.7.0 through 2.7.3, update to version 2.7.4 or later to resolve the issue. As a temporary workaround, consider restricting access to the `formats` parameter until a patch is available.

**Name of the Vulnerable Software and Affected Versions** HTTP::Daemon versions prior to 6.15 **Description** The issue is related to inconsistent interpretation of HTTP requests when handling `Content-Length` values, potentially allowing a remote attacker to gain privileged access to APIs or poison intermediate caches by sending specially crafted HTTP requests. This could lead to HTTP request smuggling attacks, enabling an attacker to bypass web application firewall protection and conduct XSS attacks. The library is commonly used for local development and tests, and most Perl-based applications are served on top of Nginx or Apache. **Recommendations** For versions prior to 6.15, update to version 6.15 or later to resolve the issue. As a temporary workaround for users unable to upgrade, add additional request handling logic by inspecting the returned `HTTP::Request` object after calling `my $rqst = $conn->get request()`, and querying the `Content-Length` header (`my $cl = $rqst->header('Content-Length')`) to detect any abnormalities that should be dealt with by a `400` response. Expected strings of `Content-Length` should consist of either a single non-negative integer or a comma-separated repetition of that number. Anything else should be rejected.

Name of the Vulnerable Software and Affected Versions: hyper versions 0.12.0 through 0.13.9 hyper versions 0.14.0 through 0.14.2 Description: The HTTP server code in hyper has a flaw that incorrectly understands some requests with multiple transfer-encoding headers to have a chunked payload, when it should have been rejected as illegal. This combined with an upstream HTTP proxy that understands the request payload boundary differently can result in "request smuggling" or "desync attacks". To determine if vulnerable, all these things must be true: using hyper as an HTTP server, using HTTP/1.1, and using a vulnerable HTTP proxy upstream to hyper. If an upstream proxy correctly rejects the illegal transfer-encoding headers, the desync attack cannot succeed. If there is no proxy upstream of hyper, hyper cannot start the desync attack, as the client will repair the headers before forwarding. Recommendations: For hyper versions 0.12.0 through 0.13.9, update to version 0.13.10 or later. For hyper versions 0.14.0 through 0.14.2, update to version 0.14.3 or later. As a temporary workaround, consider rejecting requests that contain a `transfer-encoding` header. Alternatively, ensure any upstream proxy handles `transfer-encoding` correctly.