대상: Next.js를 운영 환경에서 쓰는 팀, 그리고 도입을 검토하는 사람. 목표는 '프레임워크는 CVE가 많다'는 막연한 느낌을 실제 숫자와 그 내용으로 바꾸는 것이다.
데이터(NVD, 2026년 8월 22일 기준)
| Next.js | React | |
|---|---|---|
| 전체 기간 | 56 | 6 |
| 연도별 | 2020:1 / 2021:3 / 2022:3 / 2023:1 / 2024:6 / 2025:14 / 2026:28 | 2018:1 / 2025:4 / 2026:1 |
| 심각도 | CRITICAL 2, HIGH 21, MEDIUM 29, LOW 4 | CRITICAL 1, HIGH 3, MEDIUM 2 |
| 가장 심각한 것 | CVE-2025-29927 — 미들웨어에서 인증할 때의 인가 우회(CVSS 9.1) | CVE-2025-55182 — React Server Components의 인증 전 RCE(CVSS 10.0) |
CVE 건수를 읽는 법
건수가 많다고 위험한 기술이라는 뜻은 아니다. 많이 쓰일수록 연구가 늘고, 연구가 늘면 보고도 는다. 건수가 적은 것은 '안전하다'는 뜻일 수도, '아무도 보지 않는다'는 뜻일 수도 있다. 건수는 출발점일 뿐이고, 판단은 문제가 어디서 어떤 종류로 생기느냐에서 나온다. 여기 숫자는 NVD를 CPE(vercel:next.js, facebook:react)로 조회한 것이므로, CPE가 지정되지 않은 것은 세지 않았다.
어디서 생기는가
2025–2026년에 공개된 Next.js CVE를 설명에 나온 기능별로 분류하면 다음과 같다.
| 위치 | 모습 |
|---|---|
| 캐시 | 캐시 혼동과 오염 — 한 사용자의 응답이 다른 사용자에게 제공된다 |
| 미들웨어 / 라우팅 | 인가 우회: 미들웨어가 지킨다고 믿은 경로가 뚫린다 |
| 이미지 최적화 | 원격 URL 가져오기를 통한 SSRF와 자원 고갈 |
| Server Actions / RSC | 신뢰할 수 없는 요청 본문의 역직렬화, 요청에 의한 과부하 |
| rewrites / redirects | 전달 대상에 대한 해석 불일치 |
CWE 분포도 같은 말을 한다. CWE-770(제어되지 않는 자원 할당), CWE-918(SSRF), CWE-502(역직렬화), CWE-400(자원 고갈), CWE-444(요청 해석 불일치), CWE-288/285(인가 우회와 실패). 서버와 프록시의 약점 목록이다.
브라우저 쪽 — 컴포넌트를 렌더링하는 React
React 자체의 NVD CVE는 2018년의 1건
서버 쪽 1: React Server Components
최근 React CVE 다섯 건이 모두 여기(최악: 인증 전 RCE)
서버 쪽 2: Next.js 미들웨어 / 캐시 / 이미지 최적화 / rewrites
인가 우회, SSRF, 캐시 오염, 자원 고갈
반복되는 문제: 미들웨어에서의 인가
어떤 단일 CVE보다 반복되는 패턴이 더 중요하다.
2025년 3월 — CVE-2025-29927(CVSS 9.1)
특정 헤더가 붙은 요청이 미들웨어에서 하는 인가 확인을 우회할 수 있었다. 12.3.5 / 13.5.9 / 14.2.25 / 15.2.3에서 수정.2026년 5월 — CVE-2026-44574(CVSS 8.1)
조작된 쿼리 매개변수로 보이는 경로는 그대로 둔 채 페이지가 받는 동적 라우트 값을 바꿀 수 있어, 미들웨어 확인을 거치지 않고 보호된 콘텐츠가 렌더링됐다. 15.5.16 / 16.2.5에서 수정.2026년 7월 — CVE-2026-64642(CVSS 8.2)
Turbopack을 쓰는 App Router에서config.i18n.locales에 항목이 하나뿐일 때, 조작된 요청으로 미들웨어/프록시 기반 인증을 우회할 수 있었다. 16.2.11에서 수정.
여기서 나오는 설계상의 결론
18개월 동안 심각도 높은 미들웨어 인가 우회가 세 번. 이것은 개별 구현 버그가 이어진 것이 아니라, 판단을 라우트 앞에서 내리는데 그 라우트의 해석이 바뀔 수 있을 때 일어나는 일이다. 우리의 입장: 미들웨어는 첫 번째 대략적인 확인으로 두고, 진짜 인가 판단은 데이터에 접근하기 직전에 다시 한다(페이지, 라우트 핸들러, 데이터 계층에서). 확인을 두 번 쓰는 비용은 한 번의 우회로 생기는 피해보다 작다.
호스팅 방식에 따라 달라지는 것도 있다
놓치기 쉬운 점: 같은 CVE라도 직접 호스팅하느냐에 따라 영향이 다를 수 있다. CVE-2026-44578(CVSS 8.6)은 내장 Node.js 서버를 쓰는 자체 호스팅 환경에서 조작된 WebSocket 업그레이드 요청으로 SSRF를 일으켜 내부 서비스나 클라우드 메타데이터 엔드포인트에 도달할 수 있게 한다. 권고문은 Vercel에서 호스팅하는 배포는 영향받지 않는다고 밝힌다.
즉 'Next.js 취약점'은 한 가지가 아니다. 해당 여부는 어떻게 운영하고 어떤 기능을 쓰느냐에 달려 있다.
할 일
인가를 두 번 한다(가장 효과가 큼)
미들웨어 확인은 첫 번째 대략적인 확인으로 두고, 데이터에 접근하기 직전에 다시 판단한다. 위의 세 가지 우회는 모두 그것으로 막을 수 있었다. 두 개념을 나누는 법은 인증과 인가의 차이를 참고하라.
서버가 가져올 수 있는 대상을 허용 목록으로 정한다
이미지 최적화가 불러오는 원격 URL, 서버 측 fetch의 대상, rewrite 대상을 제한한다. SSRF 문제는 외부 대상이 제한되지 않은 곳에서 가장 큰 피해를 낸다. 앱에서 클라우드 메타데이터 엔드포인트에 도달할 수 있는지도 확인한다.
Server Action과 RSC 엔드포인트를 인증 뒤에 둔다
이곳은 요청 본문을 역직렬화하는 경로이며, 실제로 CWE-502 CVE가 나왔다. 인증 바깥에 두지 말고, 요청 제한을 적용하고, 예상치 못한 페이로드로 프로세스가 죽지 않게 한다. /api와 똑같이 다룬다.
업데이트를 장치로 만든다
Next.js는 수정을 빠르게 내놓지만, 업데이트해야 의미가 있다. 구체적인 방법(실제로 돌아가는 버전으로 판단하기, 의존성을 자동으로 감시하기)은 Next.js를 안전하게 운영하기와 osv-scanner 시작하기에 있다. 1년에 28건이면 사람의 주의로는 따라갈 수 없다.
이 사이트의 관점: 프레임워크 선택은 건수의 문제가 아니다
'CVE가 많으니 Next.js를 피해야 하나?'는 잘못된 질문이다. 데이터가 보여 주는 것은 Next.js가 꾸준히 서버 역할을 더 맡아 왔다는 사실이다. 미들웨어에서 인가하고, 원격 이미지를 가져오고, 캐시를 갖고, 요청을 역직렬화한다. 사실상 의존성 하나로 리버스 프록시와 애플리케이션 서버를 함께 얻는 셈이다. 그래서 평가할 것은 건수가 아니라 그 서버 기능 중 무엇을 실제로 쓰고, 누가 그것을 지키는가다. 필요 없는 것은 끄고, 쓰는 것 주변에는 자체 통제를 겹친다. 이렇게 보면 선택은 취향의 문제가 아니라 운영 역량의 문제가 된다.
출처
- NVD(NIST) — 2026년 8월 22일에
cpe:2.3:a:vercel:next.js와cpe:2.3:a:facebook:react를 조회한 수치 - CVE-2025-29927(미들웨어 인가 우회) / CVE-2026-44574(동적 라우트 값 변경) / CVE-2026-64642(App Router + Turbopack 인증 우회)
- CVE-2026-44578(자체 호스팅 WebSocket SSRF, Vercel 호스팅은 영향 없음)
- CVE-2025-55182(React Server Components의 인증 전 RCE, CVSS 10.0) / CVE-2026-23864(RSC 서비스 거부)
다음에 읽을 글
-
구현: Node.js의 프로토타입 오염(런타임이 범위 밖이라고 선언한 영역)
-
운영: CVE에 뒤처지지 않고 Next.js를 안전하게 운영하기 / osv-scanner로 의존성을 기계 감시하기
FAQ
QNext.js는 취약점이 많은가요?
건수로는 그렇고, 늘고 있습니다. 2026년 8월 22일에 NVD를 조회하면 Next.js 관련 CVE는 56건이며, 2024년 6건, 2025년 14건, 2026년 28건이 공개됐습니다. 다만 건수가 많다고 '위험한 기술'로 읽지 마세요. 많이 쓰일수록 연구가 늘고, 그만큼 보고도 늘어납니다. 중요한 것은 개수가 아니라 문제가 어디서 생기느냐입니다.
QReact는 취약점이 적은가요?
브라우저 쪽 UI 라이브러리로서의 React는 매우 적어서 NVD에 6건입니다. 그리고 2018년의 1건을 빼면 최근 것은 모두 서버에서 동작하는 React Server Components(react-server-dom-parcel / turbopack / webpack)에 관한 것입니다. 그중 CVE-2025-55182는 CVSS 10.0의 인증 전 원격 코드 실행입니다.
Q그럼 실제 위험은 어디에 있나요?
서버 기능에 있습니다. 최근 Next.js CVE는 미들웨어, 캐시, 이미지 최적화, Server Actions, rewrites에 몰려 있고, 상위 CWE는 SSRF(CWE-918), 신뢰할 수 없는 데이터의 역직렬화(CWE-502), 제어되지 않는 자원 소비(CWE-770/400), 인가 실패(CWE-285/288)입니다. 모두 컴포넌트를 어떻게 쓰느냐와는 무관합니다.
Q가장 효과가 큰 변경은 무엇인가요?
네 가지입니다. (1) 인가를 미들웨어에만 맡기지 않는다. 우회가 반복해서 나왔습니다. (2) 이미지 최적화, 서버 측 fetch, rewrites의 외부 대상을 허용 목록으로 제한한다. (3) Server Action과 RSC 엔드포인트를 인증과 요청 제한 뒤에 둔다. (4) 업데이트를 의지가 아니라 장치로 만든다. 같은 형태의 우회가 2025년과 2026년에 모두 나왔으므로 (1)이 가장 중요합니다.