CVSS 10.0 React2Shell(RSC) 원격코드실행 React/Next.js 취약점

React2Shell(CVE-2025-55182)는 React Server Components(RSC)의 Flight 프로토콜 역직렬화 취약점으로, 인증 없이 단 한 번의 HTTP 요청으로 서버에서 임의 코드 실행이 가능한 Log4Shell급 RCE입니다.

아래는

개념·기술 배경
영향 범위/공격 동향
그리고 조직 관점 종합 대응 전략 + 내부 가이드/체크리스트까지

1. 취약점 개요 – React2Shell(CVE-2025-55182)

핵심 정보

취약점: CVE-2025-55182 (별칭 React2Shell)
위치: React Server Components(RSC) – Flight 프로토콜 처리부
유형: 사전 인증 원격 코드 실행(Pre-auth RCE)
점수: CVSS 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)
원인
- 클라이언트가 보내는 Flight 페이로드를 서버에서 역직렬화할 때
- 특정 필드를 통해 Prototype Pollution/unsafe deserialization이 가능해지고
- 결과적으로 공격자가 서버 컨텍스트에서 임의 코드를 실행할 수 있음

300x250

⚠️ 중요 포인트

애플리케이션이 직접 “서버 함수(Server Actions)”를 구현하지 않아도
- RSC를 지원하는 프레임워크(Next.js 등)를 쓰는 순간
- 내부 “통합 계층”에서 취약한 코드 경로가 활성화될 수 있음
공격자는 특수하게 조작된 HTTP 요청 1회 만으로 RCE 가능
- 인증 불필요, 사용자 상호작용 불필요 → 대규모 스캔·자동화 공격에 최적화

2. 기술적 배경 – RSC · Flight · Prototype Pollution

React Server Components & Flight

RSC는 일부 컴포넌트를 서버에서 렌더링/실행하고 결과만 클라이언트로 보내는 구조
이때 클라이언트↔서버 간 통신에 사용하는 것이 Flight 프로토콜
- JSON 유사 구조로 컴포넌트/함수 호출 정보를 담아 서버에 전송

취약점이 생기는 흐름(요약)

클라이언트가 Flight 요청을 보낼 때
RSC 런타임이 이를 역직렬화하고,
내부적으로 requireModule(), then, __proto__ 등의 필드를 통해
Prototype Pollution → 임의 코드 경로 실행으로 이어질 수 있는 지점이 존재

결과적으로

“Flight 페이로드를 어떻게든 ‘모듈 로딩/실행 경로’로 틀어지게 만들면, 서버에서 임의 코드 실행까지 이어진다”는 구조입니다.

3. 영향 범위 정리

1. 취약한 React RSC 패키지 버전

주요 취약 패키지/버전 (React 19 계열)

패키지	취약 버전	패치 버전(예시)
`react-server-dom-webpack`	19.0.0, 19.1.0, 19.1.1, 19.2.0	19.0.1, 19.1.2, 19.2.1
`react-server-dom-parcel`	위와 동일	동일
`react-server-dom-turbopack`	위와 동일	동일

실무에서는 “React 19.0~19.2.0 + RSC 사용 = 의심”,
최소 19.0.1 / 19.1.2 / 19.2.1 이상으로 올렸는지 확인하는 게 안전합니다.

2. 영향을 받는 프레임워크 및 생태계

대표 프레임워크/도구

Next.js (특히 App Router 사용 시)
React Router (RSC 모드)
Expo (RSC 통합 환경)
Waku, Redwood SDK
Vite RSC 플러그인, Parcel RSC 플러그인 등

Next.js 특이사항

영향 받는 경우
- Next.js 15.x / 16.x
- Next.js 14.3.0-canary.77 이후 일부 카나리 빌드
비교적 안전한 경우
- Next.js 13.x
- Next.js 14.x “안정 버전” + Pages Router 전용
React를 npm dependency로 두지 않고 vendoring(번들에 내장)하기 때문에
- 일반적인 SCA 도구가 내부에 포함된 취약 RSC 패키지를 못 보는 블라인드 스팟 발생

4. 위협 동향 및 공격 사례

