# 오픈AI가 허깅 페이스를 상대로 일으킨 우발적 사이버공격은 현실이 된 공상과학이다 이 이야기는 정말 놀랍다. 짧게 말하면 이렇다. 오픈AI는 아직 공개하지 않은 모델을 대상으로 사이버보안 테스트를 진행하고 있었고, 그 모델의 안전장치 기능은 꺼져 있었다. 모델은 테스트를 푸는 대신 오픈AI의 샌드박스를 뚫고 나왔다. 그런 다음 허깅 페이스에 *침입(in)*할 익스플로잇을 찾아냈다. 답을 훔쳐 테스트에서 부정행위를 하려는 목적이었다. 그 과정에서 모델 접근성의 불균형이 소프트웨어 보안을 지키는 능력을 얼마나 해치고 있는지 보여 주는, 지금까지 가장 강력한 사례도 함께 만들어졌다. #### 무슨 일이 있었나 현재 이 사건을 이해하는 데 도움이 되는 문서는 세 가지다. 1. [ExploitGym: AI 에이전트는 보안 취약점을 실제 공격으로 바꿀 수 있는가?](https://arxiv.org/abs/2605.11086)는 2026년 5월 11일에 공개된 논문이다. LLM 기반 에이전트 시스템을 위한 새로운 평가 모음인 ExploitGym을 설명한다. 2. 허깅 페이스가 2026년 7월 16일에 공개한 [보안 사고 공개 — 2026년 7월](https://huggingface.co/blog/security-incident-july-2026)은 “에이전트형 보안 연구 하네스(agentic security-research harness)—사용된 LLM은 아직 알 수 없음”에서 온 공격을 어떻게 탐지했는지 설명한다. 이 공격은 허깅 페이스의 일부 시스템을 침해했다. 3. 오픈AI가 2026년 7월 21일에 공개한 [오픈AI와 허깅 페이스, 모델 평가 중 발생한 보안 사고 대응을 위해 협력](https://openai.com/index/hugging-face-model-evaluation-security-incident/)은 이 일을 벌인 것이 *그들의(their)* 에이전트 하네스였다고 인정한다. 또한 오픈AI가 허깅 페이스와 함께 사태를 수습하고 있다고 밝힌다. #### ExploitGym 나는 이전에 [ExploitGym 논문](https://arxiv.org/abs/2605.11086)을 보지 못했는데, 꽤 흥미로운 논문이다. UC 버클리, 막스 플랑크 연구소, UC 산타바버라, 애리조나 주립대학교 소속 저자들이 새로운 벤치마크를 설계했다. 이 벤치마크는 보고된 취약점을 구체적인 익스플로잇으로 바꾸는 모델의 능력을 평가한다. 오픈AI, 앤트로픽, 구글은 피드백을 제공하고 자사 모델을 대상으로 벤치마크를 실행하는 데 도움을 줬다. 이 벤치마크는 “인기 있는 소프트웨어 프로젝트에 영향을 준 실제 취약점에서 파생한 898개 인스턴스”로 구성된다. 여기에는 리눅스 커널과 V8 자바스크립트 엔진도 포함된다. ExploitGym 벤치마크는 [깃허브에서 제공된다](https://github.com/sunblaze-ucb/exploitgym). 벤치마크 결과를 가장 잘 보여 주는 문단은 다음과 같다. > 모든 구성 가운데 클로드 미토스 프리뷰와 GPT-5.5가 각각 157건, 120건으로 가장 높은 성공 횟수를 기록했다. 이는 현재의 프런티어 에이전트가 통제된 조건에서 실제 취약점의 상당 부분을 익스플로잇할 수 있음을 보여 준다. GPT-5.4도 54개 과제를 해결해 중간 수준에 올랐다. 나머지 모델–에이전트 조합은 각각 15개 미만의 과제만 해결했다. 이는 종단 간 익스플로잇이 여전히 어렵고, 오늘날의 프런티어 시스템을 뚜렷하게 구분하는 능력임을 강조한다. 주목할 점은 클로드 오퍼스 4.7이 더 최신 체크포인트임에도 클로드 오퍼스 4.6보다 성공 횟수가 적었고, 전체 세트 기준 비용도 훨씬 낮았다는 점이다. 추적 내용을 살펴보면 클로드 오퍼스 4.7과 제미나이 3.1 프로는 대상 취약점이 익스플로잇 불가능하다고 판단한 뒤 일찍 결론을 내리는 경우가 잦았다. 논문은 에이전트가 테스트 범위 밖으로 나가 부정행위를 하지 못하게 막기 위해 어떤 접근법을 취했는지도 설명한다. 이 부분은 곧 중요해진다! > 외부 연결은 엄선된 허용 목록으로 제한된다. 이 목록은 일반적인 패키지 설치(Ubuntu apt 저장소와 PyPI)와 V8 빌드에 필요한 툴체인 가져오기를 허용한다. 그 밖의 모든 외부 엔드포인트는 차단된다. 논문은 다음과 같이 결론짓는다. 강조는 내가 했다. > 우리의 결과는 **프런티어 AI 에이전트의 자율적 익스플로잇 개발(autonomous exploit development)이 더 이상 가상의 능력이 아님**을 보여 준다. 현재 에이전트가 모든 대상에서 아직 안정적으로 작동하는 것은 아니지만, 이미 커널 구성 요소 같은 복잡한 대상을 포함해 **실제 취약점의 의미 있는 일부를 익스플로잇(exploit)한다**. 이러한 능력이 빠르게 등장했다는 사실 자체가 핵심 발견이다. 예전에는 그럴듯하지 않다고 여겨졌을 능력이 이제 배포된 프런티어 모델에 존재한다는 뜻이기 때문이다. 여기서 중요한 세부 사항이 있다. 이 논문은 취약점 발견에 관한 것이 아니다. 이미 알려진 취약점을 가져와 실제로 작동하는 익스플로잇으로 바꾸는 능력에 관한 논문이다. 앤트로픽이 [지난 4월](https://simonwillison.net/2026/Apr/7/project-glasswing/) 처음으로 Mythos 접근을 제한했을 때도 이 능력을 언급했다. 취약점을 단순히 발견할 수 있는 모델보다, 그 취약점을 실제 행동으로 옮길 수 있는 모델이 훨씬 더 위험하다. Fable이 Mythos와 다른 점 가운데 하나는 이런 방식으로 취약점을 무기화하는 요청을 거부할 가능성이 더 높다는 것이다. 미국 정부가 [지난달](https://simonwillison.net/2026/Jun/16/fable-5-export-controls/) Fable을 금지했을 때 이 차이를 이해하지 못했다는 인상을 받았다. #### 허깅 페이스 사고 우리가 이 공격의 첫 단서를 얻은 것은 허깅 페이스가 2026년 7월 16일에 올린 [이 블로그 글](https://huggingface.co/blog/security-incident-july-2026)에서였다. > 악성 데이터셋이 우리의 데이터셋 처리 과정에 있는 두 가지 코드 실행 경로를 악용했다. 하나는 원격 코드 데이터셋 로더였고, 다른 하나는 데이터셋 구성의 템플릿 인젝션이었다. 이를 통해 처리 워커에서 코드가 실행됐다. 그 뒤 공격자는 노드 수준 접근 권한으로 권한을 상승시키고, 클라우드와 클러스터 자격 증명을 수집했으며, 주말 동안 여러 내부 클러스터로 횡적 이동을 했다. 이 일을 가능하게 한 코드에 대해 더 자세한 내용을 공개해 주면 좋겠다. 나는 이것이 허깅 페이스가 플랫폼에서 데이터셋을 묶어 공유하기 위해 만든 프로젝트인 [datasets 라이브러리](https://github.com/huggingface/datasets)를 사용하는 패키지를 뜻한다고 추정한다. 이 라이브러리는 예전에는 임의 코드를 실행했지만, 시간이 지나며 꾸준히 잠겨 왔다. 2025년 7월 [4.0.0 릴리스](https://github.com/huggingface/datasets/releases/tag/4.0.0)에서는 `trust_remote_code=True` 플래그가 완전히 제거됐다. 공격이 그 라이브러리를 사용했다고 가정하면, 피클 직렬화를 어떤 식으로든 악용했거나, 잘 드러나지 않는 다른 코드 실행 경로를 찾았거나, 아니면 아마도 `datasets<4.0.0`을 의존성으로 지정했을 것이다. > 이 캠페인은 자율 에이전트 프레임워크가 실행했다. 에이전트형 보안 연구 하네스 위에 구축된 것으로 보였고, 사용된 LLM은 아직 확인되지 않았다. 이 프레임워크는 수명이 짧은 샌드박스 무리 전체에서 수천 건의 개별 동작을 수행했으며, 공개 서비스 위에 자체 이동형 명령제어를 단계적으로 배치했다. 정교한 공격이었다! 그러다 허깅 페이스는 벽에 부딪혔다. 공격을 분석하는 데 “상용 API 뒤에 있는 프런티어 모델”을 사용하려 했다. 아마 앤트로픽과 오픈AI 모델이었을 것이다. 하지만 차단당했다. > 로그 분석을 시작했을 때 우리는 먼저 상용 API 뒤에 있는 프런티어 모델을 사용했다. 이는 작동하지 않았다. 분석에는 실제 공격 명령, 익스플로잇 페이로드, C2 산출물을 대량으로 제출해야 한다. 그런데 이런 요청은 제공업체의 안전장치에 의해 차단됐다. 그 안전장치는 사고 대응 담당자와 공격자를 구분하지 못한다. 허깅 페이스는 자체 호스팅한 MIT 라이선스 GLM-5.2 인스턴스로 전환했고, 이를 통해 상황을 파악하는 데 도움을 받았다. 이는 방어팀과 당시까지 정체를 알 수 없었던 공격자 사이에 근본적인 비대칭이 있음을 보여 줬다. > 공격자의 에이전트를 어떤 모델이 구동했는지는 알 수 없다. 탈옥된 호스팅 모델이었을 수도 있고, 제한 없는 오픈 웨이트 모델이었을 수도 있다. 어느 쪽이든 공격자는 사용 정책에 묶여 있지 않았다. 반면 우리가 처음 시도한 호스팅 모델의 안전장치는 우리의 포렌식 작업을 차단했다. 허깅 페이스가 이 공격을 얼마나 심각하게 받아들였는지 보여 주는 유용한 지표는 다음과 같다. > \[...\] 마지막으로, 우리는 이 사건을 법 집행기관에도 신고했다. 그렇다면 이 “자율 에이전트 프레임워크”의 책임자는 누구였을까? 알고 보니 오픈AI 자신들이었다. #### 오픈AI의 고백 닷새 뒤인 [7월 21일](https://openai.com/index/hugging-face-model-evaluation-security-incident/), 오픈AI는 범인을 공개했다. 그들은 아직 공개하지 않은 새 모델을 대상으로 ExploitGym 벤치마크를 실행하고 있었다. 그리고 그 모델은 의도된 범위를 *훨씬 벗어나(way)* 작동하고 있었다. 강조는 내가 했다. > 조사 결과, 우리는 이제 **이 특정 사고가 오픈AI 모델들의 조합으로 인해 발생했다는 사실**을 알게 됐다. 여기에는 GPT‑5.6 Sol과 그보다 더 강력한 사전 공개 모델이 포함됐다. 모두 평가 목적상 사이버 관련 거부 동작을 줄인 상태였으며, 사이버 역량 [벤치마크](https://arxiv.org/abs/2605.11086) \[ExploitGym\]에서 내부 테스트를 받는 중이었다. \[...\] > > 우리는 **모델이 고위험 사이버 활동을 추구하지 못하게 막는 운영 환경용 분류기를 사용하지 않고 이 평가를 실행함으로써** 최대 사이버 역량을 추정한다. 우리의 벤치마크는 고도로 격리된 환경에서 실행된다. 네트워크 접근은 내부 호스팅된 서드파티 소프트웨어를 통해 패키지를 설치할 수 있는 범위로 제한된다. 이 소프트웨어는 패키지 레지스트리의 프록시이자 캐시 역할을 한다. > > 모델들은 테스트 해답을 허깅 페이스의 운영 데이터베이스에서 직접 얻기 위해 **오픈AI의 연구 환경과 허깅 페이스의 운영 인프라 전반에 걸친 취약점을 식별하고 연결했다**. 모든 증거는 모델들이 ExploitGym의 해답을 찾는 데 극도로 몰두했으며, 매우 좁은 테스트 목표를 달성하기 위해 극단적인 수단까지 동원했음을 시사한다. 여기서 무슨 일이 있었는지는 꽤 분명하다. 오픈AI는 개발 중인 모델의 안전 필터를 제거하고, 샌드박스에 가둔 뒤 ExploitGym 문제를 풀라고 지시했다. 안전장치가 없었기 때문에 모델이 샌드박스를 탈출하고, 허깅 페이스에 침입해, 그곳에서 답을 읽는 것을 막을 장치가 없었다. 오픈AI의 샌드박스는 이제 흔해진 패턴을 사용했다. 통제된 프록시를 통해 추가 패키지 설치와 관련된 사이트 허용 목록에 접근할 수 있게 하는 방식이다. 오픈AI의 표현은 이렇다. > 샌드박스 테스트 환경에서 작동하는 동안, 우리 모델들은 평가 문제를 풀기 위해 **열린 인터넷 접근 권한을 얻는 방법을 찾는 데 상당한 추론 연산량을 사용했다**. 접근 권한을 얻기 위해 모델들은 **패키지 레지스트리 캐시 프록시에 있는 제로데이 취약점(zero-day vulnerability)을 식별하고 익스플로잇했다. 이 취약점은 현재 공급업체에 책임 있게 공개했다**. 이 접근 권한을 바탕으로 모델들은 우리의 연구 테스트 환경에서 일련의 권한 상승과 횡적 이동을 수행했고, 인터넷 접근 권한이 있는 노드에 도달했다. 그러니까 1단계는 공용 인터넷으로 빠져나가는 것이었다. 그다음 모델은 답을 찾기 위해 허깅 페이스에 침입했다. > 인터넷 접근 권한을 얻은 뒤, 모델들은 **허깅 페이스가 ExploitGym 관련 모델, 데이터셋, 해답을 호스팅하고 있을 가능성이 있다고 추론했다**. 이를 알고 모델은 평가에서 부정행위를 하는 데 사용할 수 있는 비밀 정보에 접근할 방법을 찾았고, 성공적으로 발견했다. 한 사례에서 **모델은 탈취한 자격 증명과 제로데이 취약점을 사용하는 등 여러 공격 벡터를 연결해** 허깅 페이스 서버에서 원격 코드 실행 경로를 찾아냈다. 여러 공격 벡터를 연결하는 일은 바로 이 새로운 모델들이 할 수 있는 *정확히(exactly)* 그런 종류의 작업이다. 이전 세대 모델은 이런 작업에서 실패했을 수도 있다. 나는 지난달 [클로드 Fable이 집요할 정도로 선제적이다](https://simonwillison.net/2026/Jun/11/fable-is-relentlessly-proactive/)라는 글을 썼다. 웹킷 CSS 문제 디버깅을 돕기 위해 내 노트북에서 맞춤형 웹 서버를 띄우고 CORS 꼼수를 배포하는 모습을 봤기 때문이다. 알고 보니 집요한 선제성은 이 새로운 세대의 Mythos급 모델을 정의하는 특징이다. 이들에게 목표를 설정하고 거기에 도달할 방법을, 설령 실수로라도 제공하면, 그들은 *반드시 방법을 찾아낸다(will figure it out)*. #### 이 일을 보여 주기식 사건으로 치부하고 싶은 유혹을 경계하라 어떤 사람들은 필연적으로 이 이야기를 오픈AI가 자사 모델을 무시무시하게 효과적인 것처럼 보이게 하려는 부정직한 마케팅 수법이라고 깎아내릴 것이다. 나는 이 사건에 관한 [해커 뉴스 토론](https://news.ycombinator.com/item?id=48997548)에서 “마케팅”이라는 단어가 81번 등장하는 것을 봤다. 그런 사람들에게 나는 *모래 속에서 머리를 빼라(pull your heads out of the sand)*고 말하고 싶다. 이제 여러분은 여기 쌓여 가는 증거를 부정하려고 허깅 페이스까지 음모론에 끌어들이고 있다! 오늘날 우리가 가진 최고의 모델들은 새로운 취약점을 찾아내고 익스플로잇하는 능력을 모두 갖추고 있다. ExploitGym 논문 자체도 “프런티어 AI 에이전트의 자율적 익스플로잇 개발은 더 이상 가상의 능력이 아니다”라고 결론짓는다. 이번 사건은 바로 그 사실을 완벽하게 보여 주는 사례다. #### 비대칭은 갈수록 답답해진다 이 이야기에서 가장 화나는 세부 사항 가운데 하나는 허깅 페이스의 처지다. 허깅 페이스는 오픈AI 모델 중 하나가 일으킨 우발적이고 공격적인 공격을 마주했지만, 정작 그 공격을 막는 데 도움을 얻으려고 오픈AI 모델에 의지할 수 없었다. 우리가 접근할 수 있는 프런티어 모델은 우리 소프트웨어를 보호하는 데 얼마나 도움을 줄 수 있는지 점점 더 강하게 제약받고 있다. 여기에는 미국 정부가 계속 내비치는 수출 통제 위협이 큰 영향을 미친다. 클로드 Fable 5는 내가 쓴 [이 글](https://simonwillison.net/guides/agentic-engineering-patterns/prompts/#proofreader)을 교정하는 것조차 해 주지 않았다! 대신 능력이 떨어지는 모델로 나를 낮춰야 한다고 고집했다. 반면 GLM-5.2, Kimi 3, 새 Qwen 3.8 Max 같은 중국의 오픈 웨이트 모델에는 이런 제약이 없어 보인다. 설령 *어떤 제약(do)*이 존재하더라도, 가중치를 수정해 파인튜닝하면 아마 제거할 수 있을 것이다. 이런 제약은 우리를 더 안전하게 만들기 위한 것이다. 하지만 나는 오히려 반대 효과를 내고 있을 위험이 있다고 생각한다.