오픈클로 2026.5.26 업데이트와 SSRF | 보안 취약점 정리와 대응 방법

오픈클로(OpenClaw)는 텔레그램, 디스코드, 아이메시지, 왓츠앱, 시그널, 웹챗, 음성 통화, 로컬 셸, 그리고 다양한 모델 제공자(provider)를 하나로 묶어주는 자율형 AI 에이전트 플랫폼이다. 단순히 텍스트로 답하는 챗봇과 달리, 파일을 읽고 웹페이지를 탐색하고 미디어를 처리하며 실제 작업을 자동으로 수행한다. 이렇게 에이전트가 사용자의 실제 워크플로에 깊숙이 연결될수록 작은 보안 틈이 큰 사고로 번질 수 있다.

2026년 5월 26일(공식 릴리즈 태그 기준 2026.5.26, 발표일 5월 27일) 업데이트는 표면적으로는 게이트웨이 속도 개선과 트랜스크립트(대화 기록) 처리 강화가 헤드라인이지만, 운영자 관점에서 가장 주목해야 할 부분은 SSRF를 포함한 보안 경계 강화다. 이 업데이트는 새로운 기능을 화려하게 추가했다기보다, 에이전트가 외부 콘텐츠를 신뢰하는 방식 자체를 더 안전하게 다듬은 성숙기 릴리즈에 가깝다.

이 문서에서는 SSRF가 정확히 무엇이고 AI 에이전트에서 왜 특히 위험한지, 2026.5.26 업데이트가 어떤 보안 구멍을 막았는지, 그리고 오픈클로를 둘러싼 실제 CVE 사례와 운영자가 지금 당장 취해야 할 대응을 정리한다. 클라우드 환경에서 운영 중이라면 더더욱 흘려보내서는 안 되는 내용이다.

1. SSRF란 무엇이고 AI 에이전트에서 왜 위험한가

SSRF는 Server-Side Request Forgery(서버 측 요청 위조)의 약자로, 공격자가 직접 접근할 수 없는 내부 서버나 자원에 대해 서버가 대신 요청을 보내도록 속이는 공격이다. 웹 보안 분류 체계에서는 CWE-918로 등록되어 있으며, OWASP 상위 위험 목록에도 꾸준히 이름을 올려온 고전적이면서도 여전히 치명적인 취약점이다.

일반적인 웹 애플리케이션에서 SSRF가 위험한 이유는 서버가 내부망(사설 IP 대역)이나 클라우드 메타데이터 엔드포인트에 접근할 수 있기 때문이다. AWS·GCP·Azure 같은 클라우드 환경에서는 169.254.169.254 같은 링크-로컬 주소를 통해 인스턴스의 임시 자격 증명을 조회할 수 있는데, 공격자가 SSRF를 통해 이 주소로 요청을 유도하면 서버의 IAM 자격 증명이 통째로 탈취될 수 있다. 2019년 캐피털 원(Capital One) 사고가 바로 이 패턴으로, SSRF를 통해 AWS 메타데이터에서 자격 증명을 빼낸 뒤 수천만 건의 고객 정보가 유출된 대표 사례다.

AI 에이전트에서는 이 위험이 한층 증폭된다. 에이전트는 사람이 일일이 지시하지 않아도 스스로 URL을 열고, 페이지를 스냅샷으로 읽고, 파일을 가져오고, 미디어를 처리한다. 만약 악의적인 웹페이지나 첨부 파일이 에이전트가 어떤 주소로 요청을 보낼지 영향을 줄 수 있다면, 공격자는 사람의 클릭 없이도 내부망 정탐과 자격 증명 탈취를 자동으로 시도할 수 있다.

핵심 포인트: SSRF의 본질은 신뢰할 수 없는 입력이 서버의 요청 대상을 결정하게 만드는 것이다. AI 에이전트는 사람의 개입 없이 자동으로 URL을 열고 요청을 보내므로, SSRF 방어막(SSRF policy)이 어디서 적용되고 어디서 누락되는지가 곧 사고 여부를 가른다.

2. 오픈클로 2026.5.26 업데이트가 막은 보안 구멍

2026.5.26 업데이트의 보안 작업은 구체적이고 실용적이다. 화려하지는 않지만, 에이전트가 파일·브라우저 스냅샷·플러그인 라벨·트랜스크립트·채널 이벤트를 잠재적 컨텍스트로 읽기 시작한 이상 반드시 필요한 경계 작업이다.

2.1. SSRF 및 콘텐츠 경계 강화

1. 브라우저 스냅샷 읽기 시 탭 URL을 ChromeMCP나 직접 CDP(Chrome DevTools Protocol) 읽기 전에 SSRF 정책으로 먼저 검증하도록 변경했다. 악성 페이지가 에이전트의 요청 대상을 좌우하던 경로를 차단한 것이다.
2. 가져온(fetched) 파일 텍스트와 메타데이터를 외부 콘텐츠(external content)로 명확히 래핑해, 모델이 파일 내용을 명령이 아니라 데이터로 취급하도록 했다.
3. 시스템 이벤트 텍스트를 정제(sanitize)해, 신뢰할 수 없는 플러그인이나 채널 라벨이 중첩된 프롬프트 마커를 흉내 내지 못하게 했다.

