AWS’s EKS advisory puts pod isolation back on the test plan

A Kubernetes policy can say exactly the right thing while the software enforcing it gets the decision wrong. On November 4, 2026, AWS published CVE-2026-122266, an ingress policy bypass in the Network Policy Agent used by the Amazon VPC CNI on EKS. Under the conditions in the advisory, an attacker with authenticated access from an adjacent workload could reach a pod on the same node that should have rejected the connection. That can include a pod in another namespace. [1] [2]

Where the decision goes wrong

A Kubernetes NetworkPolicy describes which connections pods may accept or initiate. Ingress means traffic coming in. The cluster's networking component has to enforce those rules; storing a policy in the Kubernetes API does not, by itself, filter a packet. The affected AWS agent does that work for clusters using this implementation. [2] [5]

The agent uses an eBPF map, a table in the Linux kernel, to track connections. The maintainers found that crafted traffic from a workload can corrupt shared tracking state in a way that causes the agent to skip the destination pod's ingress rules. The advisory concerns clusters with this enforcement enabled and pods that share a node. It does not describe an outage, or say that anyone on the internet can reach every EKS workload. [2]

Imagine a cluster hosting an import worker and an internal reporting service. They sit in different namespaces, and the reporting service accepts requests from a designated application. If the worker and service share a node, the policy is supposed to keep the worker from opening that connection. Reaching the service through this flaw would not automatically log the worker in. But the service would have to rely on its own authentication and authorization at a point where its operators expected the network to turn the request away.

The advisory is newer than the fix

AWS lists Network Policy Agent versions before 1.3.7 and managed Amazon VPC CNI add-on versions before 1.22.3 as affected. The fixed versions are 1.3.7 and 1.22.3, respectively. Both upstream releases were published on July 6, 2026; the November bulletin explains the security issue those releases address. AWS gives no workaround and advises updating affected installations and incorporating the fixes in forks. Use the fixed release appropriate to your installation and Kubernetes version. [1] [2] [3] [4]

That timing changes the first conversation. Some teams may already have rolled out the fix during ordinary maintenance. Others may have updated their cluster's Kubernetes version while carrying an older networking component. The useful record is the deployed add-on and agent, including which node groups still run older images. A target version in a change request tells you what someone intended to install; the running workload tells you what got there.

A cluster with separate pools for long running services and short jobs is a useful example. During a phased rollout, the services might move first while jobs keep landing on an older pool. Confirming the update on a single node or in a single environment cannot settle which side of the boundary the rest of the fleet is running.

The test that proves the rule is doing its job

The check we would want after a rollout has two sides. The reporting service should still work from the application that is allowed to call it. A workload that should be denied should still be denied, including when both pods share a node. A successful request by itself only verifies the friendly half of the rule. A failed request also needs context: if the service was down, that failure says nothing about enforcement.

The published advisory is evidence of a weakness in a component, not evidence that a particular cluster was compromised. For a team assessing past exposure, placement and access matter alongside the installed version: what ran together, which workloads could initiate traffic, and what protection the destination applied independently? Those answers help decide whether this is a patch verification task or something that needs closer investigation. [1] [2]

A useful handoff to the next operator is small: the nodes covered, the agent and add-on versions observed, and the outcomes of an allowed and a denied request. That is a better picture of pod isolation than a tidy policy file on its own.