[CVE] CVE-2026-47137

주의: 이 글은 AI 자동 작성되었습니다. 반드시 재검증해야 합니다. 내용의 오류가 있을 경우 댓글 작성 부탁드립니다.

핵심 요약

CVE-2026-47137은 Node.js용 vm/sandbox 라이브러리인 vm2에서 발생한 보안 문제로, nesting: true와 require: false 조합을 막기 위해 추가된 방어 로직이 require 옵션의 부재를 제대로 처리하지 못하면서 우회되는 취약점입니다. 설명상 이 문제는 options.require === false 같은 엄격한 비교에 의존해, 아예 require 옵션을 생략한 경우를 방어하지 못합니다. 그 결과 패치가 의도했던 차단 조건이 무력화되고, 다시 위험한 구성으로 이어질 수 있습니다.

공개된 메트릭은 CVSS 3.1 10.0(CRITICAL)이며, 네트워크를 통한 공격 가능성, 낮은 공격 복잡도, 권한 불요, 사용자 상호작용 불요, 그리고 기밀성/무결성/가용성 모두에 높은 영향을 시사합니다. 다만 실제 공격 가능 범위나 익스플로잇 존재 여부는 이 데이터만으로 단정할 수 없어 확인 필요입니다.

기술 배경

vm2는 Node.js 환경에서 코드 실행을 격리하기 위한 sandbox로 사용됩니다. 이런 구성 요소는 외부 입력을 실행하거나 플러그인, 템플릿, 스크립트 같은 동적 코드를 다룰 때 자주 등장하며, 한 번 우회되면 단순한 애플리케이션 오류를 넘어 런타임 격리 자체가 무너질 수 있습니다.

제공된 설명에 따르면, 이전 취약점인 GHSA-8hg8-63c5-gwmx(CVE-2023-37903)의 수정 과정에서 nesting: true와 require: false의 결합을 차단하는 체크가 nodevm.js에 추가되었습니다. 그런데 이 체크가 options.require === false처럼 엄격한 동일성 비교에 의존해, require를 명시하지 않은 경우를 놓쳤습니다. 이후 구조 분해 할당의 기본값으로 requireOpts = false가 적용되면서, 방어 코드가 막으려던 정확한 상태가 다시 만들어집니다.

이런 유형은 단순한 입력 검증 실수처럼 보이지만, 실제로는 보안 경계의 전제 조건을 깨뜨리는 문제입니다. 특히 옵션 기반 보안 정책은 “명시적으로 거부된 값”뿐 아니라 “미지정 상태”도 보수적으로 다뤄야 하는데, 이번 사례는 그 경계 처리의 허점을 보여줍니다.

공격자 관점에서 볼 부분

공격자 입장에서는 이 취약점이 “금지되어야 할 조합이 설정 누락만으로 다시 활성화되는가”에 초점이 맞춰집니다. 즉, 보안 제어가 특정 값의 존재 여부만 보고 동작한다면, 옵션을 생략하는 방식으로 방어를 우회할 가능성을 먼저 보게 됩니다.

또한 설명상 문제의 핵심은 별도의 복잡한 입력 조작이 아니라 구성 차원의 우회입니다. 이런 경우 공격 성공 여부는 개별 호출 경로에서 require가 어떻게 전달되는지, 상위 코드가 기본값을 강제하는지, 그리고 해당 sandbox가 어떤 방식으로 외부 코드 실행과 결합되는지에 따라 달라집니다. 따라서 공격자는 단순히 라이브러리 버전만 보는 것이 아니라 실제 사용 방식과 설정 흐름을 함께 살필 가능성이 높습니다.

다만 공개 익스플로잇 신호는 확인되지 않았으므로, 현재 단계에서 실제 악용 난이도나 광범위한 악용 여부는 확인 필요입니다.

영향 범위

제공된 데이터 기준으로 영향받는 제품은 vm2입니다. 구체적으로는 3.11.4 이전 버전에 취약점이 존재하며, 3.11.4에서 패치되었다고 명시되어 있습니다.

다만 세부 영향은 vm2를 직접 사용하는 애플리케이션뿐 아니라, vm2를 내부적으로 포함해 코드 실행 격리를 맡기는 제품이나 서비스에서도 나타날 수 있습니다. 특히 사용자 제공 스크립트, 샌드박스 실행, 플러그인 실행, 테스트 격리 같은 기능이 있다면 우선 점검 대상이 됩니다.

정확한 배포판별 영향 여부나 실제 노출 조건은 제공 데이터만으로는 판단하기 어렵습니다. 따라서 환경별 적용 방식은 확인 필요입니다.

대응 및 패치

공식 설명상 수정은 vm2 3.11.4에 반영되었습니다. 따라서 가장 직접적인 대응은 해당 버전 이상으로 업그레이드하는 것입니다.

버전 업그레이드가 즉시 어렵다면, 최소한 nesting: true와 require 관련 설정이 결합되는 경로를 면밀히 점검해야 합니다. 특히 require 옵션을 명시하지 않았을 때도 안전한 값으로 해석되는지, 상위 코드에서 기본 설정을 일관되게 강제하는지 확인이 필요합니다.

운영 환경에서는 샌드박스를 신뢰 경계로 가정하지 말고, 외부 입력이 들어가는 실행 경로를 분리하는 것이 중요합니다. 또한 패치 이후에도 의존성 트리 어딘가에 구버전 vm2가 남아 있으면 보호 효과가 반감될 수 있으므로, 직접 참조뿐 아니라 간접 참조도 함께 점검해야 합니다.

메모

이 취약점은 “엄격한 비교” 자체의 문제가 아니라, 보안 정책이 다뤄야 할 상태 공간을 완전히 포착하지 못한 점에 가깝습니다. false와 undefined는 코드 관점에서는 다른 값이지만, 보안 관점에서는 둘 다 “허용되지 않은 상태” 혹은 “명시되지 않은 상태”로 취급해야 하는 경우가 많습니다.

또한 설명된 흐름은 이전 패치가 도입한 방어가 새로운 입력 상태를 놓치면서 사실상 우회 가능한 형태가 되었다는 점에서, 반복되는 수정과 우회가 발생하기 쉬운 취약점 유형임을 보여줍니다. 샌드박스/격리 계층은 한 번의 패치로 끝나지 않고, 설정 조합 전체를 보수적으로 다시 검토해야 합니다.

참고 링크