[Next.js] 취약한 React 서버 컴포넌트를 사용하고 있는 IP에 대한 보안조치

운영 중이던 서비스에 갑자기 공격 받음..
나도 이번 React Server Components 취약점(일명 React2Shell / CVE-2025-55182, CVE-2025-66478) 때문에 딱 그 상황을 겪었고, Next.js 15.4.6 환경에서 어떻게 대응했는지를 정리해서 기록함.

기준 환경:

• Next.js 15.4.6 (App Router, RSC 사용)
• React 19.1.0 / react-dom 19.1.0
• Linux 서버에 직접 배포 (Docker + Node 20)
• 방화벽은 OS 레벨에서 방화벽으로 관리

---

[1] 사건 정리 – 이상한 로그, GPT, 그리고 보안 조치 연락

1. 서비스 잘 돌다가 갑자기 접속이 안 됨
2. 서버 로그를 보니 평소와 다른 의심스러운 HTTP 요청 패턴이 찍혀 있었음
3. GPT에게 로그 패턴을 물어보니, 요즘 이슈인 React Server Components RCE 취약점 스캔/공격 시도일 가능성이 높다고 알려줌
4. 급하게 해당 IP들 방화벽 차단 조치
5. 얼마 안 있어 KT에서 전화 →
   • “KISA에서 React 서버 컴포넌트 취약점 관련 보안 조치 요청 메일 받았다”는 내용
   • 참고 링크로 KISA 보호나라 React 서버 컴포넌트 보안 업데이트 권고 안내받음 (보호나라)
   • GitHub PoC/스캐너 링크까지 포함되어 있었음 (GitHub)

여기서 확정한 사실은:

• 내 Next.js 버전(15.4.6)은 취약 범위 안에 있다.
• 이미 인터넷 상에는 PoC, 스캐너, 심지어 실제 공격까지 활발히 돌아다니고 있다. (TechRadar)

그래서 “IP 막았으니 됐겠지”가 아니라, 버전 패치를 포함한 제대로 된 대응이 필요하다고 판단했다.

[2] 취약점(React2Shell / CVE-2025-55182 / 66478) 간단 정리

아주 짧게 요약하면:

React Server Components(RSC) Flight 프로토콜의 취약점으로 인해, 인증 없이 한 번의 HTTP 요청으로 서버에서 임의 코드 실행(RCE)이 가능한 10/10급 치명적 취약점. (React)

 

조금 더 자세히:

• 문제는 React 19의 RSC 구현에서 HTTP 요청을 역직렬화(deserialize)하는 과정이 안전하지 않게 설계된 것
• 이 취약한 동작을 사용하는 대표적인 프레임워크가 Next.js App Router (Server Components + Server Actions) (www.trendmicro.com)
• CVE는 두 개로 나뉘어 있었는데:
  • CVE-2025-55182: React 자체의 RSC 취약점
  • CVE-2025-66478: Next.js 쪽(다운스트림) 영향 추적용
    → 이후 CVE-2025-66478은 55182의 중복으로 정리되었지만, “Next.js에서 이 이슈를 추적한다”는 의미로 계속 쓰이는 중 (wiz.io)
• CVSS 점수는 10.0 (만점), 여러 보안 벤더와 KISA, 해외 CERT까지 전부 “가능한 빨리 패치하라”고 권고 중 (보호나라)

그리고 중요한 포인트:

Next.js 공식 블로그에서 “우회책(워크어라운드) 없다. 무조건 패치 해야 한다”고 못 박았다. (Next.js)

 

[3] 내 서비스가 취약한 상태인지 확인하기

3-1. 구조적으로 대상인지 먼저 체크

Next.js 공식 보안 공지 기준, 영향 받는 Next.js는 아래와 같다: (Next.js)

• App Router에서 React Server Components를 사용하는 Next.js 15.x, 16.x 전체
• Next.js 14.3.0-canary.77 이상 canary
• (13.x / 14.x stable, Pages Router만 쓰는 앱은 영향 없음)

나는:

• app/ 디렉터리 기반 App Router 사용
• use server / Server Actions도 쓰고 있고
• Next.js 버전은 15.4.6

→ 구조적으로도, 버전으로도 딱 취약 대상.

3-2. 버전 확인 방법

로컬이나 서버에서 프로젝트 디렉터리로 가서:

# 설치된 버전 확인
npm ls next react react-dom

# package.json 확인
cat package.json | grep '"next"' -n
cat package.json | grep '"react"' -n

운영 서버에 코드가 그대로 올라가 있다면 위 커맨드로 바로 확인 가능하고, Docker면 docker exec로 컨테이너 안에 들어가 같은 명령을 실행하면 된다.

