2026년 2월 4일, 보안 연구원 @mxsec가 OpenClaw에서 Critical 등급의 원격 코드 실행 취약점을 공개했다. CVE-2026-0847로 등록된 이 취약점은 CVSS 점수 9.8 — 거의 최고 수준의 심각도를 받았다. 공격 시나리오는 단순했다: 악성 스킬이 OpenClaw의 스킬 실행 엔진의 입력 검증 부재를 악용하여 호스트 운영체제에서 임의의 코드를 실행할 수 있었다.
이 취약점이 공개된 지 48시간 내에, Shodan 스캔에서 인터넷에 노출된 OpenClaw 인스턴스 중 약 3,200개가 패치되지 않은 상태임이 확인되었다. 일부 보안 연구자들은 이미 야생에서 익스플로잇 시도를 관찰했다고 보고했다.
RCE 취약점의 기술적 세부사항
OpenClaw의 스킬 시스템은 JavaScript 코드를 런타임에 동적으로 평가한다. 사용자가 설치하는 스킬은 본질적으로 OpenClaw 프로세스 내에서 실행되는 코드 조각이다. 문제는 이 실행이 어떤 샌드박스도 없이 이루어진다는 점이다.
CVE-2026-0847의 핵심은 스킬의 매개변수 처리에 있었다. 스킬이 사용자 입력을 받을 때, OpenClaw는 입력을 문자열로 처리하는 대신 JavaScript 표현식으로 평가하는 경로가 있었다. 공격자는 이를 통해 require('child_process').exec() 같은 호출을 주입할 수 있었다.
더 심각한 문제는 OpenClaw의 프로세스 모델이다. 스킬 코드가 메인 OpenClaw 프로세스와 같은 Node.js 런타임에서 실행되기 때문에, 스킬은 OpenClaw가 접근할 수 있는 모든 것에 접근할 수 있었다 — 파일 시스템, 네트워크, 환경 변수, 그리고 다른 스킬의 데이터까지.
이것은 단일 취약점이 아니라 아키텍처적 문제였다. eval() 취약점을 패치하더라도, 스킬이 같은 프로세스에서 실행되는 한 유사한 공격 벡터는 계속 존재한다. 공유 프로세스 모델에서는 하나의 악성 컴포넌트가 전체 시스템을 장악할 수 있다.
실제 공격 시나리오
이 취약점이 야생에서 어떻게 악용될 수 있는지 이해하기 위해 몇 가지 시나리오를 살펴보자.
첫 번째 시나리오는 악성 스킬 배포다. 공격자가 유용해 보이는 스킬을 ClawHub에 게시한다 — 예를 들어 "고급 날씨 위젯" 같은 것이다. 사용자가 이를 설치하면, 스킬은 표면적으로는 날씨 정보를 제공하면서 백그라운드에서 호스트 시스템의 SSH 키, 환경 변수, 브라우저 쿠키를 외부 서버로 전송한다.
두 번째 시나리오는 프롬프트 인젝션을 통한 기존 스킬 악용이다. 악성 웹페이지에 숨겨진 지시문이 에이전트를 통해 스킬의 매개변수로 전달되고, 이것이 코드 실행으로 이어진다. 사용자는 단순히 "이 웹페이지를 요약해줘"라고 요청했을 뿐인데, 결과적으로 시스템이 침해된다.
세 번째 시나리오는 공급망 공격이다. 인기 있는 스킬의 의존성 중 하나가 탈취되어, 업데이트를 통해 악성 코드가 주입된다. 수천 명의 사용자가 정상적인 업데이트로 알고 악성 코드를 설치하게 된다.
NanoClaw의 컨테이너 격리가 RCE를 무력화하는 방법
NanoClaw에서는 이 세 가지 시나리오 모두 구조적으로 불가능하다. 그 이유는 단순하다: 에이전트 코드가 호스트 시스템에서 실행되지 않는다.
NanoClaw의 모든 에이전트 실행은 Linux 컨테이너 안에서 이루어진다. macOS에서는 Apple Container, Linux에서는 Docker를 사용한다. 컨테이너는 자체 파일 시스템, 자체 프로세스 공간, 자체 네트워크 스택을 가진다. 에이전트가 컨테이너 안에서 무엇을 하든 — 심지어 악성 코드를 실행하더라도 — 그 영향은 해당 컨테이너에 격리된다.
구체적으로 살펴보면:
파일 시스템 격리. 컨테이너에는 명시적으로 마운트된 디렉토리만 접근 가능하다. 프로젝트 소스는 읽기 전용으로 마운트되고, 쓰기 가능 경로는 해당 그룹에 한정된다. 호스트의 홈 디렉토리, SSH 키, 브라우저 데이터는 컨테이너에서 보이지 않는다.
프로세스 격리. 컨테이너 안의 프로세스는 호스트의 프로세스를 볼 수 없다. 호스트에서 실행 중인 다른 서비스를 발견하거나 접근할 방법이 없다.
네트워크 격리. 각 컨테이너는 자체 네트워크 네임스페이스를 가진다. 로컬 네트워크 스캐닝이 불가능하고, 다른 컨테이너와의 통신도 차단된다. 아웃바운드 HTTPS만 허용된다.
시크릿 보호. API 키는 stdin을 통해 JSON 페이로드로 전달되며, 환경 변수나 파일 시스템에 노출되지 않는다. 컨테이너가 침해되더라도 API 키를 추출할 수 없다.
이러한 격리는 애플리케이션 수준의 보안 검사가 아니라 운영체제 커널이 시행한다. 버그가 있을 수 있는 입력 검증 코드에 의존하는 것이 아니라, 수십 년간 검증된 컨테이너 기술에 의존한다.
패치의 한계
OpenClaw는 CVE-2026-0847에 대한 패치를 48시간 내에 배포했다. 하지만 이 패치는 특정 eval() 경로를 차단하는 것이지, 근본적인 아키텍처 문제를 해결하는 것이 아니다.
같은 프로세스 모델을 유지하는 한, 새로운 RCE 벡터가 발견될 가능성은 항상 존재한다. 이것은 특정 버그의 문제가 아니라 아키텍처의 문제다. 입력 검증을 아무리 강화해도, 서드파티 코드가 메인 프로세스에서 실행되는 한 완전한 격리는 불가능하다.
NanoClaw의 접근 방식은 다르다. 에이전트 코드가 무엇을 하든 — 의도적이든 실수든 악의적이든 — 피해 범위는 단일 컨테이너로 제한된다. 컨테이너는 대화 턴이 끝나면 해체된다. 이것은 패치가 아니라 설계다. 취약점을 하나씩 막는 게임을 할 필요가 없다 — 아키텍처 자체가 피해 범위를 제한한다.
보안은 기능이 아니라 아키텍처다
CVE-2026-0847 사건의 가장 중요한 교훈은 이것이다: AI 에이전트의 보안은 기능 목록에 추가하는 항목이 아니라 아키텍처의 근본 속성이어야 한다.
OpenClaw는 스킬 검증, 코드 서명, 마켓플레이스 리뷰 같은 보안 기능을 가지고 있었다. 하지만 공유 프로세스 모델이라는 아키텍처적 결정이 이 모든 기능을 무력화했다. 검문소를 아무리 많이 세워도, 일단 통과하면 모든 곳에 갈 수 있다면 의미가 없다.
NanoClaw는 반대 방향에서 접근한다. 보안 기능을 쌓는 대신, 피해 범위를 제한하는 아키텍처를 채택했다. 컨테이너 안에서 무슨 일이 일어나든 밖에는 영향이 없다. 이것은 RCE 취약점뿐 아니라, 아직 발견되지 않은 미래의 공격 벡터에 대해서도 효과적이다.
보안 커뮤니티에서는 이를 "심층 방어"라 부른다. 하지만 NanoClaw의 경우 그보다 정확한 표현이 있다: 피해 불가능한 아키텍처. 공격 표면이 애초에 존재하지 않으면, 패치할 것도 없다.