1. CISA KEV 등록

CISA KEV

2025-12-06, CISA가 CVE-2025-55182를 Known Exploited Vulnerabilities(KEV)에 공식 추가
→ “실제 공격에서 악용이 확인된 취약점”으로 분류

2. 중국 계열(China-nexus) 그룹의 신속 악용

AWS Security Blog 분석

공개 후 수 시간 이내에
- Earth Lamia, Jackpot Panda 등 중국 연계 그룹이
- 금융, 리테일, 물류, IT, 교육, 공공 등 다수 섹터를 대상으로 대규모 스캔 및 공격 시도 수행

3. 북한 계열(라자루스) EtherRAT/EtherHiding

Sysdig · 여러 매체 분석

12월 5일 이후, 북한 계열(라자루스/UNC5342) 그룹이 React2Shell을 활용해
- EtherRAT라는 새로운 백도어를 배포하고,
- C2 정보를 이더리움 스마트 컨트랙트에 숨기는 EtherHiding 기법을 사용
특징
- nodejs.org에서 합법적으로 Node.js 런타임 내려받아 활용 → 탐지 회피
- 다계층 영구성(persistence), 자가 업데이트 등 매우 정교한 공격

4. 봇넷/크립토재킹 및 무작위 스캔

GreyNoise, 기타 분석

공개 PoC + 스캐너 등장 후
- 일반 공격자/봇넷이 무작위 스캔 + 자동 악용에 React2Shell 모듈을 추가 중
일부 캠페인에서 XMRig 기반 크립토재킹까지 확인

5. 조직 관점 종합 대응 전략

보안/CSIRT 관점에서 “당장 할 것” + “그 다음 할 것” 순서대로 정리했습니다.

1단계 – 자산 및 노출 범위 식별

1) React/Next.js/RSC 사용 서비스 전수 파악

질문 리스트
- 우리 조직에서 운영하는 서비스 중
  - React 19.x를 사용하는 서비스?
  - Next.js 14.3+ / 15 / 16, 특히 App Router 기반 서비스?
  - Expo, React Router RSC 모드, Waku, Redwood, Vite/Parcel RSC 플러그인 사용 서비스?

2) 실무 버전 확인 명령 예시

# 서비스 루트에서 React / RSC 패키지 확인
npm ls react react-dom \
  react-server-dom-webpack \
  react-server-dom-parcel \
  react-server-dom-turbopack

# Next.js 버전 확인
npm ls next

# yarn/pnpm 사용 시
yarn list --pattern react-server-dom
pnpm list react-server-dom-*

Git 레포 전체에서 react-server-dom- 문자열 검색
package-lock.json, yarn.lock, pnpm-lock.yaml에 "next": "15. / "next": "16. 검색

3) 보고 포맷 예시

서비스명 / URL
사용 프레임워크/버전 (React, Next.js, 기타)
RSC/Server Actions 사용 여부
클라우드 호스팅 여부(Vercel 등)
현재 패치 상태(패치 완료 / 진행 중 / 미계획)

2단계 – 패치 및 구성 변경 (가장 중요한 부분)

1. React & RSC 패키지 업그레이드

npm 기준 업그레이드 예

# React 및 ReactDOM 최신화
npm install react@latest react-dom@latest

# RSC 관련 패키지 최신화
npm install react-server-dom-webpack@latest
npm install react-server-dom-parcel@latest
npm install react-server-dom-turbopack@latest

정책
- 최소 19.0.1 / 19.1.2 / 19.2.1 이상을 기준으로 삼고
- 가능하면 React 팀이 권고하는 최신 안정 버전으로 통일

2. Next.js 환경 패치 전략

Next.js 기준 가이드

# 예: Next 15 최신 패치 버전으로 업그레이드
npm install next@15.x.x

# 예: Next 16 최신 패치 버전
npm install next@16.x.x

# 14.x canary 사용 중이면 안정 버전으로 롤백
npm install next@14

App Router 사용 중인 서비스
- 우선 패치 버전으로 올린 뒤,
- 가능하면 민감 서비스는 Pages Router 전환 여부도 검토 (중장기)

