▲

React 서버 컴포넌트의 DoS 및 소스 코드 노출 취약점 공개

 (react.dev)
3P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • 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.) — 서비스 거부 취약점 보고
▲
GN⁺ 2일전  [-]
Hacker News 의견들

  • React Server Components(RSC)는 항상 불편하게 느껴졌음
    자바스크립트 코드만 봐서는 클라이언트에서 실행되는 부분과 서버에서 실행되는 부분을 구분하기 어렵기 때문임
    게다가 이를 구현하려면 깊은 직렬화 RPC 메커니즘이 필요하고, 이는 개발자에게 불투명하며 보안 취약점의 위험을 높이는 지점이 됨

    • 예전 NextJS pages router 시절엔 서버와 클라이언트 코드의 경계가 명확해서 좋았음
      하지만 app router로 바꾸자 혼란스러웠음. 코드가 양쪽에서 실행될 수 있다 보니 Headers 같은 객체가 항상 존재하지 않아 무엇이 어디서 실행되는지 알기 어려웠음
    • 새로 합류한 팀에서 Next를 쓰는 걸 보고 “이거 어떻게 동작하는지 아는 사람 있나요?”라고 물었는데, 아무도 명확히 설명하지 못했음
      React+Next가 잘 작동할 땐 마법처럼 느껴지지만, 팀 단위로 일할 때는 예측 가능성이 점점 사라지는 게 문제라고 느낌
    • 그래서 나는 Inertia.js의 팬임. Inertia.js는 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 링크
    • 누군가는 이걸 인식 관리(perception management) 라고 표현함
      관련 위키 문서
    • 이 사안에는 커리어적 이해관계가 얽혀 있다고 보는 시각도 있음
    • 어떤 이는 “이건 Vercel 마케팅팀이 쓴 글처럼 보인다”고 말함

  • 15년 전 Opa에서 이미 비슷한 시도를 했었음
    클라이언트와 서버 코드를 자동으로 분리하고 JSX와 유사한 문법을 도입했음
    하지만 보안 분석을 강화하다 보니 컴파일러가 거대해졌고, 결국 단일 앱 개념보다는 명확한 분리의 중요성을 깨달았음
    언젠가 LLM이 이런 코드를 자동 생성할 수도 있겠지만, 지금은 단순한 구조가 낫다고 생각함

    • 실제로 RSC의 취약점은 코드 분할보다는 직렬화/역직렬화 과정의 동적 특성 때문임
      JS의 프로토타입 오염, 함수 toString, Promise 오버라이드 같은 문제를 막기 위한 패치가 진행 중임
      RSC는 import "server-only"나 import "client-only" 같은 정적 검증으로 환경을 구분하기 때문에 구조적으로는 안전한 접근임
    • 비슷한 아이디어로 Electric Clojure라는 프로젝트도 있음 → 링크
    • 참고로 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 개인 사이트
    • 물론 대부분의 아이디어는 실패하기 마련이라, 비판만 하는 태도도 경계해야 함
      가끔은 대담한 시도가 홈런이 되기도 함
    • “당신이 더 뛰어난 걸지도 모른다”는 응원의 댓글도 있었음

  • RSC는 프론트엔드가 백엔드를 삼키려는 시도라면, HTMX는 그 반대임
    HTMX는 클라이언트–서버 경계를 유지해 백엔드 쪽은 안전하지만, 프론트엔드에선 XSS 위험이 있음

    • 하지만 HTMX는 이미 템플릿 엔진의 자동 이스케이프로 XSS 문제를 해결했음
      관련 글

  • Next 팀이 새로운 보안 업데이트를 발표했음 → NextJS Security Update 2025-12-11
    14.x, 15.x, 16.x 버전에 영향을 미침

답변달기