[이슈 해결] Next.js RSC 취약점(React2Shell) 긴급 대응 및 패치

1. 배경

2025년 12월 초, React 생태계 전반을 강타한 'React2Shell' RCE : Remote Code Execution 취약점 사태가 발생했다. 커뮤니티의 집중적인 연구가 이어진 가운데, 12월 12일 Vercel Security Team으로부터 해당 사태의 연장선상에 있는 추가 취약점인 DoS 및 소스 코드 노출에 대한 긴급 보안 권고 이메일을 수신했다.

Deep Dive! 블로그는 Next.js App Router를 기반으로 구축되어 있어, 해당 이슈의 직접적인 영향권에 있음을 인지하고 긴급 점검 및 패치 작업을 진행했다.

2. 취약점 상세 분석

공개된 CVE 정보와 Vercel의 보안 권고를 리서치한 결과, 이번 취약점은 React Server Components(RSC)의 데이터 처리 방식인 'Flight' 프로토콜의 역직렬화 과정에서 발생한다.

2.1 식별된 주요 취약점

CVE ID	심각도	유형	상세 내용
CVE-2025-55184	High	DoS (서비스 거부)	공격자가 특수하게 조작된 HTTP 요청을 보내면, 서버가 이를 역직렬화하는 과정에서 무한 루프에 빠지거나 CPU 자원을 과도하게 소모하여 프로세스가 멈춤.
CVE-2025-55183	Medium	Source Code Exposure	특정 요청을 통해 Server Action의 컴파일된 소스 코드가 클라이언트 응답으로 반환될 수 있음. 하드코딩된 Secret이 없다면 직접적인 키 유출은 없으나, 비즈니스 로직이 노출됨.

2.2 "Deep Dive!" 프로젝트에 미치는 영향

본 프로젝트는 AWS Lambda 위에서 Next.js를 구동하는 Serverless 아키텍처를 채택하고 있다. 일반적인 VM 기반 서버와 달리, 이번 취약점은 우리 아키텍처에 다음과 같은 특수한 위협을 가한다.

1. 비용 폭탄:
   • CVE-2025-55184 (DoS) 공격이 성공할 경우, Lambda 함수가 타임아웃 최대 15분까지 강제로 실행될 수 있다.
   • 공격자가 대량의 요청을 보낼 경우, Lambda의 실행 시간 과금이 급증하여 막대한 클라우드 비용이 발생할 수 있다.
2. Concurrency 고갈 (가용성 침해):
   • Lambda의 동시 실행 수 공격 요청 처리에 잠식당하면, 정상적인 독자가 블로그에 접속했을 때 503 Service Unavailable 오류를 겪게 된다.
3. Server Action 로직 노출:
   • PostUtilButtons.tsx 등 클라이언트 컴포넌트와 상호작용하는 Server Action의 내부 로직(예: Polly 음성 생성 트리거 로직, 조회수 집계 방식 등)이 노출될 가능성이 확인되었다.

3. 현황 진단

로컬 환경에서 package.json 및 설치된 모듈을 검사하여 현재 버전을 확인했다.

버전 비교 분석

패키지명	현재 사용 버전 (Vulnerable)	패치된 최신 버전 (Patched)	상태
react	19.1.0	19.x.x (Latest)	⚠️ 위험
react-dom	19.1.0	19.x.x (Latest)	⚠️ 위험
next	15.4.5	16.0.x 이상	🚨 Critical

진단 결과: 현재 사용 중인 next: 15.4.5는 보안 패치가 발표되기 이전의 버전으로, 위에서 분석한 모든 위협에 무방비 상태임이 확인되었다. 즉시 업그레이드가 필요했다.

4. 조치 과정

4.1 패키지 업그레이드

pnpm을 사용하여 관련 패키지들을 최신 안정 버전(Latest Stable)으로 일괄 업데이트했다.

pnpm --filter frontend update next@latest react@latest react-dom@latest

4.2 빌드 에러 트러블슈팅

