2026년 7월 Next.js 보안 릴리스가 나왔고, Cloudflare도 관련 WAF 규칙을 공개했어요. 여기서 제일 먼저 확인할 결론은 하나입니다. Next.js 패치가 우선이고 Cloudflare WAF는 보조 수단이라는 것.

이번 릴리스는 HIGH 4건과 MEDIUM 5건, 총 9건입니다. 공식 권고 버전은 Active LTS 16.2.11, Maintenance LTS 15.5.21이고요. WAF 전용 규칙이 생겼으니 일단 안심해도 되겠지 싶지만, 9건 가운데 전용 규칙이 배포된 건 3건뿐. 기존 SSRF 규칙으로 대응한다고 밝힌 1건을 더해도 나머지 5건은 WAF만으로 정리되지 않습니다. 숫자로 보니 바로 마음 편-안 할 상황은 아님.

이 글은 2026년 7월 26일 기준으로 Next.js 공식 보안 릴리스와 개별 GitHub Security Advisory, Cloudflare 변경 로그를 함께 확인해 정리했습니다. 설치 버전부터 실제 WAF 상태까지 어떤 순서로 봐야 하는지 쭉 짚어볼게요.

15.x는 15.5.21, 16.x는 16.2.11부터 확인

우선 package.json에 적힌 버전 범위만 보지 말고 lockfile과 실제 배포 아티팩트에서 설치된 next 버전을 확인해야 해요. 15.x를 운영 중이라면 15.5.21 이상, 16.x라면 16.2.11 이상이 공식 패치 기준입니다. 12~14 계열은 이번 공식 릴리스의 권고 패치 열에 별도 수정 버전이 없어요. 그런데 일부 취약점은 12.x 또는 13.x부터 영향을 받으니 지원 LTS 라인으로 올리는 계획이 필요함.

다만 “패치 전 버전이면 9건에 전부 해당한다”는 뜻은 아닙니다. 기능과 구성 조건이 제각각이거든요.

구분	영향 조건과 범위	수정 버전
CVE-2026-64641	App Router에서 Server Action을 하나 이상 사용하는 >=13.0.0 <15.5.21, >=16.0.0 <16.2.11	15.5.21, 16.2.11
CVE-2026-64642	App Router를 Turbopack으로 빌드하고 config.i18n.locales가 하나인 >=16.0.0 <16.2.11	16.2.11
CVE-2026-64645	요청 입력으로 외부 목적지 hostname을 만드는 rewrites()·redirects() 사용, >=12.0.0 <15.5.21, >=16.0.0 <16.2.11	15.5.21, 16.2.11
CVE-2026-64649	custom server의 Server Action 요청 전달·리다이렉트, >=14.1.1 <15.5.21, >=16.0.0 <16.2.11	15.5.21, 16.2.11
CVE-2026-64644	self-hosting, 기본 image loader, 원격 이미지 최적화 설정을 함께 사용하는 >=15.5.0 <15.5.21, >=16.0.0 <16.2.11	15.5.21, 16.2.11
CVE-2026-64646	App Router와 Server Action을 쓰는 Edge runtime, >=13.0.0 <15.5.21, >=16.0.0 <16.2.11	15.5.21, 16.2.11
CVE-2026-64643	App Router의 Server Actions 또는 use cache, >=13.0.0 <15.5.21, >=16.0.0 <16.2.11	15.5.21, 16.2.11
CVE-2026-64648	fetch(new Request(init), aDifferentInit) 형태의 서버 측 fetch, >=13.0.0 <15.5.21, >=16.0.0 <16.2.11	15.5.21, 16.2.11
CVE-2026-64647	잘못된 UTF-8 바이트가 든 요청 body의 캐시 키 충돌, >=13.0.0 <15.5.21, >=16.0.0 <16.2.11	15.5.21, 16.2.11

조건이 꽤 촘촘하죠. App Router, Server Actions, Edge runtime, Turbopack, 단일 locale, custom server, 원격 이미지 최적화, rewrite와 redirect, 서버 측 fetch 형태를 각각 확인해야 합니다.

기능을 쓰지 않아 특정 CVE의 직접 노출 조건에서 벗어날 수는 있어요. 그래도 그 사실이 오래된 버전을 계속 운영해도 된다는 면책은 아닙니다. 지원 LTS 패치로 올리는 게 기본 대응. Next.js 7월 보안 릴리스와 Vercel/Next.js Security Advisories에서 개별 범위를 함께 보는 이유예요.

WAF가 가리는 건 9건 중 일부입니다

Cloudflare의 2026년 7월 21일 변경 로그를 기준으로 보면 이번 9건은 딱 세 묶음으로 나뉩니다.

• Next.js 전용 관리형 규칙 배포: CVE-2026-64641, CVE-2026-64649, CVE-2026-64643
• 기존 SSRF 규칙으로 방어한다고 밝힌 항목: CVE-2026-64645
• WAF 시그니처로 방어할 수 없거나 안전한 공통 규칙을 만들지 않은 항목: CVE-2026-64642, CVE-2026-64644, CVE-2026-64646, CVE-2026-64648, CVE-2026-64647

전용 규칙 3개의 새 기본 동작은 모두 Block입니다. 각각 Server Action DoS, custom server의 Server Actions SSRF, 내부 Server Function ID 노출에 대응해요.

여기서 정보 노출 취약점인 CVE-2026-64643을 임의 코드 실행으로 부풀리면 안 됩니다. 확인된 내용은 endpoint ID가 인증 없이 전역 노출되어 정찰이나 공격 체인의 재료가 될 수 있다는 것. 또 CVE-2026-64645도 rewrite에서는 SSRF, redirect에서는 Open Redirect로 결과가 다릅니다. 한 덩어리로 묶으면 정작 점검할 곳이 흐릿해짐.

