보안 사건 분석 보고서 #

1. 사건 개요 #

사건 명칭 #

Metro4Shell - React Native Metro Server 원격 코드 실행 취약점 공격

발생 시기 #

• 취약점 공개: 2025년 11월 (JFrog)
• 실제 공격 첫 관측: 2025년 12월 21일
• 지속적 공격 확인: 2026년 1월 4일, 1월 21일
• CISA KEV 등록: 2026년 2월 5일

피해 대상 #

React Native 개발 환경을 사용하는 개발자 및 조직

공격자 #

신원 미상의 금전적 동기를 가진 공격자로 추정

CVE 정보 #

CVE-2025-11953, CVSS 점수 9.8

2. 사건 상세 분석 #

취약점 메커니즘 #

React Native의 Metro Development Server는 JavaScript 번들링 및 개발 서버로 개발 및 테스트 단계에서 필수적으로 사용되는 도구이다. 취약점은 Metro 서버의 /open-url 엔드포인트에서 발생했으며, 사용자가 제어 가능한 데이터를 검증 없이 직접 unsafe open() 함수에 전달하는 부적절한 입력 검증 문제가 원인이다.

Metro 서버는 기본적으로 모든 네트워크 인터페이스(0.0.0.0)에 바인딩되지만, 사용자에게는 localhost:8081 메시지를 표시하여 오해를 유발한다. 이러한 기본 설정은 같은 네트워크상의 공격자가 취약한 엔드포인트에 접근할 수 있게 만든다.

공격 프로세스 #

공격자는 특수하게 조작된 HTTP POST 요청을 Metro 서버의 /open-url 엔드포인트로 전송하여 임의의 운영체제 명령을 실행할 수 있다. Windows 시스템에서는 명령 인젝션을 통한 임의 코드 실행이 가능하며, Linux 및 macOS에서는 제한적인 매개변수 제어로 악성 실행 파일을 실행할 수 있다.

VulnCheck의 허니팟 네트워크에서 관측된 실제 공격은 다단계 PowerShell 기반 로더를 사용했다. 공격은 cmd.exe를 통해 Base64로 인코딩된 페이로드를 전달했으며, 디코딩된 스크립트는 다음과 같은 순서로 작동했다.

첫 번째 단계에서 Add-MpPreference cmdlet을 사용하여 현재 작업 디렉토리와 Windows 임시 디렉토리에 대한 Microsoft Defender 제외 경로를 추가하여 엔드포인트 보안을 우회했다. 두 번째 단계에서는 공격자가 제어하는 인프라로 원시 TCP 연결을 설정하고 GET /windows 요청을 발행하여 다음 단계 페이로드를 다운로드했다.

영향 범위 #

@react-native-community/cli npm 패키지의 버전 4.8.0부터 20.0.0-alpha.2까지 영향을 받으며, 수천 개의 인터넷 접근 가능한 React Native 인스턴스가 위험에 노출된 것으로 확인되었다.

Windows와 Linux 모두에서 고급 페이로드가 배포되었으며, 이는 Metro4Shell이 실용적인 크로스 플랫폼 초기 접근 메커니즘을 제공한다는 것을 보여준다.

3. 근본 원인 분석 #

기술적 원인 #

입력 검증 부재가 가장 직접적인 기술적 원인이다. /open-url 엔드포인트가 사용자 제공 데이터를 sanitization 없이 unsafe 함수에 직접 전달하는 설계 결함이 존재했다.

기본 네트워크 바인딩 설정의 오류도 문제였다. Metro 서버가 0.0.0.0에 바인딩되면서도 localhost로 표시되는 오해의 소지가 있는 UI는 개발자에게 잘못된 보안 인식을 제공했다.

개발 환경 도구에 대한 인증 메커니즘 부재도 근본 원인 중 하나다. /open-url 엔드포인트가 인증 없이 접근 가능하도록 설계되었다.

관리적 원인 #

개발 인프라에 대한 보안 모니터링 부족이 주요 관리적 원인이다. 개발 환경은 프로덕션 환경에 비해 상대적으로 낮은 보안 우선순위를 받았다.

패치 관리 프로세스의 지연도 문제였다. 취약점이 2025년 11월 공개되었지만, 2026년 1월까지도 많은 조직이 패치를 적용하지 않았다.

위험 평가 프로세스의 한계도 존재했다. EPSS 시스템이 2026년 1월 말까지도 0.00405의 낮은 확률을 할당하여 실제 공격 활동과 이론적 위험 모델 간의 위험한 괴리가 발생했다.

인적 원인 #

개발자의 보안 인식 부족이 인적 원인으로 작용했다. 많은 개발자가 Metro 서버가 로컬 네트워크에만 바인딩된다고 잘못 인식했다.

