# React 서버 컴포넌트의 DoS 및 소스 코드 노출 취약점 공개 > Clean Markdown view of GeekNews topic #25030. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25030](https://news.hada.io/topic?id=25030) - GeekNews Markdown: [https://news.hada.io/topic/25030.md](https://news.hada.io/topic/25030.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-13T03:34:57+09:00 - Updated: 2025-12-13T03:34:57+09:00 - Original source: [react.dev](https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components) - Points: 4 - Comments: 1 ## Topic Body - React Server Components에서 **서비스 거부(DoS)** 및 **소스 코드 노출** 취약점이 새로 발견되어 공개됨 - 이번 취약점은 **원격 코드 실행(RCE)** 은 불가능하지만, 서버 중단이나 코드 유출 위험이 존재 - 영향을 받는 패키지는 `react-server-dom-webpack`, `react-server-dom-parcel`, `react-server-dom-turbopack`의 **19.0.0~19.2.2 버전**이며, 수정 버전은 **19.0.3, 19.1.4, 19.2.3** - **DoS 취약점(CVE-2025-55184, CVE-2025-67779)** 은 악성 HTTP 요청으로 서버 무한 루프를 유발할 수 있고, **소스 코드 노출 취약점(CVE-2025-55183)** 은 서버 함수의 코드 일부를 반환할 수 있음 - React 팀은 즉시 업그레이드를 권고하며, 이번 추가 공개는 **보안 대응 주기의 정상적 과정**으로 설명됨 --- ### 새로 공개된 취약점 개요 - 보안 연구자들이 지난주 공개된 **치명적 취약점 패치 검증 중** 두 가지 추가 취약점을 발견 - 새 취약점은 **원격 코드 실행(RCE)** 은 불가능하며, 기존 **React2Shell 패치**는 여전히 유효 - 새로 공개된 취약점은 다음과 같음 - **서비스 거부(DoS)** — CVE-2025-55184, CVE-2025-67779 (CVSS 7.5, 높은 심각도) - **소스 코드 노출** — CVE-2025-55183 (CVSS 5.3, 중간 심각도) - React 팀은 **즉시 업그레이드**를 권고 ### 기존 패치의 불완전성 - 지난주 배포된 **19.0.2, 19.1.3, 19.2.2 버전의 패치가 불완전**하여 다시 업데이트 필요 - 완전한 수정은 **19.0.3, 19.1.4, 19.2.3 버전**에 포함 - 이전 게시물의 **업데이트 지침**을 따라야 함 - 수정 배포 완료 후 추가 세부 정보 공개 예정 ### 영향받는 패키지 및 버전 - 취약점은 **CVE-2025-55182**와 동일한 패키지 및 버전에 존재 - 영향받는 버전: 19.0.0~19.2.2 - 영향받는 패키지: - `react-server-dom-webpack` - `react-server-dom-parcel` - `react-server-dom-turbopack` - 수정 버전: 19.0.3, 19.1.4, 19.2.3 - 서버를 사용하지 않거나 React Server Components를 지원하지 않는 앱은 영향 없음 ### 후속 취약점 공개의 일반적 패턴 - **치명적 CVE 공개 후** 관련 코드 경로를 추가 분석하는 과정에서 후속 취약점이 종종 발견됨 - 예시로 **Log4Shell** 이후 추가 CVE들이 보고된 사례 언급 - 이러한 추가 공개는 **보안 대응이 정상적으로 작동하고 있음을 의미** ### 영향받는 프레임워크 및 번들러 - 다음 프레임워크 및 번들러가 취약한 React 패키지를 포함하거나 의존함 - `next`, `react-router`, `waku`, `@parcel/rsc`, `@vitejs/plugin-rsc`, `rwsdk` - 이전 게시물의 **업데이트 지침**을 따라야 함 ### 호스팅 제공자 완화 조치 - 여러 호스팅 제공자와 협력해 **임시 완화 조치** 적용 - 그러나 이러한 조치에 의존하지 말고 **즉시 업데이트** 필요 ### React Native 관련 지침 - **React Native 단독 사용자는 추가 조치 불필요** - **모노레포 환경**에서는 다음 패키지만 업데이트 필요 - `react-server-dom-webpack` - `react-server-dom-parcel` - `react-server-dom-turbopack` - `react` 및 `react-dom`은 업데이트할 필요 없음 - 관련 세부 내용은 React Native GitHub 이슈 참조 ### 높은 심각도: 서비스 거부(DoS) - **CVE-2025-55184, CVE-2025-67779**, CVSS 7.5 - 악성 HTTP 요청이 **React 서버 함수 엔드포인트**로 전송될 경우, 역직렬화 과정에서 **무한 루프 발생** - 서버 프로세스가 중단되고 CPU를 과도하게 점유할 수 있음 - 서버 함수 엔드포인트를 직접 구현하지 않아도, **React Server Components를 지원하는 앱**이면 취약할 수 있음 - 오늘 배포된 패치는 **무한 루프 방지**로 문제 해결 - 초기 수정이 불완전하여 추가 취약점(CVE-2025-67779)으로 보완됨 ### 중간 심각도: 소스 코드 노출 - **CVE-2025-55183**, CVSS 5.3 - 악성 HTTP 요청이 서버 함수의 **소스 코드 일부를 반환**할 수 있음 - 서버 함수가 문자열 인자를 명시적 또는 암묵적으로 노출할 경우 발생 - 예시 코드에서는 데이터베이스 연결 키 등 **하드코딩된 비밀값**이 노출될 수 있음 - 패치는 **서버 함수 소스 코드 문자열화 방지**로 문제 해결 - 노출 범위는 서버 함수 내부 코드로 제한되며, **런타임 비밀(process.env.SECRET 등)** 은 영향 없음 - 프로덕션 번들 기준으로 검증 필요 ### 타임라인 - **12월 3일**: Andrew MacPherson이 Vercel 및 Meta Bug Bounty에 코드 노출 보고 - **12월 4일**: RyotaK가 DoS 취약점 보고 - **12월 6일**: React 팀이 두 문제 확인 및 조사 시작 - **12월 7일**: 초기 수정안 작성 및 검증 계획 수립 - **12월 8일**: 호스팅 제공자 및 오픈소스 프로젝트에 통보 - **12월 10일**: 완화 조치 적용 및 패치 검증 완료 - **12월 11일**: Shinsaku Nomura가 추가 DoS 보고, CVE-2025-55183·55184·67779 공개 ### 보고자 - **Andrew MacPherson (AndrewMohawk)** — 소스 코드 노출 보고 - **RyotaK (GMO Flatt Security Inc)** 및 **Shinsaku Nomura (Bitforest Co., Ltd.)** — 서비스 거부 취약점 보고 ## Comments ### Comment 47655 - Author: neo - Created: 2025-12-13T03:34:57+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46236924) - React Server Components(RSC)는 항상 불편하게 느껴졌음 자바스크립트 코드만 봐서는 **클라이언트에서 실행되는 부분**과 **서버에서 실행되는 부분**을 구분하기 어렵기 때문임 게다가 이를 구현하려면 깊은 **직렬화 RPC 메커니즘**이 필요하고, 이는 개발자에게 불투명하며 보안 취약점의 위험을 높이는 지점이 됨 - 예전 **NextJS pages router** 시절엔 서버와 클라이언트 코드의 경계가 명확해서 좋았음 하지만 app router로 바꾸자 혼란스러웠음. 코드가 양쪽에서 실행될 수 있다 보니 Headers 같은 객체가 항상 존재하지 않아 **무엇이 어디서 실행되는지** 알기 어려웠음 - 새로 합류한 팀에서 Next를 쓰는 걸 보고 “이거 어떻게 동작하는지 아는 사람 있나요?”라고 물었는데, 아무도 명확히 설명하지 못했음 React+Next가 잘 작동할 땐 마법처럼 느껴지지만, 팀 단위로 일할 때는 **예측 가능성**이 점점 사라지는 게 문제라고 느낌 - 그래서 나는 **Inertia.js**의 팬임. [Inertia.js](https://inertiajs.com/)는 Laravel, Rails, Django 같은 전통적 MVC 백엔드와 React, Vue, Svelte 같은 프론트엔드 툴을 자연스럽게 연결해줌 역할이 명확하고, 작업이 단순하며, 대부분의 프로젝트에서 가장 안전한 선택이라고 생각함 - RSC와 SSR이 과도하게 채택된 것 같음 랜딩 페이지나 마케팅 페이지라면 SSR이 유용하지만, 일반 SaaS 대시보드 같은 앱에서는 복잡성에 비해 **이득이 거의 없음** - 다른 프레임워크(Angular, SvelteKit, Nuxt)는 이런 취약점에 얼마나 노출되어 있을지 궁금함 React가 단지 인기가 많아서 더 주목받는 걸까, 아니면 구조적으로 더 위험한 걸까 하는 의문이 있음 - 지난주 RSC를 살펴봤는데, **복잡성**이 너무 높고 문서도 거의 없었음 React는 아직 실험적 기능이라고 하지만 NextJS는 이미 광범위하게 배포했음 앞으로 더 많은 보안 이슈가 나올 것 같고, Next의 **빌드 시스템**은 지나치게 복잡해서 디버깅조차 어려웠음 얻는 이점에 비해 비용이 너무 큼 - 예전부터 Next가 “아직 프로덕션 준비가 안 된 React 기능”을 최신 기능처럼 포장한다는 불만이 있었음 그래서 나도 Next를 떠났음. **인지 부하**가 너무 커서 얻는 게 별로 없었음 - React는 오랫동안 **문서 부족** 문제가 있었음 RSC뿐 아니라 전반적으로 명확한 가이드가 늦게 나왔고, CRA 같은 도구도 공식적으로 인정하지 않음 이제 와서야 useEffect 문서가 좋아졌지만 너무 늦었음 2025년이 된 지금도 실무에서 쓰고 있는데, 여전히 **명확한 문서화**가 부족함 - SPA의 핵심은 “앱 전체를 클라이언트로 보내고 서버와는 **데이터만 주고받는 것**”이었음 - 그런데 지금 C# 진영에서는 **Blazor Server**가 유행임 예전 .aspx Web Forms처럼 모든 클릭과 입력이 서버로 전송되고, 변경된 DOM이 다시 내려옴 사실상 예전 방식으로 돌아간 셈이라 좀 황당함 - 결국 많은 개발자들이 다시 **서버 사이드 렌더링**의 이유를 깨닫고 PHP, Rails, Spring 같은 풀스택 프레임워크로 회귀했음 - 하지만 요즘은 React 같은 라이브러리로 **정적 사이트**를 만드는 경우가 많아졌고, 단순한 템플릿 엔진 + JS 조합보다 느리고 복잡함 “적절한 도구를 고르는 감각”이 사라진 게 아쉬움 - 물론 RSC는 순수 SPA용은 아님. 다른 목적을 가진 접근임 - 이번 보안 공지에서 “중대한 CVE가 발견되면 후속 취약점이 흔히 드러난다”는 문구가 가장 눈에 띄었음 문제의 범위나 영향, 완화 방법을 설명하기도 전에 **CVE를 정당화**하려는 듯 보여서 불안했음 - 하지만 어떤 사람은 “그건 정당화가 아니라, 사람들이 가장 먼저 궁금해할 부분에 대한 **설명**일 뿐”이라고 봄 - 피드백을 반영해 문구를 수정했다고 함 → [수정된 PR 링크](https://github.com/reactjs/react.dev/pull/8195) - 누군가는 이걸 **인식 관리(perception management)** 라고 표현함 [관련 위키 문서](https://en.wikipedia.org/wiki/Perception_management) - 이 사안에는 **커리어적 이해관계**가 얽혀 있다고 보는 시각도 있음 - 어떤 이는 “이건 Vercel 마케팅팀이 쓴 글처럼 보인다”고 말함 - 15년 전 **Opa**에서 이미 비슷한 시도를 했었음 클라이언트와 서버 코드를 자동으로 분리하고 JSX와 유사한 문법을 도입했음 하지만 보안 분석을 강화하다 보니 **컴파일러가 거대해졌고**, 결국 단일 앱 개념보다는 명확한 분리의 중요성을 깨달았음 언젠가 LLM이 이런 코드를 자동 생성할 수도 있겠지만, 지금은 단순한 구조가 낫다고 생각함 - 실제로 RSC의 취약점은 코드 분할보다는 **직렬화/역직렬화 과정의 동적 특성** 때문임 JS의 프로토타입 오염, 함수 toString, Promise 오버라이드 같은 문제를 막기 위한 패치가 진행 중임 RSC는 `import "server-only"`나 `import "client-only"` 같은 **정적 검증**으로 환경을 구분하기 때문에 구조적으로는 안전한 접근임 - 비슷한 아이디어로 **Electric Clojure**라는 프로젝트도 있음 → [링크](https://github.com/hyperfiddle/electric) - 참고로 **Ocsigen Eliom**이 Opa보다 먼저 이런 개념을 시도했음 - React는 원래 **MVC의 View** 역할로 작고 단순했을 때가 좋았음 지금은 너무 많은 기능이 들어가서 **비대해진 느낌**임 - 하지만 RSC는 별도 라이브러리라 기본 React 설치에는 포함되지 않음 - 예전 버전으로 돌아가려면 `git checkout v15.0.0`이면 됨 - RSC는 애초에 존재하지 말았어야 함 대부분의 앱은 서버에서 HTML을 렌더링하면 충분하고, SPA가 필요한 경우는 극히 일부임 RSC는 **복잡성과 보안 취약점**만 늘렸을 뿐임 - 동의함. 하지만 부트캠프나 VC 자금이 밀어주는 생태계가 이 방향을 계속 밀고 있음 Bun, Vercel 같은 프로젝트가 “모든 게 완벽히 돌아가는 JS 유토피아”라는 **환상**을 팔고 있어서 이 흐름이 쉽게 사라지지 않을 것 같음 - 예전에 Dan Abramov와 X에서 RSC에 대해 논쟁했었음 그는 혁신적인 기능이라 했지만, 나는 “**자기 발을 쏘는 총**”이라고 했음. 결국 현실이 그렇게 됨 - 개인적으로 RSC로 앱을 만들어봤는데 여전히 이 방식이 마음에 듦 다만 프로토콜 수준의 버그 가능성을 과소평가했음. 이번 취약점은 **직렬화 프로토콜**에 집중되어 있음 보안 커뮤니티가 이제야 깊이 들여다보는 중이라, 팀이 더 일찍 대응했으면 좋았을 것 같음 - 성공한 시스템은 결국 **과도한 확장**으로 괴물이 되기 쉬움 React도 단순 렌더링 라이브러리에서 **런타임**으로 변하면서 복잡도가 폭발했음 - 개인적으로 Dan의 접근이 그리 뛰어나다고 느끼지 않음 반면 **Vue와 Vite**는 훨씬 세련된 설계라고 생각함 → [Evan You 개인 사이트](https://evanyou.me) - 물론 대부분의 아이디어는 실패하기 마련이라, 비판만 하는 태도도 경계해야 함 가끔은 **대담한 시도**가 홈런이 되기도 함 - “당신이 더 뛰어난 걸지도 모른다”는 응원의 댓글도 있었음 - RSC는 프론트엔드가 **백엔드를 삼키려는 시도**라면, HTMX는 그 반대임 HTMX는 클라이언트–서버 경계를 유지해 백엔드 쪽은 안전하지만, 프론트엔드에선 XSS 위험이 있음 - 하지만 HTMX는 이미 **템플릿 엔진의 자동 이스케이프**로 XSS 문제를 해결했음 [관련 글](https://htmx.org/essays/web-security-basics-with-htmx/#always-use-an-auto-escaping-template-engine) - Next 팀이 새로운 보안 업데이트를 발표했음 → [NextJS Security Update 2025-12-11](https://nextjs.org/blog/security-update-2025-12-11) 14.x, 15.x, 16.x 버전에 영향을 미침