버전 업그레이드 후 로컬 빌드(pnpm build) 과정에서 예상치 못한 의존성 에러가 발생했다.

• 에러 로그: Module not found: Can't resolve '@toast-ui/editor/dist/theme/toastui-editor-dark.css'
• 원인 분석: Next.js 메이저 버전 업그레이드(v16 도입 추정)에 따른 번들러인 Turbopack 등의 동작 방식 변화와 pnpm의 엄격한 의존성 관리 방식이 충돌하여, Toast UI Editor의 내부 스타일 파일을 찾지 못하는 현상이 발생했다.
• 해결:
  1. node_modules 및 .next 캐시 디렉토리 완전 삭제.
  2. @toast-ui/editor 패키지를 frontend 워크스페이스에 명시적으로 추가하여 의존성 트리를 평탄화.

     pnpm --filter frontend add @toast-ui/editor

수정 후 로컬 빌드가 정상적으로 완료(Compiled successfully)됨을 확인했다.

pnpm --filter frontend build

5. 배포 및 검증

5.1 CI/CD 파이프라인 실행

검증된 코드를 main 브랜치에 푸시하여 GitHub Actions 기반의 CI/CD 파이프라인을 트리거했다.

• Build: Next.js 빌드 및 Docker 이미지 생성 (멀티스테이지 빌드).
• Deploy: AWS CDK를 통해 Lambda 함수 업데이트.

5.2 배포 후 테스트

배포 완료 후 실제 서비스(blog.jungyu.store)에서 기능 정상화 여부를 점검했다.

1. 렌더링 확인: RSC 기반의 상세 페이지 렌더링 속도 및 레이아웃 정상 확인.
2. 기능 확인:
   • Polly 음성 듣기 기능 : Server <-> Client 통신 정상 동작.
   • 다크 모드 토글 및 로컬 스토리지 연동 정상 확인.
3. 보안 확인: 브라우저 콘솔 내 특이 에러 없음, Sentry 대시보드 상 신규 이슈 없음 확인.

6. 마무리

금요일 밤에 수신한 Vercel의 보안 권고 메일은 꽤 긴급한 사안이었지만, 다행히 크게 당황하지 않고 차분하게 대응할 수 있었다.

취약점의 원인을 파악하고 패키지 버전을 올리는 것은 오롯이 나의 몫이었지만, 그 이후의 과정은 그동안 구축해 둔 시스템이 해결해 주었기 때문이다. 로컬에서 빌드 검증을 마친 후 메인 브랜치에 푸시하는 것만으로, 기존에 구성해 둔 CI/CD 파이프라인이 도커 이미지 빌드부터 AWS Lambda 배포까지의 전 과정을 자동으로 수행해 주었다. 덕분에 복잡한 배포 절차를 신경 쓸 필요 없이 문제 분석과 해결책 적용에만 집중할 수 있었다.

이번 대응을 통해 서버리스 환경에서의 보안 위협에 대해 다시 한번 깊이 생각해보게 되었다. 솔직히 그동안은 '서버리스'이니 보안이나 인프라 관리는 클라우드 플랫폼인 AWS의 몫이라고 막연하게 생각했었다. 하지만 이번 이슈를 통해 인프라가 아무리 안전해도 코드 레벨에서 구멍이 뚫리면 그 책임은 온전히 개발자인 나의 몫이 된다는 것을 깨달았다. 특히 Lambda 환경에서 코드 취약점은 단순한 에러를 넘어 '비용 폭탄'이나 '동시성 고갈' 같은 치명적인 인프라 손실로 직결될 수 있다는 점을 명확히 인지했다.

결국 보안 이슈는 언제든 발생할 수 있다. 중요한 것은 이슈가 발생했을 때 얼마나 빠르고 안정적으로 대응할 수 있느냐인 것 같다. 이번 경험은 '잘 설계된 아키텍처와 자동화된 배포 환경이 실제 위기 상황에서 얼마나 큰 자산이 되는지' 를 직접 체감한 계기가 되었다.