Description

Confidential Containers Guest Components provides guest tools and components for confidential container workloads. From 0.16.0 until 0.20.0, a crafted OCI image layer can make image_rs::stream::unpack::unpack() create a hardlink outside its destination directory. In image-rs/src/stream/unpack.rs, try_hardlink_fallback() validates the hardlink source but computes the destination with destination.join(&entry_rel). Rust Path::join replaces the base when entry_rel is an absolute tar entry path, so fs::hard_link(&src_canon, &dst_entry_abs) can write attacker-controlled content to an arbitrary absolute path. In Confidential Containers the workload owner already controls trusted image content, so the issue is a workload-owner escape into the pod virtual machine rather than a crossing of the image trust boundary, but it may enable access to pod virtual machine capabilities and attestation abuse. This issue is fixed in version 0.20.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.4",
  "pubDate": "2026-08-18T22:16:52.127Z",
  "pubdate": "2026-08-18T22:16:52.127Z",
  "executiveSummary": "A path traversal and arbitrary file creation vulnerability exists in Confidential Containers Guest Components, specifically within the image unpacking logic of image_rs::stream::unpack::unpack().\nThe vulnerability allows a crafted OCI image layer containing an absolute tar entry path to bypass destination directory restrictions via try_hardlink_fallback() in image-rs/src/stream/unpack.rs.\nThis flaw enables a workload owner to perform a workload-owner escape from the container containerization boundary into the underlying pod virtual machine.\nSuccessful exploitation can lead to unauthorized access to pod virtual machine capabilities and potential attestation abuse.\nThe affected product is Confidential Containers Guest Components, impacting versions from 0.16.0 up to, but not including, 0.20.0.\nMitigation requires updating the affected guest components to version 0.20.0 or later, where the path sanitization logic for hardlink extraction has been corrected.",
  "technicalDetails": "The root cause of the vulnerability resides in how file paths are constructed during the unpacking of OCI image layers within the image-rs/src/stream::unpack::unpack() function and specifically the try_hardlink_fallback() routine.\nDuring the tar archive extraction process, the implementation validates the hardlink source but fails to properly sanitize the destination path.\nThe destination path is computed using the Rust Standard Library Path::join method in the expression destination.join(&entry_rel).\nBecause Rust's Path::join replaces the base path entirely when the provided argument (&entry_rel) is an absolute path, an attacker can supply an absolute tar entry path.\nConsequently, the subsequent file system operation fs::hard_link(&src_canon, &dst_entry_abs) resolves outside the intended destination directory and writes or links content to an arbitrary absolute path on the host file system of the pod virtual machine.\nThe vulnerable component is identified as the image_rs crate, specifically within the source file image-rs/src/stream/unpack.rs.\nThe affected product versions span from 0.16.0 through 0.20.0.\nThe attack flow begins with the malicious construction of an OCI image layer containing specially crafted hardlink entries with absolute paths.\nWhen the confidential container runtime processes and unpacks this crafted image layer, the try_hardlink_fallback() function processes the absolute path without interception.\nPath::join evaluates the absolute entry path, discarding the base directory prefix.\nThe fs::hard_link function then executes, creating a hardlink targeting an arbitrary absolute path within the pod virtual machine.\nAlthough the threat model assumes the workload owner already controls trusted image content in standard confidential container scenarios, this vulnerability represents a privilege escalation vector from the container workload into the underlying pod virtual machine capabilities, enabling attestation abuse and unauthorized access."
}