Vulnerabilidade no EKS Network Policy Agent permite bypass de NetworkPolicy entre pods

O boletim 2026-170-AWS: o que a AWS corrigiu

A AWS publicou hoje, 4 de novembro de 2026, o boletim de segurança 2026-170-AWS, classificado como Important (requer atenção). Ele descreve a CVE-2026-122266, uma falha de isolamento impróprio de estado compartilhado no aws-network-policy-agent, componente open source do Amazon VPC CNI responsável por aplicar NetworkPolicy do Kubernetes em clusters EKS.

O problema: um usuário autenticado e adjacente (ou seja, com um pod já rodando no mesmo nó) pode contornar a aplicação de regras de ingress do NetworkPolicy contra outros pods co-localizados naquele nó. Não é um bypass remoto nem anônimo, mas também não exige credenciais elevadas no cluster, só a capacidade de colocar uma carga de trabalho ali.

Como o bypass funciona: estado de conntrack compartilhado no eBPF

O aws-network-policy-agent usa programas eBPF para avaliar e aplicar regras de NetworkPolicy no caminho de rede de cada pod. Parte desse mecanismo depende de um estado de rastreamento de conexão (connection tracking, ou conntrack) para decidir se um pacote de entrada pertence a uma conexão já permitida.

Segundo o boletim, esse estado de conntrack é compartilhado entre pods do mesmo nó sem isolamento adequado. Na prática, isso significa que a decisão de aplicação do NetworkPolicy para um pod pode ser influenciada por entradas de conntrack geradas por outro pod vizinho, abrindo espaço para que tráfego de ingress que deveria ser bloqueado passe.

O ponto crítico para quem desenha a topologia do cluster: a falha não está na definição da política, está no mecanismo que a aplica. Um NetworkPolicy correto, revisado e testado continua inútil se o agente que o impõe tem esse defeito de isolamento.

Quem está exposto

Isso cobre tanto quem usa o VPC CNI como add-on gerenciado do EKS quanto quem roda o agente via Helm chart ou manifesto próprio, incluindo forks ou builds derivados do projeto. A AWS é explícita sobre esse último caso: recomenda que qualquer código derivado também incorpore a correção, já que o aws-network-policy-agent é open source.

Não há distinção de região no boletim. Clusters EKS em sa-east-1 (São Paulo) que usam o VPC CNI padrão para aplicar NetworkPolicy estão na mesma situação de qualquer outra região: é preciso checar a versão do add-on e atualizar.

Não existe workaround: atualizar é a única opção

A seção de workarounds do boletim é direta: "There are no workarounds available". Isso muda a prioridade da ação. Em boletins com mitigação temporária, dá para agendar a atualização numa janela de manutenção normal; aqui, enquanto o add-on não sobe de versão, o gap de isolamento continua aberto em qualquer nó que misture pods de diferentes times, namespaces ou níveis de confiança.

Primeiro passo, verificar a versão em uso. Se o VPC CNI está instalado como add-on gerenciado do EKS:

aws eks describe-addon \
 --cluster-name <nome-do-cluster> \
 --addon-name vpc-cni \
 --query 'addon.addonVersion'

Se o agente roda fora do fluxo de add-on gerenciado (instalação manual ou via Helm), o jeito mais direto é checar a imagem do container no DaemonSet aws-node:

kubectl get daemonset aws-node -n kube-system \
 -o jsonpath='{.spec.template.spec.containers[?(@.name=="aws-network-policy-agent")].image}'

Com a versão confirmada abaixo de 1.3.7 (agente) ou 1.22.3 (add-on), a atualização pelo add-on gerenciado é o caminho mais simples, via console do EKS ou aws eks update-addon apontando para a versão corrigida do VPC CNI. Quem mantém o agente fora do add-on gerenciado precisa rastrear a tag de imagem publicada e aplicar o rollout manualmente no DaemonSet.

O que isso muda para quem desenha clusters multi-tenant em EKS

NetworkPolicy aplicado por eBPF no nó é, na prática, a camada de microssegmentação mais barata que existe em EKS: não exige service mesh, não exige nós dedicados por tenant, só política declarativa em cima de uma topologia de nós compartilhados entre namespaces ou times. Muita arquitetura de cluster multi-tenant em produção se apoia justamente nessa premissa.

Essa CVE expõe o limite dessa premissa. O NetworkPolicy não é uma fronteira de isolamento equivalente a rodar workloads em nós separados ou em Fargate: ele depende de um agente de enforcement rodando no próprio nó, compartilhando kernel e, como ficou claro aqui, estado de conntrack com os pods que ele deveria estar isolando entre si.

Em resumo: para cargas de trabalho com níveis de confiança realmente diferentes (tenants distintos, dados sensíveis versus workloads de terceiros), NetworkPolicy continua sendo defesa em profundidade, não substituto de isolamento de compute. Node groups separados com taints e tolerations, ou perfis Fargate por tenant, continuam sendo o controle primário quando o requisito é isolamento forte, não só segmentação de tráfego.

O que ainda fica em aberto

O boletim não publica pontuação CVSS nem detalha o passo a passo de exploração, e não há menção a exploração ativa. A AWS também não especifica se a falha afeta igualmente todos os modos de operação do NetworkPolicy (standard versus strict mode do VPC CNI) ou se algum deles mitiga parcialmente o problema antes do patch.

Para acompanhar atualizações técnicas da falha, a referência é o advisory GHSA-mm5f-ggvx-hmvw no GitHub do projeto aws-network-policy-agent, além da própria entrada CVE-2026-122266. Dúvidas sobre o boletim vão para aws-security@amazon.com, o canal que a AWS indica no próprio comunicado.

Fonte: AWS Security Bulletins