2.2. 프롬프트 인젝션과 메모리 보호

프롬프트 인젝션은 외부 텍스트가 마치 지시문인 것처럼 모델에 영향을 주는 공격이다. 이번 업데이트는 memory_store 도구로 명시적으로 제출되는 프롬프트형 텍스트를 임베딩·저장 이전에 거부한다. 메모리는 한 번 심어지면 이후 에이전트 행동에 지속적으로 영향을 주므로, 일회성 프롬프트 인젝션보다 더 위험한 영구 인젝션을 막는다는 점에서 의미가 크다.

2.3. 발신자 위조와 게이트웨이 남용 방어

ClickClack(오픈클로의 에이전트 간 통신 프로토콜)의 발신자 허용 목록(allowlist) 검사를 에이전트 디스패치 이전으로 앞당겼다. 신원 확인이 작업 시작 전에 이뤄지도록 순서를 바로잡은 것이다. 또한 사용자 비대면 원격·HTTP 실패에 대해 게이트웨이 인증에 기본 레이트 리미터(rate limiter)가 적용되며(루프백은 예외 유지), 무효화된 디바이스 토큰은 회전(rotation) 과정에서 거부된다.

이 밖에도 도커(Docker)에서 게이트웨이 토큰 출력 방지, 플러그인 모델 패턴 정규식의 안전한 컴파일 검증, 트랜스크립트 메타데이터 필드명 이스케이프, 세션 허용 목록 glob 매칭 강화, YOLO 모드에서 Claude 권한 오버라이드 감사, ACP 자동 승인의 명시적 허용 요구 등 다층적인 경계 작업이 포함됐다.

3. 오픈클로를 둘러싼 실제 SSRF CVE 사례

오픈클로는 2026년 들어 SSRF 계열 취약점이 반복적으로 보고되고 패치되어 왔다. 이는 부정적인 신호라기보다, 빠르게 성장하는 오픈소스 에이전트 플랫폼이 보안 연구자들의 검증을 거치며 성숙해 가는 과정으로 볼 수 있다. 대표적인 사례를 정리하면 다음과 같다.

3.1. CDP 프로필 생성 경로의 SSRF

1. CVE-2026-45000: 2026.4.20 이전 버전의 브라우저 CDP 프로필 생성 경로에서 strict-mode SSRF 정책 검증을 건너뛰는 취약점이다. 공격자가 cdpHost 값에 내부 주소나 메타데이터 엔드포인트를 가리키는 프로필을 저장해 두면, 이후 정상적인 프로필 상태 점검 과정에서 내부 요청이 발생한다. 근본 원인은 resolveBrowserSsrFPolicy 함수가 호출자가 제공한 추가 허용 호스트네임을 allowPrivateNetwork 설정과 무관하게 무조건 병합하던 데 있었다. CVSS 점수는 2.3(낮음)으로 평가됐으나, 메타데이터 접근 경로라는 점에서 환경에 따라 영향이 커질 수 있다.

3.2. IPv6 및 IPv4-매핑 우회

1. CVE-2026-41361: 2026.3.28 이전 버전이 4개의 IPv6 특수 용도(special-use) 대역을 차단하지 못해 SSRF 가드를 우회당하는 취약점(CWE-184, CVSS 5.1 중간)이다.
2. CVE-2026-26324: 완전한 형태의 IPv4-매핑 IPv6 주소를 통해 루프백·메타데이터에 도달할 수 있는 SSRF 가드 우회다. SSRF 방어가 표준 표기법만 막고 변형 표기를 놓치는 전형적인 필터링 불완전성 문제다.

3.3. 정책 우회 및 플러그인 경로

1. CVE-2026-41912: 2026.4.8 이전 버전에서 브라우저 상호작용을 악용해 정상적인 SSRF 보호 메커니즘을 우회하는 내비게이션을 유발하는 정책 우회 취약점이다.
2. CVE-2026-44116: 2026.4.22 이전 버전의 Zalo 플러그인 sendPhoto 함수가 URL을 검증하지 않아, 악성 사진 URL을 통해 내부 자원에 접근할 수 있는 SSRF다.
3. DNS 리바인딩 계열: 브라우저 SSRF 호스트네임 검증이 DNS 리바인딩으로 우회될 수 있던 문제도 별도 어드바이저리(GHSA)로 보고되어 2026.4.10/2026.4.14 릴리즈에서 수정됐다.

이러한 사례들이 보여주는 공통 패턴은 SSRF 방어막이 한 곳에서는 작동하지만 다른 경로(CDP 프로필, 플러그인, 변형 IP 표기, DNS 리바인딩)에서는 누락된다는 점이다. 2026.5.26의 브라우저 스냅샷 URL 사전 검증은 바로 이 누락 지점을 또 하나 메운 조치다.

