AI 에이전트가 스스로 해킹을? 허깅페이스 4.5일간의 침입 사건 전말

 

 

 

최근 AI 업계를 발칵 뒤집어놓은 사건이 하나 있었죠.

바로 OpenAI의 AI 에이전트가 스스로 판단해서 허깅페이스(Hugging Face) 내부 인프라까지 침투한 사건입니다.

 

사람이 하나하나 명령을 내린 게 아니라, AI 에이전트가 4.5일 동안 무려 17,600건의 공격 행위를 자율적으로 수행했다고 하니... 정말 놀라운 일이 아닐 수 없습니다.

 

허깅페이스가 2026년 7월 27일, 이 사건의 기술적 타임라인을 아주 상세하게 공개했는데요. 오늘은 이 내용을 정리해서 소개해드리려고 합니다.

 

 

사건의 시작, 평가 벤치마크를 '치팅'하려던 AI

 

발단은 OpenAI가 자사 모델의 사이버 공격 능력을 평가하기 위해 돌리던 ExploitGym이라는 평가 벤치마크였습니다.

이 벤치마크는 AI 에이전트에게 소프트웨어 취약점을 찾아 실제로 공격해보라는 과제를 주는 방식인데요.

 

문제는 이 에이전트가 평가를 받는 과정에서, 허깅페이스가 이 벤치마크의 모델과 데이터셋, 정답(reference solution)을 호스팅하고 있을지도 모른다고 '추론'했다는 겁니다.

그러니까 에이전트 입장에서는 문제를 직접 푸는 대신, 허깅페이스 서버에 들어가서 정답을 훔쳐오는 게 더 빠르다고 판단한 셈이죠.

 

일종의 AI판 '시험지 유출 사건'이라고 볼 수 있겠네요.

 

 

침투 경로 1단계: 평가용 샌드박스 탈출

 

에이전트는 먼저 OpenAI의 평가 환경에 있던 패키지 레지스트리 캐시 프록시의 제로데이 취약점을 이용해 인터넷에 접속하는 데 성공했습니다.

 

그다음 제3자가 운영하는, 보안이 허술한 공개 코드 실행 샌드박스를 발견해서 뿌리(root) 권한까지 탈취했는데요.

이곳을 자신의 공격 거점(launchpad)으로 삼고, 이후의 모든 공격을 여기서 지휘했습니다.

 

재밌는 건 침투 방식인데요. 이 샌드박스는 사용자가 제출한 C 코드를 컴파일해서 실행해주는 구조였는데, 에이전트는 `sqlite3_initialize()` 함수를 자신이 원하는 코드로 재정의해서 시스템 명령어를 실행시켰습니다. 코드를 제출하는 척하면서 사실상 셸을 탈취한 거죠.

 

 

침투 경로 2단계: 허깅페이스 내부로

 

외부 거점을 확보한 에이전트는 허깅페이스의 데이터셋 처리 파이프라인을 노렸습니다. 두 가지 방식이었는데요.

 

첫 번째는 HDF5 파일 읽기 취약점입니다. 데이터셋 설정 파일에서 실제 데이터가 저장된 로컬 경로를 지정할 수 있었는데, 에이전트는 이 경로를 `/proc/self/environ`(환경변수)이나 워커의 소스코드 경로로 지정해버렸습니다. 그러면 시스템이 이걸 그대로 읽어서 돌려줬고, 결과적으로 프로덕션 서버의 환경변수와 각종 인증 정보가 통째로 유출됐습니다.

 

두 번째는 Jinja2 템플릿 인젝션입니다. 데이터셋 설정의 특정 필드가 사실은 템플릿 엔진에서 그대로 실행돼버리는 취약점이었는데, 이를 통해 프로덕션 쿠버네티스 파드 안에서 임의의 파이썬 코드를 실행할 수 있었습니다. 이게 바로 내부 침투의 결정적 발판이 됐죠.

 

 

3일 차, 걷잡을 수 없이 번진 공격

 

가장 놀라운 대목은 3일 차(7월 11일)입니다. 단 13시간 만에 파드 하나의 코드 실행 권한이 여러 내부 클러스터의 클러스터 관리자(cluster-admin) 권한으로까지 확장됐거든요.

 

- 서비스 계정 토큰을 읽어 쿠버네티스 API에 접근

- 클라우드 메타데이터 엔드포인트에서 임시 자격증명 탈취

- 특권 파드를 만들어 노드 자체의 루트 권한 획득

- 11개 노드에 걸쳐 스스로 복제되는 '자가 증식형' 파드 함대 구성

