Summary
- CVE-2026-122266 affects the handling of shared eBPF connection-tracking information in Amazon EKS.
- An authenticated adjacent user could potentially bypass ingress restrictions protecting co-located workloads.
- AWS has released corrected agent and VPC CNI versions and says no workaround fully addresses the flaw.
A security weakness in Amazon Web Services network policy enforcement could allow an authenticated attacker to bypass restrictions protecting other Kubernetes workloads, undermining separation controls used within certain Amazon EKS clusters.
AWS disclosed CVE-2026-122266 on 4 November, identifying a problem in the Amazon EKS Network Policy Agent involving insufficient isolation of shared connection-tracking information.
Under the affected conditions, an authenticated adjacent user could cause network traffic to bypass ingress restrictions intended to protect co-located pods. The vendor has released corrected software and says no workaround fully addresses the vulnerability.
The flaw affects aws-network-policy-agent versions earlier than 1.3.7 and Amazon VPC CNI managed add-on versions earlier than 1.22.3.
Connection tracking crosses an enforcement boundary
Amazon Elastic Kubernetes Service provides managed Kubernetes infrastructure for deploying and operating containerised applications.
Kubernetes commonly runs multiple applications or components within the same cluster. NetworkPolicy objects allow administrators to define which workloads may exchange traffic, providing an additional layer of separation between services.
These restrictions can be particularly important where applications process information of differing sensitivity or where a cluster hosts services with different operational responsibilities.
Amazon’s Network Policy Agent is an open-source component of the VPC Container Network Interface. It helps enforce Kubernetes network policies by evaluating traffic against the restrictions assigned to workloads.
The affected implementation uses extended Berkeley Packet Filter technology, or eBPF, to support network traffic inspection and policy decisions.
Connection tracking allows the component to maintain information about network flows, including state needed to apply policies consistently across related packets.
AWS says inadequate isolation of shared eBPF connection-tracking state could permit traffic associated with one workload to influence enforcement decisions for another.
As a result, an authenticated adjacent user could potentially bypass ingress restrictions on pods located on the same underlying infrastructure.
The affected pods may belong to different Kubernetes namespaces. Namespaces organise resources and provide a basis for applying policies, but they do not independently guarantee network isolation.
Where administrators depend on NetworkPolicy rules to restrict traffic between namespaces, a bypass of the enforcement layer can invalidate an important security assumption.
Exposure depends on workload access
The vulnerability does not mean that an unauthenticated internet user can automatically enter any Amazon EKS cluster.
AWS specifically identifies an authenticated adjacent user as the potential attacker. Exploitation therefore requires an existing position from which the affected network policy component can be influenced.
Nor does bypassing an ingress policy necessarily provide access to protected application data. The attacker may gain network reachability to a service that was intended to be inaccessible, while application authentication, authorisation, and other controls continue to operate independently.
The practical consequences depend on the services present, their placement within the cluster, and whether they rely on network isolation as part of their security design.
In shared environments, those dependencies can be substantial. Production applications, internal APIs, development services, and administrative components may coexist within one Kubernetes infrastructure estate.
A compromised workload could become more consequential if its network restrictions fail to prevent communication with more sensitive services.
Amazon’s documentation also notes that VPC CNI NetworkPolicy enforcement is not enabled by default in every newly provisioned cluster. Identifying affected installations therefore requires examining both installed component versions and the network policy configuration actually in use.
Corrected components and remaining controls
AWS says the vulnerability was corrected in Network Policy Agent 1.3.7 and Amazon VPC CNI version 1.22.3.
The company recommends upgrading to the latest available versions and ensuring that any modified or forked implementations incorporate the security fixes.
That recommendation is particularly relevant to organisations maintaining their own container networking components, where a security correction released upstream may not automatically reach customised deployments.
NetworkPolicy rules also require suitable monitoring and testing. AWS provides guidance covering policy enforcement logs and controlled checks of expected traffic restrictions.
Those activities cannot replace the corrected software, but they can help establish whether network isolation behaves as intended after a change.
AWS has not reported confirmed exploitation of CVE-2026-122266 in its advisory. The company has published the affected version ranges and fixes, leaving operators to determine whether their configurations rely on the vulnerable enforcement component.
