CVE-2026-40243: 
NixOS vulnerability analysis and mitigation

CVE-2026-40243 is an improper certificate validation vulnerability in Incus (the Linux container and VM manager) affecting its OVN database connection logic. The flaw allows an attacker with a suitable network position to redirect Incus connections to a rogue OVN database by presenting a self-signed certificate that the broken TLS verifier accepts. All versions of github.com/lxc/incus/v6/cmd/incusd prior to 7.0.0 are affected. The vulnerability was discovered by the team at 7asecurity, published on April 30, 2026, and assigned a CVSS v4 base score of 2.3 (Low) and a CVSS v3.1 base score of 4.8 (Medium) (GitHub Advisory, Incus Advisory).

The root cause is classified as CWE-295 (Improper Certificate Validation) and CWE-287 (Improper Authentication). Incus's OVN client implementations in ovn_nb.go, ovn_sb.go, ovn_icnb.go, and ovn_icsb.go set InsecureSkipVerify: true and replace Go's standard TLS verification with a custom VerifyPeerCertificate callback. The critical flaw in this callback is that it builds the trust root pool (roots) from the raw certificates supplied by the peer during the TLS handshake — rather than from the operator-configured CA certificate (tlsCAcert). The configured CA pool (clientCAPool) is constructed but never referenced in the final x509.VerifyOptions, meaning any attacker-supplied self-signed certificate chain will pass verification. A standalone Go proof-of-concept (poc_ovn_tls_roots.go) is included in the advisory and demonstrates the flaw without requiring a live network interception setup (GitHub Advisory, Incus Advisory).

A network-adjacent attacker who can intercept or impersonate the OVN northbound or southbound database endpoint can cause Incus to connect to a rogue OVSDB instance, resulting in limited confidentiality and integrity impact (CVSS v4: VC:L/VI:L). Because OVN's mTLS requires the attacker to also authenticate to the real OVN deployment — which they cannot do — a full man-in-the-middle attack is not achievable; at best, the attacker can serve an empty replacement database that Incus briefly interacts with before encountering errors. The OVN northbound and southbound databases are authoritative control-plane interfaces for logical network configuration, so even transient misdirection represents a control-plane authentication failure with potential networking impact in clustered deployments (GitHub Advisory).

A public proof-of-concept exploit (poc_ovn_tls_roots.go) is included in the official GitHub Security Advisory and demonstrates that the flawed verification logic accepts a rogue self-signed certificate (Incus Advisory). There is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.009% (3rd percentile), reflecting very low probability of near-term exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires high attack complexity — specifically, the ability to intercept or impersonate the OVN database service on the management network, which is typically co-located with Incus servers and not externally routable (GitHub Advisory).

1. Reconnaissance: Identify an Incus deployment (version < 7.0.0) that uses OVN with SSL-enabled database connections (ssl: prefix in OVN DB address configuration).
2. Gain network position: Obtain an adjacent network position on the management or control-plane network between the Incus server and the OVN northbound/southbound database endpoints (e.g., via ARP spoofing or BGP hijacking on the management LAN).
3. Generate rogue certificate: Create a self-signed certificate using any CA key (e.g., using the published PoC poc_ovn_tls_roots.go or standard tools like openssl). The certificate does not need to be signed by the legitimate CA.
4. Stand up rogue OVSDB listener: Deploy a rogue OVSDB server (or TCP listener) at the intercepted OVN database address, configured to present the self-signed certificate during the TLS handshake.
5. Intercept connection: Redirect Incus's OVN database connection (e.g., via ARP poisoning or DNS spoofing) to the rogue server. The flawed VerifyPeerCertificate callback will accept the rogue certificate because it builds the trust root from peer-supplied certificates rather than the configured CA.
6. Interact with rogue database: Incus will briefly connect and interact with the rogue OVSDB instance (e.g., reading or writing OVN logical network state) before encountering errors due to the rest of the OVN stack not responding to committed changes (GitHub Advisory, Incus Advisory).

• Network: Unexpected TLS connections to OVN database ports (default TCP 6641 for NB, 6642 for SB) from an IP address other than the legitimate OVN controller; ARP table anomalies on the management network indicating possible spoofing toward OVN database endpoints.
• Logs: Incus daemon logs (incusd) showing OVN connection errors or repeated reconnection attempts shortly after establishing a connection (indicative of interaction with an empty/rogue database); OVSDB client errors referencing unexpected schema or missing entries.
• Process/Behavior: Incus OVN operations (network creation, logical switch/router updates) failing with errors referencing OVN stack inconsistencies immediately after a connection is established, suggesting the connected database did not reflect the expected state.

Upgrade Incus to version 7.0.0 or later, which fixes the broken VerifyPeerCertificate logic by anchoring trust in the operator-configured CA pool rather than peer-supplied certificates (GitHub Advisory, Incus Advisory). As a compensating control, implement strict network segmentation to ensure OVN database ports are accessible only from authorized Incus servers (e.g., via firewall rules or dedicated management VLANs), reducing the attacker's ability to intercept or impersonate the OVN endpoint. Monitor management network traffic for ARP anomalies or unexpected connections to OVN database ports.

The vulnerability was discovered and responsibly disclosed by the security research team at 7asecurity. The Incus maintainer (stgraber) published the advisory and patch on April 30, 2026. The advisory itself characterizes the practical exploitability as "extremely difficult" given that the OVN control plane is typically co-located with Incus on the same servers with no routing between them (Incus Advisory). Tenable's Nessus scanner (plugin 311800) added detection for this vulnerability shortly after disclosure.