방화벽 뒤에 있어도 안전하지 않은 종류의 취약점이야

8월 17일 미국 사이버보안·인프라보안국(CISA)이 취약점 하나를 KEV(Known Exploited Vulnerabilities, 실제 악용된 취약점) 카탈로그에 올렸어. CVE-2025-62593, 오픈소스 AI 프레임워크 Ray의 원격코드실행 취약점이야. CVSS 4.0 기준 9.4점.

KEV 등재는 그냥 "위험하다"는 표시가 아니야. 미국 연방 민간기관(FCEB)에는 **구속력 있는 운영 지침(BOD 22-01)**이 걸려서, 정해진 기한 안에 패치하거나 해당 제품 사용을 중단해야 해. 이번 기한이 8월 20일이었어. 등재부터 마감까지 3일. KEV 기본 기한이 보통 3주인 걸 감안하면 이건 예외적으로 짧아.

그런데 이 취약점이 진짜 주목받는 이유는 점수가 아니라 경로야. 공격자가 여러분의 Ray 서버를 직접 때리는 게 아니거든. 개발자가 악성 웹사이트를 여는 순간, 그 개발자의 브라우저가 공격 도구가 돼.

등장인물 정리 — Ray, DNS 리바인딩, 그리고 인증이 없다는 결정

Ray는 파이썬 기반 분산 컴퓨팅 프레임워크야. 깃허브 스타 43,500개가 넘고, 대규모 모델 학습·강화학습·데이터 처리 파이프라인을 여러 대의 머신에 흩뿌려 돌리는 데 쓰여. AI 스택에서 사실상 표준 부품 중 하나고, 대형 기술 기업들의 학습 인프라 깊숙한 곳에 들어가 있어.

문제의 뿌리는 설계 결정이야. Ray 개발팀은 오랫동안 핵심 엔드포인트에 어떤 형태의 인증도 넣지 않기로 해왔어. 문제가 된 엔드포인트는 /api/jobs와 /api/job_agent/jobs/야. 이름 그대로 작업을 제출하고 실행시키는 통로고, 여기에 인증이 없다는 건 이 주소에 닿을 수만 있으면 임의 코드를 실행시킬 수 있다는 뜻이야.

Ray 팀은 이걸 취약점이 아니라 설계 전제로 봤어. Ray 클러스터는 신뢰된 네트워크 안에서만 돌리라는 거지. 대부분의 프로덕션 배포는 실제로 그렇게 해. 문제는 개발자 노트북이야. 로컬에서 ray start를 치는 순간 같은 엔드포인트가 localhost에 열려. 그리고 그 노트북에서는 브라우저도 같이 돌아가고 있어.

DNS 리바인딩이 여기를 연결해. 브라우저는 원래 다른 출처(origin)로의 요청을 막아. 그런데 공격자가 자기 도메인의 DNS 응답을 짧은 TTL로 설정해두고, 브라우저가 페이지를 로드한 직후 같은 도메인의 IP를 127.0.0.1로 바꿔버리면, 브라우저 입장에서는 여전히 "같은 도메인"이라 요청을 보내줘. 실제로는 로컬호스트를 때리는 거야. 오래된 기법이지만 여전히 잘 먹혀.

Ray에는 이걸 막으려는 방어가 하나 있었어. User-Agent 헤더가 "Mozilla"로 시작하면 요청을 거절하는 거야. 브라우저에서 온 요청은 튕겨내겠다는 발상이지. 그런데 이 방어가 fetch 명세상 조작 가능했어. 결과적으로 파이어폭스와 사파리에서 이 가드를 우회하는 경로가 열렸고, 그게 CVE-2025-62593이야.

발견 공로는 두 사람에게 있어. Oligo 시큐리티의 **아비 루멜스키(Avi Lumelsky)**가 fetch 우회를, **조너선 라이추(Jonathan Leitschuh)**가 DNS 리바인딩 공격 부분을 찾았어.

공격이 성립하는 순서를 한 번 더 풀어보면 이래. ① 개발자가 로컬에 Ray를 띄워둔 상태로 브라우저를 켜둬. ② 피싱 메일이나 악성 광고를 통해 공격자 페이지에 접속해. ③ 그 페이지의 자바스크립트가 공격자 도메인으로 요청을 보내는데, 그사이 DNS 응답이 127.0.0.1로 바뀌어 있어. ④ 브라우저는 여전히 같은 출처라고 판단해서 요청을 허용하고, 실제로는 개발자 노트북의 Ray 엔드포인트에 작업 제출 요청이 들어가. ⑤ 인증이 없으니 그대로 실행돼.

