The vulnerability (CVE-2025-5981) is an arbitrary file write due to path traversal in OSV-SCALIBR's container image unpacking functionality. This occurs when processing malicious container images, particularly via the --remote-image CLI flag.

The root cause was the improper handling of file paths extracted from tar archive headers within container image layers. Specifically, paths were constructed by combining a base extraction directory with file/directory names from the tar entries. Insufficient sanitization of these names (e.g., not fully mitigating ../ sequences) allowed an attacker to craft tar entries that, when unpacked, would write files or create directories outside the intended extraction directory.

The patch (commit 2444419b1818c2d6917fc3394c947fb3276e9d59) addresses this by introducing the os.Root API. This API provides a way to confine file system operations to a specific root directory, effectively creating a chroot-like jail for the unpacking process.

The key functions involved were:

1. (*Image).handleFile: Pre-patch, this function used os.OpenFile with a potentially traversed path (realFilePath) to write files. The patch changed this to use img.root.OpenFile, ensuring writes are contained.
2. (*Image).handleDir: Pre-patch, this function used os.MkdirAll with a potentially traversed path (realFilePath) to create directories. The patch modified path handling and uses img.root.Stat to ensure operations are relative to the safe root.
3. fillChainLayersWithFilesFromTar: This function was responsible for reading tar entries and, pre-patch, for constructing the realFilePath that was then passed to handleFile and handleDir. The logic for path cleaning here was insufficient. The patch removed this direct path construction, relying on the os.Root context.
4. FromV1Image: This function orchestrates the image unpacking. The patch introduced the creation and use of an os.Root object here, which is then used by the lower-level functions.

During exploitation, these functions (in their pre-patch state) would be on the call stack. handleFile or handleDir would be the functions directly executing the unsafe os.OpenFile or os.MkdirAll calls with the attacker-controlled path. The unpack() function mentioned in the advisory likely calls FromV1Image or a similar entry point that utilizes this vulnerable logic.