Cve on ICE-ICE-BEAR-BLOG

Next.js v16.2.6 — 13개 보안 권고를 한 릴리스에 묶은 긴급 패치

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

개요

vercel/next.js가 2026-05-07 v16.2.6 릴리스에서 13개 보안 권고를 한꺼번에 닫았다. High 7건 / Moderate 4건 / Low 2건. 현장 한 줄 평이 가장 정확하다 — “패치 내용 보니 안 하면 큰일 날 거 같습니다 / 엄청 크리티컬해요”. 특히 App Router와 Middleware/Proxy가 얽힌 인증·인가 우회 권고가 3건, WebSocket SSRF 1건, 캐시 오염 권고가 3건 — 표면이 다양해서 단일 버그가 아니라 공통 패턴이 드러난다.

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 응답"]
 Cache --> C2["GHSA-vfv6-92ff-j949 <br/> RSC 캐시-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 — 가장 위험한 묶음

Middleware/Proxy는 라우트 진입 전 인증·인가·리다이렉트를 처리하는 곳이다. 이 레이어를 우회할 수 있다면 인증 자체가 무의미해진다. v16.2.6은 서로 다른 표면 3곳에서 우회 경로를 한꺼번에 닫았다.

GHSA-267c-6grr-h53f — App Router segment-prefetch route를 통한 미들웨어 우회 (High)
GHSA-26hh-7cqf-hhc6 — 위 권고의 incomplete fix follow-up (High)
GHSA-492v-c6pp-mqqv — dynamic route 파라미터 인젝션을 통한 미들웨어 우회 (High)
GHSA-36qx-fr4f-26g5 — Pages Router의 i18n 라우팅 을 통한 미들웨어 우회 (High)

세 표면(App Router segment / dynamic route / Pages Router i18n)에서 동시 발견됐다는 점이 메시지다. 단일 버그가 아니라 라우팅 모델 전반의 공통 패턴 — 미들웨어 매칭 로직과 실제 라우팅이 같은 경로를 다르게 해석하는 클래스의 결함이다. 게다가 26hh-7cqf-hhc6은 이전 패치의 incomplete fix를 같은 릴리스에 묶어 닫았다 — 외부에 불완전 패치가 노출되는 시간을 최소화한 점은 칭찬할 만하다.

2. SSRF — WebSocket upgrade

GHSA-c4j6-fc7j-m34r — WebSocket upgrade 처리에서 SSRF (High)

WebSocket upgrade 핸들링에서 Server-Side Request Forgery가 가능했다. 공격자가 서버를 통해 내부 네트워크 스캔, metadata endpoint 호출, 보호받는 내부 API 호출까지 시도할 수 있다는 뜻이다. Realtime/스트리밍 기능을 쓰는 앱은 직격탄.

3. 캐시 오염 × 3

GHSA-wfc6-r584-vfw7 — RSC 응답 캐시 오염 (Moderate)
GHSA-vfv6-92ff-j949 — RSC cache-busting 충돌을 통한 오염 (Low)
GHSA-3g8h-86w9-wvmq — Middleware/Proxy redirect 가 캐시 오염 가능 (Low)

React Server Components 응답이 CDN/Edge에서 캐싱되는 게 일반적인 만큼, 캐시가 한 번 오염되면 임의 사용자에게 악성 응답이 노출된다. 공격자가 직접 트리거 가능한 경로가 두 개. Severity가 Moderate/Low로 표시됐지만, Edge 캐시 토폴로지에 따라 실제 영향이 등급보다 클 수 있다.

4. XSS × 2

GHSA-ffhc-5mcf-pf4q — App Router의 CSP nonce 처리에서 XSS (Moderate)
GHSA-gx5p-jg67-6x7h — beforeInteractive 스크립트에 untrusted input 주입 시 XSS (Moderate)

CSP nonce는 XSS를 막기 위한 마지막 방어선인데 거기 자체에 결함이 있었다는 게 핵심. beforeInteractive는 hydration 전에 실행되는 가장 위험한 위치라 untrusted input이 들어오면 손쓸 방법이 거의 없다.

5. DoS × 3

GHSA-8h8q-6873-q5fj — Server Components DoS (High)
GHSA-mg66-mrh9-m8jx — Cache Components 커넥션 고갈 DoS (High)
GHSA-h64f-5h5j-jqjh — Image Optimization API DoS (Moderate)

세 권고 모두 외부에서 비교적 적은 비용으로 트리거 가능한 종류라 High/Moderate가 붙었다. Cache Components는 커넥션 고갈, Image API는 변환 비용을 통해 자원을 소진하는 패턴이다.

즉시 해야 할 것

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

App Router + Middleware로 인증·인가를 처리하는 앱은 즉시 업그레이드. Bypass 권고 3건이 합쳐지면 인증 자체가 의미 없어지는 시나리오가 있다. 업그레이드 전에 WAF/CDN 레이어에서 임시로 segment-prefetch 패턴과 의심스러운 ? query 파라미터를 차단하는 것도 고려.

인사이트

Triage 우선순위는 명확하다 — Bypass 3건 + SSRF 1건 + Cache poisoning 3건이 같은 릴리스에 묶였다는 사실 자체가 가장 큰 시그널이다. Middleware 우회가 세 다른 표면에서 동시 발견된 건 단일 버그가 아니라 App Router의 라우팅 모델과 Middleware 매칭 로직이 같은 경로를 다르게 해석하는 클래스의 결함이라는 뜻이다. Next.js 16이 비교적 신버전이라는 점을 감안해도, 한 릴리스에 13건이 묶이는 건 흔치 않다. Vercel 팀이 incomplete-fix follow-up을 같은 릴리스로 묶어 외부 노출 시간을 최소화한 점은 책임감 있는 disclosure의 좋은 사례. 현장 반응 “엄청 크리티컬해요” 가 정확하고, upgrade triage에서 highest priority로 다뤄야 한다. 더 큰 그림으로 보면, 이번 릴리스는 App Router의 라우팅 모델 자체에 대한 fuzz/감사가 더 필요했다는 신호다 — 미들웨어 매칭 로직과 라우팅이 분리돼 있는 한 같은 클래스의 결함은 또 나올 가능성이 높다.

참고

Release

vercel/next.js · v16.2.6 릴리스 노트 (2026-05-07 published)

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 — 패치 지연과 algif_aead 미티게이션

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

개요

2026-04-30, awslabs/amazon-eks-ami issue #2699 가 열렸다. 제목은 단순했다 — “🚨 Patch for: CVE-2026-31431”. 하지만 AWS의 답은 “패치 없음, ETA 못 줌” 이었고, 그동안 컨테이너 탈출 PoC가 공개됐다. 결국 v20260505 EKS AMI가 6일 뒤 풀릴 때까지, 공식 패치보다 커뮤니티의 미티게이션이 먼저 움직인 사례다.

flowchart TD
 A["2026-04-30 <br/> 이슈 #2699 오픈"] --> B["05-01 <br/> v20260423 AMI도 취약 확인"]
 B --> C["05-01 <br/> AWS: 패치 없음, ETA 없음"]
 C --> D["05-01 <br/> algif_aead 모듈 차단 미티게이션"]
 D --> E["05-01 <br/> kernel.org 6.12 메인라인 commit 8b88d99 머지"]
 E --> F["05-02 <br/> SSM Run Command로 일괄 적용"]
 F --> G["05-04 <br/> 커뮤니티 토론: Docker seccomp 차단 옵션"]
 G --> H["05-05 <br/> Amazon Linux 커널 fix released"]
 H --> I["05-06 <br/> EKS AMI v20260505 릴리스"]

CVE-2026-31431 — Copy-Fail 핵심

이 취약점은 리눅스 커널의 algif_aead — AF_ALG socket의 AEAD interface — 에 있는 메모리 처리 결함이다. 통칭 “Copy-Fail” 로 불린다. 핵심 특성 세 가지.

로컬 인증된 사용자가 트리거 가능. 원격 비인증 공격은 불가
컨테이너 워크로드에서 컨테이너 탈출이 가능 — 멀티테넌트 K8s, CI runner, sandbox에 직접 영향
공개 PoC: Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC
GitHub 어드바이저리: GHSA-2274-3hgr-wxv6

원격 공격자가 직접 트리거할 수는 없지만, “로컬"이라는 단어가 K8s 환경에서는 가장 약한 가정이다. 멀쩡한 컨테이너 안에서 unprivileged process 가 호스트 커널을 건드릴 수 있다는 뜻.

사건 흐름 — 이슈 #2699

날짜	진행
2026-04-30	issue #2699 오픈. 제목: “🚨 Patch for: CVE-2026-31431”
05-01	커뮤니티 검증: 최신 v20260423 AMI의 커널 6.12.79-101.147.amzn2023 도 여전히 취약
05-01	AWS 서포트 답변: “패치 없음, ETA 못 줌”
05-01	AWS 공식 미티게이션 가이드 — `algif_aead` 모듈 로딩 차단
05-01	6.12 메인라인 커널엔 commit 8b88d99 약 10시간 전 머지됨
05-02	사용자가 AWS SSM Run Command 로 클러스터 일괄 미티게이션 적용
05-04	커뮤니티 토론: “Docker 쓰시는 분들은 seccomp으로 막아도” — 미티게이션 추가 옵션 제시
05-05	Amazon Linux 커널 fix — ALAS-2026 페이지 갱신
05-06	EKS AMI v20260505 릴리스 — kernel 6.12.80-106.156 / 6.1.168-203.330. 이슈 lock 예정

AWS 공식 미티게이션 (패치 전)

기본 아이디어는 단순하다 — 취약한 커널 모듈을 로딩 자체로 차단하는 것.

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

install algif_aead /bin/false 는 modprobe가 모듈을 로드하려 할 때 /bin/false 를 대신 실행하게 만든다 — 즉 절대 로드되지 않는다. rmmod 는 이미 로드된 모듈을 즉시 제거한다.

클러스터 단위 일괄 적용 — SSM Run Command

이슈 댓글에서 사용자들이 공유한 패턴.

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"

마지막 줄은 검증 — lsmod | grep algif 가 비어 있으면 모듈이 사라진 것. 클러스터에 노드가 수십 대라도 한 번에 적용된다.

Managed Node Groups / Karpenter UserData 베이크

한 사용자 사례: Karpenter 의 NodePool UserData에 미티게이션을 박아 두면, 모든 신규 노드가 부팅 즉시 보호된 상태로 올라온다. 기존 노드는 SSM으로 일회성 처리, 새 노드는 UserData로 자동화 — 저영향, 저노력.

PoC로 차단 검증, 사이드카·데몬셋 호환성 확인 후 단계적 롤아웃이 정석.

Bottlerocket AMI는 별도 트랙

이슈 댓글 중 한 명이 보고: “Bottlerocket AMI 쓰는 클러스터는 미티게이션 적용 실패. 이건 이 레포 소관 아닐 듯.” Bottlerocket은 read-only filesystem과 다른 모듈 로딩 정책을 갖기 때문에 bottlerocket-os 쪽에서 별도 트래킹이 필요하다.

AWS 커뮤니케이션 비판

이슈 전반에 흐르는 톤은 한 줄로 요약된다 — “AWS의 커뮤니케이션이 부족했다.”

다른 매니지드 K8s 호스팅 업체들은 사전 경고 메일 발송, AWS만 무소식
“패치 release 후 X일 내 AMI release” 같은 구체적인 ETA를 줬어야
커뮤니티가 PoC와 메인라인 커밋을 먼저 추적하는 사이 AWS 서포트는 “ETA 못 줌”

이게 v20260505가 풀린 뒤 “이슈 lock 예정” 으로 정리된 배경이다.

인사이트

이 이슈가 던지는 진짜 메시지는 패치 자체가 아니라 타임라인의 모양이다. 메인라인 커널 커밋이 머지된 뒤 EKS AMI가 풀리기까지 약 6일이 걸렸고, 그 6일 동안 PoC는 이미 공개돼 있었다 — 멀티테넌트 K8s, CI runner, sandbox 환경 모두에서 컨테이너 탈출이 실증 가능한 상태였다는 뜻. 그래서 운영자에게 진짜 가치 있는 신호는 “AMI가 곧 나온다"가 아니라 “패치 전 6일 동안 어떻게 살아남는가” 다. 답은 두 줄로 정리된다 — algif_aead 모듈 차단을 SSM으로 모든 노드에 즉시 적용, Karpenter/MNG의 UserData에 베이크해 신규 노드도 자동 보호. AWS의 “ETA 못 줌” 응답은 별도 문제로, 다른 매니지드 호스팅 업체들이 사전 경고 메일을 돌리는 동안 AWS만 침묵했다는 점은 운영팀이 공식 채널 이상의 정보 소스(이슈 트래커, 커뮤니티 토론, kernel.org) 를 평소에 모니터링해야 한다는 결론으로 이어진다. 5월 4일 시점에 이미 “Docker seccomp으로 막아야” 같은 우회 옵션이 회자되고 있었다는 사실이 그 증거다 — 공식 발표보다 커뮤니티가 위협을 빠르게 인식했다. 다음 비슷한 사건에서도 패턴은 반복될 것이고, 레포 알림 + 커뮤니티 토론 + ALAS 페이지 모니터링 이 운영팀의 기본 자세가 돼야 한다.

참고

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 (2026-05-06 published)

CVE / advisories

GHSA-2274-3hgr-wxv6 — GitHub advisory
Linux kernel commit 8b88d99 — 메인라인 fix
Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC — 컨테이너 탈출 PoC
Linux algif_aead userspace API docs
Amazon Linux Security Center (ALAS)

Mitigation references

AWS SSM Run Command
Karpenter — UserData 베이크용
Bottlerocket · bottlerocket-os GitHub — 별도 트랙