Kq5Y

**Nome do Software Vulnerável e Versões Afetadas** multiparty versões 4.2.3 e anteriores **Description** Ocorre uma negação de serviço quando uma requisição multipart/form-data é enviada com um nome de campo que colide com uma propriedade herdada do Object.prototype, como ` proto `, `constructor` ou `toString`. Isso faz com que o analisador invoque a função `.push()` no valor do protótipo herdado em vez de um array, resultando em um TypeError que gera uma exceção não capturada e interrompe o processo. Este problema afeta qualquer serviço que aceite uploads multipart via multiparty. **Recommendations** Atualize para a versão 4.3.0 ou superior.

**Nome do Software Vulnerável e Versões Afetadas** Mistune versões 3.0.0a1 até 3.2.0 **Descrição** Existe uma vulnerabilidade de Negação de Serviço por Expressão Regular (ReDoS) na expressão regular `LINK TITLE RE`. Um invasor pode fornecer Markdown especialmente elaborado para processamento que desencadeia um retrocesso catastrófico (catastrophic backtracking), levando a uma complexidade de tempo exponencial O(2^N) e consumo significativo de CPU. Isso ocorre porque a expressão regular usada para analisar títulos de links contém alternativas sobrepostas tanto nos ramos de aspas duplas quanto nos de aspas simples; especificamente, uma barra invertida seguida de pontuação pode ser interpretada como uma sequência de escape ou como dois caracteres comuns. Essa ambiguidade é acessível através do processamento normal de Markdown de links inline via `parse link()` e `parse link title()`, bem como definições de referência de link de bloco via `BlockParser.parse ref link()` e `parse link title()`. Uma entrada pequena, como um documento com menos de 100 bytes contendo sequências repetidas de barra invertida e ponto de exclamação sem aspas de fechamento, pode tornar as aplicações inoperantes. **Recomendações** Para as versões 3.0.0a1 até 3.2.0, exclua o caractere de barra invertida da classe de caracteres genérica na expressão regular `LINK TITLE RE` para eliminar a sobreposição de alternância.

**Nome do Software Vulnerável e Versões Afetadas** mise versões 2026.2.18 através de 2026.4.5 **Descrição** mise carrega incorretamente as configurações de controle de confiança de um arquivo `.mise.toml` de projeto local antes de executar as verificações de confiança. Isso permite que um invasor que possa colocar um arquivo `.mise.toml` malicioso em um repositório o faça parecer confiável e, em seguida, execute diretivas perigosas como `[env] .source`, templates, hooks ou tarefas. A vulnerabilidade decorre do carregamento de arquivos de configurações locais sem verificar inicialmente sua confiabilidade. Especificamente, a configuração `trusted config paths`, quando definida como '/', permite que qualquer caminho absoluto seja considerado confiável. Isso ignora as medidas de segurança pretendidas. Um problema relacionado permite que as configurações locais `yes = true` ou `ci = true` aprovem automaticamente os prompts de confiança nas versões 2026.2.18 e posteriores, embora o vetor de exploração principal envolva a configuração `trusted config paths`. Uma prova de conceito demonstra que definir `trusted config paths = ["/"]` em um arquivo `.mise.toml` permite a execução de um script controlado por um invasor por meio de `mise hook-env`. **Recomendações** Não honre as configurações de controle de confiança de arquivos de configuração de projeto não globais. Especificamente, ignore os campos `trusted config paths`, `yes`, `ci` e `paranoid` ao carregar arquivos de configuração de projeto locais.

Nome do Software Vulnerável e Versões Afetadas Vite versões 7.1.0 até 7.3.1 e 8.0.0 até 8.0.4 Descrição Vite, um framework de ferramentas frontend para JavaScript, permite a recuperação de arquivos bloqueados por `server.fs.deny` (como arquivos .env e *.crt) com respostas HTTP 200 quando parâmetros de consulta específicos como ?raw, ?import&raw ou ?import&url&inline são anexados à solicitação. Isso ocorre quando o servidor de desenvolvimento Vite é exposto à rede e arquivos confidenciais são permitidos por `server.fs.allow` e negados por `server.fs.deny`. Recomendações As versões 7.1.0 até 7.3.1 do Vite devem ser atualizadas para a versão 7.3.2 ou posterior. As versões 8.0.0 até 8.0.4 do Vite devem ser atualizadas para a versão 8.0.5 ou posterior.

Nome do Software Vulnerável e Versões Afetadas Tinyauth versões anteriores a 5.0.5 Descrição Tinyauth é um servidor de autenticação e autorização. As implementações GenericOAuthService, GithubOAuthService e GoogleOAuthService armazenam verificadores PKCE e tokens de acesso como campos de estrutura mutáveis em instâncias singleton compartilhadas entre solicitações concorrentes. Uma condição de corrida entre `VerifyCode()` e `Userinfo()` permite que um usuário receba uma sessão com a identidade de outro usuário quando dois usuários iniciam o login OAuth para o mesmo provedor simultaneamente. A função `OAuthBrokerService.GetService()` retorna uma única instância compartilhada por provedor para cada solicitação. O fluxo OAuth armazena o estado intermediário como campos de estrutura neste singleton. Especificamente, os campos `token` e `verifier` são campos mutáveis compartilhados. No manipulador de retorno de chamada, a função `VerifyCode()` armazena o token no singleton e uma chamada subsequente para `GetUser()` lê o token do singleton. Entre essas chamadas, a função `VerifyCode()` de uma solicitação concorrente pode sobrescrever o campo `token`, fazendo com que `GetUser()` e `Userinfo()` recuperem as declarações de identidade do usuário incorreto. Essa questão também causa uma negação de serviço devido a sobrescritas de verificadores PKCE, levando a falhas nos logins OAuth. Recomendações Atualize o Tinyauth para a versão 5.0.5 ou posterior.

