36. CVE-2025-55182 React2Shell, React Server Components RCE를 어떻게 막을 것인가

React 19와 Next.js 15/16을 포함한 React Server Components(RSC) 생태계에서
치명적인 원격 코드 실행(RCE) 취약점이 공개됐다.

CVE-2025-55182, 일명 React2Shell로 불리는 이 취약점은
RSC에서 사용하는 Flight 프로토콜의 역직렬화(deserialization) 결함으로 인해,
인증 없이(pre-auth) 특수하게 조작된 요청만으로 서버 측에서 임의 코드를 실행할 수 있다. 

React 팀과 여러 보안 업체에서 CVSS 10.0(최고 심각도)로 평가하고 있고,
기본 설정 상태의 Next.js 앱(단순 create-next-app 결과물)도
코드 수정 없이 공격 대상이 될 수 있다는 점 때문에
Log4Shell에 비견되는 이슈로 다뤄지고 있다. 

1. 어떤 환경이 영향받는가

React 공식 공지와 보안 분석을 종합하면
취약한 핵심 구성요소는 RSC Flight 프로토콜을 구현한 패키지들이다. 

영향받는 주요 컴포넌트 버전은 다음과 같이 정리된다.
• react-server-dom-webpack 19.0, 19.1.0, 19.1.1, 19.2.0
• react-server-dom-parcel 19.0, 19.1.0, 19.1.1, 19.2.0
• react-server-dom-turbopack 19.0, 19.1.0, 19.1.1, 19.2.0

이 패키지를 사용하는 프레임워크들도 기본 설정에서 취약할 수 있다.
• Next.js (특히 App Router 기반, Server Components 사용 앱)
• React Router RSC, Expo, Waku, Parcel RSC, Vite RSC 등 

React와 Vercel은 취약점 공개와 동시에 패치 버전을 배포했다.
• 19.0 → 19.0.1
• 19.1.0 / 19.1.1 → 19.1.2
• 19.2.0 → 19.2.1 

정리하면,
“React 19 계열 + RSC + Server Function을 사용하는 서버사이드 React 앱”은
기본적으로 영향권에 있다고 보는 게 안전하다.

2. 취약 구조: Flight 프로토콜 역직렬화와 Server Function 엔드포인트

문제가 되는 부분은 RSC Flight 프로토콜로
클라이언트와 서버가 서버 함수(Server Function)를 호출할 때 사용하는 데이터 포맷이다.

요약하면 구조는 이렇다. 
• 클라이언트는 Flight 포맷으로 인코딩된 payload를
Server Function 엔드포인트에 HTTP 요청으로 전송한다.
• 서버 측에서는 이를 역직렬화하며
객체 구조를 복원하고, 대응되는 서버 함수를 호출한다.
• 이 과정에서 공격자가 컨트롤할 수 있는 데이터가
안전한 검증 없이 역직렬화 루틴을 통과한다.

Datadog, Palo Alto 등에서 분석한 내용에 따르면, 
• 공격자는 Flight 포맷을 흉내 낸 특수 payload를 만들어
• 서버 함수 호출처럼 보이도록 꾸민 뒤
• 역직렬화 과정에서 프로토타입 오염(prototype pollution) 또는
객체 체인을 악용해 임의 코드 실행 지점까지 도달하는 방식으로
RCE를 달성할 수 있다.

중요한 점은
“특정 개발자의 실수”가 아니라
RSC Flight 프로토콜 자체의 설계/구현 취약점이라는 것이다.

3. 왜 위험한가: 인증 전 RCE + 대규모 공격 표면

React2Shell이 특히 위험한 이유는 몇 가지가 겹쳐 있다. 
• 인증 이전 단계에서 공격 가능 (pre-auth RCE)
• 기본 설정의 Next.js / RSC 앱이 그대로 영향받음
• React가 클라우드 환경의 약 40%에서 사용된다는 분석
• 대형 서비스(페이스북, 인스타그램, 넷플릭스, 에어비앤비 등)도 React 기반으로 운영

여기에 더해 AWS, Wiz 등에서
공개 직후 이미 PoC와 실제 공격 시도가 관찰되고 있고,
중국 연계 그룹을 포함한 위협 행위자들이
적극적으로 악용 중이라는 리포트도 나왔다. 

즉, “지금 당장은 우리 서비스를 노리지 않겠지”라고
낙관적으로 보기 어려운 상황이다.

