Security

1300만 사이트에 영향 주는 취약점, 중국 해커들이 공략 중

문가용 기자

Published: 16:41, 05 Dec 2025 (Updated: 13:58, 07 Dec 2025)

💡

Editor’s Pick
- 전 세계적으로 널리 사용되는 인터페이스 관련 라이브러리, 리액트
- 12월 3일 발견된 10점짜리 취약점, 중국 해커들이 노려
- 아무도 모르는 PoC까지 활용…중국 해커들의 연대, 장기적 위협

중국의 해커들이 최근에 공개된 취약점을 빠르게 공략하기 시작했다. 문제의 취약점은 CVE-2025-55182로, 리액투셸(React2Shell)이라는 이름이 붙어 있다. 어스라미아(Earth Lamia)와 잭팟판다(Jackpot Panda) 등 여러 중국 해킹 단체들이 익스플로잇 하는 중이라고 아마존의 위협 첩보 팀에서 경고했다. 아직 피해 현황은 정확히 집계되지 않았다.

리액투셸 취약점

리액투셸 취약점은 2025년 12월 3일 처음 공개됐다. 리액트(React)라는 오픈소스 라이브러리에서 발견된, CVSS 기준 10점 만점 취약점이다. 리액트 19.x와 넥스트(Next.js) 15.x 및 16.x 버전에 영향을 미친다. 즉 리액트와 넥스트 기반 애플리케이션을 클라우드 생태계에서 운영하는 경우 이번 취약점을 통한 공격에 피해를 입을 수 있다는 것이다. 이에 대형 클라우드 기업인 AWS 측에서도 이러한 사실을 고객들에 전파하는 중이라고 한다. AWS에는 문제가 없으나, AWS 고객 중 리액트와 넥스트를 사용하는 기업들이 적지 않아서이다.

💡

여기서 잠깐!
리액트는 사용자 인터페이스를 유연하고 용이하게 만드는 데 사용되는 오픈소스 라이브러리이다. 이런 리액트를 보다 빠르고 쉽게 사용할 수 있게 개량된 것이 넥스트다. 리액트를 활용할 때 수동으로 해야 하는 작업들을 자동으로 간편하게 해주는 게 넥스트라고 볼 수 있다. 넷플릭스, 트위치, 틱톡, 노션, 우버, 나이키 등 대규모 서비스에서도 넥스트는 널리 적용되어 있다. 따라서 이번 취약점의 파급력은 꽤나 큰 편이다.

AWS의 설명에 의하면 리액투셸은 11월 29일 처음 발견됐다고 한다. “일종의 역직렬화 취약점입니다. 이런 취약점을 익스플로잇 하는 데 성공하면 원격 코드 실행과 인증 우회, 권한 상승 등의 공격을 할 수 있게 되고, 그 결과 피해자는 데이터 탈취나 서비스 마비 등의 피해를 입게 됩니다. 공격자가 피해자의 네트워크 내에서 횡적으로 이동할 수도 있게 됩니다.”

중국의 공격자들

리액투셸 취약점이 공개되고서 몇 시간 지나지 않아 익스플로잇 시도가 급증했다고 AWS는 경고한다. “저희가 설치한 허니팟을 통해 관찰한 결과 중국을 근거지로 두고 활동하는 그룹들이 유독 열심히 익스플로잇 하고 있다는 걸 알 수 있었습니다. 어스라미아나 잭팟판다 등이 오랜 시간 사용해 온 공격 인프라들도 연루돼 있었습니다. 다만 이들은 자신들의 공격 인프라를 다른 공격자들에게도 대여해주기 때문에 이번 공격을 어스루미아나 잭팟판다가 주도하고 있다고 결론을 내리기는 힘듭니다.”

참고로 어스라미아는 이전부터 남아메리카와 중동, 동남아시아 국가들을 공격해 왔던 그룹이다. 웹 애플리케이션 취약점을 익스플로잇 하는 게 주요 수법이었다. 금융과 물류, IT 산업과 대학 및 정부 기관들이 주요 표적이다. 잭팟판다는 동아시아와 동남아시아의 정부 기관들을 주로 공략해 오던 그룹이다. 만약 이번 익스플로잇 시도의 배후에 이 두 그룹이 있다면 해당 지역 기업과 기관들은 유의해야 한다는 의미가 된다.

현재 공격자들은 리액투셸을 공략하기 위해 자동 스캐닝 도구를 동원하고 있다고 AWS는 설명한다. 즉, 취약점이 패치되지 않은 구간을 다량 찾아내기 위해 공격자들이 마음을 단단히 먹었다는 의미다. 심지어 이런 스캔 행위가 발각되지 않기 위한 탐지 회피 기능도 스캔 도구에 탑재돼 있는 것으로 확인됐다고 한다. “물론 이런 대대적인 무기들을 가지고 딱 하나의 취약점만 파고들진 않겠죠. 그러면 효율이 떨어지니까요. 실제 공격자들은 리액투셸 외에도 다른 취약점들도 같이 색출하고 있습니다. CVE-2025-1338도 그런 취약점 중 하나입니다.”

공격자들만 아는 PoC?

