2025 하반기 Hot🔥보안 사건 사고

들어가며

다사다난했던 2025년이 저물어 가고 있습니다. 올해는 유독 많은 보안 사건과 사고가 발생하며 지속적으로 보안이 이슈가 된 한 해였습니다. 상반기에 이어 하반기에도 대형 보안 사고가 다수 발생하였고, 언론을 통해 관련 소식이 연일 보도되며 보안 업계 종사자가 아니더라도 보안 침해 사고를 자연스럽게 인식하게 되었습니다. 현장에서도 다수의 고객사와 소통하며 보안에 대한 경각심과 주목도가 높아진 것을 체감할 수 있었습니다. 이번 포스트에서는 티오리 Frontier Squad 팀의 연구원들이 선정한 보안 사건/사고를 통해 2025년의 하반기를 돌아보겠습니다.

상반기의 주요 보안 사건/사고에 대한 내용은 2025 상반기 보안 사건 사고에서 확인하실 수 있습니다.

1. Phrack Report: “APT Down – The North Korea Files”

2025년 8월 8일, 국제 해커 매거진 Phrack 72호에 APT Down – The North Korea Files라는 제목의 기술 보고서가 공개되었습니다. ‘Saber’, ‘cyb0rg’라는 활동명을 사용하는 해커가 게재한 해당 보고서는 대한민국의 공공·민간 영역을 대상으로 한 공격 활동을 다루고 있어, 공개 직후 국내 보안 업계에 큰 파장을 일으켰습니다.

미국 비영리 단체 DDoSecrets은 해당 보고서와 함께 약 8.9GB 분량의 관련 데이터를 다운로드 가능한 형태로 공개하였습니다. 해당 데이터에는 대한민국 정부 전자문서시스템 및 통신사 인프라와 연관된 것으로 보이는 자료가 포함되어 있었고, 이는 대한민국의 공공 시스템에 대한 장기간의 무단 접근 및 자료 열람 공격이 발생했다는 추측을 가능하게 하였습니다.

해당 정황은 정부의 발표에 따라 사실로 확인되었습니다. 국가정보원은 2025년 10월 17일 공개 발표를 통해, 외부 해커가 6개의 인증서와 6개의 국내외 IP를 이용해 범정부 업무시스템인 온나라시스템에 접속했다고 밝혔습니다. 또한, 해커들이 2022년 9월부터 2025년 7월까지 정부 원격접속시스템(G-VPN)을 통과하여 온나라시스템에서 자료를 열람한 사실을 확인하였다고 덧붙였습니다.

보다 구체적인 피해 범위는 행정안전부의 브리핑과 보도를 통해 알려졌습니다. 행정안전부에 따르면 650명분의 공무원 인증서 파일 유출이 확인되었고, 이 중 12건은 GPKI 키와 비밀번호가 함께 포함된 사례였습니다. 다만, 대부분은 이미 유효기간이 만료된 인증서였고, 유효기간이 만료되지 않은 3명의 인증서에 대해서도 2025년 8월 13일 폐기 조치가 이루어졌다고 설명했습니다.

국가정보원은 사건 설명 과정에서 원격접속 인증 체계의 미흡, 온나라시스템의 인증 로직 노출 가능성, 일부 부처 전용 서버에 대한 접근통제 미비 등 구조적 취약점을 언급하며 재발 방지의 필요성을 강조하였습니다. 특히 G-VPN을 통한 원격접속 이후 온나라시스템 접근 과정에서 추가적인 인증·행위 검증이 충분히 이루어지지 않았다는 점은, 장기간에 걸친 자료 열람이 가능했던 배경으로 분석되었습니다.

기술적 관점에서 본 이번 사건의 핵심 요소는 아래와 같이 정리할 수 있습니다.

• 공무원 인증서(GPKI) 유출 및 재사용 가능성

• G-VPN을 경유한 원격접속 환경에서의 인증 단계 단순화

• 온나라시스템 인증 로직 및 접근 제어 구조의 노출

• 장기간(약 3년)에 걸친 비인가 자료 열람 탐지 실패

사건 인지 이후 대응 과정에서 비교적 신속한 기술적 조치가 병행되었다는 점은 긍정적인 측면입니다. 행정안전부는 2025년 7월 28일 온나라시스템 로그인 정보 재사용 차단 조치를 중앙부처 및 지방자치단체에 적용하였고, 8월 4일부터는 G-VPN 접속 시 GPKI 인증에 더해 전화 기반 2차 인증(ARS)을 의무화하였습니다. 또한, 국가정보원은 악용된 IP 정보를 전 국가·공공기관에 전파하여 차단 조치를 적용하였으며, 일부 부처의 전용 시스템 공격 여부도 추가로 확인하여 조사 중이라고 밝혔습니다.

한편, 이와 같은 조치가 이루어지기까지의 시간적 경과에 대해서는 다양한 목소리가 존재합니다. 국가정보원은 보고서 공개 이전인 7월에 관련 제보를 받고 분석을 진행하였으나, 사건에 대한 공식 발표는 Phrack 보고서 공개 이후 약 두 달이 지난 시점에 이루어졌습니다. 해당 대응은 공공 부문 보안 사고 대응 절차와 정보 공개 시점에 대한 논의를 낳았으며, 이 과정에서 민간 기업에 적용되는 침해사고 24시간 내 보고 원칙과의 비교가 언급되기도 했습니다.

이번 사건은 공무원 행정업무 전반을 처리하는 핵심 업무시스템으로 알려진 온나라시스템에 대한 장기간(2022년 9월~2025년 7월)의 무단 접근 및 자료 열람이 공식적으로 확인된 사례로, 공무원의 일상적인 행정 업무를 처리하는 시스템이 공격 표면이 될 수 있음을 명확히 보여주고 있습니다. 또한, 이번 사건은 인증서 기반 접근 구조와 원격근무 인프라가 일상화된 환경에서 발생할 수 있는 위험을 보여주는 사례로서, 핵심 시스템에 대한 접근 통제와 인증 설계를 보다 높은 수준으로 관리해야 한다는 메시지를 남깁니다.

References

• https://zdnet.co.kr/view/?no=20250810150952

• https://www.nis.go.kr/CM/1_4/view.do?seq=376

• https://www.newsis.com/view/NISX20251017_0003366916

• https://v.daum.net/v/20251017123617412

• https://www.news1.kr/it-science/security-hacking/5922223

• https://www.korea.kr/briefing/policyBriefingView.do?newsId=156721907

• https://www.boannews.com/media/view.asp?idx=140890

2. NPM Supply Chain Attack

Javascript와 Node.js 생태계의 중심인 npm(Node Package Manager) 레지스트리는 2025년 기준 수백만 개의 패키지를 보유하고 있으며, 주간 다운로드 수가 수십억 건에 달하는 세계 최대의 소프트웨어 저장소로 자리 잡고 있습니다. 하지만 이러한 방대한 연결성은 역설적으로 공격자에게 큰 규모의 공격 표면을 제공하고 있습니다. 2025년 9월은 npm에서 심각도 높은 공급망 보안 사고들이 발생한 시기입니다. 이 시기 발생한 일련의 사건들은 오픈 소스 생태계의 암묵적 신뢰(Implicit Trust) 모델의 취약성을 여실히 보여줍니다.

npm 패키지 연쇄 침해

2025년 9월 8일, 전 세계적으로 널리 사용되는 다양한 npm 패키지에 악성 코드가 주입되는 사건이 발생했습니다. 해당 사건은 기술적 취약점이나 정교한 APT 공격이 아닌, 패키지 메인테이너를 노린 피싱 공격에 의해 발생했다는 특징을 가집니다.

