John Downey

Insufficient verification of data authenticity allows an adversary in the middle to substitute forged Hex package contents during dependency resolution. While Gleam fetches package metadata from a signature-verified Hex repository, the `gleam cli::dependencies::lookup package` function makes a subsequent request to an unsigned Hex API via `gleam core::hex::get package release`. The system records the `outer checksum` and dependency names from this unsigned JSON response into `manifest.toml` rather than using the verified metadata. An attacker capable of intercepting TLS traffic with a trusted certificate and modifying both the API response and the repository tarball can provide a forged package archive with a matching checksum. This leads to a loss of integrity as Gleam accepts and extracts the forged contents. This issue specifically affects projects that resolve or update Hex dependencies, such as when a manifest is missing or dependencies are modified.

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.

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.

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`.

Name of the Vulnerable Software and Affected Versions Gleam versions 1.9.0-rc1 through 1.15.3 and 1.16.0-rc1 Description An improper path validation issue exists in the Gleam compiler when handling git dependencies during the dependency download process. Dependency names from `gleam.toml` and `manifest.toml` are used to construct filesystem paths without sufficient validation, allowing attacker-controlled paths (using relative traversal like '../' or absolute paths) to target locations outside the intended dependency directory. This can lead to arbitrary file system modification, including directory deletion and creation, when resolving git dependencies with `gleam deps download`. A malicious git dependency can overwrite arbitrary directories, potentially causing data loss or, in some environments, achieving code execution by overwriting files like git hooks or shell configuration files. Recommendations Avoid using untrusted git dependencies, especially without pinning to a specific commit SHA. Review dependency trees carefully, including transitive git dependencies. Run dependency resolution commands in a restricted or isolated environment (e.g., containers).

gleam-wisp wisp contains a flaw in multipart form body parsing that can lead to a denial of service. The `multipart body` function does not enforce configured limits on body and file sizes. Specifically, when a multipart boundary is missing in a chunk, the parser appends the chunk without updating the quota, leading to an unauthenticated attacker being able to exhaust server resources by sending large multipart form submissions.

A path traversal issue exists in gleam-wisp wisp that allows arbitrary file reading through percent-encoded path traversal. The `wisp.serve static` function is susceptible because sanitization occurs before percent-decoding. The encoded sequence `%2e%2e` bypasses string replacement and is then converted to `..` by `uri.percent decode`, enabling directory traversal when the file is read. An unauthenticated attacker can read any file accessible to the application process with a single HTTP request, potentially including source code, configuration files, secrets, and system files.