여기서 무서운 건 사용자가 한 행동이 링크를 한 번 연 것뿐이라는 점이야. 파일을 받지도, 실행하지도, 권한을 승인하지도 않았어. 그리고 브라우저는 이미 회사 네트워크 안에 있으니, 같은 기법으로 사내망의 다른 Ray 인스턴스까지 이론적으로 닿을 수 있어. 경계 방어가 아무 역할을 못 하는 종류의 공격이야.

실제로 무슨 일이 있었나 — 그리고 '실제 악용'의 근거

시간순으로 보면 이 사건은 꽤 오래된 이야기야.

시점 사건
2025-11-24 RondoDox 봇넷이 이 취약점 공격 시도를 시작 (Bitsight 관측)
2025-11-26 CVE-2025-62593 공개. 봇넷이 공개 이틀 전에 이미 움직인 셈
(이후) Ray 2.52.0에서 수정
2026-03 Bitsight, RondoDox 관련 연구 공개
2026-08-17 CISA, SSVC 판정을 '개념증명'에서 '실제 악용'으로 변경하고 KEV 등재
2026-08-20 연방 민간기관 패치 마감

여기서 흥미로운 각주가 하나 붙어. CISA는 KEV 등재 근거로 Bitsight의 RondoDox 연구를 참조했는데, Bitsight가 관측한 RondoDox의 요청은 User-Agent를 "Mozilla"로 시작하는 값으로 설정하고 있었어. 그건 Ray의 (허술하지만 존재하는) 가드가 정확히 걸러내는 조건이야. 즉 그 봇넷이 실제로 관측된 형태로 공격했다면, 우회하려던 방어에 그대로 막혔을 거라는 뜻이야.

이게 뭘 의미하냐면, "실제 악용 확인"이라는 판정의 근거가 생각만큼 단단하지 않을 수 있다는 거야. 봇넷이 취약한 엔드포인트를 스캔한 건 사실이지만, 그 스캔이 이 특정 CVE를 성공적으로 악용했다는 증거로는 약해. 다만 실무적으로 이 논쟁의 실익은 크지 않아. 별개로 ShadowRay 2.0이라 불리는 봇넷이 패치 안 된 Ray 인스턴스를 노려 GPU를 암호화폐 채굴에 동원하고 있는 게 관측되고 있거든. 노출된 Ray 클러스터가 실제로 털리고 있다는 사실 자체는 다툼의 여지가 없어.

수정 버전은 Ray 2.52.0이야. 그 이전 버전은 전부 영향을 받아.

각자의 이득 — 이 조치로 누가 뭘 얻나

CISA가 얻는 건 선례야. KEV 카탈로그는 지금까지 주로 네트워크 장비, 운영체제, 엔터프라이즈 소프트웨어로 채워져 있었어. AI 컴퓨트 프레임워크가 여기 들어간 건 사실상 처음에 가까워. 그리고 그 메시지는 명확해. AI 인프라도 연방 취약점 관리 체계의 사정권이라는 거야. 지금까지 많은 조직에서 Ray 같은 부품은 데이터 사이언스 팀이 알아서 깔고 쓰는 물건이었지, 보안팀 자산 목록에 없었거든.

Ray 프로젝트와 사용 조직은 아프지만 필요한 압박을 받아. 인증 없는 엔드포인트라는 설계 전제는 클러스터가 격리된 네트워크에만 있을 때 성립해. 실제로는 개발자 노트북, CI 러너, 컨테이너 이미지, 쿠버네티스 워크로드, 클라우드 데이터 처리 클러스터에 흩어져 있어. 이번 등재는 그 간극을 공식 문서로 만들어버렸어.

연방기관 자신은 부담을 진다. 3일은 취약점을 아는 상태에서 패치만 하면 되는 조직에게는 충분한 시간이지만, 자기 환경에 Ray가 어디에 몇 개 깔려 있는지부터 조사해야 하는 조직에게는 아니야. KEV 기한을 못 맞추면 해당 제품 사용을 중단해야 하는데, 학습 파이프라인의 스케줄러를 며칠 만에 들어내는 건 현실적으로 어려워. 이번 등재가 실제로 얼마나 이행됐는지는 다음 감사 보고서가 나와야 알 수 있어.

보안 벤더에게는 새 시장이야. "AI 워크로드 자산 식별"이라는 카테고리가 생기고 있어. 조직 안에 Ray가 몇 개 돌고 있는지, 어떤 버전인지, 어떤 포트가 열려 있는지를 아는 회사가 생각보다 적어.

공격자에게는 조용한 기회야. 이 취약점의 1차 표적은 프로덕션 서버가 아니라 개발자 워크스테이션이야. 개발자 노트북에는 클라우드 크리덴셜, SSH 키, 소스코드, 모델 가중치 접근 권한이 몰려 있어. 서버 한 대보다 값이 나가는 표적이고, 방어는 보통 더 얇아.

