Jakub Witczak

#2670de 53,635
93.9CVSS total
Vulnerabilidades · 15
Baixa
1
Média
9
Alta
5
PT-2026-48463
6.5
2026-06-10
Unknown · Erlang/Otp · CVE-2026-48855
**Nome do Software Vulnerável e Versões Afetadas** Erlang OTP versões 17.0 até 29.0.1 Erlang OTP versões anteriores a 28.5.0.2 Erlang OTP versões anteriores a 27.3.4.13 **Description** Um problema no módulo `ssh sftpd` permite a descoberta de arquivos através da exposição de informações sensíveis. O manipulador `SSH FXP READLINK` envia o resultado bruto da função `file:read link/2` para o cliente sem utilizar `chroot filename/2` para remover o prefixo da raiz do backend. Consequentemente, um cliente SFTP autenticado pode criar um link simbólico dentro do chroot apontando para `/`, e a leitura desse link via `SSH FXP READLINK` retorna o caminho absoluto da raiz do backend (ex: `/data/sftp`) em vez do valor chrooted `/`. Isso expõe o caminho absoluto do sistema de arquivos do diretório raiz do SFTP e de quaisquer alvos de links simbólicos dentro dele, embora o conteúdo de arquivos, credenciais e caminhos fora do diretório raiz permaneçam inacessíveis. Este problema está associado ao arquivo `lib/ssh/src/ssh sftpd.erl` e requer que o subsistema SFTP esteja habilitado com a opção `root` configurada na chamada `ssh sftpd:subsystem spec/1`. **Recommendations** Atualize o Erlang OTP para a versão 29.0.2 ou posterior. Atualize o Erlang OTP para a versão 28.5.0.2 ou posterior. Atualize o Erlang OTP para a versão 27.3.4.13 ou posterior. Utilize chroot ao nível do sistema operacional para executar a VM Erlang ou o processo do servidor SFTP em um ambiente de sistema de arquivos isolado. Garanta que a porta do servidor SFTP não esteja acessível a partir de máquinas não confiáveis. Certifique-se de que nenhuma informação sensível possa ser inferida a partir do caminho absoluto do diretório raiz configurado.
PT-2026-44041
8.1
2026-05-27
Unknown · Erlang/Otp · CVE-2026-42790
**Nome do Software Vulnerável e Versões Afetadas** Erlang OTP versões 19.3 até 26.2.5.20 Erlang OTP versões 26.2.5.21 até 27.3.4.11 Erlang OTP versões 27.3.4.12 até 28.5.0.0 Erlang OTP versões 28.5.0.1 até 29.0.0 public key versões 1.4 até 1.15.1.6 public key versões 1.15.1.7 até 1.17.1.2 public key versões 1.17.1.3 até 1.20.3.0 public key versões 1.20.3.1 até 1.21.0 **Description** A validação inadequada de certificados nos módulos `pubkey cert` e `public key` permite a evasão de nameConstraints de DNS durante a verificação de nome de host TLS. Isso ocorre porque a função `pubkey cert:validate names/6` verifica apenas as entradas de DNS do Subject Alternative Name (SAN) em relação às nameConstraints, o que significa que certificados sem um SAN satisfazem trivialmente as restrições de DNS permitidas. Simultaneamente, a função `public key:pkix verify hostname/3` recorre ao CommonName do assunto quando nenhum SAN está presente, comparando-o com o nome de host de referência. Essa combinação permite que uma CA subordinada com nameConstraints de DNS restritas emita um certificado final que um cliente TLS OTP aceita para um nome de host fora de escopo. Essa evasão é acessível via `ssl:connect` utilizando `verify peer`, uma CA confiável, SNI e o correspondente de nome de host https estrito. **Recommendations** Atualize o Erlang OTP para a versão 26.2.5.21, 27.3.4.12, 28.5.0.1 ou 29.0.1, dependendo da ramificação de lançamento atual. Atualize o public key para a versão 1.15.1.7, 1.17.1.3, 1.20.3.1 ou 1.21.1, dependendo da ramificação de lançamento atual. Utilize a opção `verify fun` no aplicativo ssl para garantir que as conexões TLS falhem se o certificado da entidade final não possuir a extensão subjectAltName ou um nome de domínio, assegurando que a `verify fun` não aceite o erro `name not permitted`.
PT-2026-43713
6.3
2026-05-27
Unknown · Erlang/Otp · CVE-2026-42791
**Nome do Software Vulnerável e Versões Afetadas** Erlang OTP versões 27.0 até 27.3.4.11 Erlang OTP versões anteriores a 28.5.0.1 Erlang OTP versões anteriores a 29.0.1 public key versões 1.16 até 1.17.1.2 public key versões anteriores a 1.20.3.1 public key versões anteriores a 1.21.1 **Description** A Validação Imprópria de Certificado no módulo `pubkey ocsp` do `public key` do Erlang OTP permite que respostas forjadas do Online Certificate Status Protocol (OCSP), assinadas com um certificado de respondedor expirado, sejam aceitas como válidas. As funções `verify response/5` e `is authorized responder/3` não verificam o período de validade (`notBefore`/`notAfter`) do certificado do respondedor OCSP. Um invasor que possua a chave privada de um certificado de respondedor OCSP designado pela CA e expirado pode forjar respostas que o sistema aceita. Isso afeta clientes TLS que utilizam OCSP stapling via aplicação `ssl`, permitindo que um servidor comprometido apresente um certificado TLS revogado como válido. Também afeta aplicações que chamam diretamente a função `pkix ocsp validate/5`, o que pode levar ao bypass de autenticação durante a validação de certificado de cliente no lado do servidor. **Recommendations** Atualize o Erlang OTP para a versão 27.3.4.12, 28.5.0.1 ou 29.0.1. Atualize o public key para a versão 1.17.1.3, 1.20.3.1 ou 1.21.1. Para clientes TLS que utilizam a aplicação `ssl`, desative o OCSP stapling definindo `{stapling, no staple}` nas opções do cliente ou alterne para a verificação de revogação baseada em CRL com `{crl check, true}`. Para aplicações que chamam `pkix ocsp validate/5` diretamente, valide o período de validade do certificado do respondedor no código da aplicação antes de chamar a função.
PT-2026-43712
7.0
2026-05-27
Unknown · Erlang/Otp · CVE-2026-42789
**Nome do Software Vulnerável e Versões Afetadas** Erlang OTP versões 17.0 até 26.2.5.20 Erlang OTP versões 27.x anteriores a 27.3.4.12 Erlang OTP versões 28.x anteriores a 28.5.0.1 Erlang OTP versões 29.x anteriores a 29.0.1 public key versões 0.22 até 1.15.1.6 public key versões 1.17.x anteriores a 1.17.1.3 public key versões 1.20.x anteriores a 1.20.3.1 public key versões 1.21.x anteriores a 1.21.1 **Description** O acompanhamento inadequado da cadeia de confiança de um certificado no módulo `pubkey cert` permite que um certificado não-CA seja aceito como um emissor intermediário, possibilitando a falsificação da cadeia de certificados. A função `pubkey cert:validate extensions/7` contém falhas onde um certificado com `basicConstraints` definido como `cA:false` e sem a extensão `keyUsage` pode ser usado como emissor intermediário em uma cadeia passada para `public key:pkix path validation/3`. Isso ocorre porque a cláusula `cA:false` não rejeita o certificado quando ele está na posição de emissor, e a verificação de `keyUsage` é ignorada se a extensão estiver totalmente ausente. Consequentemente, um invasor com um certificado de entidade final emitido por uma CA confiável pode assinar certificados folha falsificados para identidades arbitrárias. Isso afeta todos os endpoints TLS ou mTLS construídos na aplicação ssl do OTP que utilizam o verificador padrão, incluindo a verificação de identidade do servidor no lado do cliente e a verificação de certificado do cliente em servidores mTLS. **Recommendations** Atualize o Erlang OTP para a versão 26.2.5.21, 27.3.4.12, 28.5.0.1 ou 29.0.1, dependendo do ramo de lançamento atual. Atualize o public key para a versão 1.15.1.7, 1.17.1.3, 1.20.3.1 ou 1.21.1, dependendo do ramo de lançamento atual. Utilize a opção `verify fun` na aplicação ssl ou public key para garantir que a validação do caminho rejeite cadeias onde um certificado intermediário não possua `basicConstraints cA:true`.
PT-2026-33930
5.3
2026-04-21
Unknown · Erlang/Otp · CVE-2026-32147
**Name of the Vulnerable Software and Affected Versions** Erlang OTP versões 17.0 até 28.4.3 Erlang OTP versões 17.0 até 27.3.4.11 Erlang OTP versões 17.0 até 26.2.5.20 **Description** Uma falha de path traversal no módulo `ssh sftpd` do Erlang OTP ssh permite que um usuário SFTP autenticado modifique atributos de arquivos fora do diretório chroot configurado. O daemon SFTP armazena o caminho bruto fornecido pelo usuário em handles de arquivo em vez do caminho resolvido pelo chroot. Quando o `SSH FXP FSETSTAT` é emitido em tal handle, os atributos do arquivo (permissões, propriedade, timestamps) são modificados no caminho real do sistema de arquivos, ignorando completamente o limite do diretório raiz. Isso requer que o servidor esteja configurado com a opção root e que o arquivo alvo exista no sistema de arquivos real no mesmo caminho relativo. Esta falha permite apenas a modificação de atributos de arquivos; o conteúdo dos arquivos não pode ser lido ou alterado. Se o daemon SSH for executado como root, um invasor pode obter escalonamento de privilégios ao definir o bit setuid em binários, alterar a propriedade de arquivos sensíveis ou tornar configurações do sistema graváveis por qualquer usuário. O problema está associado ao arquivo `lib/ssh/src/ssh sftpd.erl` e às funções `ssh sftpd:do open/4` e `ssh sftpd:handle op/4`. **Recommendations** Atualize o Erlang OTP para uma versão posterior a 28.4.3, 27.3.4.11 ou 26.2.5.20, dependendo do ramo de lançamento. Não utilize a opção root em `ssh sftpd:subsystem spec/1` e, em vez disso, utilize chroot em nível de SO ou isolamento de container para confinar usuários SFTP. Certifique-se de que a VM Erlang não esteja sendo executada como um usuário de SO privilegiado para limitar o impacto das modificações de atributos.
PT-2026-30815
7.6
2026-04-07
Erlang · Public Key · CVE-2026-32144
**Nome do Software Vulnerável e Versões Afetadas** Erlang OTP versões 27.0 até 28.4.2 e 27.3.4.10 public key versões 1.16 até 1.20.3 e 1.17.1.2 ssl versões 11.2 até 11.5.4 e 11.2.12.7 **Descrição** Existe uma falha no public key (módulo pubkey ocsp) do Erlang OTP relacionada à validação inadequada de certificados. Especificamente, o processo de validação da resposta OCSP não verifica a assinatura criptográfica dos certificados de respondedores designados pela CA, confiando apenas na correspondência do nome do emissor e no uso estendido OCSPSigning. Isso permite que um invasor falsifique respostas OCSP, marcando potencialmente certificados revogados como válidos. Isso afeta os clientes SSL/TLS que usam OCSP stapling e aplicativos que usam diretamente a API `public key:pkix ocsp validate/5`. O código vulnerável está localizado nos arquivos lib/public key/src/pubkey ocsp.erl e nas rotinas de programa `pubkey ocsp:is authorized responder/3`. **Recomendações** Para usuários SSL: Não habilite a configuração de validação OCSP (o padrão atual é {stapling, no staple}) Use a verificação de revogação baseada em CRL definindo a opção SSL {crl check, true} em vez disso Para aplicativos que usam `public key:pkix ocsp validate/5` diretamente: Passe a opção {is trusted responder fun, Fun} com uma função que valide os certificados de respondedores confiáveis Restrinja o acesso do respondedor OCSP a endpoints confiáveis por meio de controles de rede