rickidevs/cve-2026-32913OpenClaw에서 제로데이 취약점을 발견했습니다 — 그 과정은 이러했습니다
소스 코드를 검토하는 동안, 저는 OpenClaw가 HTTP 요청을 처리하는 방식, 특히 서버 측 fetch 호출을 담당하는 fetchWithSsrFGuard() 함수에 집중했습니다.
이상한 점을 발견했습니다.
요청이 교차 출처 리디렉션(즉, 서버가 다른 도메인을 가리키는 3xx 응답을 보낸 경우)을 따를 때, OpenClaw는 새 대상으로 요청을 전달하기 전에 민감한 헤더를 제거해야 했습니다. 실제로 제거는 했지만, 하드코딩된 좁은 차단 목록에 대해서만 그랬습니다:
Authorization, Proxy-Authorization, Cookie, Cookie2
문제는? 그 목록이 불완전하다는 것입니다.
X-Api-Key, Private-Token 또는 개발자들이 흔히 사용하는 다른 베어러 스타일 헤더와 같은 사용자 정의 인증 헤더는 전혀 제거되지 않았습니다. 이들은 리디렉션 대상으로 그대로 전달되었습니다.
즉, 공격자가 리디렉션이 가리키는 위치를 제어하거나 영향을 줄 수 있다면, 그들에게 전달될 의도가 없었던 민감한 자격 증명을 받을 수 있다는 뜻입니다.
애플리케이션이 OpenClaw를 사용하여 사용자 정의 X-Api-Key 헤더로 내부 API를 호출한다고 상상해 보세요. 악성 서버가 공격자가 제어하는 URL로의 리디렉션으로 응답합니다. OpenClaw는 리디렉션을 따르고 — API 키도 함께 전달합니다.
게임 오버입니다. 이제 자격 증명은 다른 사람의 손에 넘어갔습니다.
CVSS 3.1 점수: 9.3 (치명적)
유지관리자들은 차단 목록 방식을 안전한 헤더 허용 목록으로 대체했습니다. 알려진 나쁜 헤더를 차단하려고 시도하는 대신, 새 로직은 교차 출처 리디렉션 시 알려진 안전한 헤더(콘텐츠 협상 및 캐시 검증기 등)만 통과시킵니다. 그 외의 모든 것은 기본적으로 제거됩니다.
이것이 올바른 접근 방식입니다. 차단 목록 기반 보안은 취약하고, 허용 목록 기반 보안은 견고합니다.
참고 자료
46715371b0612a6f9114dffd1466941ac476cef5<= 2026.3.2>= 2026.3.7즉시 >= 2026.3.7로 업데이트하세요.
사용자 정의 인증 헤더(예: X-Api-Key 또는 Private-Token)를 사용하고 있고 이전 버전을 사용 중이었다면, 해당 자격 증명이 잠재적으로 유출된 것으로 간주하고 교체하세요.