React2Shell(CVE-2025-55182)란? React Server Components 취약점 원인과 대응 방법 총정리

“JavaScript world”가 진짜로 shell-shocked… React2Shell 이야기

요즘 JavaScript world 쪽 소식 좀 본 사람이라면, 솔직히 한 번쯤은 “어… 이거 진짠가?” 싶었을 거예요. 갑자기 10.0 maximum pwnage급, 그러니까 사실상 “끝판왕” 수준의 critical vulnerability가 발견됐다는 얘기가 터졌거든요.
문제의 중심은 ReactJS framework—그중에서도 server components의 Flight protocol 코드 쪽입니다.

이게 왜 더 무섭냐면요. 흔히 보는 “누가 쓰는지 알 수도 없는 플러그인 하나”가 아니라는 점이에요. 이건 이미 millions of modern React apps에 깊게 섞여 있고, Next.js 같은 대형 framework들도 광범위하게 얹혀 있죠. (스크립트에서는 “Nex.js”라고 부르며 놀리듯 말하긴 했지만요.)
게다가 요 몇 년간 internet을 “쓸데없는 slop”로 도배해온 vibe engineers가 기본값처럼 Next.js를 고르는 흐름이 있었잖아요? 그런데 이제 그 slop이 “쓸모없기만 한” 수준을 넘어, 경우에 따라 extremely dangerous가 되어버렸다는 게 포인트예요.

 

2021의 Log4Shell이 떠오른다면… 2025에는 React2Shell

 

---

2021의 Log4Shell이 떠오른다면… 2025에는 React2Shell

혹시 Log4Shell 기억나요? 2021년에 log4java library(스크립트 표현 그대로예요) 쪽 exploit로 서버들이 대규모로 두들겨 맞고, 공격이 폭발적으로 번졌고, 거의 global economy를 흔들 뻔했다고까지 말이 나왔죠.

그런데 2025년에, 그 Log4Shell이 마치 “새 자매”를 데려온 것처럼 불리는 사건이 등장합니다. 별명이 React 2 shell, 줄여서 React2Shell. 그리고 공식 이름처럼 붙는 게 CVE-2025-55182예요.

스크립트가 강조하는 핵심은 이거예요:

• attacker가 HTTP request 하나 던지는 것만으로
• shell access까지 갈 수 있고
• logging in도 필요 없고
• “이상한 edge case”를 억지로 파고드는 것도 아니라며
• 어떤 경우엔 default configs에서도 통한다는 얘기까지 나옵니다.

그래서 영상에서는 “오늘은 React를 쓰지 말아야 할 최신 이유를 뜯어보고, 이 exploit이 실제로 어떻게 굴러가는지 보자”는 흐름으로 들어가요.
그리고 오프닝 멘트. “It is December 9th, 2025, and you’re watching the Code Report.”
(이런 거, 괜히 긴장감 올라오죠.)

 

 

 

---

React developer라면… “얼마나 screwed 됐는지”부터 체크하라고?

여기서부터 분위기가 한층 더 독해집니다. 영상에서는 React developer한테 거의 이렇게 말해요:
“자, 이제 너희가 지금 얼마나 screwed 됐는지 확인해보자.”

방법은 단순합니다. command를 한 번 돌려서, 특정 server components packages를 쓰고 있는지, 그리고 “문제 있는 versions”에 걸려 있는지 확인하라는 거죠.
(스크립트에는 정확한 목록이 다 적혀 있진 않지만, ‘이 패키지/버전대인지 확인해봐라’는 메시지가 핵심이에요.)

그리고 문제 버전이 뜨면… 갑자기 농담이 칼이 됩니다.

• “그 버전이 보이면, 올해 Hanukkah 선물은 네 아이들한테 못 줄 수도 있다”
• “왜냐면 너는 사실상 npm install로 malware를 깔아버린 거랑 비슷한 상태니까”
• “운 나쁘면 사이트 되찾으려고 어떤 중국 해커한테 bitcoin 한두 개는 뜯길 수도 있다”
• “근데 뭐… 그게 React developer로 사는 비용이지”

