Louis Pilfold

A path traversal issue exists where a malicious package publisher can cause the deletion of directories outside the project build directory. This occurs because Gleam reads the `app` field from the hex.pm release API and uses it as the package build directory name without proper validation. If a dependency fails to compile, Gleam uses the `remove dir all` function to delete the directory associated with that name. A publisher could set the `app` field to an absolute path or a relative path containing `..` components to target arbitrary directories. This can be triggered by commands such as `gleam build`, `gleam check`, `gleam run`, `gleam test`, or `gleam export` when a project depends on a malicious release. The issue is specifically linked to the `hex manifest package` function in `compiler-cli/src/dependencies.rs` and the `ProjectPaths::build directory for package` function.

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.

A path traversal issue exists in the handling of custom documentation pages. The `documentation.pages` entries within the `gleam.toml` file are incorporated into filesystem paths without sufficient validation. Specifically, the `documentation.pages[].path` field allows writing generated documentation files outside the intended `build/dev/docs/<package>/` directory, and the `documentation.pages[].source` field allows reading files from outside the project directory to embed them into the output. An attacker can exploit this by convincing a victim to run `gleam docs build` on an untrusted project or with malicious `gleam.toml` content, leading to arbitrary file read and write operations.

A symlink following issue in the Hex package export allows files outside the project root to be embedded in the generated package tarball. The file collection helpers `gleam files`, `native files`, and `private files` in compiler-cli/src/fs.rs use `follow links(true)` when walking publishable directories such as src/ and priv/. These paths are then added to the package archive via `add path to tar` in compiler-cli/src/publish.rs without verifying that the resolved target remains within the project root. An attacker with write access to the project repository can place a symlink in src/ or priv/ pointing to arbitrary files. When a maintainer or CI pipeline executes the commands "gleam publish" or "gleam export hex-tarball", local files readable by the publisher, such as secrets, tokens, or SSH keys, are silently embedded into the published package artifact.

A path traversal issue in the dependency management system allows for the recursive deletion of arbitrary directories. This occurs because package keys read from the `build/packages/packages.toml` file by the `LocalPackages::read from disc` function are passed without validation to `paths.build packages package()`. This process constructs a filesystem path by joining the project build directory with an attacker-controlled key, which is then passed to `fs::delete directory` (which calls `remove dir all`). Since the system does not verify if the path remains within the intended `build/packages/` directory, both absolute paths and relative traversal sequences (such as `../`) can be used to target and delete any directory on the victim's system when the `gleam deps download` command is executed on a project containing a malicious configuration file.

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.