React2Shell 대응: Next.js·React 서버 컴포넌트 보안 정리

핵심 요약

React Server Components 취약점(CVE-2025-55182 / CVE-2025-66478)로 인해 Next.js 15~16.0.6 구간이 광범위하게 영향을 받았습니다. Vercel의 WAF가 많은 공격을 걸러내고 있지만, 궁극적인 해결책은 애플리케이션을 패치된 버전으로 즉시 업그레이드하는 것입니다.

React2Shell 취약점 상황 개관

React2Shell은 React Server Components(RSC)를 악용해 서버 측에서 임의 코드 실행까지 이어질 수 있는 심각한 취약점 계열입니다.

이번 이슈는 특정 프레임워크 한두 개만의 문제가 아니라, RSC를 사용하는 모든 애플리케이션이 잠재적으로 영향을 받을 수 있다는 점이 핵심입니다.

특히 Next.js 15.0.0부터 16.0.6까지의 대부분 릴리스가 포함되어 있어, "최신 버전이라서 안전하겠지"라는 기대가 통하지 않는 상황입니다. 따라서 현재 사용 중인 버전 확인과 신속한 업데이트가 가장 중요한 액션입니다.

Next.js: 어떤 버전이 위험하고 무엇으로 올려야 하는가

보안 대응의 첫 단계는 "내 버전이 취약한가?"를 정확히 판단하는 것입니다.

Next.js는 15~16 계열 상당수가 취약하며, 아래는 "취약한 버전대 → 안전한(패치된) 버전"의 대응 관계입니다.

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

캐너리 버전은 일반 릴리스와 규칙이 다릅니다.

Next.js 14 캐너리는 14.3.0-canary.76 이후 일부가 취약하며, 이 경우 오히려 해당 버전으로 "다운그레이드"하는 것이 안전한 선택입니다. 반대로 Next.js 15, 16 캐너리는 특정 버전 이후가 패치 버전입니다.

14 캐너리: 14.3.0-canary.76 "이후"가 취약 → 14.3.0-canary.76이 안전
15 캐너리: 15.6.0-canary.58 "이후"가 안전 버전
16 캐너리: 16.1.0-canary.12 "이후"가 안전 버전

결론적으로, 자신이 속한 메이저/마이너 라인을 확인한 뒤, 위 표에서 제시하는 최소 패치 버전 이상으로 올리면 됩니다.

내 Next.js 버전 확인하는 간단한 방법

버전 확인은 어렵지 않습니다. 앱이 이미 배포되어 있다면, 브라우저 콘솔에서 한 줄로 확인할 수 있습니다.

next.version

이 값을 통해 현재 배포된 버전을 확인하고, 앞에서 정리한 패치 버전 목록과 비교하면 됩니다.

로컬 프로젝트에서는 package.json 파일의 dependencies 또는 devDependencies 안에 있는 "next": "..." 항목을 보면 됩니다. 개발용과 배포용이 다를 수 있으니, 최종 배포 환경의 버전도 반드시 확인하는 것이 좋습니다.

React Server Components를 쓰는 다른 프레임워크의 경우

Next.js를 사용하지 않더라도, React Server Components를 사용하는 프레임워크라면 같은 계열의 위험에 놓일 수 있습니다.

예를 들어 RSC 기반 자체 프레임워크나, react-server-dom-* 계열 패키지를 직접 사용하는 경우에도 취약 버전인지 확인이 필요합니다.

이때는 React 팀이 공개한 공식 보안 공지(React Security Advisory)를 기준으로, 사용하는 패키지와 버전을 하나씩 대조하고, 해당 프로젝트에서 안내하는 패치 버전으로 즉시 업그레이드하는 것이 가장 안전한 절차입니다.

Vercel WAF 방어: 무엇을 해주고, 무엇은 안 해주는가

Vercel은 이 취약점이 공개되기 전부터 React 팀과 협력해 WAF(Web Application Firewall) 규칙을 준비하고 배포했습니다. 이 규칙들은 이미 알려진 공격 패턴을 기반으로 의심스러운 요청을 필터링하고 차단합니다.

실제로 취약점 관련 POC가 공개된 뒤, Vercel WAF의 검증 트래픽에 큰 스파이크가 관측되었는데, 이는 공격자들이 활발히 스캔 및 시도를 하고 있음을 보여줍니다.

이 방어막 덕분에 많은 공격이 차단되지만, WAF는 원리상 "알려진 패턴이나 특정 규칙"에 의존합니다. 새로운 변종 공격이나 정교하게 우회된 페이로드까지 100% 막는 것은 불가능합니다.

따라서 Vercel에 호스팅 중이라고 해서 업그레이드를 미루는 것은 매우 위험합니다. WAF는 "안전벨트" 정도로 이해하고, 실제 문제를 해결하는 것은 "소프트웨어 업데이트"라고 생각하는 편이 좋습니다.

Vercel이 제공하는 취약성 노출 확인 방법

Vercel은 사용자 편의를 위해 대시보드에 취약성 관련 안내도 추가했습니다.

