Alessio Della Libera

O problema decorre da verificação ou tratamento inadequado de condições excepcionais, devido à não verificação do comprimento dos dados de origem. A criação de um novo `twain.TwainSDK` com uma propriedade `productName`, `productFamily`, `manufacturer` ou `version.info` com comprimento >= 34 caracteres leva a um estouro de buffer.

O problema decorre da validação inadequada do índice da matriz quando `frameSize` é passado para as funções `new OpusDecoder().decode` ou `new OpusDecoder().decodeFloat`, uma vez que não é verificado se há valores negativos. Isso pode levar à falha do processo.

O problema está relacionado ao fornecimento de tipos de entrada inesperados a várias funções diferentes, o que pode levar à falha do processo devido ao acionamento de uma macro de verificação. Especificamente, o fornecimento de certos valores inteiros, como 0, à função `size` pode resultar em um erro de falha de segmentação, causando a falha do processo.

O problema está relacionado a uma condição de Negação de Serviço (DoS) que pode ocorrer quando a propriedade `channels` do objeto `Speaker` recebe tipos de entrada inesperados, levando à ativação de uma macro de assert e potencialmente causando a falha do processo.

O problema decorre de um cálculo incorreto do comprimento da memória no pacote node-stringbuilder, levando a uma leitura fora dos limites. Isso ocorre quando métodos como `ToBuffer`, `ToString` ou `CharAt` são chamados em um objeto `StringBuilder` com um valor de string não vazio como entrada. O fornecimento de índices negativos pode resultar na devolução de memória previamente alocada, levando a uma divulgação de informações.

O problema está relacionado a uma condição de Negação de Serviço (DoS) que pode ocorrer quando um objeto de entrada com a propriedade `toString` é fornecido a várias funções diferentes. Isso pode levar à falha do sistema ou do processo.

Nome do software vulnerável e versões afetadas: versões do go-getter anteriores à 1.7.4 o ramo e o pacote go-getter/v2 não foram afetados Descrição: A biblioteca go-getter está vulnerável à injeção de argumentos ao executar o Git para descobrir ramos remotos. Um invasor pode formatar uma URL do Git para injetar argumentos adicionais na chamada do Git. Isso pode ocorrer quando o go-getter está realizando uma operação do Git e tenta clonar o repositório especificado, verificando a referência HEAD do repositório remoto em seu ramo padrão, passando argumentos para o binário do Git no host em que está sendo executado. Recomendações: Para versões do go-getter anteriores à 1.7.4, atualize para a versão 1.7.4 ou posterior para resolver o problema. Como solução temporária, considere restringir o uso de URLs do Git que possam ser usadas para injetar argumentos adicionais do Git até que um patch esteja disponível. Os usuários da biblioteca go-getter devem avaliar o risco associado a essas questões no contexto de seu uso do go-getter.

The issue arises when untrusted user input is used to build header values, allowing an attacker to inject malicious content by adding carriage return line feeds (`r `) to end the HTTP response headers. This can lead to a potential XSS vulnerability, enabling the attacker to inject additional headers or a new response body.

The issue affects the ithewei/libhv package, where untrusted user input used to set request headers can lead to CRLF Injection. An attacker can inject additional headers into the request by adding carriage return line feeds (`r `) characters.

The issue concerns Cross-site Scripting (XSS) where filenames containing malicious payloads are not properly sanitized when rendered. This occurs when a file with such a name is served by the application.

The issue concerns HTTP Response Splitting when untrusted user input is used to build header values. Header values are not properly sanitized against CRLF Injection in the `set header` and `add header` functions. An attacker can add the `r ` (carriage return line feeds) characters to end the HTTP response headers and inject malicious content.

The issue arises when untrusted user input is used to set request headers in the `addHeader` function, allowing an attacker to inject additional headers by adding `r ` (carriage return line feeds) characters. This enables the injection of extra headers in the request sent.

The issue arises when untrusted user input is used to build header values in the `addHeader` and `addCookie` functions, allowing an attacker to inject malicious content by adding `r ` (carriage return line feeds) characters to end the HTTP response headers. This enables HTTP Response Splitting, where an attacker can manipulate the HTTP response to inject malicious content.

The issue is related to the use of a regular expression with inefficient computational complexity in the semver package, which can lead to a Regular Expression Denial of Service (ReDoS) via the `new Range` function when untrusted user data is provided as a range. This can allow a remote attacker to cause a denial of service.

The issue is related to Cross-site Scripting (XSS) due to improper user input sanitization in the `themes.NoPage(filename, theme)` function. This can be exploited when a file or resource is not found.

The issue is related to the incomplete fix for a previous problem, which allows an attacker to inject arbitrary HTTP headers when untrusted user input is used to set the content-type header in HTTP requests, such as .Patch, .Post, .Put, and .Delete. This can lead to logical errors and other misbehaviors. The vulnerability is due to the lack of measures to neutralize CRLF sequences.

The issue is related to Regular Expression Denial of Service (ReDoS) due to the `upgradeWebSocket` function, which contains regexes in the form of `/s*,s*/`, used for splitting the `Connection/Upgrade` header. A specially crafted `Connection/Upgrade` header can be used to significantly slow down a web socket server.

A program using FoundationNetworking in swift-corelibs-foundation is potentially vulnerable to CRLF injection in URLRequest headers. This allows a client to insert one or several CRLF sequences into a URLRequest header value, which can be interpreted by the server as extra headers or even a second request. For example, a URLRequest to "http://example.com/" with the GET method and a header "Foo" set to "Bar Extra-Header: Added GET /other HTTP/1.1" can appear to the server as two requests. This vulnerability escalates if un-sanitized user input is placed in header values, allowing a malicious user to inject new headers or requests to an intermediary or backend server.

The issue is related to insufficient validation of HTTP header field values before sending them to the network, allowing attackers to inject new HTTP header fields or entirely new requests into the data stream. This can cause requests to be understood differently by the remote server than intended, potentially resulting in logical errors and other misbehaviors. Users are vulnerable if they pass untrusted data into HTTP header field values without prior sanitization, such as placing usernames from a database into HTTP header fields.

O problema ocorre quando um servidor HTTP/1.1 aceita entradas geradas pelo usuário a partir de uma solicitação recebida e as reflete em um cabeçalho de resposta HTTP/1.1. Um usuário mal-intencionado pode adicionar novas linhas à sua entrada e “injetar” essas novas linhas na resposta HTTP retornada, permitindo-lhe contornar cabeçalhos de segurança e cabeçalhos de enquadramento HTTP/1.1. Isso pode levar a XSS, envenenamento de cache e outras falhas.