John Downey

#5853of 53,633
46.1Total CVSS
Vulnerabilities · 6
Medium
1
High
5
PT-2026-43712
7.0
2026-05-27
Unknown · Erlang/Otp · CVE-2026-42789
**Name of the Vulnerable Software and Affected Versions** Erlang OTP versions 17.0 through 26.2.5.20 Erlang OTP versions 27.x prior to 27.3.4.12 Erlang OTP versions 28.x prior to 28.5.0.1 Erlang OTP versions 29.x prior to 29.0.1 public key versions 0.22 through 1.15.1.6 public key versions 1.17.x prior to 1.17.1.3 public key versions 1.20.x prior to 1.20.3.1 public key versions 1.21.x prior to 1.21.1 **Description** Improper following of a certificate's chain of trust in the `pubkey cert` module allows a non-CA certificate to be accepted as an intermediate issuer, enabling certificate chain forgery. The function `pubkey cert:validate extensions/7` contains flaws where a certificate with `basicConstraints` set to `cA:false` and no `keyUsage` extension can be used as an intermediate issuer in a chain passed to `public key:pkix path validation/3`. This occurs because the `cA:false` clause does not reject the certificate when it is in the issuer position, and the `keyUsage` check is bypassed if the extension is entirely absent. Consequently, an attacker with an end-entity certificate issued by a trusted CA can sign forged leaf certificates for arbitrary identities. This affects all TLS or mTLS endpoints built on the OTP ssl application using the default verifier, including client-side server identity verification and mTLS server client certificate verification. **Recommendations** Update Erlang OTP to version 26.2.5.21, 27.3.4.12, 28.5.0.1, or 29.0.1 depending on the current release branch. Update public key to version 1.15.1.7, 1.17.1.3, 1.20.3.1, or 1.21.1 depending on the current release branch. Use the `verify fun` option in the ssl or public key application to ensure path validation rejects chains where an intermediate certificate lacks `basicConstraints cA:true`.
PT-2026-44041
8.1
2026-05-27
Unknown · Erlang/Otp · CVE-2026-42790
**Name of the Vulnerable Software and Affected Versions** Erlang OTP versions 19.3 through 26.2.5.20 Erlang OTP versions 26.2.5.21 through 27.3.4.11 Erlang OTP versions 27.3.4.12 through 28.5.0.0 Erlang OTP versions 28.5.0.1 through 29.0.0 public key versions 1.4 through 1.15.1.6 public key versions 1.15.1.7 through 1.17.1.2 public key versions 1.17.1.3 through 1.20.3.0 public key versions 1.20.3.1 through 1.21.0 **Description** Improper certificate validation in the `pubkey cert` and `public key` modules allows a DNS nameConstraints bypass during TLS hostname verification. This occurs because `pubkey cert:validate names/6` only checks Subject Alternative Name (SAN) DNS entries against nameConstraints, meaning certificates without a SAN trivially satisfy permitted DNS constraints. Simultaneously, `public key:pkix verify hostname/3` falls back to the subject CommonName when no SAN is present, matching it against the reference hostname. This combination allows a subordinate CA with restricted DNS nameConstraints to issue a leaf certificate that an OTP TLS client accepts for an out-of-scope hostname. This bypass is reachable via `ssl:connect` using `verify peer`, a trusted CA, SNI, and the strict https hostname matcher. **Recommendations** Update Erlang OTP to version 26.2.5.21, 27.3.4.12, 28.5.0.1, or 29.0.1 depending on the current release branch. Update public key to version 1.15.1.7, 1.17.1.3, 1.20.3.1, or 1.21.1 depending on the current release branch. Use the `verify fun` option in the ssl application to ensure TLS connections fail if the end-entity certificate lacks the subjectAltName extension or a domain name, ensuring the `verify fun` does not accept the `name not permitted` error.
PT-2026-33930
5.3
2026-04-21
Unknown · Erlang/Otp · CVE-2026-32147
**Name of the Vulnerable Software and Affected Versions** Erlang OTP versions 17.0 through 28.4.3 Erlang OTP versions 17.0 through 27.3.4.11 Erlang OTP versions 17.0 through 26.2.5.20 **Description** A path traversal issue in the Erlang OTP ssh `ssh sftpd` module allows an authenticated SFTP user to modify file attributes outside the configured chroot directory. The SFTP daemon stores the raw, user-supplied path in file handles instead of the chroot-resolved path. When `SSH FXP FSETSTAT` is issued on such a handle, file attributes like permissions, ownership, and timestamps are modified on the real filesystem path, bypassing the root directory boundary. This requires the server to be configured with the root option and for the target file to exist on the real filesystem at the same relative path. This flaw only allows the modification of file attributes; file contents cannot be read or altered. If the SSH daemon runs as root, an attacker can achieve privilege escalation by setting the setuid bit on binaries, changing ownership of sensitive files, or making system configurations world-writable. The issue is associated with the file `lib/ssh/src/ssh sftpd.erl` and the functions `ssh sftpd:do open/4` and `ssh sftpd:handle op/4`. **Recommendations** Update Erlang OTP to a version later than 28.4.3, 27.3.4.11, or 26.2.5.20 depending on the release branch. Do not use the root option in `ssh sftpd:subsystem spec/1` and instead use OS-level chroot or container isolation to confine SFTP users. Ensure the Erlang VM is not running as a privileged OS user to limit the impact of attribute modifications.