CVE-2026-41326: Arbitrary File Overwrite in Kata Containers via CopyFile API Symlink Subversion

Kata Containers provides a standard implementation of lightweight Virtual Machines (VMs) that behave like containers, bridging hardware isolation with standard container workflows. The Kata Agent, running inside the guest VM, exposes a gRPC/ttrpc interface to the host. This interface allows the host-side shim to manage the container lifecycle and transfer files between the host and the guest workload. The CopyFile API handles file transfer requests and relies on a Rego-based policy engine (Open Policy Agent) to enforce authorization boundaries.

CVE-2026-41326 is an authorization bypass and symlink following vulnerability (CWE-61) affecting the CopyFile API in Kata Containers versions 3.4.0 through 3.28.0. The vulnerability occurs because the agent's policy engine validates the destination path of the file write operation but ignores the file type and the associated payload data. When the request specifies the creation of a symbolic link, the policy engine permits the operation based solely on the link's location, rather than examining where the link points.

An attacker with host-level access to the Kata Agent's communication socket can exploit this flaw by issuing a sequence of tailored CopyFile requests. The attacker first creates a symbolic link in an allowed directory that points to a restricted guest file. The attacker then issues a second write request to the newly created symlink, which the agent blindly follows, overwriting the restricted target. This compromises the integrity of the guest VM.

The impact is highly specific to the security model of Confidential Virtual Machines (CVMs), where the guest workload must remain isolated from an untrusted host. By exploiting this flaw, a compromised or malicious host can inject arbitrary code into the guest, modify execution flows, or extract sensitive data. The vulnerability possesses a CVSS 4.0 score of 8.2, reflecting the high integrity impact on the isolated guest subsystem.

The root cause of CVE-2026-41326 lies in the overloaded nature of the CopyFile API and the incomplete authorization logic applied by the Kata Agent's policy engine. The API processes requests to create regular files, directories, and symbolic links through a single interface. The behavioral mode of the operation is dictated by a file_mode bitmask provided in the remote procedure call.

Prior to version 3.29.0, the CopyFileRequest structure submitted to the policy engine only exposed the intended destination path. The engine evaluated this path against a list of permitted directories, ensuring that the target resided within allowed boundaries such as /run/kata-containers/shared/containers/. The validation logic correctly prevented basic directory traversal attacks by normalizing the provided path.

However, the policy engine lacked visibility into the file_mode and the data fields of the request. When the file_mode bitmask includes the POSIX S_IFLNK flag, the data field represents the target path of the symbolic link rather than file contents. By ignoring the file_mode, the authorization logic treated the symlink creation request as a standard file write, approving it because the link itself was placed in a permitted directory.

Once the symlink exists in the guest filesystem, subsequent file operations interacting with that path follow standard POSIX filesystem semantics. A second CopyFile request targeting the symlink resolves to the absolute or relative path specified during the link's creation. Because the initial path validation only checks the requested endpoint—not the resolved endpoint—the write operation succeeds, bypassing the intended directory restrictions.

The patch introduced in commit 1b9e49eb2763aa6ea6a99b276d3ff5e2c7f658f2 addresses the root cause by decoupling the raw gRPC request from the policy evaluation context. The fix implements a data normalization step within the Kata Agent, transforming the CopyFileRequest into a PolicyCopyFileRequest structure before passing it to the Rego engine. This transformation extracts and explicitly defines the file type and the symlink target.

// Pre-patch structure lacking context
// struct CopyFileRequest { path: String, file_mode: u32, data: Vec<u8> }
 
// Post-patch explicit policy structure
pub struct PolicyCopyFileRequest {
    pub path: String,
    pub file_type: String,     // 'Regular', 'Directory', or 'Symlink'
    pub symlink_target: String // Extracted from data if file_type == 'Symlink'
}

The corresponding Rego policy in src/tools/genpolicy/rules.rego implements rigorous validation for symlink targets. The policy now requires symlinks to be relative, explicitly rejecting any target path beginning with a forward slash. Additionally, the policy enforces path normalization on the target, prohibiting the use of .. components that enable directory traversal out of the permitted scope.

