MLflow 웹훅 전송 단계에서 발생하는 SSRF(SSRF, 서버 사이드 요청 위조) 취약점 CVE-2026-64849가 CISA Known Exploited Vulnerabilities(KEV)에 등록됐습니다. CISA KEV에는 해당 취약점에 대해 공격자가 내부 또는 클라우드 메타데이터 서비스에 도달하고 response_status와 response_body를 받아낼 수 있다는 설명이 포함돼 있습니다. MLflow 서버를 운영 중이라면, 웹훅 전송 경로와 리다이렉트 처리 방식을 중심으로 점검해야 합니다.
취약점 개요
MLflow의 웹훅 전달 과정에서 발생하는 이 취약점은 CWE-918(Server-Side Request Forgery, 서버 사이드 요청 위조)으로 분류됩니다. MLflow 보안 공지에 따르면 3.10.0에 포함된 _validate_webhook_url은 웹훅 호스트명을 해석하고 비공개 IP를 거부하지만, 전달 과정이 HTTP 리다이렉트를 따르며 리다이렉트 대상에 대한 재검증을 수행하지 않아 우회 가능합니다.
공격 대상이 302 응답으로 169.254.169.254 또는 127.0.0.1 지점으로 전환을 반환하면 MLflow는 해당 주소로 요청을 계속합니다. /test 경로가 응답 본문을 그대로 반환하기 때문에, 기본 서버 환경에서는 인증 없이 전체 응답을 읽을 수 있는(full-read) SSRF로 이어집니다.
영향 범위
이 취약점이 적용되는 환경은 다음과 같습니다.
- MLflow 웹훅 전송 기능의
_validate_webhook_url검증 경로 - 3.10.0에 포함된 검증 로직이 적용되더라도 리다이렉트 재검증 부재로 우회가 가능한 구성
- 기본 서버에서
/test가 응답 본문을 반환하는 환경 - 내부 서비스 또는 클라우드 메타데이터 서비스에 도달할 수 있는 MLflow 서버
MLflow 서버가 내부 서비스나 클라우드 메타데이터 서비스에 요청을 수행할 수 있고, 그 응답 상태와 본문이 공격자에게 반환될 수 있다는 점에서 기본 서버 환경에서의 내부 정보 노출 범위가 넓어질 수 있습니다. 웹훅 기반 워크플로우를 사용하는 운영 환경에서는 공격 표면이 내부 네트워크와 클라우드 메타데이터 접근까지 확장된다고 볼 수 있습니다.
기술적 분석
취약점의 핵심은 검증 시점과 실제 요청 대상 사이의 격차입니다. _validate_webhook_url은 최초 웹훅 URL에 대해 비공개 IP 여부를 검사하지만, 전송 과정에서 발생한 리다이렉트 결과에는 다시 검증을 하지 않습니다. 따라서 외부에서 제어되는 중간 응답이 내부 또는 메타데이터 주소로의 전환을 유도하면, 서버는 검증되지 않은 대상으로 요청을 전송합니다.
/test 경로가 응답 본문을 그대로 반환하는 구성은 이 리다이렉트 우회를 실제 데이터 유출로 연결합니다. 이 구조가 결합되면 인증된 사용자가 아니어도 서버가 대신 수행한 요청의 응답을 받아볼 수 있으며, 내부 네트워크나 클라우드 메타데이터 엔드포인트에 대한 접근이 그 대상이 됩니다.
공개 PoC·익스플로잇 분석
CVE-2026-64849는 CISA KEV에 2026-08-20에 추가됐으며, 2026-08-19 기준으로 added to CISA KEV 기록이 확인됩니다. CISA KEV 카탈로그에는 대응 기한이 2026-09-03으로 기재돼 있습니다. KEV 등록으로 실제 악용(in-the-wild exploitation) 가능성이 공식적으로 알려진 상태이며, 공개 PoC 상태도 확인됐습니다.
PoC의 전제조건은 MLflow 서버가 웹훅 전송 기능을 활성화하고, /test 경로가 응답 본문을 반환하며, 서버가 내부 네트워크나 메타데이터 엔드포인트에 도달 가능한 위치에 있어야 한다는 것입니다. 입증되는 범위는 공격자가 제어하는 대상이 302 리다이렉트로 169.254.169.254 또는 127.0.0.1으로 전환할 때, 서버가 해당 주소를 재검증하지 않고 요청을 수행하고 그 응답이 호출자에게 반환된다는 것입니다.
운영상 의미는, 해당 취약점이 인증이나 특권 계정을 요구하지 않고 기본 서버 설정에서 동작할 수 있다는 점입니다. 다만 현재 근거에는 실제 공격 이벤트에서 확인된 피해 범위나 공격자 집단에 대한 세부 사항이 없고, KEV의 2026-09-03 기한이 규제 대응 기한인지 조직 내부 우선순위 기준인지는 출처에서 명확히 구분되지 않습니다. 이 부분은 추가 확인이 필요합니다.
대응 방안
취약점 메커니즘에 기반한 점검 관점
제시된 근거가 직접 확인하는 것은 302 리다이렉트 재검증 부재와 /test 경로에서의 응답 본문 반환입니다. MLflow 웹훅 전송 기능에서 302 응답으로 169.254.169.254 또는 127.0.0.1 지점으로 전환이 반환될 때 요청이 계속 수행되고, 그 응답 상태와 본문이 호출자에게 반환되는 메커니즘이 실제 취약점의 핵심입니다. 따라서 점검의 초점은 MLflow 서버가 웹훅 전송 경로를 통해 내부 서비스나 클라우드 메타데이터 서비스에 도달할 수 있는지에 집중됩니다.
패치 상태에 대한 한계
- CVE-2026-64849가 수정된 구체적인 MLflow 릴리스 버전은 현재 제공된 근거로 확인되지 않습니다. v3.15.0 릴리스에는 MCP Registry 기능이 포함된 것으로 확인됐으나, 해당 릴리스가 이 취약점 자체를 수정하는지는 확인되지 않습니다. 패치 대상 버전은 추가 출처 확인이 필요합니다.
- KEV 대응 기한 2026-09-03이 규제 대응 기한인지 조직 내부 우선순위 기준인지 확인해야 합니다.
- 공개 PoC와 KEV 등록 외에 실제 공격 대상 환경, 공격자 집단, 피해 범위에 대한 세부 사항은 현재 근거로 확정할 수 없습니다.
- 클라우드 환경별 메타데이터 서비스 주소가
169.254.169.254단일 주소로 제한되는지는 클라우드 운영 방식에 따라 추가 확인이 필요합니다.
참고자료
- CVE-2026-64849 Record (CVELIST V5)
- CISA Known Exploited Vulnerabilities Catalog
- MLflow Security Advisory: Unauthenticated full-read SSRF in MLflow webhook delivery
- MLflow Release v3.15.0
함께 읽으면 좋은 글
- CVE-2026-65400 대응: macOS 화면 공유 인증 우회 취약점 분석
- CVE-2026-33824 대응: Windows IKE Extension 이중 해제 취약점
- CVE-2026-59310: VMware vCenter 경로 순회 취약점 실제 악용 대응 가이드
본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.
댓글 (0)
댓글을 작성하려면 로그인이 필요합니다.
로그인아직 댓글이 없습니다.
첫 번째 댓글을 작성해보세요!