Suse
CVE-2026-34992
HIGH
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessDeploy dual-stack Antrea cluster with IPsec enabled
-
ExploitSend IPv6 Pod traffic across nodes
-
ExecutionIntercept plaintext IPv6 packets on network
-
ImpactExtract sensitive Pod communication data
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V14 - Data Protection Encryption of sensitive data
|
| Exploitation Conditions | Antrea cluster configured for dual-stack networking with IPsec encryption enabled ( |
| Impact | Real-world risk is moderate and highly dependent on deployment context. Without CVSS scoring or EPSS probability data, assessment relies on environmental factors and technical impact analysis. The vulnerability requires specific preconditions: dual-stack cluster configuration with IPsec enabled, which narrows the affected population to organizations running modern IPv6-enabled Kubernetes infrastructure. Attack complexity is low once preconditions are met-passive network sniffing requires no authentication or user interaction. The primary impact is confidentiality loss through plaintext exposure of inter-Pod IPv6 traffic, which may contain application data, service mesh communications, or microservice API calls. Exploitation is not automatable in the SSVC sense (requires positioned network access), and no active exploitation is confirmed via CISA KEV. However, the silent failure mode is concerning: administrators believe traffic is encrypted when it is not, creating a false sense of security. Priority should be elevated for multi-tenant clusters, environments with compliance requirements (PCI-DSS, HIPAA), or networks where adversaries may have physical or virtualization-layer access to monitor traffic. Single-stack deployments face no risk, and the availability of patches across three release branches with a validation tool significantly reduces remediation burden. |
| Exploit ScenarioDerived | An attacker with network access between Kubernetes nodes in a dual-stack Antrea cluster (such as a compromised VM on the same hypervisor, access to network infrastructure, or lateral movement within a cloud VPC) uses packet capture tools like tcpdump or Wireshark to monitor inter-node traffic. While IPv4 Pod communications appear as encrypted ESP packets, the attacker observes that IPv6 traffic is transmitted in plaintext within Geneve or VXLAN encapsulation. By filtering for IPv6 packets, the attacker can read application payloads, API tokens, database queries, or other sensitive data exchanged between microservices, bypassing the intended encryption security control without triggering detection mechanisms that assume all inter-Pod traffic is encrypted. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Apr 03, 2026
IPv6 Pod traffic in Antrea dual-stack Kubernetes clusters transmits in plaintext despite IPsec encryption configuration, exposing inter-node communication to network eavesdropping. Affects Antrea versions prior to 2.6.0, 2.5.2, and 2.4.5 when dual-stack networking is enabled with trafficEncryptionMode: ipsec. Vendor-released patches are available across multiple stable branches. No public exploit identified at time of analysis, though the vulnerability bypasses intended encryption controls and could enable passive network monitoring in multi-tenant or untrusted network environments.
RemediationAI
Upgrade to Antrea version 2.6.0 or later for the current release branch, or apply the backported patches in versions 2.5.2 or 2.4.5 depending on your deployment stream. The upstream fix is implemented in GitHub pull request #7759 (https://github.com/antrea-io/antrea/pull/7759) and commit 738bad662b20a5d358d19466936176ef580a9b07. After upgrading, run the validation tool antctl check installation --run ipsec (introduced in PR #7757) to verify ESP traffic is correctly generated for both IPv4 and IPv6 address families. If immediate patching is not feasible, switch from IPsec to WireGuard encryption mode as a temporary workaround-WireGuard support in Antrea does not exhibit this IPv6 encryption failure. Consult the official Traffic Encryption Guide (https://github.com/antrea-io/antrea/blob/main/docs/traffic-encryption.md) for configuration details.
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in go
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
This vulnerability stems from a missing encryption implementation (CWE-311) in Antrea's IPsec traffic encryption subsystem. Antrea is a Kubernetes CNI (Container Network Interface) plugin written in Go that provides networking and security services for Pod-to-Pod communication. When configured for dual-stack networking (simultaneous IPv4 and IPv6), the IPsec encryption pathway correctly applies ESP (Encapsulating Security Payload) protocol to IPv4 traffic but completely bypasses encryption for IPv6 packets. The affected packets are still encapsulated using Geneve or VXLAN overlay protocols but traverse the network without cryptographic protection. This represents a partial feature failure where one address family receives intended security controls while the other silently degrades to plaintext transmission. The issue is specific to the IPsec encryption mode; Antrea's alternative WireGuard encryption implementation correctly handles both address families.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
Lifecycle Timeline
2DescriptionGitHub Advisory
Impact
This is a missing encryption vulnerability (CWE-311) affecting inter-Node Pod traffic. In Antrea clusters configured for dual-stack networking with IPsec encryption enabled (trafficEncryptionMode: ipsec), Antrea fails to apply encryption for IPv6 Pod traffic.
While the IPv4 traffic is correctly encrypted via ESP (Encapsulating Security Payload), traffic using IPv6 is transmitted in plaintext. This occurs because the packets are encapsulated (using Geneve or VXLAN) but bypass the IPsec encryption layer.
Impacted Users: users with dual-stack clusters and IPsec encryption enabled.
Single-stack IPv4 or IPv6 clusters are not affected.
Patches
Yes, the issue has been patched: https://github.com/antrea-io/antrea/pull/7759 Users should upgrade to one of the following versions:
- Antrea v2.6.0 or later
- Antrea v2.5.2
- Antrea v2.4.5
Antrea recommends running the antctl check installation --run ipsec tool after upgrading to verify that both address families are correctly producing ESP traffic.
Workarounds
There is no configuration workaround to enable IPsec IPv6 in affected versions. If an immediate upgrade is not possible, user may consider using WireGuard instead for inter-Node Pod traffic encryption. The WireGuard support in Antrea does *not* suffer from the same issue.
Resources
Pull Request with Fix: antrea-io/antrea#7759 Validation Tool PR: antrea-io/antrea#7757 Antrea Documentation: Traffic Encryption Guide
Executive ViewAI
Antrea's IPsec encryption fails to protect IPv6 pod traffic in dual-stack Kubernetes clusters, leaving inter-node communication exposed to network eavesdropping despite active encryption configuration. Organizations running Antrea with dual-stack networking and IPsec enabled face unencrypted data transmission between cluster nodes, creating compliance and confidentiality risks in shared or untrusted network environments.
Apply vendor patch. If immediate patching is infeasible: (1) Disable trafficEncryptionMode: ipsec until patch deployment, accepting temporary loss of encryption; (2) Restrict network access to cluster nodes using network ACLs or firewall rules to limit exposure to trusted networks only; (3) Segment cluster traffic to isolated VLANs or network zones to reduce eavesdropping surface.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Affected Products (CPE)GitHub Advisory
Same weakness CWE-311 – Missing Encryption of Sensitive Data
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: Important| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
GHSA-qcmw-8mm4-4p28
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB