Cve on ICE-ICE-BEAR-BLOG

Next.js v16.2.6 — One Release That Closes 13 Security Advisories at Once

Fri, 08 May 2026 00:00:00 +0900

Overview

On 2026-05-07, vercel/next.js shipped v16.2.6, a single release that closes 13 security advisories at once — 7 High, 4 Moderate, 2 Low. The most accurate one-line read came from the chat room itself: “Looking at the patch notes, you’ll be in trouble if you don’t upgrade — extremely critical.” What stands out is not the count but the shape: three Middleware/Proxy bypasses across different surfaces, one WebSocket SSRF, and three cache-poisoning advisories — these aren’t isolated bugs, they’re a common pattern.

graph TD
 Release["Next.js v16.2.6 <br/> 2026-05-07"] --> Bypass["Middleware/Proxy <br/> Bypass × 3"]
 Release --> SSRF["SSRF × 1"]
 Release --> Cache["Cache poisoning × 3"]
 Release --> XSS["XSS × 2"]
 Release --> DoS["DoS × 3"]
 Release --> Other["follow-up × 1"]

 Bypass --> B1["GHSA-267c-6grr-h53f <br/> segment-prefetch"]
 Bypass --> B2["GHSA-492v-c6pp-mqqv <br/> dynamic route param"]
 Bypass --> B3["GHSA-36qx-fr4f-26g5 <br/> Pages Router i18n"]

 SSRF --> S1["GHSA-c4j6-fc7j-m34r <br/> WebSocket upgrade"]

 Cache --> C1["GHSA-wfc6-r584-vfw7 <br/> RSC response"]
 Cache --> C2["GHSA-vfv6-92ff-j949 <br/> RSC cache-busting"]
 Cache --> C3["GHSA-3g8h-86w9-wvmq <br/> redirect"]

 XSS --> X1["GHSA-ffhc-5mcf-pf4q <br/> CSP nonce"]
 XSS --> X2["GHSA-gx5p-jg67-6x7h <br/> beforeInteractive"]

 DoS --> D1["GHSA-8h8q-6873-q5fj <br/> Server Components"]
 DoS --> D2["GHSA-mg66-mrh9-m8jx <br/> Cache Components"]
 DoS --> D3["GHSA-h64f-5h5j-jqjh <br/> Image API"]

 Other --> O1["GHSA-26hh-7cqf-hhc6 <br/> incomplete fix"]

1. Middleware/Proxy Bypass × 3 — The Most Dangerous Cluster

Middleware/Proxy is the layer where authentication, authorization, and redirects run before a route is reached. If you can bypass that layer, your auth is meaningless. v16.2.6 closes bypasses found in three different surfaces at once.

GHSA-267c-6grr-h53f — middleware bypass via App Router segment-prefetch routes (High)
GHSA-26hh-7cqf-hhc6 — incomplete-fix follow-up to the above (High)
GHSA-492v-c6pp-mqqv — middleware bypass via dynamic route parameter injection (High)
GHSA-36qx-fr4f-26g5 — middleware bypass via Pages Router i18n routing (High)

The fact that the same class of bug appeared on three different surfaces (App Router segments, dynamic routes, Pages Router i18n) is itself the message. This is not a single bug — it’s a class of bugs where Middleware path matching and the actual router disagree on what a path means. The fact that the team also bundled the incomplete-fix follow-up (26hh-7cqf-hhc6) into the same release deserves credit — it minimizes the window in which a known-incomplete patch is exposed.

2. SSRF — WebSocket Upgrades

GHSA-c4j6-fc7j-m34r — Server-Side Request Forgery via WebSocket upgrade handling (High)

A WebSocket upgrade path could be coerced into making outbound requests, meaning an attacker could scan the internal network, hit cloud metadata endpoints, or call protected internal APIs through the server. Apps with realtime/streaming features are squarely in the blast radius.

3. Cache Poisoning × 3

GHSA-wfc6-r584-vfw7 — cache poisoning of RSC responses (Moderate)
GHSA-vfv6-92ff-j949 — poisoning via RSC cache-busting collisions (Low)
GHSA-3g8h-86w9-wvmq — Middleware/Proxy redirects can be cache-poisoned (Low)

React Server Components responses are commonly cached at the CDN/Edge layer. Once those caches are poisoned, arbitrary users get the malicious response served to them. Two of these are directly attacker-triggerable. The Moderate/Low labels can underplay the real impact depending on your edge cache topology.

4. XSS × 2

GHSA-ffhc-5mcf-pf4q — XSS via App Router CSP nonce handling (Moderate)
GHSA-gx5p-jg67-6x7h — XSS when untrusted input reaches the beforeInteractive script strategy (Moderate)

CSP nonces are the last line of defense against XSS, and the bug being inside that mechanism is what makes it nasty. beforeInteractive runs the earliest and most privileged scripts on the page — there isn’t a good way to recover from untrusted input at that stage.

5. DoS × 3

GHSA-8h8q-6873-q5fj — Server Components DoS (High)
GHSA-mg66-mrh9-m8jx — Cache Components connection-exhaustion DoS (High)
GHSA-h64f-5h5j-jqjh — Image Optimization API DoS (Moderate)

All three are remotely triggerable at low cost, which is why they earned High/Moderate. Cache Components exhausts connections; the Image API burns transform budget.

What to Do Right Now

npm install next@16.2.6
yarn add next@16.2.6
pnpm add next@16.2.6
bun add next@16.2.6

Apps using App Router + Middleware for auth should upgrade immediately. Combine the three bypass advisories and you can reach a state where authentication is effectively bypassed. While you roll out the fix, consider blocking suspicious segment-prefetch patterns and unusual query parameters at the WAF/CDN layer as a temporary buffer.

Insights

Triage priority is unambiguous — 3 bypasses + 1 SSRF + 3 cache-poisoning advisories landing in one release is itself the loudest signal in this batch. The fact that middleware bypass appeared on three different surfaces says it isn’t one bug; it’s a class of defect where the App Router’s matching logic and the router’s actual resolution disagree about what a path is. Even adjusting for Next.js 16 being a relatively new major, 13 advisories in one release is unusual. Bundling the incomplete-fix follow-up into the same release is a good example of responsible disclosure — it shrinks the window when an unfinished patch is in the wild. The chat room’s instinct — “extremely critical” — is right: this should be the highest-priority upgrade in your queue. Zooming out, the release is a hint that the App Router routing model itself deserves more fuzzing and audit. As long as middleware matching and the router are independent, the same class of bug is likely to surface again.

References

Release

vercel/next.js · v16.2.6 release notes (published 2026-05-07)

High severity advisories

GHSA-8h8q-6873-q5fj — Server Components DoS
GHSA-267c-6grr-h53f — App Router segment-prefetch bypass
GHSA-26hh-7cqf-hhc6 — incomplete-fix follow-up
GHSA-mg66-mrh9-m8jx — Cache Components DoS
GHSA-492v-c6pp-mqqv — dynamic-route bypass
GHSA-c4j6-fc7j-m34r — WebSocket SSRF
GHSA-36qx-fr4f-26g5 — Pages Router i18n bypass

Moderate / Low advisories

GHSA-ffhc-5mcf-pf4q — App Router CSP-nonce XSS (Moderate)
GHSA-gx5p-jg67-6x7h — beforeInteractive XSS (Moderate)
GHSA-h64f-5h5j-jqjh — Image Optimization DoS (Moderate)
GHSA-wfc6-r584-vfw7 — RSC cache poisoning (Moderate)
GHSA-vfv6-92ff-j949 — RSC cache-busting collision (Low)
GHSA-3g8h-86w9-wvmq — Middleware redirect cache poisoning (Low)

Next.js docs

EKS AMI CVE-2026-31431 Copy-Fail — Patch Delay and the algif_aead Mitigation

Mon, 04 May 2026 00:00:00 +0900

Overview

On 2026-04-30, awslabs/amazon-eks-ami issue #2699 opened with a simple title — “🚨 Patch for: CVE-2026-31431.” AWS support’s answer was “no patch yet, no ETA,” and meanwhile a container-escape PoC went public. It took six days for EKS AMI v20260505 to ship — and during those six days, the community’s mitigation moved faster than the official patch.

flowchart TD
 A["2026-04-30 <br/> Issue #2699 opens"] --> B["05-01 <br/> v20260423 AMI confirmed vulnerable"]
 B --> C["05-01 <br/> AWS: no patch, no ETA"]
 C --> D["05-01 <br/> algif_aead module-load mitigation"]
 D --> E["05-01 <br/> kernel.org 6.12 mainline commit 8b88d99 merged"]
 E --> F["05-02 <br/> SSM Run Command rollout to clusters"]
 F --> G["05-04 <br/> Chat thread: Docker seccomp option"]
 G --> H["05-05 <br/> Amazon Linux kernel fix released"]
 H --> I["05-06 <br/> EKS AMI v20260505 release"]

CVE-2026-31431 — Copy-Fail in a Nutshell

The vulnerability lives in the Linux kernel’s algif_aead — the AEAD interface of the AF_ALG socket family. The community calls it “Copy-Fail.” Three things matter.

Locally authenticated users can trigger it. No remote unauthenticated path.
Container escape is feasible in container workloads — direct impact on multi-tenant K8s clusters, CI runners, and sandbox environments.
Public PoC: Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC
GitHub advisory: GHSA-2274-3hgr-wxv6

“Local” is the weakest assumption you have in K8s. It means an unprivileged process inside an apparently fine container can reach into the host kernel.

Timeline — Issue #2699

Date	Event
2026-04-30	Issue #2699 opens. Title: “🚨 Patch for: CVE-2026-31431”
05-01	Community check: even the latest v20260423 AMI (kernel 6.12.79-101.147.amzn2023) is still vulnerable
05-01	AWS support reply: “no patch, no ETA available”
05-01	AWS official mitigation guide — block loading of the `algif_aead` module
05-01	The 6.12 mainline kernel had merged commit 8b88d99 about 10 hours earlier
05-02	A user rolls out the mitigation cluster-wide via AWS SSM Run Command
05-04	Community discussion: “for Docker users, you can also block this in seccomp” — proposes an additional mitigation surface
05-05	Amazon Linux kernel fix — see the ALAS-2026 page
05-06	EKS AMI v20260505 release — kernel 6.12.80-106.156 / 6.1.168-203.330. Issue scheduled to be locked.

AWS’s Pre-Patch Mitigation

The idea is simple — block the vulnerable kernel module from loading at all.

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true

install algif_aead /bin/false tells modprobe to run /bin/false instead of loading the module — meaning it never loads. rmmod removes the module if it is already loaded.

Cluster-Wide Rollout — SSM Run Command

A pattern shared in the issue comments.

aws ssm send-command \
 --region eu-west-3 \
 --document-name "AWS-RunShellScript" \
 --targets "Key=tag:eks:cluster-name,Values={{CLUSTER_NAME}}" \
 --parameters 'commands=[
 "echo \"install algif_aead /bin/false\" > /etc/modprobe.d/disable-algif.conf",
 "rmmod algif_aead 2>/dev/null || true",
 "lsmod | grep algif && echo STILL_LOADED || echo MITIGATED"
 ]' \
 --comment "CVE-2026-31431 mitigation"

The last line is a verification check — if lsmod | grep algif is empty, the module is gone. Even with dozens of nodes per cluster, this is one command.

Bake into Managed Node Group / Karpenter UserData

One user’s playbook: bake the mitigation into the Karpenter NodePool UserData so every newly provisioned node boots already protected. Existing nodes get a one-shot SSM application, new nodes are auto-handled by UserData — low impact, low effort.

The standard rollout discipline applies: verify the PoC is blocked, confirm sidecar and DaemonSet compatibility, then stage the rollout.

Bottlerocket Is a Separate Track

A commenter reported: “Bottlerocket AMI clusters can’t apply this mitigation. This probably belongs in the other repo.” Bottlerocket has a read-only filesystem and a different module-loading policy, so it has to be tracked over at bottlerocket-os.

The AWS Communication Critique

The single thread that runs through the whole issue: “AWS communicated poorly.”

Other managed-K8s vendors sent advance warning emails. AWS sent nothing.
A specific ETA — “AMI within X days of upstream patch” — would have helped operators plan.
While the community was tracking the PoC and the mainline commit themselves, AWS support’s answer was still “no ETA.”

That tension is exactly why the issue was set to be locked once v20260505 shipped.

Insights

The real signal in this issue isn’t the patch — it’s the shape of the timeline. About six days passed between the mainline kernel merge and the EKS AMI release, and during those six days the PoC was already public, meaning container escape was demonstrably reachable in multi-tenant K8s, CI runners, and sandbox setups. So what operators actually needed wasn’t “a patch is coming,” but “how do we survive six days before the patch.” The answer fits in two lines — apply the algif_aead module block to every node immediately via SSM, and bake it into Karpenter and Managed Node Group UserData so new nodes come up already protected. AWS’s “no ETA” reply is a separate problem; while other managed hosting providers were sending advance warning emails, AWS stayed silent, which means operations teams need to monitor information sources beyond official channels — issue trackers, community chat rooms, kernel.org — as a baseline practice. The fact that a 2026-05-04 chat thread was already debating “block it via Docker seccomp instead” is the proof: the community recognized the threat faster than the official announcement. The same pattern will repeat with the next CVE, and repo subscriptions + community channels + the ALAS feed should be the standard ops posture.

References

Issue and AMI release

awslabs/amazon-eks-ami issue #2699 — 🚨 Patch for: CVE-2026-31431
EKS AMI v20260505 release — kernel 6.12.80-106.156 / 6.1.168-203.330 (published 2026-05-06)

CVE / advisories

GHSA-2274-3hgr-wxv6 — GitHub advisory
Linux kernel commit 8b88d99 — mainline fix
Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC — container-escape PoC
Linux algif_aead userspace API docs
Amazon Linux Security Center (ALAS)

Mitigation references

AWS SSM Run Command
Karpenter — for UserData baking
Bottlerocket · bottlerocket-os GitHub — separate track