3. 패치 전 임시 완화(가능한 경우)

일부 서비스에서는 아래와 같은 임시 방안 검토 가능
- RSC/Server Actions 기능 비활성화
- 특정 RSC endpoint를 L7에서 차단 또는 내부망 한정
단, 프레임워크 내부 구현과 결합도가 높기 때문에
- 공식 패치 없이 설정만으로 ‘완전 차단’했다고 가정하면 위험

3단계 – WAF / IPS / 웹 게이트웨이 강화

1. 클라우드 WAF 활용

벤더별 요약

AWS: CloudFront/AWS WAF용 React2Shell 완화 룰 제공,
- AWSManagedRulesKnownBadInputsRuleSet 등에 포함
Azure: Azure WAF 커스텀 룰 세트로 React2Shell 대응 가이드 제공
GCP: Cloud Armor용 완화 가이드 및 룰 패턴 제공

메시지는 명확히:
“클라우드 WAF는 패치까지 시간을 버는 보조수단일 뿐, 근본 해결책은 아님”이라고 내부에 공유해야 합니다.

2. 자체 WAF/게이트웨이 룰 설계 포인트

검사 포인트

HTTP 헤더
- Next-Action, X-ReactFlight-* 등 Flight/RSC 관련 커스텀 헤더
Body/Content-Type
- multipart/form-data + 특이한 form-data name 조합(예: "0", _rsc, _react, status 등)
Payload 내용
- JSON 내 __proto__, constructor, then, resolved_model 등의 키 조합

ModSecurity 개념 예시

# Next-Action 헤더 존재 시 의심
SecRule REQUEST_HEADERS:Next-Action "@rx .+" \
  "id:2551821,phase:2,log,deny,\
  msg:'Potential React2Shell / RSC attack - Next-Action header detected'"

# RSC 경로 + multipart/form-data 조합 차단 예 (개념)
SecRule REQUEST_HEADERS:Content-Type "@contains multipart/form-data" \
  "id:2551822,phase:2,log,deny,\
  msg:'Suspicious multipart to RSC endpoint',\
  chain"
  SecRule REQUEST_URI "@rx /_rsc|/react" "t:none"

실제 운영에서는 엔키화이트햇, 티오리, 국내/글로벌 WAF 벤더가 제공하는 공식 룰셋을 최대한 활용하고, 위 예시는 “보안팀이 컨셉을 이해하고 벤더 룰을 리뷰할 때 참고하는 수준”으로 쓰는 것이 좋습니다.

3. Charset(UTF-16LE) 우회 방어

우회 기법에 대한 대응

공격자가 WAF를 우회하기 위해 UTF-16LE, UTF-32 등 비표준 charset으로 페이로드를 보내는 기법이 논의 중
대응 방안
- 웹게이트웨이에서 charset 화이트리스트 운영 (예: utf-8만 허용)
- charset 미지정·비정상인 경우, 로깅 + 강한 제약
- WAF의 “인코딩 정규화 후 검사” 옵션이 있다면 활성화

4단계 – 공격 탐지 및 로그 모니터링

1. IDS/IPS 룰 적용

Snort/Suricata

Cisco Talos 등에서 React2Shell 전용 시그니처 제공(예: gid:sid 1:65554 등)
자체 룰 예(개념 – 귀하가 인용하신 TryHackMe 기반 룰과 유사)

alert http any any -> $LAN_NETWORK any (
  msg:"Potential Next.js React2Shell / CVE-2025-55182 attempt";
  flow:to_server,established;
  content:"Next-Action"; http_header; nocase;
  content:"multipart/form-data"; http_header; nocase;
  pcre:"/\"status\"\s*:\s*\"resolved_model\"/s";
  pcre:"/\"then\"\s*:\s*\"\$1:__proto__:then\"/s";
  classtype:web-application-attack;
  sid:6555182;
  rev:1;
)

2. 로그 쿼리 예시

웹 로그(Grep)

# Next-Action 헤더가 포함된 요청 탐색
grep -i "Next-Action" /var/log/nginx/access.log*

# RSC 경로로 multipart 요청 탐색
grep -i "multipart/form-data" /var/log/nginx/access.log* | grep -E "/_rsc|/react"