qix라는 ID를 사용하는 메인테이너는 npm 지원팀(support@npmjs.help)을 사칭한 이메일을 수신했습니다. 해당 이메일은 메인테이너의 2단계 인증(2FA) 자격 증명을 업데이트해야 한다는 명목으로 가짜 로그인 페이지 접속을 유도했습니다. 공격자는 이와 같은 전형적인 중간자 공격(AiTM, Adversary-in-the-Middle) 기법을 통해, 실시간으로 메인테이너가 입력한 ID, 비밀번호, OTP(One-Time Password) 코드를 가로채어 실제 npm 세션을 탈취하는 데 성공했습니다.

공격자는 탈취한 세션을 통해 18개의 핵심 패키지에 대한 쓰기 권한을 획득했습니다. 이들은 npm 생태계의 기초적인 역할을 하는 라이브러리로, 직접적으로 사용될 뿐 아니라 수만 개의 다른 프로젝트에서 의존성으로 사용하고 있어 막대한 연쇄적 파급 효과를 낳았습니다.

해당 패키지들의 주간 다운로드 수 합계는 약 26억건에 달했으며, 이는 npm 생태계 전체 트래픽의 상당 부분을 차지합니다. 결과적으로 공격자는 이와 같이 널리 사용되는 패키지를 감염시킴으로써, 별도의 해킹 과정 없이도 손쉽게 전 세계 수백만 대의 개발자 PC, CI/CD 서버, 이용자의 브라우저 환경에 악성 코드를 주입할 수 있었습니다.

패키지 악성 코드 분석

이번 공격의 기술적 특징 중 가장 주목할 부분은 악성 코드의 동작 환경과 목표입니다. 서버 측 셸 권한을 획득하거나 랜섬웨어를 배포하는 전통적인 공격 방식과 달리, 이번 공격에서는 브라우저 환경에서 실행되며 암호화폐 지갑을 탈취하도록 설계된 Crypto Wallet Drainer 페이로드가 사용되었습니다.

해당 악성 코드는 난독화된 Javascript 형태로 배포되었으며, 웹 애플리케이션의 번들에 포함된 상태로 전달되어 최종 이용자의 브라우저에서 실행될 때 활성화되도록 설계되었습니다.

1. 네트워크 API 후킹: 브라우저의 API 중 하나인 window.fetch와 XMLHttpRequest.prototype.send를 오버라이딩하여, 발생하는 모든 비동기 웹 요청을 가로채고 감시할 수 있는 권한을 확보합니다.

2. 트랜잭션 데이터 스캔: 이용자가 암호화폐 지갑(예: Metamask, Coinbase Wallet)을 이용해 트랜잭션을 시도할 때, 악성 코드는 해당 트랜잭션의 본문(Payload)를 검사합니다. 이때, 이더리움이나 비트코인과 같은 주요 블록체인의 주소 패턴과 일치하는 문자열을 확인합니다.

3. 정규표현식과 패턴 매칭: 다양한 암호화폐 주소 탐색을 위해 정교한 정규표현식을 사용합니다. 또한, 단순한 주소 탐색 외에도 rpc, api, wallet 등의 키워드가 포함된 요청을 타겟팅하여 탐지 확률을 낮췄습니다.

해당 악성 코드는 매우 교모한 방식으로 트랜잭션 목적지 주소를 변조했습니다. 목적지 주소를 단순히 공격자의 주소로 설정할 경우, 이용자는 육안으로 해당 변화를 인지할 수 있을 것입니다. 이번 공격에서는 이를 회피하기 위해, 사전에 대량의 공격자 지갑 주소를 생성하고 해당 주소의 풀(Pool)에서 Levenshtein 거리(편집 거리) 알고리즘을 사용하여 문자열 간 차이가 최소화되는 주소를 탐색했습니다. 이를 통해 피해자의 기존 목적지 주소와 시각적으로 가장 유사한 주소를 실시간으로 선택함으로써, 이용자가 트랜잭션 승인 창에서 유사한 공격자의 주소를 확인하고 정상적인 거래로 오인하여 서명을 진행하도록 유도했습니다. 서명이 진행되면, 이용자의 자산은 공격자의 지갑으로 전송됩니다.

추가로, 악성 코드는 이용자가 트랜잭션에 서명하기 직전 데이터 자체를 변조하는 기능을 수행습니다. 이더리움이나 솔라나와 같은 네트워크 환경에서는 단순한 주소 변경 동작 외에도, approve 함수 호출 과정에서 승인 권한을 조작함으로써 공격자가 피해자 지갑의 자금에 지속적으로 접근할 수 있도록 백도어를 설치하는 행위가 확인되었습니다. 이는 일회성 자산 탈취를 넘어, 장기적인 자금 탈취가 가능한 구조를 형성한다는 점에서 위험도가 높습니다.

Shai-Hulud 웜과 자동화된 전파

2025년 9월 15일에는 개발자 환경을 공격하는 Shai-Hulud 웜이 등장했습니다. 해당 웜은 시스템 자동화 메커니즘을 역으로 이용하여 스스로 전파되는 방법을 채택하여, npm 생태계에서 자가 복제에 성공한 최초의 공급망 형 웜 공격 사례로 평가됩니다.

Shai-Hulud의 핵심 목표는 개발자의 로컬 개발 환경과 CI/CD 파이프라인을 감염시킨 후, 해당 개발자가 유지보수하는 다른 npm 패키지로 감염을 확산하는 것입니다. 이를 통해 공격자는 개별 패키지를 하나씩 침해하지 않고, 단일 개발자 계정을 기점으로 대규모 확산을 유도할 수 있습니다. 웜의 동작 과정은 아래와 같습니다.

1. 초기 침투: 웜은 감염된 패키지의 postinstall 혹은 preinstall 스크립트를 통해 실행됩니다. 해당 스크립트는 사용자가 npm install 명령을 실행할 때 별도의 확인 절차 없이 실행됩니다.

2. 자격 증명 스캐닝: 실행된 웜은 환경 변수(env) 및 홈 디렉터리 설정 파일(예: .npmrc, .aws/credentials, .git-credentials)을 스캔하여, 크리덴셜(예: NPM_TOKEN, GITHUB_TOKEN, 클라우드 서비스의 API 키)을 수집합니다.

3. 자가 복제 및 배포: 유효한 NPM_TOKEN을 발견하면, 웜은 해당 토큰의 권한을 확인합니다. 패키지 배포 권한이 있는 경우, 해당 사용자가 메인테이너로 있는 다른 패키지 목록을 조회합니다. 이후, 해당 패키지에 악성 코드를 주입하고 버전을 수정하여 레지스트리에 배포함으로써 감염을 확산합니다.

Shai-Hulud는 특히 Github Actions와 같은 CI/CD 환경을 주요 공격 대상으로 삼았습니다. CI/CD 환경은 배포 자동화를 위해 높은 권한의 API키와 시크릿을 환경 변수로 설정하는 경우가 많습니다. 웜은 이를 탈취하여 공격자 제어 서버로 전송하고, 감염된 저장소에 악성 워크플로우 파일(예: .github/workflows/shai-hulud-workflow.yml)을 생성하여 지속성을 확보했습니다. 이로 인해, 개발자가 로컬에서 악성 패키지를 삭제하더라도, 원격 저장소의 워크플로우가 다시 악성 코드를 실행하거나 시크릿을 유출하는 구조가 형성되었습니다.

