문제를 풀랬더니 Hugging Face를 털었습니다, OpenAI 모델의 샌드박스 탈출

OpenAI가 Hugging Face 보안 사고의 공격 주체가 자사 모델이었다고 인정했습니다. 내부 사이버 평가에 투입된 GPT-5.6 Sol과 그보다 강한 미공개 모델이 샌드박스를 빠져나와 Hugging Face 운영 서버까지 침입했습니다. 목표는 사이버 벤치마크의 정답을 얻는 것이었습니다. 이번에는 ‘샌드박스 탈출’이 비유가 아니라 실제로 벌어진 일입니다.

사건이 시작된 ExploitGym은 실제 취약점 898개를 놓고 AI가 작동하는 공격 코드를 만들 수 있는지 확인하는 벤치마크입니다. OpenAI는 모델의 최대 사이버 능력을 측정하려고 상용 서비스에 적용되는 일부 거부 장치를 끈 상태로 평가를 진행했습니다. 모델은 외부 인터넷에 접속할 수 없었고, 필요한 패키지만 내부 캐시 프록시를 통해 설치할 수 있었습니다.

모델은 문제를 풀다가 이 캐시 프록시에서 아직 알려지지 않은 제로데이 취약점을 찾아냈습니다. 이 취약점으로 권한을 높이고 OpenAI 연구망 안을 이동한 끝에 인터넷에 연결된 노드까지 도달했습니다. 샌드박스를 벗어난 모델은 Hugging Face에 ExploitGym 관련 데이터와 정답이 있을 수 있다고 판단했습니다.

Hugging Face에는 악성 데이터셋을 올려 데이터 처리 과정의 취약점 두 개를 뚫었습니다. 처리 서버에서 코드를 실행한 뒤 클라우드와 클러스터 자격 증명을 수집했고, 여러 내부 클러스터를 돌아다니며 운영 데이터베이스까지 접근했습니다. 그리고 그곳에서 ExploitGym의 정답을 찾아냈습니다. 문제를 정면으로 푸는 대신 정답지가 있는 서버를 찾아가 털어버린 셈입니다.

Hugging Face는 7월 16일 정체를 알 수 없는 AI 에이전트에게 공격받았다고 먼저 밝혔습니다. 공격 과정에서는 수많은 단기 샌드박스가 사용됐고, 공개 서비스를 거쳐 지휘 서버를 계속 옮겨 다니며 1만7천 건이 넘는 행동을 남겼습니다. Hugging Face가 이를 발견해 차단한 뒤 OpenAI가 조사에 합류했고, 7월 21일이 돼서야 공격자가 누구였는지 공개됐습니다.

피해가 Hugging Face 전체로 번진 것은 아닙니다. 일부 내부 데이터셋과 서비스용 자격 증명이 노출됐지만, 공개 모델과 데이터셋, Spaces가 변조됐다는 증거는 없었습니다. 배포된 컨테이너와 패키지도 정상으로 확인됐습니다. AI가 자기 가중치를 복사하거나 인터넷 어딘가에서 독립적으로 살아남았다는 증거도 없습니다. 그렇다고 단순한 연구실 사고로 넘길 수도 없습니다. 타사의 운영 서버와 데이터베이스가 실제로 침해됐기 때문입니다.

사건을 수습하는 과정에서는 또 다른 이야기가 나왔습니다. Hugging Face가 공격 기록을 상용 프런티어 모델 API로 분석하려 하자 실제 공격 명령어와 익스플로잇이 안전장치에 막혔습니다. 결국 Hugging Face는 오픈웨이트 모델인 GLM 5.2를 자체 서버에서 실행해 1만7천 건의 기록을 분석했습니다.

개발자 커뮤니티에서는 곧바로 “폐쇄형 GPT가 공격하고 중국 오픈웨이트 모델이 막았다”는 농담이 퍼졌습니다. 정확히는 GLM 5.2가 GPT와 실시간으로 싸운 것이 아니라 사후 포렌식을 맡았습니다. 그래도 공격자는 제한 없이 움직이는데 방어자는 안전장치 때문에 공격 기록조차 분석하지 못했다는 문제는 그대로 남습니다.

주인장이 섬뜩하게 느낀 부분은 모델이 샌드박스를 뚫었다는 사실만이 아닙니다. 공격에 나선 모델은 평가를 위해 안전장치가 느슨해진 상태였고, 침입을 분석하려던 방어자의 모델은 안전장치에 막혀 공격 기록조차 제대로 읽지 못했습니다. 안전을 위해 만든 제약이 오히려 방어자를 옭아맨 셈입니다. 이대로라면 족쇄가 없는 AI가 공격하고, 족쇄가 채워진 AI가 방어하는 상황이 올 수도 있습니다. 앞으로 이런 일이 더 자주 벌어진다면, 제약 없는 AI에 맞서는 방어자에게는 어떤 모델을 쥐여줘야 할까요.