Hacker News 의견

• 이번 취약점은 RSC/server actions 도입 때부터 경고받던 최악의 시나리오가 현실화된 사례임
  서버가 클라이언트의 신뢰할 수 없는 입력을 그대로 역직렬화해 모듈과 export 이름을 찾아 실행했음
  hasOwnProperty 패치로 막을 수는 있지만, 근본적으로 React가 RPC 레이어를 만든다는 사실을 명확히 인식하지 않았던 게 문제임
  gRPC나 SOAP 같은 전통적 RPC 프레임워크는 명시적 스키마와 서비스 정의로 경계를 분명히 하지만, React는 번들러가 볼 수 있는 모든 API를 노출하는 방식이라 위험함
  이런 설계로 인한 보안 문제는 앞으로도 반복될 가능성이 높음

  • 이건 단순히 부주의함의 문제로 보임
    명시적 스키마가 있더라도, 마지막 단계에서 신뢰할 수 없는 입력이 서버 네임스페이스의 아무 객체나 참조할 수 있게 두면 소용없음
  • 실제로는 클라이언트가 요청하는 모든 엔드포인트가 노출되는 게 아님
    "use server"로 표시된 함수만 노출되고, React 팀도 RPC 시스템을 설계하고 있다는 걸 인식하고 있음
    이런 버그는 다른 RPC 시스템에서도 충분히 발생할 수 있음 (React 기여자임)
  • 경고를 받았는데도 이런 일이 생겼다는 건 결국 부주의한 구현으로밖에 볼 수 없음
  • 일반 사용자 입장에서는 이 접근법을 쓰지 않으면 안전한 건지 궁금함
    하지만 오래된 비공개 레포를 유지하는 것도 좋은 선택은 아님

• Next는 정적 빌드가 유일한 장점임
  그 지원이 중단되면 더 이상 사용할 이유가 없음

• Facebook/Meta의 보안 권고문에 따르면, React Server Components 19.0.0~19.2.0 버전에 인증 전 원격 코드 실행(RCE) 취약점이 존재함
  React 공식 블로그 공지에서도, 클라이언트가 서버 함수를 호출할 수 있는 구조 때문에 공격자가 악의적인 HTTP 요청을 만들어 서버에서 임의 코드를 실행할 수 있다고 설명함

  • 수정 내용이 hasOwnProperty 검사 추가라면, 공격은 아마도 프로토타입 체인의 속성(__proto__ 등)을 참조하는 방식이었을 것 같음
  • “클라이언트가 서버 함수를 호출할 수 있다”는 문장이 의도된 기능이라면 꽤 무서운 설계로 느껴짐

• 수정 커밋은 이 커밋으로 보임
  여러 변경과 함께 스쿼시되어 세부 내용이 가려진 듯함
  코드에서 노출되는 함수 목록을 화이트리스트 방식으로 제한하는 패턴이 4곳에서 보임

  • 혹은 이 커밋이 원인일 수도 있음 (“중대한 보안 취약점 수정” 명시)

• Vercel은 이미 플랫폼 수준 보호로 악성 요청 패턴을 차단하고 있음
  공지 참고
  Cloudflare도 WAF 규칙으로 선제 대응함

  • 여러 파트너사와 협력해 사전 완화 조치를 배포했음
    그래도 Next, React, 기타 메타 프레임워크 의존성을 즉시 업데이트할 것을 강력히 권장함
  • Netlify의 대응 공지와
    Deno Deploy/Subhosting의 블로그 글도 참고할 만함
  • 나는 직접 패치하고 재빌드했으며, 혹시 모를 누락에 대비해 Crowdsec WAF 규칙도 추가했음

• PoC 저장소를 참고해 취약점을 재현해봤음

  • 패치된 react-server-dom-webpack으로도 RCE가 실행돼서, 메커니즘이 완전히 맞지는 않은 듯함
    실제 Next.js 프로젝트에서 데모를 보여주면 좋겠음
  • 그래도 정리해준 글이 정말 인상적이었음

• “Vercel 없이 RCE는 없다”는 말이 나올 정도로 이번 사건은 호스팅 환경과 보안의 상관관계를 드러냄

• CVE 점수 10.0은 이렇게 널리 쓰이는 프로젝트에선 충격적인 수치임

  • 영향을 받은 패키지 react-server-dom-webpack은 “실험적이며 위험을 감수하라”고 명시돼 있음
    그런데도 주간 다운로드가 31만 건이 넘음
  • 이런 사건에서는 CVSS 10.0을 명확히 표기해야 PR성 발언으로 덮이지 않음
  • React는 널리 쓰이지만, React Server Components는 아직 그렇게 보편적이지 않음

• React 팀이 왜 이렇게 혼란스러운 기능에 시간을 쓰는지 이해하기 어려움
  SSR보다 나은 점이 뭔지, 성능 향상이 얼마나 되는지도 의문임
  Hook 도입 이후 개발자 경험이 나빠졌는데, 그걸 개선하기보다는 또 다른 복잡성을 추가함
  차라리 JS 본연의 제어 흐름을 컴포넌트 로직에서 자연스럽게 쓸 수 있게 해줬으면 함

  • Server Components는 SSR과 직접 관련이 없음
    나는 이를 컴포넌트화된 BFF(Backend for Frontend) 계층으로 봄
    각 UI 조각이 대응되는 백엔드 로직과 직접 연결되어, fetch 호출 없이 데이터를 가져올 수 있음
    이렇게 하면 프론트와 백엔드가 함께 진화하기 쉬워지고, 필요한 데이터만 세밀하게 로드할 수 있음
    결국 UI 전용 서버 로직을 컴포넌트 구조 안에 자연스럽게 녹여낼 수 있음
  • React가 “기본 프레임워크”가 된 게 아쉬움
    Svelte나 React의 컴파일러 기반 모델이 훨씬 다루기 편함
  • 근본적으로는 JS 언어의 한계와 경쟁 부재가 문제라고 생각함
    Vue, Svelte, Angular 등은 모두 별도 컴파일러와 파일 확장이 필요함
    반면 React/JSX는 전처리기 단계에서 이미 특혜를 받음
    Rust는 매크로 시스템으로 이런 문제를 해결했음 — 예를 들어 Leptos나 Yew는 표준 .rs 파일 안에서 JSX나 HTML 템플릿을 지원함
    JS가 이런 확장성을 갖추지 못하면, 웹은 앞으로도 복잡하고 비효율적인 환경에 머물 가능성이 큼
  • 나는 hooks를 좋아함 :)
  • RSC는 SSR을 빠르게 만들지 못한 결과로 나온 대체 시도임
    클라이언트 측 부하를 줄이려 했지만, 그마저도 실패한 느낌임

• React 블로그의 상세 설명도 참고할 만함