진짜 과장 섞인 조롱인데도, 듣는 사람 마음이 싸해지는 건 어쩔 수 없어요. 한 번 뚫리면 피해가 너무 크니까요.

 

 

 

---

“Flight protocol? 그게 뭔데요?” — React Flight를 shed로 설명하기

여기서 많은 사람이 속으로 이렇게 생각하죠.

“내 resume에 ReactDev Expert 써놨는데… 솔직히 Flight protocol은 처음 들어봄.”

영상도 그 포인트를 찌릅니다. 근데 설명 자체는 의외로 단순하게 풀어요.

React Flight는 한마디로, server components가 server에서 만든 결과를 client 쪽 browser로 전달하기 위한 “청사진/전달 방식” 같은 거예요.
server에서 일부 component를 만들고, 그걸 serialize해서 네트워크로 보내고, browser에서 최종적으로 render해서 웹사이트가 완성되는 흐름이죠.

여기서 갑자기 인생 썰이 튀어나옵니다.
스크립트 작성자(영상 진행자)가 “내가 17살 때 첫 직장이 Tough Shed였는데…” 하면서요.

• 공장에서 shed 부품을 미리 prefab하고
• 트럭에 싣고
• 설치 장소로 가져가서
• 현장에서 최종 조립한다

React도 비슷하다고 설명해요.
server에서 미리 만들고 → 네트워크로 보내고 → browser에서 완성.

비유가 꽤 촉감 있게 들어오죠. 트럭에 실린 부품이 덜컹덜컹 흔들리는 느낌까지 상상되는 타입의 설명.

 

 

 

---

그리고 항상 반복되는 그 실수: deserialize untrusted input…

문제는 “이론은 예쁘다”로 끝나지 않는다는 거예요.
영상은 여기서 확 꺾습니다.

React가 저질렀다는 실수는, 우리가 이미 수없이 봐온 바로 그 실수:

• deserialize untrusted input 해놓고
• 마치 친한 친구가 준 데이터처럼 믿어버리고
• 결과는 devastating remote code execution

공격자는 malicious flight payloads를 만들어서, server가 그걸 deserialize할 때 정상 코드 흐름에서는 절대 나올 리 없는 object graphs가 만들어지게 유도할 수 있다고 해요.
그렇게 생긴 비정상 object 구조를 발판으로:

• runtime environment를 교란하거나
• 위험한 APIs를 간접적으로 호출하게 만들거나
• 결국 server에서 arbitrary code를 실행하는 데까지 갈 수 있다는 설명입니다.

무서운 건 “세션이 있어야 한다” 같은 조건이 별로 없다는 식으로 말한다는 점이에요.
즉,

• authentication 없음
• valid session 없음
• 그냥 한 번, 딱 한 번
• React server components 처리하는 endpoint로 poison된 request를 던지면

그 서버가 순식간에 “엄청 비싼 cryptominer”로 변할 수도 있다는 거죠.

 

 

 

---

공개되자마자 바로 공격 트래픽? 이미 스캔 중이라는 말까지

여기서 스크립트는 ‘지금 당장’ 느낌을 강하게 밀어붙입니다.

• 공개(public disclosure)된 뒤 몇 시간 안에 여러 security company가 실제 attack traffic을 관측했다
• Amazon은 거의 즉시, Chinese hacking groups와 연관된 시도로 보이는 공격을 봤다
• vulnerable server가 2 million 넘게 있을 거라는 추정도 있다
• 지금 이 순간에도 해커들이 마구 스캔하고 exploit 시도 중이다

이 문장들은 한 줄 한 줄이 사람을 조급하게 만들죠.
그리고 결론은 당연히 이겁니다.

그러니까 update를 ASAP로 해라. 지금 당장.