프로덕션 배포에 next, react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack의 취약 버전이 포함되어 있으면, Vercel 웹사이트 상단에 이를 알려주는 배너가 표시됩니다.

다만 이 알림은 어디까지나 "추가적인 안전장치"일 뿐, 완전한 진단 도구는 아닙니다. 프로젝트 코드와 배포 버전을 직접 확인하는 절차를 반드시 병행해야 합니다.

또한 Vercel은 취약한 Next.js 버전을 사용하는 새 배포에 대해, 아예 배포 자체를 차단하는 조치도 도입했습니다. 이는 실수로 취약 버전을 다시 배포하는 일을 줄여주는 보호장치입니다.

이미 공격당했는지 어떻게 점검할 수 있을까?

WAF가 선제적으로 적용되었더라도, "혹시 이미 뚫린 건 아닐까?"라는 불안은 남습니다. 이 경우 직접 로그와 시스템 행동을 점검하는 것이 중요합니다.

우선 함수 실행 로그, API 로그 등에서 평소와 다른 패턴이 있는지 살펴봅니다. 대표적으로 특이한 형태의 POST 요청이 늘어나거나, 특정 엔드포인트에서 비정상적인 호출 빈도가 관측될 수 있습니다.

또한 서버리스 함수의 타임아웃이 갑자기 증가하는 현상도 참고 지표가 될 수 있지만, 이것만으로는 침해 사실을 단정할 수 없습니다. 공격자는 의도적으로 빠르게 끝나는 페이로드를 만들 수도 있고, 반대로 단순 스캐닝만으로도 타임아웃이 늘어날 수 있기 때문입니다.

결국 "정상적 사용 패턴과 비교했을 때 이례적인 행동이 있는가?"를 중심으로, 로그·모니터링 시스템을 통해 다각적으로 살펴보는 것이 현실적인 대응입니다.

캐너리 기능을 쓰는 Next.js 프로젝트의 선택지

Next.js의 캐너리 버전은 실험적 기능을 먼저 써볼 수 있는 대신, 안정성과 보안 리스크가 더 클 수 있습니다. 이번 취약점 역시 일부 캐너리 버전만을 따로 고려해야 했습니다.

문제는 "캐너리 전용 기능"을 이미 프로덕션에서 사용 중인 경우입니다. 이때 단순히 안정 버전으로 내리면 기능이 사라지거나 동작이 달라질 수 있습니다.

Next.js 보안 공지에서는 이런 상황을 고려해, 캐너리 기능을 유지하면서도 취약점을 해결할 수 있는 특정 패치 캐너리 버전으로의 업그레이드 경로를 안내하고 있습니다. 즉, "기능을 포기할 것인가 아니면 위험을 감수할 것인가"의 양자택일이 아니라, "보안 패치된 캐너리 버전으로 이동"이라는 제3의 선택지가 준비되어 있습니다.

공개된 POC로 직접 공격 테스트를 해도 될까?

인터넷에 돌아다니는 POC 코드로 내 서비스를 직접 공격해보고 싶은 유혹이 생길 수 있습니다. 하지만 프로덕션 환경에서 이것을 실행하는 것은 매우 큰 위험을 수반합니다.

첫째, POC 자체에 악성 코드나 의도치 않은 부작용이 포함되어 있을 수 있습니다. 둘째, 설령 "테스트"였다고 하더라도 실제 데이터 파손, 성능 저하, 예기치 못한 상태 변화를 일으킬 수 있습니다.

만약 꼭 테스트가 필요하다면, 실제 데이터가 없는 별도의 샌드박스 환경을 만들고, 네트워크·데이터 격리 상태에서 실험하는 것이 바람직합니다. 그 이전에 해야 할 최우선 작업은 어디까지나 "패치 적용"입니다.

인사이트

이번 React2Shell 사태에서 얻을 수 있는 가장 큰 교훈은 두 가지입니다.

첫째, "RSC와 같은 최신 기술 스택을 쓴다면, 보안 공지와 릴리스 노트를 정기적으로 확인하는 습관"이 필수라는 점입니다. 기능 업데이트만이 아니라 보안 패치 버전에 항상 주목해야 합니다.

둘째, "WAF나 클라우드 제공자의 보호 장치에만 의존하지 말 것"입니다. 방화벽, 탐지 시스템은 중요한 방어선이지만, 애플리케이션 자체를 패치하지 않는 한 근본적인 문제는 그대로 남습니다.

실무적 조언을 정리하면 다음과 같습니다.

지금 사용하는 Next.js·React RSC 관련 패키지 버전을 즉시 확인하고,
공식이 제시한 최소 패치 버전 이상으로 업그레이드하며,
배포 후 로그와 모니터링을 통해 이상 징후를 꾸준히 확인하고,
신규 기능·캐너리 기능을 도입할 때는 보안 리스크를 함께 평가하는 절차를 팀 문화로 정착시키는 것이 좋습니다.

이 네 가지만 지켜도 유사한 취약점이 다시 등장했을 때 훨씬 빠르고 침착하게 대응할 수 있습니다.

출처 및 참고 : Resources for protecting against 'React2Shell' - Vercel