또는, 프런트 쪽에서 브라우저 DevTools 콘솔에:

window.next?.version

이렇게 찍어보면 Next.js 버전이 나오는 경우도 있다. (실제 GitHub 스캐너도 이 값을 읽어서 버전을 판별한다.) (GitHub)

나의 결과:

next@15.4.6
react@19.1.0
react-dom@19.1.0

3-3. KISA / Ahnlab / Next.js 공지와 매칭

Ahnlab 보안 권고에서 Next.js 취약 범위를 이렇게 정리해준다(요지만): (ASEC)

• 14.3.0-canary.77 이상 canary
• 15.0.0 이상 15.0.5 미만
• 15.1.0 이상 15.1.9 미만
• 15.2.0 이상 15.2.6 미만
• 15.3.0 이상 15.3.6 미만
• 15.4.0 이상 15.4.8 미만
• 15.5.0 이상 15.5.7 미만
• 16.0.0 이상 16.0.7 미만

그리고 Next.js 공식 공지에서 “패치가 된 최소 버전”을 이렇게 제시한다: (Next.js)

• 15.0.x → 15.0.5
• 15.1.x → 15.1.9
• 15.2.x → 15.2.6
• 15.3.x → 15.3.6
• 15.4.x → 15.4.8
• 15.5.x → 15.5.7
• 16.0.x → 16.0.7

즉, 15.4.6은 딱 “취약 범위” 안에 있고,
15.4.8로 올려야 최소 패치 수준이 된다.

React 쪽도 마찬가지로:

• 취약: 19.0 / 19.1.0 / 19.1.1 / 19.2.0
• 패치: 19.0.1 / 19.1.2 / 19.2.1 (보호나라)

나는 19.1.0이었으니 React도 19.1.2로 올려야 안전하다.

[4] 15.4.6 → 15.4.8, React 19.1.0 → 19.1.2 업그레이드 전략

4-1. 우선 원칙

1. 우회책 없다. 버전 올려야 한다.
   Next.js 공식 문서에도 “워크어라운드 없음, 업그레이드 필수”라고 명시되어 있다. (Next.js)
2. 최소 변경으로 패치
   • 이미 운영 중이라, 대규모 리팩토링은 부담
   • 같은 minor line 안에서 패치 버전으로만 올리는 방식으로 진행
   • 즉 15.4.6 → 15.4.8, 19.1.0 → 19.1.2
3. 패치 후에는 반드시 재빌드 / 재배포
   • Ahnlab에서도 “npm install 후 반드시 빌드를 다시 돌려야 런타임에 패치가 반영된다”고 강조한다. (ASEC)

4-2. 패키지 버전 업데이트

프로젝트 루트에서:

# 1) Next / React / ReactDOM 패치 버전으로 업그레이드
npm install next@15.4.8 react@19.1.2 react-dom@19.1.2

여기서 많이들 겪는 오류가 바로 npm ci 관련 에러:

npm ci can only install packages when your package.json and package-lock.json are in sync.
Invalid: lock file's next@15.4.6 does not satisfy next@15.4.8
...

이 에러는:

• package.json은 15.4.8로 바뀌었는데
• package-lock.json에는 아직 15.4.6이 남아 있어서

둘이 안 맞는다고 말하는 것.

해결 방법은 둘 중 하나다:

1. 정석 방법: npm install로 lock 파일 갱신그리고 Docker 빌드/배포 파이프라인에서는 그대로 npm ci 사용
2. npm install # package-lock.json 갱신 npm ls next react react-dom
3. lock 파일 초기화 (추천도는 1보다 낮지만, 어차피 새로 맞출 거면…)이후 다시 커밋하고, CI/CD에서 이 lock 파일 기준으로 npm ci를 돌리면 된다.
4. rm package-lock.json npm install

나는 첫 번째 방법(기존 lock 유지 + 갱신)으로 처리했다.

업데이트 후 버전 체크:

npm ls next react react-dom

# 출력 예시
# next@15.4.8
# react@19.1.2
# react-dom@19.1.2

 

[5] 빌드 & 배포 과정 정리

5-1. 로컬(또는 스테이징) 빌드

npm run build
npm run start   # 또는 next start

간단하게라도:

• 주요 페이지 라우팅
• 폼/액션 호출 (Server Actions)
• 파일 업로드/다운로드
• 인증 플로우

정도는 한 번 씩 눌러 보면서 확인했다.

5-2. Docker 환경이라면

멀티 스테이지 Dockerfile을 쓰고 있다면, 대략 이런 느낌일 것이다 (예시):

FROM node:20-bullseye AS builder
WORKDIR /app

COPY package.json package-lock.json ./
RUN npm ci

COPY . .
RUN npm run build