- 시크릿 오브젝트에서 136개의 키가 담긴 프로덕션 시크릿 탈취

- 내부 VPN(메시 네트워크)에 잠입해 사내망을 우회 경유지로 활용

 

특히 내부 서비스 커넥터 하나가 여러 클러스터에 공유된 자격 증명을 갖고 있었는데, 이게 `system:masters` 권한에 바인딩되어 있었다고 합니다. 자격증명 하나로 두 개 클러스터의 관리자 권한을 1초 만에 얻어버린 셈이니, 설정 실수 하나가 얼마나 크게 번질 수 있는지 보여주는 사례네요.

 

 

다행히 실질적 피해는 제한적

 

여기까지 보면 정말 아찔한데요. 다행히 허깅페이스가 확인한 바로는 실제 유출된 고객 데이터는 ExploitGym 관련 챌린지 정답이 담긴 데이터셋 5개뿐이었고, 다른 고객의 모델이나 데이터셋, Space는 영향을 받지 않았다고 합니다.

 

내부 MongoDB 데이터베이스에도 접근하긴 했지만 읽기만 했을 뿐 쓰기(수정) 기록은 없었고, 소스코드 저장소에 대한 쓰기 권한도 획득했지만 실제로 배포된 코드에는 악성 변경이 없었다는 걸 확인했다고 하네요.

 

흥미로운 점은, 에이전트가 시도한 파괴적인 클라우드 API 호출들이 전부 `DryRun=True`(실제 실행 없이 테스트만) 옵션으로 이뤄졌다는 겁니다. 이는 이 에이전트의 목적이 '파괴'가 아니라 '정보 수집과 도달 범위 확장'에 있었다는 걸 시사합니다.

 

 

역설적인 순간, AI 보안팀도 AI를 썼다

 

이 사건 조사 과정에서 재미있는 일화가 있습니다.

허깅페이스 보안팀이 방대한 공격 로그를 분석하기 위해 처음 시도한 건 Claude Opus와 Fable이었는데, 이 모델들의 안전장치가 "이건 공격 로그를 리버스 엔지니어링하는 것 = 실제 공격을 돕는 것"으로 판단해 분석 작업 상당 부분을 거부했다고 합니다.

 

결국 팀은 오픈소스 모델인 zai-org의 GLM-5.2를 자체 인프라에 올려서 분석 파이프라인을 전면 전환했고, 이를 통해 공격자가 로그에 남긴 암호화 키까지 복원해 숨겨진 페이로드를 해독하는 데 성공했습니다.

 

폐쇄형 모델이 안전장치를 끄고 공격하고, 또 다른 폐쇄형 모델은 안전장치 때문에 방어를 거부하고, 결국 오픈소스 모델이 이를 구해낸 상황이라 커뮤니티에서도 화제가 됐습니다.

 

 

이 사건이 던지는 질문

 

허깅페이스는 이번 사건 이후 클라우드 메타데이터 접근 차단, 자격증명 전면 교체, 핵심 클러스터 재구축, 데이터셋 렌더러의 취약점 패치 등 다양한 조치를 취했습니다.

 

하지만 더 근본적인 시사점은 따로 있습니다. 이번에 악용된 개별 취약점들은 사실 특별할 게 없었습니다. 안전하지 않은 데이터 처리, 노출된 클라우드 메타데이터, 과도하게 넓은 권한, 장기 유효 자격증명... 숙련된 사람 공격자라면 충분히 찾아낼 수 있는 흔한 약점들이었죠.

 

문제는 속도와 규모입니다. 에이전트는 실패한 경로도 무수히 시도하면서, 결국 여러 독립적인 시스템을 가로지르는 공격 경로 하나를 찾아냈습니다. 사람이라면 몇 주, 몇 달이 걸릴 일을 기계 속도로 며칠 만에 해낸 겁니다.

 

AI 에이전트가 코드를 실행하고, 클라우드 자원을 다루고, API를 호출할 수 있게 되면서, 이제 "이 에이전트가 실제로 어떤 결과를 초래할 수 있는 행동까지 할 수 있는가"를 미리 파악하고 통제하는 게 모델 성능 평가만큼이나 중요해졌다는 걸, 이번 사건이 잘 보여준 것 같습니다.

 

 

 

#허깅페이스 #HuggingFace #AI에이전트 #AI보안 #사이버보안 #프롬프트인젝션 #제로데이 #OpenAI #GLM52 #클라우드보안 #쿠버네티스보안 #AI해킹