allow_copy_file if {
    input.file_type == "Symlink"
    # Symlinks must be relative.
    not startswith(input.symlink_target, "/")
    # Symlinks must be normalized.
    check_directory_traversal(input.symlink_target)
    # Symlinks are not allowed on the top-level of shared directory.
    allow_copy_file_path(input.path, ".*/.+")
}

The fix is complete and robust. By forcing symlinks to be relative and prohibiting upward directory traversal within the link target, the agent ensures that any created symlink strictly resolves to a location within the already-permitted base directory. Restricting symlinks at the top level of shared directories further hardens the filesystem layout against link-following edge cases.

Exploitation of CVE-2026-41326 requires the attacker to possess elevated privileges on the physical host machine, specifically the ability to interact with the Kata Agent's communication socket. In a standard deployment, this socket is restricted and managed by the container runtime shim. An attacker who breaches the host OS or compromises the container orchestrator component can bypass the isolation of Confidential Virtual Machines by interacting directly with the agent.

The attack sequence involves two distinct gRPC/ttrpc requests. In the first phase, the attacker constructs a CopyFile request where the file_mode specifies S_IFLNK. The destination path is set to an allowed directory, such as /run/kata-containers/shared/containers/sandbox-xyz/link. The data payload contains the absolute path to the intended target file within the guest, for example, /etc/shadow or an executable binary in /usr/bin/.

In the second phase, the attacker issues another CopyFile request. This request targets the newly created symlink at /run/kata-containers/shared/containers/sandbox-xyz/link. The policy engine validates this path against its allowlist and permits the operation. The Kata Agent executes the file write operation using standard system calls. The underlying operating system follows the symlink, writing the attacker's payload directly into the restricted target file.

Depending on the overwritten file, the attacker achieves various objectives. Overwriting critical system binaries allows for arbitrary code execution within the guest context. Modifying configuration files or credential stores facilitates privilege escalation or persistence. In the context of Confidential Computing, this breaks the fundamental guarantee that the host cannot tamper with the guest workload.

The CVSS 4.0 vector assigned to this vulnerability is CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:H/SI:N/SA:N, resulting in a base score of 8.2. The primary factor driving this high severity rating is the high integrity impact (VI:H) on the vulnerable system and the corresponding high impact on the sub-component (SC:H). The vulnerability allows complete control over the guest filesystem state from the host environment.

Kata Containers is frequently deployed as the runtime engine for Confidential Virtual Machines. CVMs are designed to protect workloads from untrusted or malicious host environments, shifting the trust boundary inward to the hardware and the guest OS. CVE-2026-41326 directly subverts this architecture. A compromised host administrator can trivially bypass the cryptographic and logical isolation provided by the CVM framework, rendering the confidential computing guarantees void.

Despite the severe impact on integrity and isolation, the practical exploitability of this vulnerability is limited by its strict prerequisites. The attacker must already possess local access to the host machine and the ability to interface with the container runtime sockets. Consequently, the EPSS score indicates a very low probability of mass exploitation in the wild (0.00019). The vulnerability poses no risk to internet-facing services unless the underlying host is already severely compromised.

The primary remediation for CVE-2026-41326 is upgrading the Kata Containers installation to version 3.29.0 or later. This release incorporates the updated agent logic and the revised Rego policies that normalize input and strictly validate symbolic link targets. Administrators must ensure that the updated agent binary is deployed within all base VM images used by the container runtime.

For environments where immediate patching is not feasible, operators should focus on hardening the host-side infrastructure. Restricting access to the ttrpc/gRPC sockets used by the Kata shims prevents unauthorized local users or processes from communicating with the guest agent. Implement strict Discretionary Access Control (DAC) and Mandatory Access Control (MAC) policies, such as AppArmor or SELinux, on the host OS to confine container orchestration components.

Security teams can verify the integrity of their deployments by auditing the Rego policy files bundled with their Kata Containers distributions. Ensure that the allow_copy_file rule explicitly checks input.file_type and enforces the check_directory_traversal logic on input.symlink_target. Monitoring host-side audit logs for anomalous CopyFile requests, particularly those defining symlinks across isolation boundaries, aids in detecting attempted exploitation.