CVE-2026-103061 in Gleam
Summary
by MITRE • 10/12/2026
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in gleam-lang gleam allows a malicious package publisher to delete a directory outside the project's build directory when a developer builds a project.
A Hex package release's metadata carries an app field with the release's OTP application name. Gleam reads this field from the hex.pm release API when it downloads dependencies and uses it as the package's build directory name without validating it (hex_manifest_package in compiler-cli/src/dependencies.rs, ProjectPaths::build_directory_for_package). When a dependency fails to compile, Gleam deletes that directory with remove_dir_all. hex.pm didn't restrict the field to a directory name before 2026-10-12, so a publisher could set it to a value such as ../../../../target or an absolute path. When a project depends on such a release directly or transitively and the release fails to compile, gleam build, gleam check, gleam run, gleam test or gleam export deletes the directory the name resolves to. For a pure Gleam package no publisher code runs.
This issue affects gleam: from 0.32.4 before 1.19.2.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified as an improper limitation of a pathname to a restricted directory, commonly known as path traversal or directory traversal, represents a critical security flaw within the Gleam programming language ecosystem. This specific issue arises from inadequate validation of input data derived from external package metadata, specifically when interacting with the Hex.pm registry. The core technical failure lies in how the compiler handles the app field found in Hex package release metadata. When developers execute commands such as gleam build, gleam check, gleam run, gleam test, or gleam export to compile and manage their projects, the Gleam toolchain retrieves dependency information from the hex.pm API. It extracts the OTP application name specified in this metadata and uses it directly as the identifier for the package's local build directory without performing any sanitization checks on the string content. This lack of validation allows a malicious actor who controls or compromises a Hex package publisher account to inject arbitrary file system paths into the metadata field.
The operational impact of this vulnerability is severe because it enables remote code execution in terms of file system manipulation, specifically leading to unauthorized deletion of directories outside the intended project scope. The Gleam compiler utilizes a function called remove_dir_all to clean up build artifacts when a dependency fails to compile or during standard cleanup processes. Because the directory name was derived directly from untrusted input without restricting it to valid alphanumeric characters or relative paths within the current working tree, an attacker can craft a malicious package release with an app field set to values such as ../../../../target or absolute system paths like /etc or C:\Windows. If a developer's project depends on this compromised package, either directly or transitively through other dependencies, and that dependency fails its compilation check, the Gleam tool will execute the deletion command against the resolved path. This results in the permanent destruction of critical files and directories belonging to the operating system, other projects, or sensitive configuration data located outside the project's build directory.
This vulnerability is classified under CWE-22: Improper Limitation of a Pathname to a Restricted Directory, which describes scenarios where software does not properly neutralize special elements within file names that could cause files to be located in unintended directories. From an offensive security perspective, this aligns with ATT&CK technique T1083: File and Directory Discovery or more accurately T1485: Data Destruction when considering the outcome of directory deletion. The attack vector is primarily remote via network access to package registries but requires a specific trigger condition where the malicious dependency fails to compile during the developer's build process. This makes it particularly insidious as it does not require code execution on the target machine in the traditional sense, nor does it involve running arbitrary publisher code since pure Gleam packages do not execute pre-compiled binaries from publishers; instead, it exploits the automated tooling behavior of the compiler itself during error handling and cleanup phases.
The scope of this vulnerability affects versions of Gleam starting from 0.32.4 up to but not including version 1.19.2. The root cause was exacerbated by historical permissiveness in the Hex.pm registry, which did not enforce strict naming conventions for the app field until October 12, 2026. Prior to this date, publishers could submit releases with arbitrary strings as application names, creating a window of opportunity for attackers to publish malicious packages that would remain dormant until triggered by a developer's build process involving those specific dependencies. Even after registry-side restrictions were implemented, existing cached metadata or previously published versions might still pose risks if not properly invalidated or updated in local caches.
Mitigation strategies must focus on both immediate remediation and long-term defensive coding practices. The primary mitigation is to upgrade the Gleam toolchain to version 1.19.2 or later, where input validation for package metadata has been strengthened to ensure that directory names are restricted to safe characters and relative paths within the project structure. Developers should also audit their dependency trees using tools like gleam deps tree to identify any dependencies on packages published before the registry hardening date, particularly those with unusual application name formats. In environments where upgrading is not immediately feasible, implementing a pre-build script that validates package metadata against expected patterns can provide an additional layer of defense. Furthermore, organizations should enforce strict dependency management policies and consider using private registries or mirrors to control which packages are allowed into the build environment, thereby reducing exposure to untrusted third-party code from public sources. Regular security audits of CI/CD pipelines should include checks for path traversal vulnerabilities in all tooling that processes external metadata.