2025년 11월에 발견된 변종인 Shai-Hulud 2.0은 더욱 공격적인 성향을 보였습니다. 해당 웜은 C2서버와 통신할 수 없거나 특정 조건에서 실행이 차단될 경우, 감염된 시스템의 홈 디렉터리나 주요 파일 시스템을 삭제(rm -rf ~/*)하도록 설계되었습니다. 이는 단순한 정보 탈취를 넘어, 개발자의 작업물을 파괴하거나 빌드 서버를 마비시키는 가용성 침해(DoS) 공격으로 발전할 수 있습니다. 이처럼 Shai-Hulud는 공급망 공격이 데이터 탈취를 넘어 랜섬웨어와 유사한 파괴적 공격으로 진화할 수 있음을 보여주는 사례입니다.

더 이상 오픈 소스 생태계에서 암묵적 신뢰(Implicit Trust)를 유지하기는 어렵습니다. qix 계정 탈취 사건은 2FA 와 같은 기술적인 보호 조치가 인간의 심리를 파고드는 사회공학적 공격(AiTM) 앞에서 무력화될 수 있음을 보여주었고, Shai-Hulud 웜은 개발 편의를 위해 구축된 CI/CD 파이프라인이 치명적인 공격 경로가 될 수 있음을 드러냈습니다. 공격자는 이제 표면적인 서버의 방화벽을 뚫으려 노력하기보다, 수십억 건의 다운로드가 이루어지는 신뢰된 패키지 뒤에 숨어 개발자의 로컬 환경, 이용자의 브라우저, 기업의 빌드 서버를 겨냥하고 있습니다.

npm은 그 영향력을 쉽게 대체할 수 없는 현대 웹 개발의 핵심 인프라입니다. 우리가 사용하는 코드가 우리가 작성한 코드보다 위험할 수 있다는 사실을 인식하지 않는다면, 공급망 공격은 반복될 수밖에 없습니다. 편리함 뒤에 숨겨진 연결성의 위험을 끊임없이 검증하는 자세만이 오픈 소스 생태계에서 공급망 공격에 대응할 수 있는 실질적인 방어책이 될 것입니다.

References

• https://www.paloaltonetworks.com/blog/cloud-security/npm-supply-chain-attack/

• https://thehackernews.com/2025/09/20-popular-npm-packages-with-2-billion.html

• https://www.paloaltonetworks.com/blog/cloud-security/npm-supply-chain-attack/

• https://www.trendmicro.com/en_us/research/25/i/npm-supply-chain-attack.html

• https://arcticwolf.com/resources/blog/shai-hulud-malware-targets-numerous-npm-packages-second-wave-npm-supply-chain-attack/

• https://about.gitlab.com/blog/gitlab-discovers-widespread-npm-supply-chain-attack/

• https://access.redhat.com/security/supply-chain-attacks-NPM-packages

3. Personal Credit Data Leakage at Lotte Card

2025년 9월 18일, 롯데카드는 해킹에 의한 대규모 데이터 유출 사고를 공식 발표하며 다수의 해킹 이슈로 혼란스러운 사회 전반에 충격을 더했습니다. 유출된 데이터에는 고객의 기본적인 개인정보를 포함하여 온라인 결제 정보, CI(온라인상 고유식별번호), 비밀번호, 카드 번호, CVC 등 유출 시 2차 피해를 야기할 수 있는 민감한 정보가 다량 포함되어 있었습니다.

사고의 타임라인을 살펴보면, 롯데카드는 2025년 8월 26일 일부 서버가 악성 코드에 감염된 사실을 확인하고 자체적으로 전사서버에 대한 정밀 조사를 진행하였습니다. 조사 결과, 3개의 서버에서 2종의 악성 코드와 5종의 웹셸이 발견되었습니다. 이후 8월 31일, 온라인 결제 서버에서 외부 공격자의 데이터 유출 시도를 확인하였고, 다음 날인 9월 1일에 약 1.7GB 규모의 데이터가 유출되었다는 내용으로 금융당국에 해킹 피해 사실을 신고했습니다. 금융당국은 정확한 해킹 원인 및 피해 규모를 확인하기 위해 조사에 착수하였고, 이 과정에서 실제 유출된 데이터의 규모가 약 200GB에 달하고, 공격자가 CVE-2017-10271 취약점을 악용하여 서버에 침투했다는 사실을 확인했습니다.

CVE-2017-10271

롯데카드 해킹 사고에 악용된 CVE-2017-10271은 Oracle WebLogic Server에서 원격으로 코드를 실행할 수 있는 취약점입니다. 공격자는 해당 취약점을 악용하여 특수하게 조작된 XML 데이터를 전송하는 것으로 별도의 인증이나 권한 없이 서버를 완전히 장악할 수 있습니다.

취약점의 근본 원인은 Java의 XMLDecoder 클래스에 있습니다. XMLDecoder는 단순히 XML 구조를 파싱하는 것이 아니라, XML 스크립트(XML 형식으로 표현된 객체와 메서드 호출)를 실제로 실행하는 인터프리터 역할을 수행합니다. 따라서 신뢰할 수 없는 데이터를 해당 클래스로 파싱할 경우, 역직렬화 취약점이 발생하여 원격 코드 실행으로 이어질 수 있습니다. 10.3.6.0.0, 12.1.3.0.0, 12.2.1.1.0, 12.2.1.2.0 버전의 Oracle WebLogic Server는 특정 엔드포인트(예: /wls-wsat/CoordinatorPortType)에서 전달받은 XML 데이터를 XMLDecoder로 그대로 파싱하도록 설계되어 있어, 조작된 XML 요청을 전송하여 서버를 장악할 수 있는 취약점(CVE-2017-10271 )이 발생했습니다.

롯데카드 해킹의 핵심적인 경로를 제공한 취약점은 CVE-2017-10271이지만, 사고의 근본 원인을 하나의 취약점으로 한정하기는 어렵습니다. 패치 거버넌스 미흡, 자산 식별 부족, 침입 탐지 체계의 한계 등이 복합적으로 작용하여 해당 사태가 발생했다고 보는 것이 보다 적절합니다. 만약 서버가 보안 패치를 하여 CVE-2017-10271에 취약하지 않았더라도, 다른 서버를 통한 침투가 가능했다면 유사한 데이터 유출 시나리오가 재현될 수 있기 때문입니다.

이러한 이유로, 이번 사례는 취약점 패치 그 자체보다 운영 현실에 기반한 보안 관리가 중요하다는 메시지를 전달합니다. 인터넷에 노출된 WAS에서 패치가 누락된 서버가 하나라도 남아 있으면, 그 지점은 전체 인스턴스의 공격 표면이자 데이터 유출의 시발점이 될 수 있습니다. 처음 침투한 서버가 핵심 시스템이 아니더라도, 내부 시스템 간 연결 구조를 따라 침투 범위를 확장할 경우 공격자는 매우 높은 확률로 민감 정보가 저장된 서버에 접근할 수 있습니다.

결론적으로 해당 사태의 원인은 아래와 같이 정리할 수 있습니다.

1. 보안 패치 누락

2. 인스턴스의 아웃바운드 트래픽 통제 미흡

3. 침입 탐지 및 자산 식별 미흡

현실적으로 소유 중인 모든 인스턴스에 대한 완벽한 보안 패치 적용, 모니터링, 목적에 맞는 트래픽 통제를 수행하는 것은 어렵습니다. 하지만 보안은 단순히 고가의 솔루션을 도입하고 사용하는 것으로 완성되지 않습니다. 치명적인 보안 사고는 작은 실수나 무관심 등이 모여 초래되기 때문에, 실질적인 방어 체계를 구축하기 위해서는 각 기능의 이유와 목적, 환경과 위험을 정확히 이해하고 필요한 지점에 적절하게 리소스를 배분해야 합니다.

References

• https://news.tvchosun.com/site/data/html_dir/2025/09/19/2025091990300.html

• https://blog.plura.io/ko/threats/case-lottecard_weblogic/

• https://www.industrynews.co.kr/news/articleView.html?idxno=71674

• https://blog.78researchlab.com/262db461-3e5b-80ec-be96-fbd1d80578e6

4. RediShell

2025년 10월 6일, 전 세계 인프라 환경에서 광범위하게 사용되는 Redis(Remote Dictionary Server)의 치명적인 보안 취약점이 Wiz에 의해 공개되었습니다. RediShell로 명명된 CVE-2025-49844는 Redis에 내장된 Lua 스크립트 엔진에서 발생하는 Use-After-Free(UAF) 기반 메모리 손상 취약점입니다. 해당 취약점은 CVSS v3.1 기준 10.0점(Critical)을 기록하였으며, 악용 시 인증된 공격자가 Lua 샌드박스를 탈출하여 호스트 시스템에서 임의 코드를 실행(RCE)할 수 있는 것으로 알려졌습니다.

CVE-2025-49844는 Wiz Research 팀에 의해 발견되었으며, 2025년 5월 16일 Pwn2Own 베를린에서 보고되었습니다. 해당 취약점은 Redis가 사용하는 Lua 5.1 인터프리터의 구현 결함에서 비롯된 것으로, Lua 스크립트를 해석하고 실행하는 과정에서 특정 메모리 객체의 생성과 해제 시점(생명주기)이 잘못 관리되어 발생합니다.

취약점의 핵심은 UAF입니다. UAF는 프로그램이 이미 해제된 메모리를 여전히 유효한 것으로 간주하고 메모리 주소를 가리키는 포인터(Dangling Pointer)를 사용하여 접근할 때 발생하는 취약점으로, 일반적으로 메모리 손상 및 제어 흐름 탈취로 이어질 수 있습니다. RediShell의 경우, Lua 스크립트 실행 중 가비지 컬렉터(Garbage Collection, GC)의 동작 시점을 공격자가 조작하여 사용 중인 객체를 강제로 해제하면 발생합니다.

공격은 진행 단계는 아래와 같습니다.

1. 스크립트 주입: 인증된 공격자가 EVAL 명령어를 통해 악성 Lua 스크립트를 Redis에 전송합니다.

2. 힙 그루밍(Heap Grooming): Lua 스크립트 내에서 메모리 레이아웃을 조작하기 위해 다수의 객체를 할당하고 해제하는 과정을 수행합니다. 해당 과정은 UAF 발생 시 해제된 메모리 영역을 공격자가 원하는 데이터로 덮어쓰기 위한 단계입니다.

3. GC 조작 및 UAF 유발: 공격자는 luaY_parser의 버그를 이용하여 메모리 참조 오류를 유발합니다. 스크립트를 통해 Lua의 파서가 특정 문자열이나 객체(예: TString) 처리 중, 강제로 GC가 동작(collectgarbage())하도록 합니다. 이때 Redis의 Lua 구현체에 존재하는 결함으로 인해, 파서가 여전히 참조하고 있는 객체가 더 이상 사용되지 않는 객체로 오인되어 메모리에서 해제됩니다.

4. 메모리 오염(Memory Corruption): 해제된 메모리 공간(TString 메모리 공간)에 공격자의 데이터가 재할당되면, 파서는 해제된 이전 객체의 포인터를 사용하여 해당 데이터에 접근합니다. 이렇게 공격자의 데이터를 참조하여, 내부 데이터 구조가 손상되는 메모리 오염이 발생합니다.

5. 샌드박스 탈출(Sandbox Escape): 내부 데이터 구조 손상을 바탕으로 공격자는 Lua 샌드박스 제약을 우회합니다. 차단된 함수(예: os.execute, io.popen)에 접근하거나, 메모리 주소를 직접 조작하여 기계어 코드를 실행하고 샌드박스를 탈출할 수 있습니다.

6. 호스트 장악: 샌드박스를 탈출한 공격자는 Redis 프로세스 권한으로 호스트 운영체제에서 명령어를 실행할 수 있습니다.

해당 취약점은 d5728cb5795c966c5b5b1e0f0ac576a7e69af539 커밋을 통해 수정되었습니다. 해당 패치는 Lua 파서(lparser.c) 내 luaY_parser 함수에서 문자열 객체의 생명주기를 GC를 통해 관리하는 대신, 명시적으로 관리하도록 변경합니다.

/* lparser.c 내부 패치 전 */
luaX_setinput(L, &lexstate, z, luaS_new(L, name));

/* lparser.c 내부 패치 후 */
TString *tname = luaS_new(L, name);
setsvalue2s(L, L->top, tname);
incr_top(L);
luaX_setinput(L, &lexstate, z, tname);

기존 코드에서는 luaS_new(L, name) 호출로 생성된 문자열 객체가 스택에 고정(anchor)되지 않은 상태로 luaX_setinput 함수에 전달됩니다. 이때 luaX_setinput 내부 또는 하위 호출에서 GC가 동작한다면, luaS_new로 생성된 문자열은 도달 불가능(Unreachable)한 객체로 간주되어 해제될 수 있습니다.

수정된 코드에서는 luaS_new 함수로 생성된 문자열을 luaX_setinput 함수 호출 전에 명시적으로 Lua 스택(L->top)에 푸시(push)합니다. 이로 인해 GC가 동작하더라도 해당 객체는 스택에 의해 참조되고 있는 상태로 유지되어 해제되지 않습니다.

RediShell 취약점의 파급력은 Redis의 사용량에 비례합니다. 현재도 약 60,000여 개의 Redis 인스턴스가 별도 인증 없이 인터넷에 노출되어 있으며, 공격자는 추가적인 자격 증명 탈취 과정 없이 인스턴스에 접속하여 EVAL 명령만으로 원격 코드 실행을 할 수 있습니다. 해당 취약점의 근본 원인이 되는 코드는 Redis 소스 코드 내에 약 13년간 존재해 왔으며, 이는 지난 10년간 배포된 거의 모든 Redis 인스턴스가 잠재적으로 동일한 위협에 노출되어 있음을 의미합니다. 아래는 CVE가 발급된 2025년 10월 3일 공개된 보안 패치입니다.

RediShell(CVE-2025-49844)은 오픈 소스 생태계와 인프라 보안에 중요한 시사점을 남겼습니다. 먼저, Lua 샌드박스와 같은 격리 메커니즘이 존재하더라도, 인터프리터 자체의 메모리 관리 결함이 있다면 샌드박스가 무력화될 수 있다는 한계를 보여주었습니다. 또한, 해당 취약점 코드가 13년 동안이나 발견되지 않고 존재했다는 점은, 오래된 코드가 안전한 코드라는 일반적인 통념을 깨뜨립니다. 이번 사례는 널리 사용되는 성숙한 프로젝트일지라도, 코드 검수(Audit)와 퍼징(Fuzzing) 테스트가 지속적으로 이루어질 필요가 있음을 보여줍니다.

References

• https://redis.io/blog/security-advisory-cve-2025-49844/

• https://www.wiz.io/blog/wiz-research-redis-rce-cve-2025-49844

• https://comate.baidu.com/zh/page/vjfxlmux9gm

• https://www.offsec.com/blog/recent-vulnerabilities-in-redis-servers-lua-scripting-engine/ 

• https://github.com/Yuri08loveElaina/CVE-2025-49844

5. Internal Data Breach at SK Shieldus

2025년 10월 17일, 해커 조직 Black Shrantac이 다크웹을 통해 국내 대표 통합 보안 기업인 SK쉴더스의 내부 데이터를 탈취했다고 주장했습니다. Black Shrantac은 다크웹 게시글을 통해 약 24GB 규모의 내부 문서와 기술 자료를 확보하였다고 밝히며, 탈취한 파일의 일부를 공개하여 추가 공개 가능성을 언급하였습니다. 이는 게시글을 통해 정보를 단순히 공개하는 것에 그치지 않고, 정보 유출 위험을 무기로 기업을 압박하는 데이터 기반 협박(extortion) 방식으로 볼 수 있습니다.

공개된 자료에는 고객사 관련 제안서, 네트워크 구성 문서, 시스템 설계 자료, 내부 프로젝트 문서 등이 포함되어 있었고, 일부 문서에는 실제 임직원의 이름과 시스템 구조가 평문으로 노출되어 있었습니다.

유출 사건 공론화 이후 초기 대응 과정에서, SK쉴더스는 해당 데이터가 실제 운영망이 아닌 허니팟(Honeypot) 환경에서 유출된 것이라고 밝혔습니다. 허니팟은 공격자의 공격 기법을 분석하기 위해 의도적으로 공격자를 유인하는 시스템이므로, SK쉴더스의 초기 주장에 따르면 유출된 정보는 허니팟에 존재하는 미끼 정보이므로 실제 고객 시스템 및 핵심 운영망의 침해는 발생하지 않은 것입니다.

하지만 확인 결과, 유출된 문서 상당수가 단순한 더미 데이터가 아닌 실제 프로젝트 수행 과정에서 사용된 PoC 자료, 네트워크 설계도, 내부 운영 문서로 밝혀졌습니다. 또한, 실제 임직원의 개인정보가 포함되어 있었다는 점에서 유출된 자료를 단순한 미끼 정보로 보기 어렵다는 지적이 있었습니다.

이후 추가 조사 결과, 허니팟에 연결된 직원의 개인 이메일 계정을 통해 일부 업무 자료가 외부로 유출된 정황이 확인되었습니다. SK쉴더스는 해당 상황에 대해 허니팟 구축용 가상머신(VM)에서 사용하는 크롬 브라우저에 실제 계정으로 자동 로그인이 되어 있어, 이메일 계정의 업무 관련 문서가 해커의 침투에 의해 유출된 것이라는 입장을 밝혔습니다. 이는 허니팟 환경이 실제 운영 정보와 충분히 분리되지 않았을 가능성을 시사합니다. 보안 연구를 목적으로 구성된 시스템이라 하더라도, 그 안에 실질적인 내부 정보나 고객 관련 자료가 포함되어 있다면, 공격자 관점에서는 그 자체로 가치 있는 공격 자산이 됩니다. 일반적으로 공격자를 의도적으로 유인하는 취약한 시스템을 허니팟이라고 부르지만, 허니팟의 가장 중요한 정의는 ‘침해가 발생하더라도 조직에 실질적인 피해가 발생하지 않는 시스템’입니다. 따라서, 이번 사건과 같이 실제 피해가 발생했다면 해당 시스템은 더 이상 허니팟이라고 부를 수 없습니다.

과학기술정보통신부 조사 결과, 실제로 유출된 데이터는 해커가 주장한 24GB보다 적은 15.1GB로 확인되었습니다. 유출된 데이터에는 단순 로그나 테스트 결과가 아니라, 네트워크 구조, 방화벽 정책, 프로젝트 문서, 내부 API 설명 자료 등이 포함되었고, 이는 단독으로 가치를 지닐 뿐 아니라, 향후 추가 공격을 설계하는 데 유용한 기반 자료가 됩니다.

현재까지 공개된 정보를 바탕으로 보면, 이번 사고는 특정 취약점 하나로 인해 발생한 문제가 아닌 환경 분리 및 정보 관리 미흡으로 인해 발생한 문제로 요약할 수 있습니다. 허니팟·PoC·테스트 환경은 본래 실제 운영망과 논리적·물리적으로 강하게 분리되어야 하지만, 유출된 자료에는 실제 운영 구조를 추정할 수 있는 정보가 포함되어 있었습니다. 이는 환경 분리가 미흡하다는 근거이며, 공격자가 단순한 미끼 환경이 아닌 의미 있는 내부 시스템에 접근하였다는 것을 보여줍니다.

유출된 정보 외에 공격 방식에도 주목할 필요가 있습니다. 기존 다크웹 기반 공격자들은 서버를 장악한 뒤 데이터를 암호화해 서비스 가용성을 위협하는 랜섬웨어 방식을 주로 사용해 왔습니다. 그러나 이번 공격은 서비스 마비가 아닌 정보 유출 그 자체를 협상 수단으로 활용했다는 점에서 차별화됩니다. 최근 국내에서 다수의 보안 사고가 연이어 발생하며 정보 유출의 파급력이 널리 인식된 상황에서, 이러한 공격 방식은 피해 규모와 영향이 직관적으로 전달된다는 점에서 더욱 위협적입니다. 이번 사고는 공격자들이 단순히 시스템을 중단시키는 데 그치지 않고, 데이터의 가치를 정확히 인식하고 이를 적극적으로 활용하고 있음을 보여줍니다.

SK쉴더스 해킹 사고는 보안 기업이 침해될 경우, 그 영향이 단일 조직에 국한되지 않고 관련된 다수의 기업으로 확산될 수 있음을 보여주었습니다. 규모가 큰 기업의 보안 사고는 그 자체로 위험이지만, SK쉴더스는 보안 서비스를 제공하는 기업이기에 보안 사고 발생 시 파급력이 크다는 점도 주목해야 합니다. 보안 기업은 다수 고객사의 민감한 정보를 다루게 되고, 기업의 정보가 유출됨에 따라 내부 문서, 네트워크 구성도, 고객사 관련 자료가 공격자에게 넘어갈 경우 보안 기업 외에도 고객사의 신뢰도에 문제가 발생하기 때문입니다.

많은 조직이 소스 코드나 개인정보에는 높은 수준의 보안을 적용하는 반면, 설계 문서나 내부 기술 자료에 대해서는 상대적으로 느슨한 관리 방식을 취하고 있습니다. 그러나 공격자의 관점에서 이러한 문서들은 시스템 구조를 이해하고 우회 공격을 설계하는 데 있어 매우 가치 있는 정보 자산에 해당합니다. 내부 자료 유출은 단순한 정보 노출을 넘어, 이후 공격의 정밀도를 높이는 기반이 될 수 있습니다.

이번 침해가 허니팟 환경에서 시작되었다는 점은, 테스트 및 실험 환경 보안의 중요성을 다시 한 번 강조합니다. 실제 보안 점검 현장에서도 레거시 환경이나 테스트 환경에서 발견된 문제가 운영 환경에서도 동일하게 재현되거나, 더 큰 보안 사고로 이어지는 경우를 자주 확인할 수 있습니다. 이는 테스트 환경이 오히려 관리 사각지대에 놓이며, 위험성이 높은 공격 표면으로 작용할 수 있음을 시사합니다.

이번 사건을 계기로, 보안을 완성하는 데 있어 기술적 통제뿐 아니라 운영과 정책이 중요하다는 것을 기억할 필요가 있습니다. 허니팟을 어떻게 정의하고, 어떤 정보를 포함시키며, 누구에게 접근을 허용할 것인지는 모두 운영적 판단의 영역에 속합니다. 기술적으로 정교한 보안 솔루션을 갖추고 있더라도, 운영 기준이 명확하지 않거나 일관되지 않다면 전체 보안 구조는 쉽게 무너질 수 있습니다.

References

• https://www.dailysecu.com/news/articleView.html?idxno=201475

• https://www.boannews.com/media/view.asp?idx=139820

• https://www.mt.co.kr/tech/2025/10/17/2025101714304936028

• https://v.daum.net/v/20251021171946456

• https://www.dailysecu.com/news/articleView.html?idxno=201496

• https://news.sbs.co.kr//news/endPage.do?newsId=N1008307199

6. Cloudflare Outage

2025년 11월과 12월, 전 세계 인터넷에 광범위한 영향을 미친 두 차례의 대규모 서비스 장애가 발생했습니다. 첫 번째 장애는 한국 시간으로 11월 18일 20시 20분부터 11월 19일 02시 06분까지, 두 번째 장애는 12월 5일 17시 47분부터 18시 12분까지 발생했습니다.

두 사건의 원인은 모두 전 세계 CDN(콘텐츠 전송 네트워크) 및 보안 인프라 서비스를 제공하는 Cloudflare의 시스템 문제로 확인되었습니다.

Cloudflare의 요청 처리 방식

Cloudflare는 전 세계 수많은 웹사이트의 트래픽이 통과하는 거대한 관문 역할을 합니다. 이용자가 웹사이트 접속을 시도하면, 해당 요청은 먼저 Cloudflare의 네트워크를 거치게 됩니다. 이 과정에서 Cloudflare는 HTTP/TLS 계층에서 연결을 수신하고, 핵심 프록시 시스템인 'Frontline(FL)'을 통해 요청을 처리합니다.

이 프록시 시스템 내부에서는 아래와 같은 다양한 보안 기능이 모듈 형태로 동작합니다.

• WAF(웹 방화벽): 악성 공격 차단

• DDoS 방어 시스템: 대규모 트래픽 공격 방어

• Bot Management: 머신러닝 기반 봇 트래픽 식별 및 관리

이들 모듈은 각 웹사이트에 설정된 규칙에 따라 트래픽을 검사한 후, 최종적으로 원본 서버로 요청을 전달하거나 캐시된 콘텐츠를 이용자에게 반환합니다.

11월 18일 첫 번째 장애

11월 18일에 발생한 첫 번째 장애는 Bot Management 시스템의 설정 파일 문제에서 시작되었습니다. 당시 Cloudflare 엔지니어들은 데이터베이스 시스템의 보안 강화를 위해 권한 설정을 변경하는 작업을 진행하였고, 이 과정에서 예상하지 못한 부작용이 발생했습니다.

Bot Management는 머신러닝을 기반으로 봇을 탐지하며, 이를 위해 '피처 파일(Feature file)'이라는 설정 파일을 사용합니다. 해당 파일은 5분마다 데이터베이스 쿼리를 통해 자동으로 생성되어 전체 네트워크에 배포됩니다. 하지만 권한 변경 작업의 영향으로 데이터베이스 쿼리가 중복된 메타데이터를 반환하게 되었고, 그 결과 동일한 설정 항목이 파일 내에 중복 생성되어 파일 크기가 2배 이상 커졌습니다.

이 결과는 시스템이 처리할 수 있는 피처의 최대 개수가 200개로 제한되어 있어 문제가 되었습니다. 평소에는 약 60개 수준의 피처만 사용하고 있었기에 이는 여유 있는 수치였지만, 중복 데이터로 인해 해당 제한을 초과하자 프록시 시스템 소프트웨어가 패닉(panic) 상태에 빠지며 중단되어 대규모 장애로 이어졌습니다.

Cloudflare 팀은 문제 원인을 파악한 후 한국 시간 기준 11월 18일 23시 30분경부터 복구 작업을 시작했습니다. 구체적인 조치는 아래와 같습니다.

1. 문제가 되는 피처 파일의 자동 생성 및 배포 중단

2. 이전에 정상 동작하던 구버전 파일을 네트워크 전체에 수동 재배포

3. 영향을 받은 프록시 시스템을 순차적으로 재시작하여 정상 파일 로드

위 조치 결과, 한국 시간으로 11월 19일 새벽 2시 6분경 모든 시스템이 정상화되었습니다.

12월 5일 두 번째 장애

12월 5일에 발생한 두 번째 장애는 React 프레임워크의 보안 취약점(CVE-2025-55182) 긴급 대응 과정에서 발생했습니다. Cloudflare는 React Server Components에서 발견된 취약점을 방어하기 위해, WAF가 검사하는 요청 본문(body)의 최대 크기 제한을 기존 128KB에서 Next.js의 기본값인 1MB로 상향하는 작업을 진행했습니다.

해당 변경 사항을 배포하는 과정에서, 내부에서 사용하는 WAF 테스트 도구가 늘어난 버퍼 크기를 제대로 처리하지 못하는 문제가 발견되었습니다. 테스트 도구는 고객 트래픽에 영향을 주지 않는 내부 도구였기에 엔지니어들은 즉시 해당 도구를 비활성화하였습니다. 하지만 이 '비활성화' 조치가 수년간 코드 내부에 잠재되어 있던 버그를 촉발하였습니다. 문제가 발생한 코드는 아래와 같습니다.

if rule_result.action == "execute" then
  rule_result.execute.results = ruleset_results[tonumber(rule_result.execute.results_index)]
end

위 코드는 규칙 집합(Ruleset)의 평가 결과를 처리하는 로직입니다. 코드는 규칙의 동작이 '실행(execute)'인 경우, 관련 결과 객체(rule_result.execute)가 항상 존재할 것이라는 가정 하에 작성되어 있었습니다. 하지만 WAF 테스트 도구 규칙이 비활성화되며 분기로 인해 해당 규칙이 실행되지 않아, rule_result.execute 객체가 생성되지 않았습니다. 이 상태에서 코드는 존재하지 않는 객체(nil) 접근을 시도하였고, 이로 인해 nil 값 참조 오류(Attempt to index a nil value)가 발생했습니다.

이 오류로 인해 영향을 받은 서버들은 즉시 HTTP 500 오류를 반환하였으며, 다행히 Cloudflare 측에서 변경 사항을 신속하게 롤백(원상복구)하여, 장애 발생 약 25분 만에(한국 시간 18시 12분) 서비스는 정상화되었습니다.

이번 두 차례의 장애는 현대 웹 생태계가 Cloudflare라는 하나의 플랫폼에 얼마나 깊이 의존하고 있는지 다시 한 번 확인시켜 주는 사례입니다. 아무리 규모가 크고 안정적인 서비스라도, '단일 실패 지점(SPOF)'이 될 수 있기 때문에 서비스의 안전성을 위해서는 만약의 상황에 대비한 인프라 다중화 및 의존성 분산이 필요합니다.

References

• https://blog.cloudflare.com/ko-kr/18-november-2025-outage/

• https://blog.cloudflare.com/ko-kr/5-december-2025-outage/

7. Personal Information Breach at Coupang

2025년 11월 19일, 국내 대표 이커머스 플랫폼인 쿠팡은 개인정보 유출 의심 정황을 확인하고 이를 경찰에 신고하였습니다. 사건 초기 쿠팡은 비정상적인 접근 시도를 감지하고 즉각적인 경로 차단 및 내부 보안 점검에 착수하였으며, 정확한 피해 규모를 파악하기 위해 자체 조사와 함께 수사 기관에 의뢰를 진행했습니다. 정밀 분석 후 11월 29일, 쿠팡은 개인정보 유출의 피해 범위가 약 3,370만 명에 이르는 것으로 확인되었다고 공식 발표했습니다. 이는 국내 최대 규모의 개인정보 유출 사건입니다.

현재까지 알려진 정보에 따르면, 이번 사고는 외부 침입보다는 내부 시스템의 설계적 특성과 권한 관리의 이슈가 복합적으로 작용한 결과로 추정됩니다. 공격은 2025년 6월 24일부터 11월 말까지 약 5개월간 지속되었으며, 공격자는 해외 서버를 경유하여 장기간에 걸쳐 은밀하게 데이터를 조회한 것으로 파악됩니다. 중국 국적으로 추정되는 전직 직원이 퇴사 이후에도 회수되지 않은 API 접근 키(Access Key)와 인증 정보를 이용해 외부에서 무단 접속한 것으로 보고 있습니다.

이번 공격은 예측 가능한 식별자 사용과 내부 API의 부적절한 노출이라는 두 가지의 치명적인 결함을 악용한 사례로 분석됩니다. 첫째, 쿠팡의 내부 데이터베이스에서 이용자 식별값(Primary Key)을 난수가 아닌, 1씩 증가하는 정수 형태로 설계되어 있었던 것으로 보입니다. 해당 구조에서 공격자는 숫자를 순차적으로 대입하는 것만으로도 대규모 데이터를 수집할 수 있습니다. 둘째, 내부에서만 사용되어야 하는 API가 외부망에 노출되어 있었습니다. 해당 API는 순차적인 정수값을 매개로 인증 토큰을 발급하는 로직을 갖고 있었으며, 이로 인해 공격자는 복잡한 우회 기법 없이도 단순 반복 요청만으로 방대한 데이터를 조회할 수 있었습니다.

이번 사고는 단순한 관리 부실을 넘어, 시스템 설계 단계에서의 보안 고려(Security by Design) 부재가 기업과 이용자 전체에 어떤 영향을 가져오는지 보여주는 사례로 평가됩니다. 특히 쿠팡과 같이 방대한 데이터와 복잡한 마이크로서비스 아키텍처를 운영하는 환경에서는, 개발 편의성을 위해 설계된 내부 로직이 의도치 않게 외부 위험에 노출될 수 있으며, 이는 곧 서비스의 잠재적 취약점으로 작용할 수 있음을 시사합니다.

데이터 식별자는 예측 불가능한 난수(예: UUID)로 설계되어야 하며, 내부 API는 철저한 망 분리와 접근 제어를 통해 외부 접근을 원천 차단해야 합니다. 기술적 편의를 위해 남겨둔 작은 구멍은 결국 보안을 무너뜨리는 대규모 피해로 이어질 수 있습니다. 이제 온라인 기반 비즈니스 환경에서는 보안을 단순한 IT 운영의 일부가 아니라, 비즈니스 연속성과 브랜드의 생존을 좌우하는 핵심 리스크 요소로 인식해야 합니다. 보안은 시스템을 보호하는 기술인 동시에, 고객과의 신뢰를 지키는 마지막 방어선이라는 점을 기억해야 합니다.

References

• https://v.daum.net/v/20251202212010142

• https://v.daum.net/v/Px0Hu69U33

• https://www.eroun.net/news/articleView.html?idxno=69042

• https://news.coupang.com/archives/58857/

• https://www.pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074&mCode=C020010000&nttId=11642

• https://www.nepla.ai/wiki/it-정보-방송통신/개인정보-위치정보-신용정보/쿠팡-개인정보-3-370만개-유출-사건-정리-2025년-w5dnz3w648e6

• https://www.donga.com/news/Economy/article/all/20251202/132880891/2

8. React2Shell

2025년 12월 3일, React2Shell로 알려진 CVE-2025-55182 취약점이 공개되었습니다. 해당 취약점은 React Server Components(RSC) Flight Protocol의 안전하지 않은 역직렬화로 인해 발생하며, 프로토타입 오염(Prototype Pollution) 공격에 의해 원격 코드 실행(RCE)까지 이어질 수 있습니다. 특히, 공격자가 조작된 HTTP 요청을 보내는 것만으로 별도의 설정 없이 공격을 수행할 수 있어 위험도가 높습니다. React에 의존하는 프레임워크인 Next.js 역시 동일한 구조를 사용하고 있어 같은 취약점의 영향을 받습니다.

Theori에서 만든 ReactGuard를 통해 현재 운영 중인 서버가 해당 취약점의 영향을 받는지 확인할 수 있습니다.

React Server Components

RSC가 등장하기 이전의 React 기반 애플리케이션은 JavaScript 번들 파일을 모두 클라이언트에게 전달한 후, 브라우저에서 코드를 로딩하고 실행하는 구조였습니다. 해당 방식은 번들 크기에 따라 상당한 비용이 발생하였고, 백엔드와 통신하기 위한 민감한 로직이 클라이언트 번들에 노출될 수 있다는 문제도 내포하고 있었습니다.

이러한 한계를 해결하기 위해 RSC 개념이 도입되었습니다. RSC는 서버에서만 실행하는 React 컴포넌트를 생성하고, Flight Protocol을 통해 코드에 대한 노출 없이 서버의 실행 결과만을 클라이언트로 전달합니다. RSC 환경에서 클라이언트가 서버 로직을 호출하는 주요 수단은 Server Action이며, 클라이언트가 HTTP 요청을 전송하여 Server Action을 호출하면 서버는 요청 본문을 Flight Protocol 규칙에 따라 다시 파싱한 후 서버 함수를 실행합니다.

아래는 Server Action의 예시입니다. 이용자가 Next.js로 데이터를 입력하여 버튼을 클릭하면, 서버는 데이터를 그대로 반환합니다.

// app/pages.tsx
"use client";
import { pingpong } from "./actions";
export default function Page() {
  return (
    <form action={pingpong}>
      <input type="text" name="ping" placeholder="메시지를 입력하세요" />
      <button type="submit">전송</button>
    </form>
  );
}

// app/actions.ts
"use server";
export async function pingpong(formData: FormData) {
  console.log("Server received:", formData);
  const ping = formData.get("ping");
  return {
    success: true,
    ping,
  };
}

이에 대한 요청 및 응답은 아래와 같습니다.

[Request]
POST / HTTP/1.1
Host: localhost
Content-Length: 377
next-action: 4067cee7ffcfc30860beeb78f35dd3cec02d4084ac
x-nextjs-request-id: 92c675a9
next-router-state-tree: %5B%22%22%2C%7B%22children%22%3A%5B%22__PAGE__%22%2C%7B%7D%2Cnull%2Cnull%5D%7D%2Cnull%2Cnull%2Ctrue%5D
Accept: text/x-component
Content-Type: multipart/form-data; boundary=----WebKitFormBoundarydKf562tVKmAb3SAf
x-nextjs-html-request-id: Fdgu0NxeBjN_wsjojB9Nk
Accept-Encoding: gzip, deflate, br
------WebKitFormBoundarydKf562tVKmAb3SAf
Content-Disposition: form-data; name="1_$ACTION_ID_4067cee7ffcfc30860beeb78f35dd3cec02d4084ac"
------WebKitFormBoundarydKf562tVKmAb3SAf
Content-Disposition: form-data; name="1_ping"
123
------WebKitFormBoundarydKf562tVKmAb3SAf
Content-Disposition: form-data; name="0"
["$K1"]
------WebKitFormBoundarydKf562tVKmAb3SAf--

[Response]
:N1766324207396.7583
0:{"a":"$@1","f":"","b":"development"}
1:D{"time":0.37404199999946286}
1:{"success":true,"ping":"123"}

서버는 이용자가 전달한 요청을 파싱하여 Server Action을 실행하고, 실행 결과를 Flight Protocol 형식으로 직렬화하여 클라이언트에 응답합니다. 아래는 Flight Protocol 파싱 로직을 수행하는 parseModelString() 함수입니다.

// <https://github.com/facebook/react/blob/88ee1f595572b1dcf8f45897cb115b4bbd1aefb8/packages/react-server/src/ReactFlightReplyServer.js#L1311-L1335>
function parseModelString(
  response: Response,
  obj: Object,
  key: string,
  value: string,
  reference: void | string,
): any {
  if (value[0] === '$') {
    switch (value[1]) {
      case '$': {
        // This was an escaped string value.
        return value.slice(1);
      }
      case '@': {
        // Promise
        const id = parseInt(value.slice(2), 16);
        const chunk = getChunk(response, id);
        return chunk;
      }
      case 'h': {
        // Server Reference
        const ref = value.slice(2);
        return getOutlinedModel(response, ref, obj, key, loadServerReference);
      }
      case 'T': {
      ...

아래 예시는 multipart/form-data 요청으로 두 개의 chunk를 전달한 것입니다. 첫 번째 chunk의 bar 필드는 $1:bar 형태의 참조를 포함하고, 이는 Flight Protocol에 따라 두 번째 chunk의 bar 필드를 가리킵니다.

------WebKitFormBoundaryv77gZrFCS37c0Dkg
Content-Disposition: form-data; name="0"
{"foo":"1","bar":"$1:bar"}
------WebKitFormBoundaryv77gZrFCS37c0Dkg
Content-Disposition: form-data; name="1"
{"test":1,"bar":"zz"}
------WebKitFormBoundaryv77gZrFCS37c0Dkg--

서버에서 Flight 응답을 역직렬화하는 과정에서 이 참조는 실제 값으로 해석되고, 최종적으로 아래와 같은 형태의 객체가 생성됩니다.

{ foo: "1", bar: "zz" }

하지만 이 참조 해석 과정에서 입력값에 대한 검증이 충분히 이루어지지 않기 때문에, 공격자가 Object prototype에 접근하여 prototype pollution을 발생시킬 수 있습니다. 예를 들어, 아래와 같이 요청을 전달할 경우, Flight Protocol의 참조 해석 과정에서 prototype chain을 따라 constructor.constructor에 접근하게 됩니다.

------WebKitFormBoundaryv77gZrFCS37c0Dkg
Content-Disposition: form-data; name="0"
{"foo":"1","bar":"$1:__proto__:constructor:constructor"}
------WebKitFormBoundaryv77gZrFCS37c0Dkg
Content-Disposition: form-data; name="1"
{}
------WebKitFormBoundaryv77gZrFCS37c0Dkg--

{ foo: "1", bar: [Function: Function] }

prototype pollution으로 임의 코드를 실행하는 방법을 살펴보겠습니다.

chunk 파싱 결과는 action-handler.ts 파일의 decodeReplyFromBusboy() 함수에서 반환하는 값으로 전달됩니다. Content Type이 Multipart일 경우[1], decodeReplyFromBusboy() 함수는 form data를 파싱[2]합니다.

// <https://github.com/vercel/next.js/blob/aab1edcb8d7a57a6f7a1637d0f87be84ea62edc8/packages/next/src/server/app-render/action-handler.ts#L867-L893>
// -- [1] 
if (isMultipartAction) {
  if (isFetchAction) {
    // A fetch action with a multipart body.
    const busboy = (
      require('next/dist/compiled/busboy') as typeof import('next/dist/compiled/busboy')
    )({
      defParamCharset: 'utf8',
      headers: req.headers,
      limits: { fieldSize: bodySizeLimitBytes },
    })
    // We need to use `pipeline(one, two)` instead of `one.pipe(two)` to propagate size limit errors correctly.
    pipeline(
      sizeLimitedBody,
      busboy,
      // Avoid unhandled errors from `pipeline()` by passing an empty completion callback.
      // We'll propagate the errors properly when consuming the stream.
      () => {}
    )
		// -- [2]
    boundActionArguments = await decodeReplyFromBusboy(
      busboy,
      serverModuleMap,
      { temporaryReferences }
    )
  }
  ...

이때 JavaScript의 await 연산자는 반환값이 Promise가 아니더라도 then property를 가진 객체를 thenable로 인식합니다. 즉, await value 구문에서 value.then이 함수로 존재할 경우, JavaScript 런타임은 이를 Promise처럼 취급하여 then 함수를 자동으로 호출합니다.

foo = {}
foo.then = function(resolve, reject) {
  resolve(1);
}
await foo
// output
// 1

결과적으로 공격자는 prototype pollution을 통해 then 함수를 주입함으로써, await 구문에서 임의 코드를 실행할 수 있습니다. 이에 대한 최종 payload는 공개된 React2Shell PoC에서 확인할 수 있습니다.

해당 취약점의 root cause는 이용자의 입력 값에 대한 검증 부재입니다. React는 7dc903cd29dac55efb4424853fd0442fef3a8700 커밋을 통해 ReactFlightReplyServer.js‎ 파일의 getOutlinedModel() 함수에서 참조 대상이 객체 자신의 property 인지 확인하도록 hasOwnProperty() 함수 기반 검증을 추가하였습니다. 패치에 대한 상세 설명은 React 블로그 및 Next.js 공식 보안 권고에서 확인할 수 있습니다.

이번 취약점은 서버와 클라이언트의 실행 경계가 흐려진 현대 웹 아키텍처에서 입력 해석과 실행 흐름을 연결하는 과정의 중요성을 보여줍니다. 특히 서버 측에서 이용자의 입력을 구조적으로 재조립하고 이를 실행 흐름에 반영하는 구조에서는, 기본적인 검증 부재가 직접적인 코드 실행으로 이어질 수 있기에 더욱 주의할 필요가 있습니다.

References

• https://www.wiz.io/blog/critical-vulnerability-in-react-cve-2025-55182

• https://github.com/lachlan2k/React2Shell-CVE-2025-55182-original-poc

• https://nextjs.org/blog/CVE-2025-66478

• https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components

마치며

2025년 하반기의 보안 사건들은 더 이상 보안이 조용히 시스템 뒤에서만 작동하는 문제가 아니라, 누구나 체감할 수 있는 현실적인 위험 요소로 드러났음을 보여주었습니다. 이전까지는 보안 사고가 일부 시스템이나 특정 조직 내부의 문제로 인식되었다면, 이제는 서비스 장애, 데이터 유출, 신뢰 붕괴와 같은 즉각적인 문제로 이어져 기업과 일반 대중 모두가 그 영향을 체감하게 되었습니다. 보안은 더 이상 “잘 돌아가고 있으니 괜찮은 것”이 아니라, 항상 조심하지 않으면 언제든 문제로 나타날 수 있는 영역이 되었습니다.

사건들을 통해 알 수 있듯이, 보안은 개별 기술의 문제가 아니라 연결된 구조 전체의 문제입니다. 보안은 사슬과 같아서, 가장 강한 부분이 아니라 가장 약한 고리만큼 안전합니다. 프레임워크, 오픈 소스, 내부 API, 테스트 환경, 자동화된 운영 과정과 같은 다양한 영역 중 어느 한 지점이라도 취약하다면, 그 지점이 곧 전체 시스템의 침투 경로가 됩니다. 공격자들은 가장 취약한 약한 고리를 집요하게 찾아내 활용하고 있습니다.

보안은 특정 솔루션이나 담당자의 책임으로 분리할 수 있는 문제가 아니라, 설계와 운영 전반에서 지속적으로 점검하고 조심해야 하는 기본 전제입니다. ‘지금의 시스템은 무엇을 신뢰하고 있는가’, ‘신뢰는 어떤 조건에서 깨질 수 있는가’, ‘그리고 그러한 상황에 대비해 어떤 구조와 기준을 준비해 두었는가’라는 질문에 답하지 못한다면, 보안 사고는 언제든 반복될 수 있습니다.

이번 한 해 동안 Frontier Squad 팀은 다양한 고객 환경에서의 시스템 점검과 침해사고 조사를 통해, 당장의 위협뿐만 아니라 잠재적인 위험 요소까지 고려하며 대응해 왔습니다. 2026년에도 이러한 경험을 토대로 활동을 지속하며, 새로운 기술과 위협 환경에 대한 사례 조사와 기술 연구를 바탕으로 실제 공격 시나리오와 운영 환경을 반영한 분석을 수행할 예정입니다. 이를 통해 보다 현실적이고 실행 가능한 대응 방향을 제시함으로써, 보안의 실질적인 향상에 기여하고자 합니다.

🔍 About Theori Frontier Squad

Theori의 Frontier Squad 팀은 실제 해커들의 공격 기법을 기반으로 고객의 서비스와 인프라를 진단하고, 현실적인 공격 시나리오를 바탕으로 보안의 사각지대를 발견하는 오펜시브 보안 전문 조직입니다. 설계 단계 위협 모델링부터 코드 수준의 취약점 리뷰, 실전 침투 테스트까지 다양한 방식으로 보안 문제를 발견하고 해결합니다. 우리는 공격자보다 한발 앞서 대응하고, 불가능해 보이는 문제를 기술적으로 해결하는 오펜시브 사이버보안의 리더로서, 더 안전한 디지털 세계를 만들고자 합니다.