새로운 공격, OpenClaw AI 에이전트를 속여 코드 실행·비밀 유출
출처: The Hacker News
두 보안 팀이 이번 주에 발표한 별도 연구에서, 인기 있는 자체 호스팅 AI 에이전트인 OpenClaw가 평범해 보이는 입력을 통해 공격자가 제어하는 코드를 실행하거나 민감한 데이터를 넘겨줄 수 있음을 보여주었습니다.
Imperva는 공유 연락처, vCard, 위치 핀 안에 명령을 숨겨 에이전트가 피해자가 전혀 보지 못한 채 실행하도록 했습니다. Varonis에서는 플랫폼 위에 테스트 에이전트를 구축하고, 합성된 비즈니스 데이터가 가득한 메일함을 제공한 뒤, 단 한 통의 평범한 이메일이 가짜 AWS 키와 가짜 고객 내보내기 파일을 외부 주소로 전달하도록 만들었습니다.
Imperva가 발견한 결함은 OpenClaw 2026.4.23에서 패치되었으니, 사용 중이라면 업데이트하십시오. Varonis가 발견한 피싱 취약점은 패치만으로 해결되지 않으며, 에이전트가 스스로 할 수 있는 행동을 제한하는 것이 핵심입니다.
같은 방에 들어가는 다른 문: 에이전트는 자신에게 도달하는 정보를 신뢰하고, 그 접근 권한이 공격자에게 넘어갑니다.
공유 연락처에 숨겨진 명령
Imperva 연구원 Yohann Sillam은 OpenClaw가 메시지 데이터를 뒤에 있는 모델에 어떻게 전달하는지 살펴보았습니다. 문제는 파이프라인에 있습니다.
에이전트가 공유 연락처, vCard, 혹은 위치 정보를 LLM에 전달할 때, 해당 객체를 프롬프트 텍스트 안에 그대로 평탄화(flatten)하고, 신뢰할 수 없다는 경계 표시를 하지 않습니다. 웹에서 가져온 콘텐츠는 “신뢰할 수 없는 콘텐츠” 마커로 감싸지만, 메시지 객체는 그렇지 않습니다.
모델에 전달되는 필드는 일부에 불과하며, 바로 그 부분을 공격자가 악용합니다. 공유 연락처는 이름 필드만 전송하고, 이는 <와 > 같은 각괄호가 이름에 허용되기 때문에 모델이 실제 이름과 삽입된 명령어의 경계를 구분하지 못합니다. 연락처 이름은 화면에 표시될 때 잘려 보이므로, 피해자는 페이로드를 전혀 보지 못합니다.
WhatsApp이 기본적으로 지원하는 vCard의 full-name 필드와 공유 위치 핀의 라벨에서도 동일한 트릭이 통합니다.
Imperva가 Gemini 3.1 Pro(프리뷰 빌드)를 대상으로 수행한 테스트에서, 숨겨진 텍스트는 에이전트에게 연구진이 제어하는 서버에서 스크립트를 다운로드하고 실행하도록 지시했습니다. 에이전트는 그대로 실행했습니다. 이미지에 명령을 숨긴 경우는 실패했는데, 이는 해당 공격이 너무 많이 보고돼 모델이 이미 방어하도록 학습되었기 때문으로 보입니다. 메시지 객체 경로가 성공한 이유는 모델이 아직 해당 패턴을 충분히 학습하지 못했기 때문입니다.
OpenClaw의 메모리가 기본적으로 켜져 있는 경우, Imperva는 널리 공유된 단일 콘텐츠에 숨겨진 명령이 포함돼 있으면, 샌드박스가 적용되지 않은 에이전트가 조용히 타협될 수 있다고 경고합니다.
Imperva는 이 문제를 공개했고, OpenClaw는 2026.4.23 버전에서 연락처 이름, vCard 필드, 위치 라벨을 프롬프트 본문이 아닌 별도의 “신뢰할 수 없는 메타데이터” 채널로 이동시키는 패치를 배포했습니다. Imperva는 동일한 평탄화 패턴을 다른 개인 AI 어시스턴트에서도 발견했으며, 근본적인 문제는 OpenClaw에만 국한된 것이 아니라는 점을 강조했습니다.
평범한 이메일 하나만 있으면 충분
Varonis Threat Labs는 사회공학적 관점에서 OpenClaw을 조사했습니다. Itay Yashar가 이끄는 연구팀은 플랫폼 위에 Pinchy 라는 에이전트를 구축하고, 현실적인(하지만 합성된) 비즈니스 잡동사니와 가짜 비밀 정보가 들어 있는 Gmail 인박스를 연결한 뒤, Google Gemini 3.1 Pro와 OpenAI Codex GPT‑5.4를 대상으로 네 차례의 피싱 시뮬레이션을 진행했습니다.
그들은 데이터를 통해 명령을 숨기는 “프롬프트 인젝션”과, 정상적인 채널을 통해 도착하고 에이전트가 발신자를 확인하기 전에 동작하는 “에이전트 피싱”을 구분했습니다.
에이전트는 두 가지 탈취 테스트 모두에서 실패했습니다. 첫 번째 시나리오에서는 외부 Gmail 주소에서 온 팀 리드 “Dan”이라는 인물이 가짜 프로덕션 사고 중에 스테이징 접근 권한을 요청했습니다. Pinchy는 해당 자격 증명을 찾아내어 가짜 AWS IAM 액세스 키, 데이터베이스 연결 문자열, SSH 자격 증명을 평문으로 전달했습니다.
](