Elasticsearch/Kibana 예시 (query_string)

request.headers:("Next-Action" OR "X-ReactFlight" OR "X-Next-Action")
AND request.method:(POST OR PUT)

request.body:( "__proto__" AND "resolved_model" AND "then" )

→ 이런 쿼리를 임시 saved search/Detection Rule로 만들어 두면, 관제에서 빠르게 모니터링 가능합니다.

5단계 – 취약 자산 진단(스캐너 활용)

1. 외부 인터넷 노출 자산 스캔

Nuclei

# React2Shell 전용 템플릿을 사용한 스캔 예시
nuclei -t cves/2025/CVE-2025-55182.yaml -u https://target.example.com

도메인 인벤토리에서 React/Next.js 사용 의심 도메인 리스트를 뽑아 일괄 스캔

기타 스캐너

Theori ReactGuard (웹/CLI)
엔키화이트햇, OWASP Seoul, 국내 여러 보안사에서 제공하는 웹/CLI 스캐너

2. 내부망/사설 도메인

CLI 기반 스캐너(ReactGuard CLI, OWASP Seoul 등)를
- 내부망 자산에 대해 정기적으로 실행
정책화
- 신규/변경 배포 시 React2Shell 스캔 필수
- 분기·월 단위 전체 내부 자산 스캔

6단계 – 침해 여부 조사 및 사고 대응(IR)

1. 서버 측 행위 점검

실행/프로세스 레벨

웹서비스 계정 기준으로
- 비정상 bash, sh, curl, wget, python, node, xmrig 프로세스 존재 여부
- /tmp, /dev/shm, /var/tmp 등 임시 디렉터리에 수상한 실행 파일/스크립트 존재 여부
영구성(Persistence)
- crontab, systemd 서비스, /etc/rc.local, ~/.bashrc 등 변경 사항
- 의심스러운 서비스/타이머 유무

2. 클라우드 자격증명·설정 탈취 여부

클라우드 측 점검

AWS/Azure/GCP IAM 로그에서
- 생소한 리전/서비스에서의 API 호출
- 대량 List/Get 호출 패턴
- S3, Secrets Manager, Parameter Store 등에서의 비정상 접근
React2Shell 악용 캠페인에서 클라우드 설정/자격증명 탈취 시도가 보고된 만큼,
- 의심 시 키/토큰 전면 교체를 기본 대응으로 가져가는 것이 안전합니다.

3. EtherRAT / EtherHiding 관련 점검

EtherRAT 특징
- Ethereum 네트워크로 C2 정보 조회
- Node.js 런타임 번들/다운로드 후 사용
점검 포인트
- 서버에서 비정상 Ethereum RPC/노드 접속 시도
- Node.js가 예상치 못한 경로에서 실행되는 패턴
- Sysdig·벤더가 제공하는 YARA/규칙 활용

4. 의심 시 IR 기본 플로우

서비스/인스턴스 격리(네트워크 단절)
메모리/디스크 이미지 확보 (포렌식 대비)
해당 서비스 관련 모든 자격증명 교체
소스/빌드 시스템 점검 후 클린 빌드 + 신규 이미지로 재배포
비즈니스 영향/재발 방지 대책까지 포함한 사후 분석 리포트 작성

7단계 – 중장기 보안 체계 강화

프레임워크 취약점 SLA

프레임워크 레벨 취약점(React/Next.js, Spring 등)은
- Tier-0 (최상위 위험)로 분류
SLA 예시
- 외부 노출 서비스: 48~72시간 내 패치
- 내부/어드민 서비스: 7일 내 패치

SBOM + SCA 의무화

모든 서비스 빌드 시
- SBOM(Syft/Trivy 등) 생성
- SCA 도구(Trivy, osv-scanner 등)로
  - CVE-2025-55182급 Critical 발견 시 빌드 실패 정책

RSC/서버 기능 도입 시 보안 검토 의무

신규 프로젝트에서 RSC/Server Actions 사용하려면
- 사전 Threat Modeling/보안 검토 문서 필수
- “클라이언트에서 서버 함수를 호출한다 = 사실상 API 노출”이라는 인식 정착

