제2의 Log4j 사태, React2Shell 취약점

최근 React2Shell 취약점이 공개되면서, 2021년 전 세계를 뒤흔들었던 Log4j(Log4Shell) 사태가 다시 주목받고 있습니다. 두 사건 모두 ‘로그인 없이 단 한 번의 요청만으로 서버를 장악할 수 있다’는 공통점을 가지고 있어 개발자와 보안 담당자들에게 큰 경각심을 주고 있습니다. React2Shell 취약점

 

React2Shell(CVE-2025-55182)이란?

React2Shell은 CVE-2025-55182로 분류된 원격 코드 실행(RCE) 취약점으로, React Server Components에서 사용하는 Flight라는 통신 방식의 설계 문제에서 출발합니다. 쉽게 말해, 서버와 브라우저가 주고받는 데이터의 형식에 보안 구멍이 있어서 공격자가 이 형식을 교묘하게 조작하면 서버가 해서는 안 될 명령까지 그대로 실행해 버리는 문제입니다.

이 취약점이 특히 위험한 이유는 로그인이나 인증이 필요 없다는 점입니다. 일반 사용자가 웹 페이지에 접속하듯이 공격자도 단순한 HTTP 요청 한 번으로 공격을 시도할 수 있습니다. 또한 특별한 커스터마이징 없이도 기본 설정만으로도 취약한 환경이 만들어질 수 있다는 점도 큰 문제입니다. React Server Components를 사용하는 React, Next.js, 그리고 일부 관련 프레임워크들이 한꺼번에 영향을 받기 때문에 웹 생태계 안에서의 파급력이 상당히 큰 취약점으로 평가되고 있습니다.

실제로 여러 글로벌 보안 벤더는 이 취약점을 CVSS(취약점의 공격 난이도와 피해 범위를 수치화한 국제 표준 점수 체계) 10.0, 즉 최고 등급의 치명적 취약점으로 분류하고 긴급 패치를 권고하고 있으며, 중국 연계 해킹 조직을 포함한 다양한 공격 그룹들이 공개 직후부터 대규모 스캔과 악용 시도를 진행하고 있다는 보고도 나와 있습니다.

React2Shell 취약점

 

React2Shell이 ‘제2의 Log4j’로 불리는 이유: 원격코드 실행(RCE) 공격과 광범위한 영향도

Log4j는 Java 진영에서 널리 사용되던 로깅 라이브러리인 Log4j에 발견된 원격 코드 실행 취약점으로, 역사상 가장 심각한 취약점 중 하나로 평가받습니다. 당시에는 서버 로그에 특정한 문자열 한 줄만 남겨도 서버가 공격자가 준비해 둔 코드를 내려 받아 실행해 버리는 바람에 전 세계 수많은 시스템이 동시에 위험에 노출되었습니다.

React2Shell이 Log4j와 비슷하다고 불리는 가장 큰 이유는 두 취약점 모두 원격 코드 실행(RCE, Remote Code Execution)을 가능하게 하고 인증 없이 공격이 가능하며 한 번 뚫리면 서버 장악, 랜섬웨어 설치, 데이터 탈취 등으로 이어질 수 있다는 공통점을 가지고 있기 때문입니다. 다만 Log4j는 당시 거의 모든 Java 기반 시스템에 들어가 있다시피 한 라이브러리였기 때문에 규모와 파급력 면에서 정말 전 지구적인 위협이었습니다.

React2Shell은 그보다는 React Server Components를 사용하는 웹 애플리케이션에 집중된 이슈라 영향 범위가 완전히 동일하다고 보기는 어렵습니다. 그래서 보안 업계에서는 ‘전체 IT 생태계 수준으로 보면 Log4j만큼은 아니지만, 현대 웹 생태계 안에서는 Log4j급 충격’이라는 식의 평가도 나옵니다. 국내외 언론에서도 ‘2021년 Log4j 악몽 재현’, ‘제2의 Log4j 사태를 막자’와 같은 표현을 사용하며 경각심을 환기시키고 있습니다.

 

React2Shell 취약점, 실제 공격은 어떻게 이뤄질까

React Server Components를 사용하면 서버에서 컴포넌트를 렌더링하고 그 결과를 Flight라는 형식으로 브라우저에 전달합니다. 이 Flight 데이터는 ‘화면을 이렇게 그려라’라는 지시와 관련 데이터들이 섞여 있는 일종의 설계도라고 이해하면 됩니다. 문제는 서버가 이 Flight 데이터를 처리하는 과정에서 ‘이건 정상적인 데이터일 것이다’라고 지나치게 신뢰하고 안전성 검증을 충분히 하지 않은 채 코드 실행과 이어질 수 있는 부분까지 열어두었다는 점입니다.