WAF는 origin 앞에서 알려진 악성 HTTP 패턴을 막는 데 도움을 줍니다. 하지만 애플리케이션 내부의 캐시 키 계산을 고치거나, 정상 이미지 최적화 요청과 악성 요청을 항상 구별해 주지는 못해요. Turbopack 단일 locale 조건의 middleware/proxy 우회도 Cloudflare가 시그니처 엔진으로 방어할 수 없다고 밝혔습니다.

그러니 “Cloudflare 앞에 있으니까 업데이트는 나중에”는 곤란합니다. WAF가 막지 못하는 5건은 그대로 남고, 막는다고 밝힌 항목도 실제 ruleset 배포와 설정 상태를 확인해야 하거든요. 패치 우선, WAF 보조. 이번 대응의 핵심은 이 순서입니다. Cloudflare WAF 변경 로그

기본 Block이 곧 모든 사이트의 자동 차단은 아닙니다

변경 로그의 New Action: Block만 보면 Cloudflare 사용 사이트에는 알아서 다 적용된 것처럼 느껴질 수 있어요. 근데 이 부분이 은근 함정.

Block은 해당 Cloudflare Managed Ruleset이 대상 zone에 실제로 배포·활성화되어 있고, ruleset·tag·개별 rule 수준의 override나 예외가 동작을 바꾸지 않았을 때 의미가 있습니다. 일부 관리형 규칙은 오탐을 줄이기 위해 기본 비활성화될 수도 있고요. 반대로 규칙 전체를 일괄 활성화하면 정상 트래픽에 영향을 줄 수 있어 Cloudflare도 권장하지 않습니다.

또 7월 변경 로그는 세 규칙이 Cloudflare Managed Ruleset에 포함됐다고 적지만, Free Managed Ruleset 제공까지 명시하지는 않았어요. 무료 플랜에도 전부 자동 적용된다고 단정하면 안 됨. 실제 계정과 zone의 제공 범위를 봐야 합니다.

변경 로그에는 Next.js 이름으로 재분류된 규칙이 하나 더 보입니다. Next.js - Remote Code Execution - Cache Components 규칙인데요. 같은 표에 있다는 이유만으로 이번 7월 9개 중 하나를 막는 네 번째 전용 규칙으로 세면 안 됩니다. 9개 취약점 표에 직접 매핑된 건 앞서 말한 3개뿐이에요.

실제 운영 점검은 이 순서로

먼저 실제 설치 버전과 기능 노출 조건을 확인합니다. lockfile과 배포 아티팩트의 next 버전을 보고, App Router와 Server Actions부터 Turbopack, custom server, 이미지 최적화, rewrite·redirect, 캐시 관련 fetch 형태까지 체크하면 돼요.

그다음 패치하고 회귀 테스트. 16.x는 16.2.11 이상, 15.x는 15.5.21 이상으로 올린 뒤 빌드, App Router 탐색, Server Actions, middleware/proxy 인증, rewrite·redirect, 이미지 최적화, 캐시 동작을 확인합니다. 업그레이드만 하고 인증 흐름이 깨졌는지 안 보면 또 다른 총체적난국 가능…

마지막으로 Cloudflare 쪽을 봅니다.

1. 대상 zone에 Cloudflare Managed Ruleset이 배포되고 활성화됐는지 확인
2. Next.js 전용 규칙 3개의 status와 action이 Block인지 확인
3. ruleset·tag·rule override 또는 예외가 동작을 덮어쓰는지 확인
4. CVE-2026-64645에 대응하는 기존 SSRF 규칙이 비활성화되지 않았는지 확인
5. Security Events에서 매치와 정상 요청 오탐을 함께 관찰

Security Events에 기록이 없다고 취약하지 않다는 뜻은 아닙니다. 공격 요청이 없었거나 규칙이 제대로 배포되지 않은 상황도 가능하니까요. 이벤트 0건 = 보안 완료, 이렇게 계산하면 너무 간단 간단.

WAF 규칙이 없는 항목도 별도 위험으로 남겨야 해요. Edge Server Action 본문 크기는 앱의 실제 요청 크기에 맞춘 bodySizeLimit 정책을 검토하고, origin이 Cloudflare를 우회해 직접 노출되는지도 확인합니다. 인증과 인가가 middleware 한 곳에만 기대고 있지 않은지 보는 것도 방어 심층화 차원에서 필요한 점검이고요.

결론은 패치 완료 후 WAF 상태까지 확인

이번 Next.js 보안 취약점 대응은 WAF 규칙 개수 세기보다 순서가 중요합니다. 실제 버전과 기능 조건 확인 → 15.5.21 또는 16.2.11 이상으로 패치 → 회귀 테스트 → Cloudflare Managed Ruleset과 예외 상태 점검. 이 흐름이면 됨.

Cloudflare WAF는 일부 공격 패턴을 origin 전에 차단해 주는 꽤 유용한 보조책입니다. 다만 9건 전체를 고치는 패치는 아니고, 기본 Block도 내 zone의 실제 활성 상태를 대신 확인해 주지 않아요. 둘 중 하나를 고르는 문제가 아니라 패치를 먼저 끝내고 WAF로 남은 노출을 줄이는 조합이 맞습니다.

Category: Hot Issue

Tags: Next.js, 보안 취약점, Cloudflare WAF, 패치

Next.js #보안취약점 #CloudflareWAF #패치