WAF 변경 관리 프로세스

Cloudflare처럼 WAF 룰 오배포로 대규모 장애가 발생하지 않도록,
- 스테이징 테스트 → 일부 도메인 → 전체 도메인 순 단계적 롤아웃
- 롤백 전략(기존 룰셋 복구 절차) 문서화

개발/운영/보안 교육

이번 사례를 중심으로
- 프레임워크 기본 기능도 공격 표면이라는 관점
- “서버 컴포넌트 = 서버 코드, 즉 가장 민감한 영역”이라는 메시지 전달
- 실제 PoC 시연/연습 환경(TryHackMe 등)을 활용한 실습 교육 권장

내부 배포용 실무 체크리스트

개발팀용

우리 서비스에서 React 19.x / Next.js 14.3+ / 15 / 16, RSC 사용하는지 확인
해당 시 React / RSC / Next.js를 패치 권고 버전 이상으로 업그레이드
npm ls 결과와 패치 상황을 보안·플랫폼팀에 공유
신규 배포 시 SBOM & SCA 리포트 첨부

플랫폼/인프라팀용

WAF/게이트웨이에서 React2Shell 관련 공식 룰셋 최신 적용
charset=utf-8 기반 화이트리스트 정책 검토 및 비정상 인코딩 차단
Nuclei/ReactGuard 등으로 외부 노출 자산 정기 스캔
IDS/IPS 룰셋에 React2Shell 전용 시그니처 활성화

보안관제/IR팀용

12월 초 이후 RSC/Next.js 서비스 대상 비정상 HTTP 패턴 탐지 룰 구성
CISA KEV, AWS, Sysdig, 국내 CTI에서 제공하는 React2Shell IoC 최신 반영
크립토재킹(XMRig), EtherRAT/EtherHiding 관련 이벤트 상시 모니터링
침해 의심 시 격리→포렌식→자격증명 교체→재배포 플로우 실행

728x90

그리드형(광고전용)

저작자표시 비영리 동일조건 (새창열림)

CVSS 10.0 React2Shell(RSC) 원격코드실행 React/Next.js 취약점

CVSS 10.0 React2Shell(RSC) 원격코드실행 React/Next.js 취약점

1. 취약점 개요 – React2Shell(CVE-2025-55182)

2. 기술적 배경 – RSC · Flight · Prototype Pollution

3. 영향 범위 정리

1. 취약한 React RSC 패키지 버전

2. 영향을 받는 프레임워크 및 생태계

4. 위협 동향 및 공격 사례

1. CISA KEV 등록

2. 중국 계열(China-nexus) 그룹의 신속 악용

3. 북한 계열(라자루스) EtherRAT/EtherHiding

4. 봇넷/크립토재킹 및 무작위 스캔

5. 조직 관점 종합 대응 전략

1단계 – 자산 및 노출 범위 식별

2단계 – 패치 및 구성 변경 (가장 중요한 부분)

1. React & RSC 패키지 업그레이드

2. Next.js 환경 패치 전략

3. 패치 전 임시 완화(가능한 경우)

3단계 – WAF / IPS / 웹 게이트웨이 강화

1. 클라우드 WAF 활용

2. 자체 WAF/게이트웨이 룰 설계 포인트

3. Charset(UTF-16LE) 우회 방어

4단계 – 공격 탐지 및 로그 모니터링

1. IDS/IPS 룰 적용

2. 로그 쿼리 예시

5단계 – 취약 자산 진단(스캐너 활용)

1. 외부 인터넷 노출 자산 스캔

2. 내부망/사설 도메인

6단계 – 침해 여부 조사 및 사고 대응(IR)

1. 서버 측 행위 점검

2. 클라우드 자격증명·설정 탈취 여부

3. EtherRAT / EtherHiding 관련 점검

4. 의심 시 IR 기본 플로우

7단계 – 중장기 보안 체계 강화

내부 배포용 실무 체크리스트

개발팀용

플랫폼/인프라팀용

보안관제/IR팀용

관련글

댓글

티스토리툴바