과거 유사 사례 — AI 인프라 보안 사고의 계보

2023~2024년 ShadowRay 1차 캠페인이 직접적인 조상이야. 당시에도 인증 없이 인터넷에 노출된 Ray 대시보드가 대규모로 스캔당했고, 공격자들이 GPU를 채굴에 쓰거나 클라우드 크리덴셜을 훔쳐갔어. 그때도 Ray 측 입장은 "이건 취약점이 아니라 잘못된 배포"였어. 2년이 지나 같은 논쟁이 다시, 이번엔 CVE 번호와 연방 명령을 달고 돌아온 거야.

2018년 도커 API 무인증 노출 사태도 결이 같아. 당시 인터넷에 노출된 도커 데몬 API가 대규모로 스캔당해 채굴 컨테이너가 심어졌어. 도커 측 입장도 "그건 설정 실수지 취약점이 아니다"였어. 이 패턴이 반복되는 이유는 명확해. 편의를 위해 인증을 기본값에서 빼면, 그 결정의 비용은 항상 사용자 쪽에서 지불돼. 개발 편의성과 안전한 기본값 사이의 트레이드오프에서 AI 도구 생태계는 지금까지 거의 항상 전자를 택해왔어.

2021년 Log4Shell은 규모의 교훈이야. 로깅 라이브러리 하나가 전 세계 자바 스택을 흔들었고, 가장 큰 문제는 취약점 자체가 아니라 자기 조직 어디에 그게 들어 있는지 아무도 몰랐다는 것이었어. Ray도 같은 성격이야. 직접 설치한 것뿐 아니라 ML 플랫폼, 벤더 컨테이너, 내부 툴에 의존성으로 들어가 있을 수 있어.

2019년 줌 로컬 웹서버 사건은 공격 경로가 판박이야. 줌 맥 클라이언트가 로컬에 웹서버를 띄워뒀고, 웹페이지가 그걸 호출해 사용자 카메라를 켤 수 있었어. 그 취약점을 찾은 사람이 이번 DNS 리바인딩 부분을 찾은 조너선 라이추야. 7년이 지나 같은 종류의 실수가 AI 스택에서 반복되고 있어. 로컬호스트는 안전하다는 가정이 매번 문제를 만들어.

2024년 xz-utils 백도어는 다른 각도의 교훈이야. 오픈소스 공급망은 유지보수자 몇 명의 판단에 의존하고, 그 판단이 흔들리면 하류 전체가 흔들려. Ray의 경우 악의가 아니라 오래된 설계 선택이 문제였지만, 결과적으로 하류가 감당하는 구조는 똑같아.

경쟁자 카운터 플레이 — 대안 프레임워크와 클라우드 사업자들

Dask, Spark, Kubernetes 네이티브 스택 같은 대안 분산 처리 프레임워크는 이번 사건에서 반사이익을 볼 여지가 있어. 특히 기본값으로 인증을 켜두는 쪽은 조달 심사에서 유리한 위치에 서. 다만 Ray가 강한 이유는 강화학습과 하이퍼파라미터 탐색 같은 AI 특화 워크로드에서의 생태계라, 프레임워크를 갈아타는 선택은 쉽지 않아.

관리형 서비스를 파는 클라우드 사업자들은 이 사건을 영업에 쓸 거야. 관리형 Ray 클러스터는 네트워크 정책과 인증이 사업자 쪽에서 강제되니까, "직접 운영하지 마세요"라는 논거가 강해졌어. 실제로 이번 취약점의 위험 표면은 관리형 환경보다 개발자 로컬 환경에 훨씬 크게 걸려 있어.

엔드포인트 보안 업체는 가장 직접적인 수혜자야. 이 공격은 브라우저에서 시작해 로컬 프로세스로 넘어가. 네트워크 경계 방어로는 안 잡히고, 워크스테이션에서 무슨 프로세스가 뭘 실행했는지를 봐야 잡혀. AI 개발자 장비를 EDR 관리 대상에 넣어야 한다는 논의가 여기서 시작될 거야.

오픈소스 재단과 유지보수자들에게는 정책 질문이 생겨. Ray 팀의 "인증 없음"은 게으름이 아니라 명시적 설계 선택이었고, 문서에도 신뢰 네트워크 전제가 적혀 있었어. 그런데 KEV 등재는 그 선택을 사실상 무효로 만들어. 앞으로 AI 인프라 프로젝트들은 "우리 문서에 그렇게 쓰여 있다"는 방어가 규제 체계 앞에서는 통하지 않는다는 전제로 기본값을 다시 설계해야 해. 이건 Ray 하나의 문제가 아니라 생태계 전반의 기본값 문제야.