개발 편의성 우선 문화도 문제였다. 보안보다 개발 속도와 편의성을 우선시하는 조직 문화가 취약점을 방치하는 요인이 되었다.

4. 학습 포인트 #

개발 인프라의 보안 중요성 #

개발 인프라는 도달 가능한 순간부터 프로덕션 인프라가 된다는 인식이 필요하다. 개발 도구라는 의도와 관계없이, 네트워크 접근이 가능한 순간 공격 대상이 된다.

개발자 워크스테이션은 소스 코드, 자격 증명, API 키, 프로덕션 인프라 접근 권한을 포함하는 경우가 많아 측면 이동을 위한 이상적인 목표가 된다. 그러나 프로덕션 시스템에 비해 상대적으로 보호 수준이 낮은 경우가 많다는 점에서 보안 격차가 발생한다.

위험 평가 모델의 한계 #

EPSS와 같은 이론적 위험 점수 시스템은 실제 공격 활동을 반영하지 못할 수 있다. 2025년 12월부터 실제 공격이 관측되었지만, 2026년 1월 말까지도 EPSS는 0.00405라는 낮은 점수를 유지했다.

공격자는 KEV 목록이나 벤더 요약을 기다리지 않는다. PoC 코드가 존재하고 스캐닝이 가능해지면 공격이 빠르게 이어진다. 개념 증명 코드 공개 후 단 며칠 만에 실제 공격이 시작되었다는 점이 이를 증명한다.

기본 설정의 위험성 #

안전하지 않은 기본 설정은 심각한 보안 위험을 초래한다. Metro 서버가 0.0.0.0에 바인딩되지만 localhost 메시지를 표시하는 것은 개발자에게 잘못된 보안 인식을 제공했다.

보안은 기본값이어야 하며, 편의성은 명시적인 선택이어야 한다. 기본적으로 127.0.0.1에 바인딩하고, 외부 접근이 필요한 경우 명시적인 설정을 요구하는 방식이 더 안전하다.

탐지 지연의 위험 #

공격이 2025년 10월에 발생했지만 2026년 2월까지 광범위한 인식이 없었다는 점은 탐지 지연의 심각성을 보여준다. 초기 공격 탐지와 광범위한 인식 사이의 격차가 방어자가 준비되지 않은 상태로 남아있게 만드는 지점이다.

개발자 도구에 대한 모니터링과 로깅이 부족한 경우가 많아, 공격이 발생해도 즉시 탐지되지 않는다. 개발 환경에 대한 적절한 모니터링 체계 구축이 필요하다.

5. 예방 및 완화 전략 #

즉각적 조치 #

@react-native-community/cli-server-api를 버전 20.0.0 이상으로 업데이트해야 한다. 모든 개발자 머신과 CI/CD 파이프라인에서 강제 적용이 필요하다.

Metro를 127.0.0.1(localhost)에만 바인딩하도록 구성해야 한다. 0.0.0.0 바인딩을 방지하여 네트워크를 통한 서버 접근을 차단한다.

네트워크에 노출된 포트를 식별하기 위한 내부 스캐닝을 수행해야 한다. 8081(기본 Metro 포트), 3000, 3001, 8080을 네트워크에 노출하는 개발자 머신을 찾아내야 한다.

중장기 대책 #

개발자 워크스테이션에서 알려지지 않은 외부 IP로의 원시 TCP 포트 아웃바운드 연결을 차단하는 이그레스 필터링을 구현해야 한다. Metro4Shell 캠페인은 원시 TCP를 통해 2단계 페이로드를 가져오는 능력에 의존한다.

EDR 솔루션을 구성하여 설명된 공격 체인과 일치하는 PowerShell 또는 bash 실행 패턴에 대해 경고하도록 설정해야 한다. 식별된 파일 해시의 존재도 모니터링해야 한다.

개발 환경에 대한 네트워크 세분화를 구현하여, 공격자가 개발자 머신에서 프로덕션 환경으로 쉽게 이동하지 못하도록 해야 한다.

정기적인 취약점 스캐닝 및 패치 관리 프로세스를 개발 도구에도 적용해야 한다. 프로덕션 시스템과 동일한 수준의 보안 관리가 필요하다.

개발자 보안 교육 프로그램을 강화하여, 개발 도구의 보안 설정 중요성과 기본 설정의 위험성에 대한 인식을 높여야 한다.

6. 컨설팅 관점 적용 #

경영진 보고 #

개발 환경 보안 투자의 필요성을 경영진에게 전달해야 한다. 개발자 워크스테이션 침해가 소스 코드 유출, 자격 증명 탈취, 프로덕션 시스템 접근으로 이어질 수 있는 비즈니스 리스크를 강조한다.

Metro4Shell 사례를 들어, 취약점 공개 후 단 며칠 만에 공격이 시작되었고, 수개월간 탐지되지 않았다는 점을 설명하여 신속한 패치 관리의 중요성을 강조한다.

