🇰🇷 한글 설명
Heym 0.0.90 이하 버전에서 두 가지 서버 측 요청 위조(SSRF) 취약점이 발견되었습니다. 첫째는 이미지 로더가 보안 검증을 우회하여 임의의 URL을 호출할 수 있는 문제이며, 둘째는 IPv6 전환 주소 형식을 이용해 내부 네트워크 및 클라우드 메타데이터 엔드포인트에 접근할 수 있는 문제입니다.
💡 쉬운 설명
해커가 조작된 이미지 주소를 보내면, 서버가 내부 네트워크나 중요한 관리자 페이지에 대신 접속하게 만드는 보안 구멍입니다. 특히 IPv6라는 특수한 주소 형식을 이용해 보안 필터를 교묘하게 통과할 수 있는 문제가 있습니다.
🇺🇸 원문 (English)
Heym versions 0.0.90 and earlier contain two server-side request forgery (SSRF) egress gaps, both remediated in app/services/ssrf_guard.py in 0.0.91. First, the LLM image-edit input loader (_load_image_bytes) fetched caller-controlled HTTP/HTTPS URLs with a bare httpx.get, applying only a scheme check and bypassing the egress-pinning HTTP client; because the workflow DSL supports "imageInput": "$userInput.body.imageUrl", a webhook or API caller can choose the fetch target when a workflow author uses that expression, allowing requests to loopback, RFC1918, and cloud metadata endpoints. Second, _is_public_address unwrapped only IPv4-mapped IPv6 addresses, so IPv6 transition forms — the NAT64 well-known prefix 64:ff9b::/96, deprecated IPv4-compatible ::x.x.x.x addresses, and 6to4 (2002::/16, classified as globally routable by Python 3.11.0 through 3.11.9) — could carry loopback, RFC1918, link-local, or cloud-metadata IPv4 destinations past both the initial URL validation and the dial-time IP pin. Version 0.0.91 routes the image loader through guard_http_url and the guarded client, evaluates NAT64 and IPv4-compatible addresses by their embedded IPv4 address, and refuses 64:ff9b:1::/48, 6to4, and Teredo (2001::/32) outright.
📍 영향받는 시스템
Heym versions 0.0.90 and earlier
⚔️ 공격 벡터
사용자 입력값(imageUrl)을 통해 조작된 HTTP/HTTPS URL 또는 IPv6 전환 주소를 전달하여 내부망 접근
🛡️ 대응 방법
Heym 버전을 0.0.91 이상으로 업데이트하여 보안 가드 및 IPv6 검증 로직 적용
🔧 검증 코드
출력된 버전이 0.0.91 미만(예: 0.0.90 이하)이면 취약한 상태입니다.
pip show heym | grep Version