공격자는 이 포맷을 분석해 정확히 이해한 뒤, 데이터처럼 보이지만 실제로는 서버에 특정 명령을 실행시키는 트로이 목마 같은 내용을 심어 보낼 수 있습니다. 서버는 이를 단순한 응답 데이터로 착각하고 처리하다가 결과적으로 공격자가 원하는 코드를 실행하게 됩니다. 그 결과 서버에 백도어가 설치되거나 데이터베이스에서 민감한 정보가 유출되고 랜섬웨어나 암호화폐 채굴 프로그램이 깔리며 내부망으로의 추가 침투까지 이어질 수 있습니다. Log4j 사태 때 단순한 로그 한 줄이 원격 코드 실행의 통로가 되었던 것처럼 React2Shell 역시 ‘서버와 브라우저 간 통신 형식’이 새로운 공격 경로로 악용된 사례라고 볼 수 있습니다.

 

 

React2Shell 취약점에 대한 각국과 기업의 대응 방안

React2Shell이 공개된 직후, 여러 국가의 보안 기관과 글로벌 클라우드 및 보안 기업들은 빠르게 경보를 발령하고 대응책을 내놓기 시작했습니다. React와 Next.js를 개발·관리하는 쪽에서는 취약점을 수정한 버전을 배포하고 어떤 버전이 영향을 받는지, 어떻게 업데이트해야 하는지에 대한 상세 가이드를 공개했습니다.

국가 차원에서는 각국의 CERT(Computer Emergency Response Team, 침해사고 대응팀)와 대학, 공공기관 보안팀 등이 긴급 보안 공지 형식으로 React2Shell 관련 알림을 발행하고 최고 우선순위에 준하는 패치 적용을 권고하고 있습니다. 클라우드와 보안 벤더들도 대응에 적극적입니다. AWS, Google Cloud, Microsoft 등은 자사 보안 블로그에서 React2Shell 탐지 및 차단 규칙, 로그 분석 방법, 공격 징후를 소개하며 고객이 빠르게 대응할 수 있도록 정보를 제공하고 있습니다.

물론 실제 조직 차원에서는 무엇을 해야 할지가 가장 중요합니다. Log4j 사태 당시 가장 큰 교훈 중 하나는 ‘우리 시스템 어디에 Log4j가 쓰이고 있는지 아무도 정확히 알고 있지 못했다’는 점이었습니다. React2Shell 대응에서도 똑같은 실수를 반복하지 않기 위해, 먼저 우리 서비스가 영향을 받는지부터 파악하는 것이 필요합니다. 회사에서 운영 중인 웹 서비스 중 React나 Next.js를 사용하는 시스템이 무엇인지 목록을 만들고 특히 서버 렌더링과 React Server Components를 사용하는 프로젝트가 있는지 개발팀과 함께 확인해야 합니다. 그 다음 단계는 최신 버전으로의 업데이트입니다. React와 Next.js 공식 공지에서 안내한 ‘취약점이 해결된 버전’으로 가능한 빨리 업데이트를 진행해야 하며, 규모가 큰 서비스라면 스테이징 환경에서 먼저 업데이트 후 기능 테스트를 거쳐 운영 환경에 반영하는 것이 안전합니다.​​

 

Log4j 이후 많은 기업이 소프트웨어 공급망 전반을 이해하고 우리 시스템에 어떤 라이브러리와 프레임워크가 어디에 쓰이는지 파악하는 능력이 얼마나 중요한지 깨달았습니다. React2Shell 역시 특정 프레임워크와 기능에 국한된 이슈처럼 보일 수 있지만 그 본질은 우리가 의존하고 있는 기술 스택의 내부 동작과 보안 위험을 얼마나 잘 이해하고 있느냐는 질문을 다시 던지는 사건입니다.

이번 React2Shell 이슈를 단순히 ‘React 쪽에서 또 취약점이 나왔다더라’ 정도로 넘기기보다는 우리 조직의 기술 자산을 얼마나 투명하게 관리하고 있는지, 취약점 공지 이후 실제 패치까지 소요되는 시간이 어느 정도인지, 개발과 보안이 얼마나 긴밀하게 협업하고 있는지를 점검하는 기회로 삼는 것이 필요합니다. Log4j의 악몽을 되풀이하지 않기 위해서는 React2Shell 같은 최신 취약점에 빠르게 대응하는 것과 더불어 평소에도 보안 패치 문화와 자산 관리 체계를 꾸준히 다지는 것이 가장 확실한 방어 전략입니다.