요 며칠, 새벽에 잠이 깨서 폰으로 보안 알림을 확인하는 버릇이 생겼어요. 솔직히 말하면… “에이 설마 또?” 하면서도 손이 먼저 가더라구요. 그런데 이번 건은 좀 다릅니다. 오픈클로우(OpenClaw) 대규모 RCE 취약점(CVE-2026-25253) 악용이 실제로 커지고 있고, 감염 인스턴스에서 API 키 탈취가 퍼지고 있다는 정황까지 나왔거든요.
핵심은 하나예요. 🟥 기능 확장에만 속도를 내던 자율형 AI 프레임워크 생태계가 ‘보안 공백’을 그대로 드러냈다는 것.
1) 오픈클로우 RCE(CVE-2026-25253) 악용, “배포 72시간” 만에 터진 이유
오픈클로우는 원래 자동화·에이전트 기반 기능이 강점이라, 개발자 입장에선 “이거 되게 편하네?” 싶은 도구였어요. 그런데 편한 도구는 해커한테도 편합니다. 특히 원격 코드 실행(RCE) 급 취약점은, 말 그대로 외부에서 내 서버를 “내 집처럼” 쓰게 만드는 문이 될 수 있어요.
이번 이슈가 더 위험했던 이유는 속도입니다. 배포된 지 72시간 만에 심각한 결함들이 알려지고, 공격자들이 곧바로 악용에 들어갔죠. 공격이 빨라진 이유는 보통 이런 조건이 겹칠 때입니다.
- 기본 설정이 개발 편의 중심(인증·격리·권한 최소화가 약함)
- 자동 배포/설치 스크립트 구조가 넓은 권한으로 실행되기 쉬움
- 스캔 도구(Shodan류)로 노출 인스턴스를 빠르게 수집 가능
- “AI 프레임워크” 특성상 API 키·토큰이 앱 내부에 붙어 있을 확률이 높음
여기서 중요한 포인트 하나. 🟥 **RCE는 ‘취약점 하나’가 아니라 ‘침해의 시작점’**이에요. 한 번 들어오면 다음 단계는 거의 정해져 있습니다. 계정 토큰 훔치고, 키 뽑고, 옆으로 이동(lateral movement)하고, 결국 데이터 유출 또는 추가 악성코드 배포로 이어지죠. “그냥 테스트 서버인데요?” 하는 순간, 테스트 서버가 내부망으로 가는 다리가 되기도 하구요.
2) API 키 탈취가 위험한 진짜 이유: 계정이 아니라 ‘결제·권한·데이터’가 털린다 (테이블 포함)
이번 사례에서 특히 강조되는 게 API 키 유포입니다. 감염된 인스턴스가 3만 개 이상이라는 분석도 나왔고, 더 넓게 보면 기본 포트로 인터넷에 노출된 인스턴스가 31만 개 이상이라는 정황까지 언급됐죠. 숫자가 크면 뭐가 무섭냐면요… “자동화”가 붙습니다. 공격도 자동화되고, 키 수집도 자동화돼요.
API 키가 털렸을 때 피해는 단순 로그인 탈취를 넘어갑니다. 아래 표처럼요.
| 탈취 대상 | 공격자가 할 수 있는 일 | 실제로 터지는 문제 |
|---|---|---|
| 클라우드 API 키(AWS/GCP/Azure 등) | 리소스 생성, 스토리지 접근, 로그 삭제 시도 | 과금 폭탄, 데이터 유출, 증거 인멸 |
| AI 서비스 키(LLM API 등) | 무단 호출, 프롬프트 인젝션 연계, 정책 우회 시도 | 비용 급증, 내부 데이터 노출 가능성 |
| OAuth 토큰/세션 | 사용자 권한으로 API 호출, 계정 장악 | 관리자 권한 탈취, 조직 전체 확산 |
| Git/CI 토큰 | 코드 접근, 파이프라인 변조, 배포 악성화 | 공급망 공격으로 확장 |
| 앱 내 비밀값(.env 등) | DB 접속, 서드파티 연동 접근 | 고객정보·영업정보 유출 |
여기서 “아… 키만 바꾸면 되겠네?”라고 생각하기 쉬운데, 반만 맞습니다. 🟥 키를 바꾸기 전에 먼저 ‘침해 여부’를 확인해야 해요. 이미 공격자가 백도어를 심어둔 상태면, 키를 바꿔도 다시 털립니다. 그래서 순서는 보통 이렇게 가는 게 안전해요.
- 외부 노출 차단(방화벽/보안그룹) → 의심 프로세스/크론/서비스 점검 → 로그 확인 → 무결성 확인 → 그 다음 키 교체
3) ‘ClawHavoc’ 자동 배포 악용: 정상 설치 스크립트처럼 보이게 만드는 수법 (리스트 포함)
이번 공격에서 무서운 부분은, 사용자가 “속기 쉬운 흐름”으로 설계됐다는 겁니다. 예를 들어 ‘ClawHavoc’ 캠페인은 자동 배포 기능을 악용해 Atomic Stealer 같은 정보탈취형 페이로드를 정상 도구인 것처럼 위장해 배포했다고 해요. 개발자들은 설치 스크립트 실행에 익숙하잖아요. “문서에 적힌 대로” 했을 뿐인데, 그 순간부터 터지는 거죠.
실제로 이런 유형의 공격이 자주 쓰는 패턴은 다음과 같습니다.
- 설치 스크립트에 원격 다운로드 명령을 섞어 둠(curl/wget 등)
- 실행 권한/관리자 권한으로 돌게 유도(sudo, 서비스 등록)
- 실행 후 흔적 최소화(로그 삭제, 파일명 위장)
- 토큰·비밀번호·브라우저 저장정보 등 수집 후 외부 전송
- 추가 원격 제어(리버스 쉘 등)로 장기 거점화
체감상 제일 위험한 건 “그럴듯함”이에요. README가 그럴싸하고, 별표(star) 좀 있고, 설치가 잘 되면… 의심이 확 내려가거든요. 그래서 팀 단위로는 🟥 스크립트 실행을 기본 금지하고, 검증된 레포/해시/서명 기반으로만 설치하는 룰이 필요합니다. 귀찮아도요. 진짜로.
4) ClawHub 마켓플레이스 공급망 공격: “플러그인이 백도어가 되는 순간”
2월 초에는 ‘ClawHub’ 마켓플레이스를 악용해 백도어가 삽입된 가짜 스킬이 유포된 사례도 포착됐다고 합니다. 이게 왜 공급망 공격이냐면, 사용자는 “공식 생태계 안에서 받았다”고 믿기 때문이에요. 공격자는 그 신뢰를 이용해서 유통망 자체를 감염시킵니다.
이 방식이 특히 위험한 이유는 세 가지예요.
첫째, 설치 경로가 정상입니다. 다운로드 URL도, 설치 과정도 정상처럼 보여요.
둘째, 권한이 큽니다. AI 에이전트/프레임워크는 외부 API 접근이 넓고, 작업을 대신 수행하니 더더욱요.
셋째, 확산이 빠릅니다. 마켓플레이스는 “배포 채널”이라 업데이트/추천/복제 설치로 순식간에 퍼져요.
그리고 실제로 보고된 내용처럼, 이 유형은 OAuth 토큰·비밀번호를 실시간으로 탈취하고 원격 쉘 명령 실행까지 이어질 수 있습니다. 즉, 단순 정보유출이 아니라 “내 서버가 공격자 장비가 되는” 시나리오가 됩니다.
5) 31만 개 노출 인스턴스와 기본 포트 문제: “인증 없는 인터넷 노출”은 거의 즉시 발견된다 (테이블 포함)
기본 포트(예: 18789)를 그대로 쓰고, 인증 없이 노출된 인스턴스가 많았다는 정황은 진짜 아픈 지점이에요. 솔직히 말해 이런 건 공격자가 특별히 똑똑해서가 아니라, 검색엔진처럼 찾아주는 서비스가 많기 때문이죠. 노출돼 있으면 “언젠가”가 아니라 “곧” 발견됩니다.
그래서 실무에서는 아래처럼 “기본값 제거”를 최우선으로 둡니다.
| 위험 포인트 | 흔한 실수 | 바로 적용할 대응 |
|---|---|---|
| 기본 포트 유지 | 문서 그대로 운영 반영 | 포트 변경 + 접근 IP 제한 |
| 인증/토큰 미적용 | 내부 테스트라고 방심 | 최소한의 인증·ACL 적용 |
| 인터넷 직접 노출 | 편의상 0.0.0.0 바인딩 | 내부망/VPN/프록시 뒤로 이동 |
| 비밀값 평문 보관 | .env/설정파일 그대로 | Vault/Secret Manager로 분리 |
| 마켓플레이스 무검증 설치 | “공식이니까” 믿음 | 승인된 목록(allowlist)만 허용 |
보안 기본 원칙은 OWASP에서도 반복해서 강조합니다(특히 인증·권한·구성 관리).
🟦🔗 https://owasp.org/www-project-top-ten/
6) 지금 당장 해야 할 현실적인 대응 10가지 (리스트 포함)
“그래서 우리 팀은 뭘 해야 하죠?” 여기로 바로 가겠습니다. 아래는 오픈클로우뿐 아니라 유사한 자율형 AI 프레임워크 전반에 적용되는, 꽤 현실적인 체크리스트예요.
- 외부 노출 즉시 차단: 보안그룹/방화벽에서 18789 등 관련 포트 닫기
- 침해 지표(IOC) 탐지: 의심 프로세스, 신규 계정, 크론탭, 서비스 등록 확인
- 플러그인/스킬 전수 조사: 최근 설치/업데이트 목록부터 역추적
- 토큰·API 키 즉시 교체(단, 1~3번 먼저): LLM 키, 클라우드 키, Git 토큰 포함
- 권한 최소화: 운영키는 읽기/쓰기 분리, 필요 권한만 부여
- 격리 운영: AI 실행 환경을 업무망과 분리(별도 VPC/서브넷 권장)
- 아웃바운드 통제: 서버가 외부로 나가는 트래픽을 허용 목록 기반으로 제한
- 무결성 검증: 바이너리/스크립트 해시, 컨테이너 이미지 서명 확인
- 로그 보존/중앙화: 침해 후 로그 삭제 대비, SIEM/중앙 로그로 전송
- 배포 정책 재정의: “스크립트 한 줄 설치” 금지, 리뷰·승인·서명 기반 배포로 전환
여기까지 하면, 최소한 “한 번에 싹 털리는” 상황은 크게 줄어듭니다. 완벽은 없지만, 격리와 최소권한은 진짜로 효과가 커요.
FAQ
Q. 오픈클로우 RCE 취약점은 왜 이렇게 파급이 큰가요?
A. RCE는 공격자가 서버에서 임의 코드를 실행할 수 있어요. 거기에 AI 프레임워크는 API 키·토큰이 붙어 있을 확률이 높아서, 탈취→확산이 빠르게 이어집니다.
Q. API 키가 유출되면 가장 먼저 뭘 확인해야 해요?
A. 과금/로그인보다 먼저 침해 흔적을 확인하세요. 이미 백도어가 있으면 키를 바꿔도 재탈취됩니다.
Q. 마켓플레이스 기반 공급망 공격은 어떻게 막나요?
A. 플러그인/스킬은 허용 목록(allowlist), 서명/해시 검증, 코드 리뷰 없이는 설치하지 않는 게 안전합니다.
Q. “테스트 서버”도 이렇게 위험한가요?
A. 네. 테스트 서버는 보안 설정이 느슨해서 오히려 먼저 털립니다. 그리고 내부망으로 들어가는 발판이 되기 쉬워요.
Q. 우리 조직이 자율형 AI 프레임워크를 계속 써도 될까요?
A. 가능은 합니다. 다만 🟥 **설계 단계부터 보안(격리·권한·검증·로그)**을 기본값으로 바꿔야 해요. 기능보다 안전이 먼저입니다.
마무리: AI 도구는 “똑똑한 만큼” 더 위험해질 수 있다
이번 오픈클로우 사태는 한 프레임워크만의 문제가 아니라, 자율형 AI 에이전트 생태계 전체가 겪는 성장통에 가깝습니다. 기능은 빨리 늘었는데, 보안은 그 속도를 못 따라간 거죠.
혹시 지금 조직에서 AI 프레임워크를 PoC로라도 돌리고 있다면, 오늘 한 번만이라도 외부 노출·키 관리·마켓플레이스 설치 이력부터 확인해보세요. 작은 점검이 큰 사고를 막습니다.
댓글로 “우리도 비슷한 로그 봤다” 같은 경험 공유해주시면, 현장에서 쓸 수 있는 대응 팁으로 더 정리해서 올려볼게요.
