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.

**Nome do software vulnerável e versões afetadas** Versões do HTTP::Daemon anteriores à 6.15 **Descrição** O problema está relacionado à interpretação inconsistente de solicitações HTTP ao lidar com valores de `Content-Length`, o que pode permitir que um invasor remoto obtenha acesso privilegiado a APIs ou corrompa caches intermediários enviando solicitações HTTP especialmente criadas. Isso poderia levar a ataques de contrabando de solicitações HTTP, permitindo que um invasor contorne a proteção do firewall de aplicativos web e realize ataques XSS. A biblioteca é comumente usada para desenvolvimento e testes locais, e a maioria dos aplicativos baseados em Perl é servida sobre o Nginx ou o Apache. **Recomendações** Para versões anteriores à 6.15, atualize para a versão 6.15 ou posterior para resolver o problema. Como solução temporária para usuários que não podem atualizar, adicione lógica adicional de tratamento de solicitações inspecionando o objeto `HTTP::Request` retornado após chamar `my $rqst = $conn->get request()` e consultando o cabeçalho `Content-Length` (`my $cl = $rqst->header(‘Content-Length’)`) para detectar quaisquer anomalias que devam ser tratadas com uma resposta `400`. As strings esperadas de `Content-Length` devem consistir em um único inteiro não negativo ou em uma repetição desse número separada por vírgulas. Qualquer outra coisa deve ser rejeitada.

**Nome do software vulnerável e versões afetadas: hyper versões 0.12.0 a 0.13.9 hyper versões 0.14.0 a 0.14.2 Descrição: O código do servidor HTTP no hyper apresenta uma falha que interpreta incorretamente algumas solicitações com múltiplos cabeçalhos de codificação de transferência como tendo uma carga fragmentada, quando na verdade deveriam ter sido rejeitadas por serem inválidas. Isso, combinado com um proxy HTTP upstream que interpreta o limite da carga útil da solicitação de maneira diferente, pode resultar em “contrabando de solicitações” ou “ataques de dessincronização”. Para determinar se há vulnerabilidade, todas estas condições devem ser verdadeiras: uso do hyper como servidor HTTP, uso de HTTP/1.1 e uso de um proxy HTTP vulnerável upstream do hyper. Se um proxy upstream rejeitar corretamente os cabeçalhos de codificação de transferência ilegais, o ataque de dessincronização não poderá ser bem-sucedido. Se não houver proxy upstream do hyper, o hyper não poderá iniciar o ataque de dessincronização, pois o cliente reparará os cabeçalhos antes do encaminhamento. Recomendações: Para as versões 0.12.0 a 0.13.9 do hyper, atualize para a versão 0.13.10 ou posterior. Para as versões do hyper 0.14.0 a 0.14.2, atualize para a versão 0.14.3 ou posterior. Como solução temporária, considere rejeitar solicitações que contenham um cabeçalho `transfer-encoding`. Como alternativa, certifique-se de que qualquer proxy upstream lide com `transfer-encoding` corretamente.