CVE-2026-77763 in JuiceFS
Summary
by MITRE • 08/21/2026
The filestore backend in pkg/object/file.go, used for file:// stores and as a common juicefs sync destination, derived every operation's target from path(key), which returned either filepath.Join(d.root, key) or filepath.Clean(d.root + key) with no check that the result stayed beneath the root. Put, Get, Head, Delete, Chmod, Chown, Symlink and Readlink all consumed that value directly. Object keys enumerated from a source object store during a sync are not constrained the way local filesystem names are, so a key containing traversal segments causes juicefs to write attacker-supplied content to a path outside the intended local destination, and no error is returned. An operator syncing from a bucket whose contents they do not fully control, such as a shared or public bucket or one an attacker can write to, is therefore exposed to a file write at an attacker-influenced location. The fix changes path() to return an error and rejects any key whose resolved path escapes the root.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/21/2026
The vulnerability identified in the JuiceFS filestore backend represents a critical directory traversal flaw that allows for arbitrary file writes outside of the intended storage root. This issue resides within pkg/object/file.go, which serves as the implementation for file:// stores and acts as a common destination for synchronization operations. The core technical failure stems from how the system resolves object keys into local filesystem paths. Specifically, the path resolution logic relies on functions such as filepath.Join or string concatenation followed by filepath.Clean to combine the configured root directory with the provided key. Crucially, this process lacks any subsequent validation step to verify that the resulting absolute path remains strictly within the boundaries of the designated root directory. Consequently, if an object key contains relative path traversal sequences like dot-dot-slash, the system fails to detect or reject these attempts, allowing the resolved path to escape the sandboxed environment.
The operational impact of this flaw is severe because it affects multiple file operations including Put, Get, Head, Delete, Chmod, Chown, Symlink, and Readlink. Since all these functions consume the unvalidated target path directly, an attacker can manipulate any of them by supplying a maliciously crafted object key during synchronization or direct upload. When syncing from a source object store where the operator does not have full control over the contents—such as public buckets, shared repositories, or environments where attackers can inject objects—the risk is amplified significantly. By embedding traversal segments in the metadata keys of these external sources, an attacker can force JuiceFS to write files to arbitrary locations on the host filesystem. This capability effectively bypasses isolation mechanisms intended by the storage configuration, potentially leading to data corruption, unauthorized modification of system files, or further exploitation through symlink attacks if symbolic links are involved.
From a security classification perspective, this vulnerability aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, commonly known as directory traversal. The attack vector is classified under ATT&CK technique T1083: File and Directory Discovery or more specifically the write capabilities associated with privilege escalation via path manipulation. The lack of input validation on object keys which are treated as file paths creates an open redirect-like scenario but for local filesystem access. This flaw undermines the integrity guarantees provided by the storage backend, allowing untrusted data to influence critical system states beyond its intended scope.
The remediation strategy implemented in the fix addresses this issue at the root level of path resolution. The modified logic now explicitly checks whether the resolved absolute path remains beneath the configured root directory before proceeding with any operation. If a key results in a path that escapes these boundaries, the function returns an error rather than executing the command. This strict validation ensures that all file operations are confined to the designated storage area regardless of how maliciously crafted the input keys may be. Operators should immediately update their JuiceFS installations to incorporate this patch and review synchronization configurations to ensure they do not rely on untrusted sources without additional pre-processing or filtering of object keys before ingestion.