FROM node:20-bullseye AS runner
WORKDIR /app

COPY --from=builder /app ./
ENV NODE_ENV=production

CMD ["npm", "start"]

이번에 우리가 한 건:

1. 로컬에서 package.json / package-lock.json까지 버전 갱신 후 커밋
2.  서버에서 docker실행 및 정상 동작 확인

중요한 포인트는:

이미지 안에서 빌드를 다시 하는 것이 아니라, “패치된 의존성 + 코드”를 기반으로 새 이미지를 빌드하는 것.

[6] 마무리 – 3개월차 Next.js 개발자의 교훈

솔직히 말하면, Next.js 시작한 지 3개월 만에:

• 알 수 없는 로그
• GPT가 “이거 RCE 스캔일 수도 있다”고 하고
• 실제로 KT/KISA에서 연락까지 오는 상황을 겪을 줄은 몰랐다.

하지만 운영 중인 서비스라면 언젠가는 꼭 겪게 되는 종류의 사건이라고 생각한다. 이번에 느낀 교훈 몇 가지:

1. “어차피 우리 서비스는 작은데…”라는 생각은 금물
   • 자동 스캐너/봇은 규모 안 가리고 다 긁는다.
2. 보안 공지/업데이트는 “나중에 한 번 볼게요”가 아니라 “지금 대응해야 하는 운영 이슈”
   • 특히 CVSS 10.0, pre-auth RCE 급이면 무조건 최우선.
3. Next.js / React 버전은 항상 명시하고, 주기적으로 점검하기
   • npm ls 한 번 돌려보는 것도 보안 점검의 시작.
4. 패치 후에는 “비밀키 회전 + 사후 점검”까지 해야 진짜 끝
   • 패치만 하고 비밀키 그대로 두면, 이미 탈취된 키로 계속 공격이 이어질 수 있다.

이번 글이, 나처럼 Next.js 15.x + RSC를 쓰다가 당황한 사람들에게 조금이나마 도움이 되길 바란다.
(그리고 미래의 나에게도 “그때 이렇게 했었지?” 하는 체크리스트가 되길… 😂)

---

[7] 참고할 만한 링크들

1. 공식 보안 공지

• React 공식 보안 공지 – Critical Security Vulnerability in React Server Components (CVE-2025-55182)
  React 19 RSC 취약점 개요, 영향 받는 버전, 패치 버전(19.0.1 / 19.1.2 / 19.2.1) 정리
• Next.js 공식 보안 공지 – Security Advisory: CVE-2025-66478
  Next.js 15/16 App Router 환경에서 영향 범위와 최소 권장 버전(15.4.8 등) 안내
• Vercel React2Shell 안내 – React2Shell Security Bulletin
  React2Shell 취약점 개요와 Next.js/React 사용자용 대응 가이드
• Vercel Changelog – CVE-2025-55182 요약
  RSC 취약점 요약 및 업데이트 안내
• GitHub Security Advisory – RCE in React Server Components (Next.js)
  Next.js 저장소 관점에서 정리된 RSC RCE 취약점

---

2. 국내(한글) 보안 권고

• KISA 보호나라 – React 서버 컴포넌트 보안 업데이트 권고
  국내 공식 권고문, 영향 받는 React/Next.js 버전 및 패치 버전 정리
• AhnLab ASEC – React Server Component 보안 업데이트 권고 (CVE-2025-55182)
  RSC 취약점 개요와 대응 방법을 한글로 요약
• NHN Cloud – React, Next.js 제품 보안 업데이트 권고
  국내 클라우드 사업자 관점의 React/Next.js 패치 안내

---

3. 기술 분석 & 실제 공격 사례

• Wiz – Critical Vulnerability in React (CVE-2025-55182)
  RSC Flight 프로토콜 취약 구조와 기본 설정에서도 왜 취약한지 기술 분석
• Wiz – React2Shell: Technical Deep-Dive & In-the-Wild Exploitation
  실제 공격 흐름, 페이로드 구조, 클라우드 백도어 시나리오 상세 분석
• Trend Micro – Critical React Server Components Vulnerability CVE-2025-55182
  보안팀 관점에서 CVE-2025-55182 정리 및 대응 전략
• Trend Micro – CVE-2025-55182: React2Shell Analysis, PoC Chaos, and In-the-Wild Exploitation
  PoC 난립 상황과 실제 악용 사례 정리
• Sysdig – Detecting React2Shell
  로그/행위 기반 탐지 관점에서 React2Shell을 어떻게 찾고 막을지 설명
• AWS Security Bulletin – CVE-2025-55182 / CVE-2025-66478 안내
  AWS 환경에서 React/Next.js를 쓰는 고객에게 권장하는 패치 가이드