4. 운영자가 지금 적용해야 할 대응 방법

SSRF는 코드 수정만으로 끝나는 문제가 아니라 네트워크 경계와 운영 정책을 함께 손봐야 효과가 극대화된다. 오픈클로를 실제 워크플로에 연결해 쓰고 있다면 다음을 단계적으로 점검하는 것이 좋다.

첫째, 가장 확실한 조치는 최신 버전으로 업그레이드하는 것이다. 알려진 SSRF CVE들은 각각 2026.3.28, 2026.4.8, 2026.4.20, 2026.4.22 등에서 수정됐고, 2026.5.26은 그동안의 보안 경계 작업을 한 번 더 다듬었다. 버전 인벤토리를 관리해 모든 호스트가 최신 릴리즈에서 동작하는지 확인하는 것이 기본이다.

둘째, 이그레스(egress) 네트워크 차단을 적용한다. 오픈클로 워커가 사설 IP 대역(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)과 링크-로컬 주소, 특히 클라우드 메타데이터 서비스(169.254.169.254)에 도달하지 못하도록 방화벽 ACL이나 이그레스 프록시로 막는다. 애플리케이션 레벨 SSRF 방어가 우회되더라도 네트워크 레벨에서 한 번 더 걸러주는 다층 방어가 된다. AWS라면 IMDSv2 강제, Azure는 홉 리밋, GCP는 VPC 방화벽 규칙을 함께 적용하면 메타데이터 탈취 위험을 크게 낮출 수 있다.

셋째, 설정과 권한을 점검한다. ssrfPolicy.allowPrivateNetwork를 false로 두고 dangerouslyAllowPrivateNetwork는 꼭 필요한 경우가 아니면 사용하지 않는다. 브라우저 프로필을 생성·수정할 수 있는 권한은 신뢰할 수 있는 운영자로 제한하고, 기존에 저장된 프로필 중 cdpHost가 내부망을 가리키는 항목이 없는지 감사한다.

넷째, 탐지와 모니터링을 갖춘다. 오픈클로 프로세스에서 사설·링크-로컬 IP로 향하는 아웃바운드 HTTP 요청, 메타데이터 엔드포인트로의 연결, 비정상적인 호스트를 향한 반복적 프로필 상태 점검 등을 침해 지표(IoC)로 삼아 중앙 분석 플랫폼으로 전송하고 경보를 설정한다.

핵심 포인트: 업그레이드는 필수 조건일 뿐 충분 조건이 아니다. 최신 버전 적용 + 이그레스 차단(특히 메타데이터 주소) + 사설망 허용 설정 비활성화 + 프로필 권한 최소화 + 아웃바운드 모니터링을 함께 갖춰야 SSRF 우회 변종이 나와도 피해를 봉쇄할 수 있다.

5. 마무리

위에서 살펴본 오픈클로 2026.5.26 업데이트와 SSRF 보안 문제의 핵심 내용을 정리하면 다음과 같습니다.

핵심 요약:

• 오픈클로(OpenClaw)는 다중 채널·음성·파일·브라우저·모델 제공자를 묶는 자율형 AI 에이전트로, 실제 워크플로에 연결될수록 보안 경계가 중요하다.
• SSRF는 서버가 신뢰 없는 입력에 따라 내부망·클라우드 메타데이터(169.254.169.254)로 요청을 보내게 만드는 공격으로, 자격 증명 탈취로 이어질 수 있다.
• 2026.5.26 업데이트는 브라우저 스냅샷 URL 사전 SSRF 검증, 외부 파일 콘텐츠 래핑, 메모리 인젝션 거부, 발신자 허용 목록 선검사, 게이트웨이 기본 레이트 리미터 등 다층 경계를 강화했다.
• CVE-2026-45000(CDP 프로필), CVE-2026-41361(IPv6 우회), CVE-2026-26324(IPv4-매핑 우회), CVE-2026-41912(정책 우회), CVE-2026-44116(Zalo 플러그인) 등 SSRF 계열 취약점이 반복 보고·패치되어 왔다.
• 공통 패턴은 SSRF 방어막이 일부 경로에서 누락된다는 점이며, 변형 IP 표기와 DNS 리바인딩이 대표적 우회 수단이다.
• 운영자는 최신 버전 업그레이드, 메타데이터·사설망 이그레스 차단, allowPrivateNetwork 비활성화, 프로필 권한 최소화, 아웃바운드 모니터링을 함께 적용해야 한다.

오픈클로를 개인 머신에서 단일 비서로만 쓴다면 이번 업데이트는 대체로 거친 부분이 줄어드는 정도로 체감되겠지만, 다중 채널·다중 에이전트의 게이트웨이로 운영한다면 보안 경계 강화는 선택이 아니라 필수다. 업그레이드를 우선 적용하고, 네트워크 레벨 차단과 권한 최소화를 더해 SSRF 우회 변종이 등장하더라도 피해가 내부망으로 번지지 않도록 다층 방어를 구성하는 것이 바람직하다.