4. 실무 기준 점검 순서 – 개발·보안팀이 같이 볼 체크리스트

보안 담당자 입장에서
현실적으로 가져갈 수 있는 점검·조치 순서를 정리해보면 다음과 같다. 
1. 자산 파악
• React 19 / Next.js 15·16 사용 서비스 목록 추출
• 그 중 RSC와 Server Components, Server Function을 사용하는 프로젝트 식별
• react-server-dom-* 패키지 버전 확인
2. 외부 노출 범위
• 인터넷에 직접 노출된 프론트엔드/백엔드 경로
• 사내 VPN/파트너망에서 접근 가능한 관리도구·백오피스
3. 위협 모델 정의
• 익명 접근이 가능한 엔드포인트인지
• 인증 토큰 없이도 Flight payload를 보낼 수 있는지
• 리버스 프록시/WAF 뒤에 있는지, 아니면 직접 노출인지
4. 우선순위 선정
• 트래픽이 많고,
• 대외 서비스에 직접 연결된 RSC 기반 서비스부터
패치·완화 조치를 적용하는 방식으로 순서 지정

5. 기술적 대응 방안

(1) 패치와 버전 업그레이드
• 가장 먼저 할 일은 React 팀이 배포한 패치 버전으로 업그레이드하는 것이다.
• Next.js 역시 대응 버전을 배포했으므로,
React와 프레임워크 양쪽 버전을 함께 올려주는 것이 좋다. 

(2) 임시 완화 – RSC/Server Function 비활성화 또는 경로 제한
• 단기적으로 패치가 어려운 레거시 환경이라면,
Server Function 엔드포인트를 외부에서 직접 호출할 수 없도록
리버스 프록시나 WAF에서 경로 제한을 거는 것도 고려할 수 있다.
• RSC를 사용하지 않는 프로젝트인데도 관련 패키지가 포함돼 있다면,
기능을 비활성화하고 라우트에서 격리하는 것도 하나의 방법이다.

(3) WAF·IDS 룰 보완
• 알려진 PoC에서 사용하는 Flight payload 패턴,
비정상적인 직렬화 토큰,
특이한 파라미터 구조 등을 기반으로 룰을 추가할 수 있다. 
• 단, 인코딩·우회 기법을 고려해
너무 특정 패턴에만 의존하지 않도록 주의해야 한다.

(4) SCA(Software Composition Analysis)와 CI 파이프라인 통합
• 이번 이슈처럼 “라이브러리/프레임워크 자체 취약점”은
SCA 도구에서 잘 잡아주는 영역이다.
• 빌드 단계에서 취약 버전을 차단하고,
최소 패치 버전을 강제하는 정책을 적용하면
신규 배포에서 구버전이 섞이는 것을 막을 수 있다.

6. 관제·포렌식 관점에서 볼 포인트

이미 공격 시도가 있었는지 확인하려면,
다음과 같은 지점을 로그와 모니터링에서 살펴보는 것이 좋다. 
• Server Function 엔드포인트로 향하는 비정상적인 HTTP 요청
• 평소보다 큰 payload, 특이한 직렬화 문자열
• 짧은 시간에 반복되는 4xx/5xx 응답
• React/Next.js 서버에서의 프로세스 생성 흔적
• node 외에 쉘, curl, wget, powershell 등
• 신규/의심스러운 파일 생성
• 서버 측 템플릿/코드 파일이 갑자기 바뀐 흔적
• 외부 C2와의 통신 시도
• 평소 접속하지 않는 IP/도메인으로의 outbound 연결

SIEM이나 EDR이 있다면
이 이벤트들을 기반으로
탐지 룰과 대시보드를 정의하고,
특히 11월 말~12월 초(공개 직후) 트래픽을 한 번 점검해 보는 게 좋다.
7. 정리

React2Shell(CVE-2025-55182)은
• RSC Flight 프로토콜의 설계/구현 취약점으로 인한
• 인증 전 원격 코드 실행,
• 널리 쓰이는 프레임워크 기본 설정까지 영향을 주는

상당히 “나쁜 조건”이 겹친 취약점이다.

실무에서는
1. 자산·버전 파악
2. 패치 가능한 구간 우선 조치
3. 임시 완화(WAF, 경로 제한 등)
4. SCA·CI 통합으로 재발 방지
5. 관제·포렌식 룰 정비

이 다섯 가지 축으로
“설명 가능한 대응 스토리”를 만드는 것이 현실적인 방향이라고 본다.