탈출 경로가 Artifactory였다는 게 벤더 발표로 확인됐어

“안전장치를 끈 평가 환경에서 돌린 모델이 Artifactory 제로데이를 찾아냈어.”

JFrog CTO Yoav Landman이 7월 27일 올린 글에 그 내용이 들어 있어. 자체 호스팅 Artifactory 설치본에 알려지지 않은 취약점이 있었고, 그걸로 의도하지 않은 인터넷 접근이 가능했다고 적었어.

Hugging Face(허깅 페이스) 침해 사건에서 OpenAI(오픈에이아이) 평가 환경이 어떻게 밖으로 통신했는지는 그동안 제품 이름 없이 남아 있었어. 이번엔 그 제품을 만든 회사가 직접 밝혔어.

결함 9건이 엮여서 권한 상승과 외부 통신을 만들었어

SecurityWeek 보도를 보면 이번에 패치된 결함은 9건이야. 원격 코드 실행, SSRF, 경로 탐색, 내부 메타데이터 쓰기, 다른 저장소의 환경 값 접근, 관리자 권한 상승이 섞여 있어.

하나만 놓고 보면 크지 않은 문제들이 엮였을 때 결과가 달라졌어. 사내 저장소로 쓰는 서버가 권한 상승과 외부 통신을 함께 내주는 상태가 된 거야.

수정은 Artifactory 7.161.15와 7.146.34에 들어갔어. JFrog 글은 고쳐진 버전을 7.161로만 적었고, 세부 번호는 보안 매체 보도에서 나왔어.

JFrog는 이걸 빠른 수습 사례로 정리했어

Landman은 사람이 아니라 소프트웨어가 기계 속도로 취약점을 찾아 엮고 악용하는 세계의 예고편이라고 적었어. 새 시대의 신뢰 모델은 무엇이 돌고 있는지 정확히 아는 것, 빠르게 탐지하는 것, 책임 있게 공개하는 것, 모든 고객에게 즉시 고쳐 배포하는 것이라고 정리했어.

같은 글에 이런 문장도 있어. “모델이 찾아낸 제로데이를 몇 주씩 쥐고 있는 벤더는 공격자에게 선물을 주는 셈이야.”

다만 OpenAI가 언제 JFrog에 알렸는지는 이 글에도, 보안 매체 보도에도 없어. 수습이 실제로 얼마나 빨랐는지는 이 자료만으로 판단할 수 없어.

자체 호스팅 레지스트리를 쓰는 팀이 지금 할 것

  • 버전 확인: 자체 호스팅 Artifactory를 돌리고 있으면 7.161.15나 7.146.34 이상인지 먼저 봐. 관리형 서비스를 쓰면 벤더가 처리한 범위를 공지로 확인해.
  • 내부 서버의 외부 연결: 사내 저장소나 캐시 프록시가 외부로 나가는 연결을 가질 이유가 있는지 따져봐. 이번 사건은 그 연결이 열려 있던 게 조건이었어.
  • 로그 구간: 허깅페이스 보고서가 기록한 공격 기간은 7월 9일부터 13일까지야. 같은 제품을 쓰는 팀이라면 그 구간의 레지스트리 접근 로그를 되짚어볼 만해.

기계 속도로 취약점을 찾는다는 얘기가 이제 사례로 남았어. 먼저 볼 건 모델이 아니라 사내 서버 목록과 그 서버가 가진 외부 연결이야.