CVE-2026-71566 in FakeFish
Summary
by MITRE • 08/17/2026
FakeFish handles incoming credentials by passing them down to scripts. This works for real hardware because in the end it's up to the BMC to validate them. However, KubeVirt relies on a KUBECONFIG file mounted to the container and completely ignores the credentials. This allows any user of the cluster to control VMs of the user that created fakefish, power them on and off, and mount arbitrary CD images to them.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/17/2026
The vulnerability in FakeFish stems from a fundamental flaw in how it processes authentication data within containerized environments compared to physical hardware deployments. In traditional setups involving real Baseboard Management Controllers or similar BMCs, the application receives credentials via standard input and passes these down to underlying scripts for validation by the hardware firmware itself. This architecture ensures that only valid, authorized credentials are accepted because the final verification step occurs at a trusted boundary outside of the application logic. However, this security model collapses when deployed in Kubernetes environments using KubeVirt, where the system relies on a mounted KUBECONFIG file rather than explicit user-supplied credentials for authentication and authorization decisions.
This architectural mismatch creates a critical privilege escalation vector because the containerized implementation completely ignores any incoming credentials provided by users or external systems. Instead of validating access requests against specific user identities through proper credential checks, the application defers entirely to the permissions associated with the service account whose KUBECONFIG file is mounted into the container environment. Consequently, the security boundary shifts from individual user authentication to cluster-level identity management, effectively bypassing any intended per-user isolation mechanisms that FakeFish might have attempted to enforce at the application layer.
The operational impact of this flaw is severe for multi-tenant Kubernetes clusters running virtual machines via KubeVirt. Any authenticated user within the cluster gains the ability to interact with all virtual machines associated with the specific service account used by the FakeFish deployment. This includes the capability to start and stop VMs belonging to other users, effectively allowing an attacker to disrupt services or consume resources allocated to others. Furthermore, attackers can mount arbitrary CD images into these virtual machines, which could be leveraged for further exploitation such as installing malicious software, exfiltrating data from guest operating systems, or pivoting to deeper network access depending on the VM's configuration and connectivity.
This vulnerability aligns with CWE-287 Improper Authentication because the system fails to properly verify user identity before granting significant administrative privileges over virtual machine resources. It also maps closely to ATT&CK technique T1078 Valid Accounts, as attackers leverage legitimate cluster credentials to access unauthorized VM instances. The flaw represents a classic case of misconfigured trust boundaries where container runtime permissions override application-level security controls.
Mitigation strategies must address both the architectural design and configuration aspects of the deployment. First, the KUBECONFIG file mounted into the FakeFish container should be restricted using Kubernetes RBAC policies to limit its scope strictly to necessary resources, ideally employing least-privilege principles that prevent access to other users' VMs if such isolation is required. Second, application logic should be refactored to validate incoming credentials independently of the service account identity, ensuring that user-specific permissions are enforced regardless of the underlying container runtime context. Additionally, implementing network policies and pod security standards can help contain potential lateral movement in case an attacker successfully exploits this vulnerability. Regular audits of mounted volumes and RBAC bindings are essential to maintain proper isolation between tenants in shared Kubernetes environments utilizing virtualization extensions like KubeVirt.