이번 AWS의 보고서에서 눈에 띄는 건 PoC에 대한 언급이다. 공격자들이 자동 스캐닝 도구에 더해 PoC까지도 활용하고 있다는 내용이다. PoC는 특정 취약점을 공략하는 게 가능하다는 걸 증명하기 위해 만들어진 일종의 ‘해킹 코드’다. 다만 진짜 해킹 공격이 아니라 공격 가능성의 증명을 목적으로 하는 것이기 때문에 그 자체로 ‘살상력’은 없다. 진짜 무기로서 작동하기 위해 꼭 필요한 부분은 빠진 채 공개된다. 하지만 공격자들은 이를 가져가 빠진 것만 채워넣는 방식으로 실제 무기를 완성시킨다.

PoC의 이러한 특성 때문에 보안 전문가들은 특정 취약점의 공략법을 알아냈다 하더라도 PoC를 함부로 만들어 공개하지 않는다. 패치가 개발되고서 충분한 시일이 흘러 많은 사용자들이 적용한 이후 시점에야 공개를 고려한다(물론 다 그러는 건 아니다). 보안 전문가로서의 입지를 높이기 위해 ‘결정적 요소가 빠져 있다’는 PoC의 고유 특성을 악용, 허위 PoC를 공개하는 경우도 존재한다.

이번 리액투셸 취약점에 대한 PoC는 아직 그 누구도 개발했다고 자랑하거나 공개하지 않은 상황이다. 허위 PoC조차 아직은 등장하지 않고 있다. 그럼에도 AWS는 공격자들이 PoC를 이용하고 있다고 한다. 이 상충되는 두 가지 사실은 무엇을 의미할까?

하나는, 공격자들이 보유한 PoC가 비공개 PoC일 수 있다는 것이다(PoC는 대부분 전체 공개용으로 만들어진다). 즉, 누군가 리액투셸의 익스플로잇 방법을 알아내고서 대강의 코드까지 완성했지만 보안 업계 전체의 확인은 받지 못한 걸 공격자들이 자신들만의 경로로 확보한 것이다. 그 ‘누군가’는 공격자들의 은밀한 조력자일 수도 있고, 공격자와 전혀 상관 없는 피해자일 수도 있다. 리액투셸 취약점을 미리 알고 있었거나 리액트와 넥스트라는 요소들에 대한 이해도가 높은 자가 관여돼 있음을 어렵지 않게 짐작할 수 있다.

그 다음은 중국 해킹 조직들 간 협력 체계가 생각보다 견고하다는 것이다. 중국 해킹 조직들이 서로의 인프라와 도구, 공격을 위한 첩보까지 공유한다는 건 수년 전부터 의심돼 왔던 것이다. 하지만 공식적으로 확인된 바는 없다. 그런 가운데 공개도 되지 않은 PoC를, 하필 중국 해커의 인프라를 공유하는 자들끼리만 알고서 활용한다는 건, 이러한 중국 해킹 단체들 간 연대감을 증명한다. 이런 연대는 서로의 강점을 빠르게 전파하여 결국 모두의 상향평준화를 이루는 데 큰 도움이 되기에 장기적으로 좋지 않은 소식이다.

또 하나 생각해볼 수 있는 건 PoC가 공개되는 속도가 대단히 빠르다는 것이다. 리액투셸이 공개된 건 12월 3일이고, PoC까지 동원한 공격이 급증한다는 보고서가 정리돼 나온 것은 불과 12월 4일의 일이다. 단 몇 시간 만에 익스플로잇의 개념이 어느 정도 틀을 갖춘 채 나타났다는 것은 방어하는 입장에서는 경악스러운 일이다. 이는 PoC를 개발하기 위해 애쓰는 게 비단 공격자들만이 아니기 때문이다. 보안 연구자들 역시 PoC를 만들려 한다. 이런 ‘의도치 않은’ 공동의 노력이 PoC 등장 속도를 증가시키는 데 기여한다.

어떤 대책 필요한가?

이 사실을 먼저 알린 AWS는 “이미 여러 계층의 보호 장치를 배포해 AWS 사용자들을 보호하고 있다”고 밝혔다. “악성 스캔을 미리 탐지해 차단하도록 했습니다. AWS의 웹 애플리케이션 방화벽의 규칙도 새롭게 설정해 이번 사태를 대비했습니다. 허니팟을 통해서 관련 첩보를 꾸준히 수집하고 있기도 하며, 아마존 위협 첩보 팀이 직접 유사 사태를 추적하고 있기도 합니다.”

그러나 이런 움직임은 불완전할 수밖에 없다고 AWS는 강조한다. “저희가 마련한 보호책은 AWS 고객들만을 위한 것입니다. EC2나 컨테이너 등 자체 환경에서 리액트나 넥스트를 운영하고 있다면 이러한 보호를 받을 수 없게 됩니다. 게다가 AWS 고객이라 하더라도 저희의 보호 장치만으로는 완벽히 안전하다고 할 수 없습니다. 결국 패치를 대체할 수는 없거든요.”

AWS는 다음과 같은 내용을 권장하고 있다.
1) 리액트와 넥스트 기반 애플리케이션을 최신화 한다.
2) 애플리케이션 및 웹 서버 로그를 확인해 의심스러운 활동이 있었는지 파악하라.
3) 특히 next-action이나 rsc-action-id 헤더가 포함된 POST 요청이 있는지 살피는 게 중요하다.
4) 애플리케이션 서버에서 예상치 못한 프로세스가 실행되거나 파일 변경 이력이 있는지 확인하라.
5) 애플리케이션이 손상된 것으로 의심될 경우 AWS 고객이라면 고객 지원 센터에 연락해 사건 대응을 요청하라.

by 문가용 기자(anotherphase@thetechedge.ai)