CVE-2025-52890 is a high-severity vulnerability affecting the Incus system container and virtual machine manager, specifically versions 6.12 and 6.13. Incus manages containers and VMs and uses nftables rules to enforce network security policies, including access control lists (ACLs) on devices connected to network bridges. The vulnerability arises from incorrect authorization (CWE-863) in the generation of nftables rules when ACLs are applied to devices on a bridge. This flaw causes partial bypassing of critical security options: security.mac_filtering, security.ipv4_filtering, and security.ipv6_filtering. As a result, an attacker with high privileges on a container or VM can exploit this weakness to perform ARP spoofing attacks on the bridge network. This enables the attacker to fully spoof another VM or container connected to the same bridge, potentially intercepting or redirecting network traffic intended for that target. The vulnerability impacts confidentiality and availability, as attackers can eavesdrop on or disrupt communications between containers or VMs. The issue was addressed in commit 254dfd2483ab8de39b47c2258b7f1cf0759231c8, though no official patch links are provided in the data. The CVSS v3.1 score is 8.1 (high), reflecting the vulnerability’s network attack vector (AV:A - adjacent network), low attack complexity (AC:L), requirement for high privileges (PR:H), no user interaction (UI:N), scope change (S:C), high confidentiality impact (C:H), no integrity impact (I:N), and high availability impact (A:H). No known exploits in the wild have been reported to date. This vulnerability is particularly relevant in environments where Incus is used to manage multi-tenant container or VM infrastructures, as it allows lateral movement and network spoofing within the same bridge domain.

For European organizations, the impact of CVE-2025-52890 can be significant, especially for those relying on Incus for container and VM management in cloud, hosting, or enterprise data center environments. The ability to bypass MAC and IP filtering and perform ARP spoofing within a bridge can lead to unauthorized interception of sensitive data, disruption of network services, and potential lateral movement between virtualized workloads. This undermines network segmentation and isolation guarantees critical for compliance with GDPR and other data protection regulations. Organizations running multi-tenant environments or critical infrastructure services on Incus-managed containers or VMs may face confidentiality breaches and availability outages. The requirement for high privileges to exploit the vulnerability means that initial compromise or insider threat scenarios are likely prerequisites, but once exploited, the attacker can compromise other tenants or services on the same bridge. This could lead to data leakage, service disruption, and increased risk of further compromise. Given the growing adoption of containerization and virtualization in European IT infrastructures, this vulnerability poses a tangible risk to cloud service providers, financial institutions, telecommunications, and government sectors.

1. Immediate upgrade: Organizations should upgrade Incus to a version later than 6.13 where the patch (commit 254dfd2483ab8de39b47c2258b7f1cf0759231c8) has been applied. If an official patched release is not yet available, consider applying the patch manually after thorough testing. 2. Network segmentation: Implement strict network segmentation and isolate bridge networks to limit the scope of potential ARP spoofing attacks. Avoid sharing bridges among tenants or critical workloads. 3. Privilege minimization: Restrict high privilege access within containers and VMs to trusted administrators only, reducing the risk of privilege escalation leading to exploitation. 4. Monitoring and detection: Deploy network monitoring tools capable of detecting ARP spoofing and anomalous MAC/IP address changes on bridges. Use IDS/IPS solutions tuned for container and VM environments. 5. Harden nftables rules: Review and harden nftables configurations to enforce strict filtering policies beyond Incus defaults, ensuring that MAC and IP filtering cannot be bypassed. 6. Incident response readiness: Prepare incident response plans to quickly isolate affected containers/VMs and bridges if suspicious activity is detected. 7. Vendor engagement: Maintain communication with the Incus vendor/project for timely updates and security advisories.