CVE-2025-66478(React2Shell) 한눈에 보기
2025-12-03에 공개된 **CVE-2025-66478(React2Shell)**는 React Server Components(RSC) 프로토콜에 존재하던 치명적인 보안 취약점입니다. 공식 공지에 따르면 CVSS 10.0이며, **공격자가 인증 없이 원격 코드 실행(Remote Control Execution. 이하 RCE)**에 도달할 수 있는 수준입니다. 해당 이슈는 Next.js App Router를 포함해 RSC를 사용하는 환경에 영향을 줄 수 있어 빠른 패치가 필요합니다.
공식 공지에서는 패치 적용을 우선하기 위해 상세 기술 정보 공개를 제한하고 있습니다. 이 글 역시 동일한 원칙 아래에서 문제의 배경과 안전한 수준의 설명을 제공합니다.
TL;DR
- RSC 프로토콜 디코딩 과정의 취약점으로 공격자가 서버 함수(Server Function) 엔드포인트에 악성 요청을 보내 RCE가 가능했습니다.
- RSC를 지원하는 앱은 Server Function을 직접 쓰지 않아도 영향을 받을 수 있습니다.
- 우회 가능한 워크어라운드 없음: 패치 버전으로의 즉시 업그레이드가 유일한 대응입니다.
- 시크릿 회전 강력 권장: 2025-12-04 13:00 PT 이전까지 온라인 상태였던 서비스는 즉시 회전을 우선하세요.
왜 이런 문제가 발생했나
공식 발표에 따르면, 이번 취약점의 핵심은 React가 Server Function 요청의 payload를 디코딩하는 과정에 있습니다. RSC와 Server Function은 클라이언트 요청을 서버의 함수 호출로 변환하는 구조인데, 이 과정에서 공격자가 제어 가능한 입력이 서버 실행 경로에 영향을 주는 문제가 있었던 것입니다.
요약하면 다음과 같습니다.
- 클라이언트가 RSC/Server Function 요청을 보냅니다.
- 서버는 요청 payload를 디코딩하여 함수 호출로 변환합니다.
- 이 디코딩 로직에 취약점이 있어 공격자가 임의의 요청을 구성할 수 있었습니다.
- 결과적으로 서버에서 의도하지 않은 코드 실행 경로가 발생할 수 있었습니다.
React Server Components와 Server Functions 이해하기
RSC는 클라이언트와 서버의 경계를 나누어 렌더링 효율을 높이는 구조입니다. 이때 **Server Function(Server Action 포함)**은 클라이언트에서 서버 함수를 호출할 수 있게 해주는 연결 통로입니다.
간단한 흐름은 아래와 같습니다.
- 클라이언트: 특정 서버 함수 호출 요청 생성
- 서버: 요청 payload를 디코딩 → 함수 호출 → 결과 반환
즉, 서버 함수 호출은 결국 HTTP 요청으로 변환되며, 이 요청의 디코딩이 안전해야 합니다. 이번 이슈는 바로 이 지점에서 발생했습니다.
요청→디코딩→함수 호출 흐름 (시각화)
아래는 RSC/Server Function 요청의 흐름을 단순화한 그림입니다. 문제는 중앙의 “디코딩/역직렬화” 단계에서 발생했습니다.
[Client]
|
| 1) RSC/Server Function 요청 전송
v
[Edge/Server]
|
| 2) 요청 payload 디코딩/검증
v
[RSC Runtime]
|
| 3) 서버 함수 호출로 변환
v
[Server Function]
|
| 4) 서버 코드 실행
v
[Response]
공격자는 2) 디코딩 단계에 조작된 payload를 주입해, 3) 함수 호출 단계의 실행 경로를 의도와 다르게 만들 수 있었습니다. 이 때문에 정상 UI를 거치지 않고도 서버 실행 경로를 건드릴 수 있습니다.
문제가 되는 예시 코드 (안전한 수준의 예시)
아래는 Next.js App Router에서 흔히 사용하는 서버 액션 예시입니다.
// app/actions.ts
'use server'
export async function updateProfile(displayName: string) {
// DB 업데이트 등 서버에서만 실행되는 로직
await db.user.update({ data: { displayName } })
return { ok: true }
}
// app/profile/page.tsx
import { updateProfile } from '@/app/actions'
export default function ProfilePage() {
async function onSubmit(formData: FormData) {
'use server'
const displayName = String(formData.get('displayName') || '')
await updateProfile(displayName)
}
return (
<form action={onSubmit}>
<input name="displayName" />
<button type="submit">Save</button>
</form>
)
}
이 코드는 정상적인 서버 액션 사용법이며, 취약점의 원인이 코드 자체에 있는 것은 아닙니다. 문제는 React 내부에서 서버 함수 요청 payload를 디코딩하는 방식에 있었고, 이 부분을 악용한 공격자가 정상 UI를 거치지 않고도 서버 함수 엔드포인트로 악성 요청을 전달할 수 있었다는 점입니다.
중요한 포인트: Server Function을 직접 정의하지 않아도, RSC를 지원하는 런타임이라면 영향 가능성이 있습니다.
문제 입력의 성격 (개념 설명)
공식 공지는 상세 공격 패턴을 제한하고 있습니다. 안전한 수준에서 요약하면, 서버가 기대하는 형식과 다른 payload를 보내 디코딩 로직을 오용할 수 있었던 것으로 정리할 수 있습니다.
의도된 요청
- 서버가 기대하는 구조/타입/길이를 만족하는 payload
문제가 된 요청(개념)
- 구조/타입을 교란하거나 예상 밖의 조합을 가진 payload
- 디코딩 단계에서 검증을 우회 → 실행 경로 왜곡
즉, “서버 함수 호출” 자체가 위험한 것이 아니라, 디코딩 단계에서의 입력 검증이 충분하지 않았던 것이 핵심 원인입니다.
영향 범위
React 공식 공지 기준 요약입니다.
- 인증되지 않은 원격 코드 실행(RCE) 가능
- Server Function을 사용하지 않아도 RSC를 지원하는 앱은 영향을 받을 수 있음
- 서버가 없는 React 앱은 영향 없음
- RSC를 지원하지 않는 환경도 영향 없음
패치 버전 및 업그레이드 가이드
아래 버전으로 업그레이드하면 CVE-2025-66478에 대응됩니다. (공식 권장)
npm install next@14.2.35 # for 13.3.x, 13.4.x, 13.5.x, 14.x
npm install next@15.0.7 # for 15.0.x
npm install next@15.1.11 # for 15.1.x
npm install next@15.2.8 # for 15.2.x
npm install next@15.3.8 # for 15.3.x
npm install next@15.4.10 # for 15.4.x
npm install next@15.5.9 # for 15.5.x
npm install next@16.0.10 # for 16.0.x
npm install next@15.6.0-canary.60 # for 15.x canary
npm install next@16.1.0-canary.19 # for 16.x canary
React 자체 패치 버전은 다음과 같습니다.
- 19.0.1
- 19.1.2
- 19.2.1
자동 진단/업그레이드 도구
npx fix-react2shell-next
시크릿 회전 (강력 권고)
공식 공지에서는 2025-12-04 13:00 PT 기준으로 온라인 상태였던 서비스는 시크릿 회전을 강력 권장하고 있습니다. 패치 적용 후에는 아래 항목을 우선 회전하는 것이 안전합니다.
- 인증 토큰 서명 키, 세션 시크릿
- 외부 API 키/서비스 계정 키
- 데이터베이스 접속 정보
대응 체크리스트
- 권장 패치 버전으로 즉시 업그레이드
- 배포 후 환경 변수 및 시크릿 회전 (특히 2025-12-04 13:00 PT 이전 노출)
- 의심스러운 트래픽/로그 점검
- 외부 노출된 Server Function 엔드포인트 점검
정리
CVE-2025-66478은 React Server Components 프로토콜 자체의 취약점으로 인해 발생했습니다. 개발자 개별 코드 실수라기보다는 RSC 요청 디코딩 과정의 안전성 문제였고, 따라서 우회 방법 없이 업그레이드만이 해결책입니다. RSC 기반 서비스를 운영 중이라면 즉시 패치 적용과 시크릿 회전을 최우선으로 진행해야 합니다.




