CVE-2026-47699: Confidential Containers Guest Components image-rs: zip-slip-class arbitrary file write via absolute entry path in hardlink fallback
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 imagers::stream::unpack::unpack() create a hardlink outside its destination directory. In image-rs/src/stream/unpack.rs, tryhardlinkfallback() validates the hardlink source but computes the destination with destination.join(&entryrel). Rust Path::join replaces the base when entryrel is an absolute tar entry path, so fs::hardlink(&srccanon, &dstentryabs) 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
image-rs (Confidential Containers Guest Components image-rs)to a version that resolves this vulnerability.Fixed in 0.20.0
Event History
Frequently Asked Questions
Which versions need to be remediated?
The vulnerable range is 0.16.0 up to, but not including, 0.20.0. Version 0.20.0 fixes the issue.
What level of control is required to exploit this?
An attacker must be able to supply a crafted OCI image layer containing a hardlink fallback entry with an absolute tar entry path. In the Confidential Containers threat model described, this means the workload owner, who already controls trusted image content.
What is the practical impact in a Confidential Containers deployment?
The issue allows the workload owner to write attacker-controlled content to an arbitrary absolute path outside the unpack destination in the pod virtual machine. It is described as a workload-owner escape into the pod VM, potentially enabling access to pod-VM capabilities and attestation abuse, rather than bypassing the image trust boundary.