CVE-2025-58354: Kata Containers Auth Bypass Vulnerability

CVE-2025-58354 Overview

CVE-2025-58354 affects Kata Containers, an open source project that runs lightweight virtual machines with container-like semantics. Versions from 3.20.0 and before contain a flaw in initdata verification on Intel Trust Domain Extensions (TDX) confidential guests. A malicious host can selectively fail IO operations during guest boot to skip the verification step. This allows the host to launch arbitrary workloads while producing valid attestations to the Trustee that impersonate benign workloads. The issue is tracked under CWE-754: Improper Check for Unusual or Exceptional Conditions and was fixed in Kata Containers 3.21.0.

Critical Impact
A malicious host can break the confidential computing trust boundary by bypassing initdata verification and passing attestation for workloads it never actually ran.

Affected Products

Kata Containers versions 3.20.0 through 3.20.x
Kata Containers confidential guest configurations on Intel TDX systems
Deployments using Trustee for remote attestation of Kata confidential workloads

Discovery Timeline

2025-09-23 - CVE-2025-58354 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-58354

Vulnerability Analysis

Kata Containers uses initdata to inject launch-time configuration and policy into a confidential guest. On TDX systems, the guest agent is expected to load and verify initdata before the workload starts. The measurement of that initdata is then bound into the attestation evidence provided to Trustee.

The vulnerability is a missing check on exceptional conditions during initdata IO. When the malicious host causes IO operations to fail selectively, the guest agent treats the failure as absence of initdata rather than as a fatal error. The workload proceeds with no policy enforcement, yet attestation still succeeds against a benign reference measurement. This breaks the integrity guarantees that confidential computing is expected to provide.

Root Cause

The root cause is improper handling of IO errors in the agent initialization path and in the initramfs verity setup. The agent did not distinguish between "initdata not present" and "initdata read failed," and veritysetup open did not panic on dm-verity corruption. A hostile host controlling the virtio backends could trigger these paths deterministically.

Attack Vector

The attacker must control the host that runs the confidential guest. By manipulating storage or virtio IO responses, the attacker forces initdata reads to fail and boots the guest without the intended policy. The guest then attests as a benign workload to Trustee, allowing the attacker to smuggle arbitrary workloads into environments that rely on remote attestation for trust decisions.

rust

// Patch: src/agent/src/main.rs - import ErrorKind to differentiate IO errors
 use std::env;
 use std::ffi::OsStr;
 use std::fs::{self, File};
+use std::io::ErrorKind;
 use std::os::unix::fs::{self as unixfs, FileTypeExt};
 use std::os::unix::io::AsRawFd;
 use std::path::Path;

Source: kata-containers commit 3e67f92

bash

# Patch: tools/packaging/static-build/initramfs/init.sh
# Force veritysetup to panic on corruption so IO tampering cannot be silently ignored
-	veritysetup open "${root_device}" root "${hash_device}" "${rootfs_hash}"
+	veritysetup open --panic-on-corruption "${root_device}" root "${hash_device}" "${rootfs_hash}"
 	mount /dev/mapper/root /mnt

Source: kata-containers commit 3e67f92

Detection Methods for CVE-2025-58354

Indicators of Compromise

Confidential guests running Kata Containers 3.20.x that boot successfully despite missing or unreadable initdata artifacts.
Trustee attestation records showing benign reference measurements for guests whose runtime behavior does not match the expected workload.
Kernel or agent logs reporting IO errors on initdata devices immediately before workload start.

Detection Strategies

Compare workload identity claimed in attestation against observed process, image, and network telemetry from the guest.
Alert on Kata agent logs that indicate initdata was absent on TDX-enabled hosts where initdata is mandatory by policy.
Inventory Kata Containers versions across confidential computing hosts and flag any node still running 3.20.x.

Monitoring Recommendations

Ingest Kata agent and hypervisor logs into a centralized analytics platform to correlate IO failures with attestation events.
Monitor Trustee for repeated attestations of the same reference value from hosts with unusual guest workload patterns.
Track dm-verity events in the initramfs and treat any non-panic recovery as a high-severity signal.

How to Mitigate CVE-2025-58354

Immediate Actions Required

Upgrade all Kata Containers deployments to version 3.21.0 or later, prioritizing TDX confidential-guest nodes.
Rebuild and redeploy the Kata guest image and initramfs so the patched veritysetup --panic-on-corruption behavior is in effect.
Rotate Trustee reference values and re-measure workloads after upgrade to invalidate any evidence produced by vulnerable agents.

Patch Information

The fix is delivered in Kata Containers 3.21.0 via commit 3e67f92e34be974e792c153add76e4e4baac9de0. See GitHub Security Advisory GHSA-989w-4xr2-ww9m for the coordinated disclosure details.

Workarounds

Restrict which hosts are authorized to launch confidential workloads until patched images are deployed everywhere.
Enforce Trustee policies that require explicit, non-empty initdata measurements and reject attestations lacking them.
Isolate untrusted or multi-tenant hypervisor hosts from workloads that depend on TDX attestation guarantees.