Arbitrary file write on the client host via archive auto-unpacking and recursive downloads

Impact

On September 22, 2026, an open-source community member reported a security vulnerability in the Pelican client's archive auto-unpacking feature to the Pelican team. When a client downloads an object with the pack option (pelican object get --pack ... or a ?pack= URL query), the client extracts the archive into the destination directory as it streams. We have confirmed that a maliciously constructed archive can write files anywhere the invoking user has permission to write, not just inside the destination directory.

The client checked each archive entry's name against the destination directory, but created symbolic links from the archive without any check on where they point, and then wrote later entries through the filesystem, which followed those links. An archive containing a symlink data -> /home/user followed by a regular file data/.bashrc therefore overwrites the user's .bashrc. A second, independent flaw in the same check accepted entry names that resolve to a sibling directory sharing the destination's name as a prefix (for example ../out-evil/x when extracting into out).

While reviewing this code, the Pelican team found a related issue in recursive downloads (pelican object get -r, pelican object sync). The client builds each local file path from entry names returned by the remote collection listing. A malicious or compromised origin or cache can return an entry named .., or an entry whose name contains path separators, and the client writes the corresponding file outside the requested destination directory.

In both cases the write happens with the privileges of the user running Pelican. Overwriting shell start-up files, SSH configuration, or cron entries turns this into code execution on the client host, including inside HTCondor job sandboxes when jobs use the Pelican plugin. Exploitation requires that the user download from a namespace where an attacker can place or serve content: anyone with write access to an origin the victim reads from, a compromised origin or cache, or a director that steers the client to a hostile server. No other precondition applies.

We have not identified any evidence that either issue has been exploited in the OSDF.

Attack preconditions

1. The victim runs an affected Pelican client on Linux or macOS. (Auto-unpacking is disabled on Windows, so only the recursive-download issue applies there.)
2. For the archive issue: the victim downloads with --pack / ?pack= an object the attacker controls.
3. For the recursive issue: the victim downloads recursively from a collection whose listing the attacker controls (hostile origin, cache, or director).

Immediate action

• Upgrade the client to a patched release. Check the version with pelican --version.
• Until upgraded, do not use --pack or ?pack= on objects from sources you do not fully trust, and avoid recursive downloads from federations or namespaces you do not trust. Running downloads as a dedicated low-privilege user, or into a container, limits what an escape can reach.
• HTCondor administrators: jobs using the Pelican plugin with pack= in transfer URLs are exposed; the plugin ships inside the Pelican package, so upgrading the package on execute nodes is sufficient.
• Server operators (origin, cache, director, registry): no action required.

Patches

The archive extractor now performs every filesystem operation through Go's os.Root, which anchors all paths to the destination directory at the operating-system level and refuses to follow any symbolic link, whether from the archive or already present on disk, that would leave it. Archive entries that would escape now fail the transfer with an explicit error instead of writing outside the destination. Recursive downloads reject any listing entry whose name is not a single plain path component. The Pelican team also audited the remaining places where remote-supplied names are joined onto local paths and hardened the ones it found.

Long-term fixes

• Reviewing all client code that turns remote-supplied names into local filesystem paths.
• Extending the os.Root-based confinement already used by Pelican servers to every client write path.