기술팀 커뮤니케이션 #

기술팀에게는 구체적인 기술적 세부사항과 완화 조치를 제공한다. 네트워크 바인딩 설정 변경, 버전 업데이트, 포트 스캐닝 절차 등 실행 가능한 단계별 지침을 전달한다.

개발 편의성과 보안의 균형을 맞추는 방법을 논의하여, 보안 조치가 개발 속도를 크게 저하시키지 않으면서도 효과적으로 적용될 수 있도록 한다.

보안팀 가이드 #

보안팀에게는 개발 환경 모니터링 체계 구축의 중요성을 강조한다. EDR 솔루션 구성, 네트워크 트래픽 모니터링, 이상 행위 탐지 규칙 설정 등 구체적인 보안 통제 방안을 제시한다.

위협 인텔리전스 피드를 활용하여 실제 공격 활동과 PoC 공개를 조기에 탐지하고 대응하는 프로세스를 수립하도록 권고한다.

7. 예상 질의응답 #

Q1: 우리 조직도 영향을 받나요? #

React Native를 사용하는 개발 프로젝트가 있는지 확인이 필요합니다. 특히 @react-native-community/cli 패키지의 버전을 확인하여 4.8.0부터 20.0.0-alpha.2 사이의 버전을 사용하는 경우 즉시 업데이트해야 합니다. 개발자 워크스테이션에서 8081 포트가 네트워크에 노출되어 있는지 확인하는 것도 중요합니다.

Q2: 개발 환경은 왜 보안이 중요한가요? #

개발 환경은 소스 코드, API 키, 데이터베이스 자격 증명, 프로덕션 시스템 접근 권한 등 민감한 자산을 포함합니다. 공격자가 개발 환경을 침해하면 이러한 자산을 탈취하고 프로덕션 환경으로 측면 이동할 수 있습니다. Metro4Shell 사례는 개발 도구가 도달 가능한 순간부터 공격 표면이 된다는 것을 보여줍니다.

Q3: EPSS 점수가 낮은데 왜 긴급한가요? #

EPSS는 이론적 모델이며 실제 공격 활동을 항상 정확하게 반영하지는 못합니다. Metro4Shell의 경우 2025년 12월부터 실제 공격이 관측되었지만 2026년 1월까지도 EPSS 점수는 0.00405로 낮게 유지되었습니다. PoC 코드가 공개되고 실제 공격이 관측되는 경우, EPSS 점수와 관계없이 즉시 대응해야 합니다.

Q4: 패치 적용이 어려운 경우 대안은? #

패치가 최선의 조치이지만, 즉시 적용이 어려운 경우 Metro 서버를 127.0.0.1에만 바인딩하도록 설정하고, 네트워크 방화벽 규칙으로 8081 포트를 차단하며, EDR/XDR 솔루션에서 PowerShell 기반 공격 패턴을 모니터링하는 임시 완화 조치를 적용할 수 있습니다. 그러나 이는 임시 조치이며 가능한 빨리 패치를 적용해야 합니다.

Q5: 이미 침해당했는지 어떻게 확인하나요? #

EDR 로그에서 Add-MpPreference cmdlet 실행, 알려지지 않은 외부 IP로의 원시 TCP 연결, cmd.exe 또는 PowerShell을 통한 Base64 인코딩된 명령 실행 등의 흔적을 찾아야 합니다. Metro 서버 로그에서 /open-url 엔드포인트로의 의심스러운 POST 요청도 확인해야 합니다. VulnCheck 보고서에 명시된 특정 파일 해시와 IP 주소(8.218.43.248:60124)도 조사해야 합니다.

8. 결론 #

Metro4Shell 사건은 개발 인프라 보안의 중요성을 명확히 보여주는 사례다. 개발 도구는 프로덕션이 아니라는 인식이 널리 퍼져 있지만, 네트워크 접근이 가능한 순간부터 공격 표면이 된다는 사실을 인식해야 한다.

특히 주목할 점은 취약점 공개와 실제 공격 사이의 시간 간격이 매우 짧다는 것이다. 2025년 11월 공개 후 단 며칠 만에 12월 21일 첫 공격이 관측되었으며, 이후 수개월간 지속적인 공격이 이어졌다. 반면 EPSS와 같은 이론적 위험 평가 시스템은 실제 공격 활동을 제대로 반영하지 못했다.

이 사건은 조직이 개발 환경에 프로덕션 수준의 보안 통제를 적용하고, 실시간 위협 인텔리전스를 활용하며, 신속한 패치 관리 프로세스를 구축해야 함을 시사한다. 안전한 기본 설정, 적절한 모니터링, 지속적인 보안 교육이 개발 인프라 보안의 핵심 요소다.