[EKS] [request]: AMI and vpc-cni builds with Go 1.25.13 / 1.26.6 for CVE-2026-39821

**Community Note**

> Please vote on this issue by adding a thumbs-up reaction to the original issue to help the community and maintainers prioritize this request. Please do not leave "+1" or "me too" comments.

**Tell us about your request**

Could the EKS team share a target timeline for shipping EKS-optimized AMIs (AL2023) and a `vpc-cni` addon build with Go binaries rebuilt against Go 1.25.13 / 1.26.6, clearing [CVE-2026-39821](https://nvd.nist.gov/vuln/detail/CVE-2026-39821)?

The flaw is in `golang.org/x/net/idna`: `ToASCII` / `ToUnicode` incorrectly accept Punycode-encoded labels that decode to an ASCII-only label, so `ToUnicode("xn--example-.com")` returns `example.com` instead of an error. NVD scores it **9.6 Critical** (`CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N`). Fixed in Go **1.25.13** and **1.26.6**, both released **2026-08-13**.

**Which service(s) is this request for?**

Amazon EKS: the EKS-optimized AMI (AL2023) and the `vpc-cni` managed addon.

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**

Amazon Inspector reports this as one finding per instance listing **24 vulnerable paths per node**, spanning two separately-versioned AWS-owned artefacts. There is no customer-side remedy for either: the Go runtime is statically linked into binaries AWS builds and ships, so OS-level patching does not clear it (the same dynamic described for `go/stdlib` on EKS in [this re:Post question](https://repost.aws/questions/QUVU6Hh1PpRripqTGx8nCS1g/eta-for-eks-optimized-ami-patching-cve-2025-68121-go-stdlib-1-25-1)).

Owned by the **AMI** (4 paths per node):

| Path | Go version | Fixed in |
|---|---|---|
| `/usr/bin/kubelet` | 1.25.12 | 1.25.13 |
| `/etc/eks/image-credential-provider/ecr-credential-provider` | 1.25.12 | 1.25.13 |
| `/usr/bin/nodeadm` | 1.26.2 | 1.26.6 |
| `/usr/bin/nodeadm-internal` | 1.26.2 | 1.26.6 |

Owned by the **`vpc-cni` addon** (20 paths per node): every binary under `/opt/cni/bin/` (`aws-cni`, `bandwidth`, `bridge`, `dhcp`, `dummy`, `egress-cni`, `firewall`, `host-device`, `host-local`, `ipvlan`, `loopback`, `macvlan`, `portmap`, `ptp`, `sbr`, `static`, `tap`, `tuning`, `vlan`, `vrf`), all at Go **1.26.5**, fixed in 1.26.6.

**What we tried, and why upgrading did not help**

We rolled a node group to the newest published AMI and the newest available addon and re-scanned after Inspector coverage returned `ACTIVE / SUCCESSFUL`:

- `node_release_version` `1.35.6-20260818` -> `1.35.7-20260827` (the latest release, published 2026-08-28)
- `vpc_cni_version` `v1.22.4-eksbuild.3` -> `v1.23.0-eksbuild.1` (the newest version offered for a 1.35 control plane)

**All 24 paths came back at identical Go versions.** `1.35.7-20260827` ships the same builds as `1.35.6-20260818` despite being built 2026-08-27, two weeks after the fixed Go releases. `v1.23.0-eksbuild.1` ships the same 1.26.5 as `v1.22.4-eksbuild.3`, which is consistent with its upstream release date of 2026-08-07, six days before Go 1.26.6 existed.

So there is currently no published EKS AMI or `vpc-cni` addon version that clears this CVE, and no version to upgrade to.

For contrast, the same CVE was resolved on the Lambda side within about eight days: [aws/aws-lambda-base-images#664](https://github.com/aws/aws-lambda-base-images/issues/664) was opened 2026-08-14 and closed 2026-08-22 once rebuilt images shipped. The rebuild is evidently routine; it just has not reached the EKS artefacts.

**Questions**

1. Is there a target AMI release for AL2023 carrying `kubelet` and `ecr-credential-provider` built on Go >= 1.25.13, and `nodeadm` / `nodeadm-internal` on >= 1.26.6?
2. Is there a target `vpc-cni` eksbuild carrying `/opt/cni/bin/*` on Go >= 1.26.6?
3. More generally: is there a policy on how quickly EKS AMI and addon binaries are rebuilt after a Go security release? A build dated two weeks after the fix still carrying pre-fix binaries suggests the toolchain bump is not tied to the AMI build, and knowing the intended lag would help customers plan node rotation windows instead of rolling nodes speculatively as we did.

**Are you currently working around this issue?**

No usable workaround exists. The binaries cannot be replaced without diverging from the managed AMI and addon. We are holding node rotation on our pilot-customer environments rather than rolling nodes for a change proven to be a no-op, and assessing reachability to decide whether to accept the risk on a time-boxed basis.

Start with the listed AMI paths (/usr/bin/kubelet, /etc/eks/image-credential-provider/ecr-credential-provider, /usr/bin/nodeadm, and /usr/bin/nodeadm-internal) and the /opt/cni/bin/* addon binaries, then review the current EKS AMI and vpc-cni versions. Done means AWS publishes artifacts using Go 1.25.13 or newer and Go 1.26.6 or newer, with the CVE cleared.

Written by the indexing model from the issue text.