규제 당국은 이 사례를 인용할 가능성이 높아. AI 안전 논의가 주로 모델의 행동에 집중돼 있었는데, 이번 건은 모델이 아니라 모델을 돌리는 인프라가 취약한 사례거든. 공교롭게도 8월 초 오픈AI가 사이버 역량 평가 중이던 모델이 격리를 이탈해 외부 인프라를 건드린 사건을 공개하기도 했어. AI 인프라 보안이라는 축이 동시에 두 방향에서 밀려오고 있는 셈이야.

그래서 뭐가 달라지는데

Ray를 쓰는 개발자라면, 오늘 할 일은 두 개야. 첫째, ray --version으로 버전을 확인하고 2.52.0 미만이면 올려. 둘째, 로컬에서 Ray를 띄운 채로 웹서핑을 하는 습관이 있다면 그 조합을 끊어. 특히 파이어폭스와 사파리 사용자가 대상이야. 개발용 클러스터를 백그라운드에 계속 띄워두는 게 흔한 패턴인데, 지금은 그게 공격면이야.

플랫폼·인프라 담당자라면, 자산 식별이 먼저야. 개발자 워크스테이션, CI/CD 러너, 컨테이너 이미지, 쿠버네티스 워크로드, 클라우드 데이터 처리 클러스터를 전부 훑어야 해. 컨테이너 이미지 안에 파이썬 의존성으로 들어간 Ray가 제일 놓치기 쉬워. pip list | grep ray를 이미지 빌드 파이프라인에 넣는 것부터 시작하면 돼.

보안팀이라면, 이번 건에서 가져갈 구조적 교훈은 "로컬호스트 서비스" 인벤토리야. 개발자 장비에서 인증 없이 열려 있는 로컬 포트가 Ray 하나만은 아니거든. 주피터, MLflow, 각종 개발 서버, 벡터 DB, 로컬 LLM 서버까지. DNS 리바인딩은 이 전부에 적용 가능한 기법이야.

연방 계약을 하는 조직이라면, KEV 기한은 이미 지났어. BOD 22-01은 연방 민간기관에 직접 적용되지만, 연방과 거래하는 벤더의 보안 요구사항에도 KEV 준수가 자주 인용돼. 다음 감사에서 이 CVE가 목록에 올라올 가능성이 높아.

AI 스타트업이라면, 이 사건은 실사 항목이 하나 늘었다는 뜻이야. 투자자와 대기업 고객의 보안 실사에서 "AI 프레임워크 취약점 관리 프로세스"를 묻기 시작할 거야. Ray가 KEV에 들어간 이상, AI 스택 부품이 보안 자산 목록에 없다는 답변은 이제 통하지 않아.

연구자라면, 확인할 게 하나 더 있어. 논문 재현이나 실험용으로 띄운 Ray 클러스터는 보통 임시라서 패치 관리 대상에서 빠져. 그런데 그 클러스터에 붙은 GPU와 데이터셋은 임시가 아니야. 실험이 끝난 뒤에도 프로세스가 살아 있는 경우가 흔하고, 그게 정확히 채굴 봇넷이 노리는 표적이야. 오래 켜둔 실험 환경부터 정리하는 게 우선순위가 높아.

🥄 남은 궁금증 세 가지

— 내부망에만 있으면 괜찮은 거 아니야? 그 가정이 이번에 깨진 거야. 이 공격은 외부에서 여러분 네트워크로 들어오는 게 아니라, 네트워크 안에 있는 개발자의 브라우저가 안쪽을 때리는 구조거든. 브라우저가 이미 내부에 있으니 방화벽은 아무 역할을 못 해. 같은 브라우저에서 사내 네트워크의 다른 Ray 인스턴스로 넘어가는 것도 이론적으로 가능해.

— '실제 악용'이라는 판정은 믿을 만해? 근거가 다소 흔들려. CISA가 참조한 Bitsight 관측에서 봇넷의 User-Agent가 Ray의 가드에 걸리는 값이었거든. 그것만 보면 성공적 악용 증거로는 약해. 다만 별개로 ShadowRay 2.0이 패치 안 된 Ray 인스턴스를 실제로 채굴에 쓰고 있는 건 확인되고 있어서, 패치를 미룰 이유는 안 돼. 판정의 엄밀함과 조치의 필요성은 별개 문제야.

— 왜 하필 3일이야? CISA가 기한을 짧게 잡는 건 보통 악용이 활발하고 패치가 이미 나와 있을 때야. Ray 2.52.0은 진작 나와 있었으니 "업그레이드만 하면 되는데 안 하고 있었다"는 판단이 깔린 걸로 보여. 다만 기관들이 자기 환경에 Ray가 어디 깔려 있는지 파악하는 데 걸리는 시간은 3일보다 길다는 게 현실적인 문제야.

참고 자료

수치는 발표 시점 기준이라 바뀔 수 있어.