**Name of the Vulnerable Software and Affected Versions** go-git versions 5.0.0 through 5.17.0 **Description** A crafted `.idx` file can cause asymmetric memory consumption, potentially exhausting available memory and resulting in a denial-of-service (DoS) condition. Exploitation requires write access to the local repository's `.git` directory to create or alter existing `.idx` files. **Recommendations** Upgrade to version 5.17.1 or later.

**Name of the Vulnerable Software and Affected Versions** go-git versions prior to 5.17.1 **Description** The `go-git` library’s index decoder for Git index format version 4 does not properly validate the path name prefix length before applying it to the previously decoded path name. A specially crafted index file can cause an out-of-bounds slice operation, leading to a runtime panic during index parsing. This issue only affects Git index format version 4. An attacker with the ability to modify or inject a Git index file within a local repository can cause applications using `go-git` to terminate, resulting in a denial-of-service (DoS) condition. **Recommendations** Upgrade to version 5.17.1, or the latest version 6.

**Name of the Vulnerable Software and Affected Versions** `yaml` versions prior to 1.10.3 `yaml` versions prior to 2.8.3 **Description** The `yaml` library is susceptible to a stack overflow when parsing YAML documents. The issue occurs during the node resolution/composition phase, which uses recursive function calls without a depth limit. An attacker providing malicious YAML input, approximately 2–10 KB in size, can trigger a `RangeError: Maximum call stack size exceeded`. This error is not a `YAMLParseError`, potentially leading to unexpected exceptions in applications that only handle YAML-specific errors. The impact can range from request failures to the termination of the Node.js process. Flow sequences, with their minimal byte overhead per nesting level, facilitate deep nesting and exacerbate the problem. The library's `Parser` (CST phase) is not affected, as it employs an iterative, stack-based approach. The affected APIs include `YAML.parse()`, `YAML.parseDocument()`, and `YAML.parseAllDocuments()`. **Recommendations** Versions prior to 1.10.3: Upgrade to version 1.10.3 or later. Versions prior to 2.8.3: Upgrade to version 2.8.3 or later.

**Name of the Vulnerable Software and Affected Versions** FileRise versions 1.0.1 through 3.9.9 **Description** FileRise is a self-hosted web file manager and WebDAV server. The `resumableIdentifier` parameter within the Resumable.js chunked upload handler, specifically the `UploadModel::handleUpload()` function, is directly incorporated into filesystem paths without proper sanitization. An authenticated user possessing upload privileges can leverage this to write files to arbitrary directories on the server, delete directories, and determine the existence of files and directories. The issue is addressed in version 3.10.0. **Recommendations** Update to version 3.10.0 or later.

**Name of the Vulnerable Software and Affected Versions** tinytag versions 2.2.0 **Description** tinytag version 2.2.0 contains an issue where an attacker who can supply MP3 files for parsing can trigger a non-terminating loop while the library parses an ID3v2 SYLT (synchronized lyrics) frame. In server-side deployments that automatically parse attacker-supplied files, a single 498-byte MP3 can cause the parsing operation to stop making progress and remain busy until the worker or process is terminated. The root cause is that ` parse synced lyrics` assumes ` find string end pos` always returns a position greater than the current offset, which is false when no string terminator is present in the remaining frame content. The vulnerable call path involves `TinyTag.get`, ` load`, ` parse tag`, ` parse id3v2`, ` parse frame`, ` parse synced lyrics`, and ` find string end pos`. The `SYLT` parsing support was introduced in version 2.2.0. **Recommendations** Update to version 2.2.1 or later to resolve this issue.

**Name of the Vulnerable Software and Affected Versions** Dasel versions 3.0.0 through 3.3.1 **Description** Dasel’s YAML reader is susceptible to excessive CPU and memory consumption when processing YAML data supplied by an attacker. This occurs because the library’s `UnmarshalYAML` implementation recursively resolves YAML alias nodes without any expansion limit, bypassing the built-in alias expansion limit present in go-yaml v4. A relatively small 342-byte payload can trigger this issue, leading to denial of service. The issue resides in the `UnmarshalYAML` function, which handles alias nodes by recursively following `yaml.Node.Alias` pointers without a defined expansion budget. This allows an attacker to create a YAML document with deeply nested aliases, causing unbounded resource growth during parsing. The root cause is that Dasel receives a compact Node tree and then re-expands aliases without a limit, unlike go-yaml v4’s `Unmarshal` function which tracks alias expansion count. **Recommendations** Versions prior to 3.3.2 are affected. Update to version 3.3.2 or later to resolve the issue.