Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-21T11:17:06.937Z",
  "pubdate": "2026-08-21T11:17:06.937Z",
  "executiveSummary": "A path traversal vulnerability exists in the filestore backend of JuiceFS, specifically within pkg/object/file.go.\nThe vulnerability allows an attacker who controls or influences objects in a source object store during a synchronization operation to write arbitrary files to attacker-influenced locations outside the intended local destination directory.\nThe affected component handles file:// stores and common juicefs sync destinations, where operations such as Put, Get, Head, Delete, Chmod, Chown, Symlink, and Readlink consume unresolved paths derived from object keys.\nThis flaw exposes operators to arbitrary file write risks when syncing from shared, public, or otherwise untrusted buckets containing specially crafted path traversal segments.\nExploitation requires the operator to initiate a synchronization process from a compromised or untrusted object store source containing malicious object keys.\nThe risk implication is severe, potentially leading to unauthorized modification or creation of critical system files on the host running the JuiceFS sync operation.",
  "technicalDetails": "The vulnerability resides in the filestore backend implemented in pkg/object/file.go.\nThe root cause of the vulnerability is the unsafe derivation of operation targets via the path(key) function, which returns either filepath.Join(d.root, key) or filepath.Clean(d.root + key) without validating whether the resulting resolved path remains constrained beneath the designated root directory.\nObject keys enumerated from a source object store during a sync operation lack the structural constraints typically enforced on local filesystem names.\nBecause path(key) does not check for boundary containment, keys containing directory traversal sequences (e.g., ../) allow attackers to break out of the intended root directory.\nOperations including Put, Get, Head, Delete, Chmod, Chown, Symlink, and Readlink consume this unsafe value directly without validation.\nDuring exploitation, an attacker supplies or uploads an object with a malicious key containing traversal sequences into a shared or writable source bucket.\nWhen an operator performs a juicefs sync operation from this bucket, the client enumerates the objects and passes the malicious keys to the filestore backend.\nThe vulnerable path() function resolves the target outside the intended local destination directory.\nSubsequent operations, such as Put, write attacker-supplied content directly to the traversed file path on the local filesystem.\nNo error is returned by the path resolution logic during this process, allowing the write to complete silently.\nThe post-exploitation impact includes arbitrary file write capabilities, potentially leading to system compromise, configuration tampering, or execution of arbitrary code depending on the overwritten file targets."
}