RUSTSEC-2026-0450

When ocipkg unpacks an OCI archive, the destination directory is derived from the image name, which ocipkg reads from the archive's own index.json (org.opencontainers.image.ref.name). That name is attacker-controlled, and ImageName::parse accepts a hostname of .., so the computed destination escapes the local image store. A "zip-slip"-style path traversal (CWE-22 / CWE-23). This is esclatable to code execution.

In Artifact::unpack (src/image/artifact.rs), the destination is image_dir(name) = data_dir().join(name.as_path()) (src/local/mod.rs:31), where the name comes from get_name_from_index (src/image/layout.rs:114-124):

let image_name = self.base.get_name()?;   // from the archive's index.json ref.name
let dest = image_dir(&image_name)?;        // data_dir().join(name.as_path()); hostname ".." escapes
if dest.exists() {
    if overwrite {
        fs::remove_dir_all(&dest)?;        // deletes a directory OUTSIDE the store
    }
}
fs::create_dir_all(&dest)?;
// ... each tar layer is then unpacked under `dest` (also outside the store)

The fix

Fixed in ocipkg 0.4.1 by PR #223. The leading reference component is validated against the org.opencontainers.image.ref.name grammar from OCI Image Specification 1.1.1 on parse and deserialization, and local::image_dir revalidates the name and rejects any non-normal path component (e.g. ..) before any filesystem mutation, so a crafted archive can no longer escape the local image store.