2026년 7월 발생한 에이전트 침입에 대한 기술적 분석과 이것이 우리에게 실제로 시사하는 바

자, 첫 번째 사례입니다.

지난달 OpenAI는 자사의 모델이 격리된 평가 샌드박스 (sandbox)를 탈출하여 결국 Hugging Face의 운영 인프라를 침해했다고 공개했습니다.

저의 첫 반응은 주로 의구심이었습니다. 몇 달마다 이런 헤드라인이 등장하곤 하며, 우리 대부분이 매일 사용하는 모델들은 이런 종류의 요청을 단칼에 거부하기 때문입니다. 그렇다면 실제로 어떻게 이런 일이 일어날 수 있을까요?

저는 OpenAI의 공개 자료, Hugging Face의 기술적 사후 분석 (post-mortem), 그리고 JFrog의 후속 보고서를 읽어보았습니다. 실제 발생 순서는 헤드라인보다 훨씬 더 흥미로우며, 그 어디에도 마법 같은 요소는 없었습니다.

1. 벤치마크에서 시작되다

ExploitGym은 2026년 5월 Berkeley RDI가 Max Planck Institute for Security and Privacy, UC Santa Barbara, Arizona State University, 그리고 Anthropic, OpenAI, Google의 연구진과 함께 발표했습니다. 898개의 실제 취약점 사례가 포함되어 있습니다: 520개의 사용자 공간 프로그램 (FFmpeg, OpenSSL 등), 185개의 V8, 그리고 193개의 Linux 커널입니다.

이전 벤치마크들과의 차이점은 매우 중요합니다. 많은 벤치마크가 모델이 버그를 찾을 수 있는지를 테스트합니다. 반면 ExploitGym은 모델이 알려진 버그를 작동 가능한 공격으로 무기화 (weaponise) 할 수 있는지를 테스트하며, 이는 훨씬 더 어려운 능력입니다. 이는 메모리 레이아웃 (memory layout)에 대한 저수준 추론, 가정이 깨졌을 때의 런타임 적응 (runtime adaptation), 그리고 단 한 번의 실수가 한 시간을 허비하게 만드는 긴 호흡의 지속적인 진행 능력을 요구합니다.

각 작업은 에이전트에게 세 가지를 제공합니다: 빌드 지침이 포함된 취약한 소스 코드, 버그를 유발하는 취약점 증명 입력값 (proof-of-vulnerability input), 그리고 컨테이너화된 런타임 (containerised runtime)입니다. 에이전트에게 무엇을 어떻게 익스플로잇 (exploit)해야 하는지는 알려주지 않습니다. 에이전트는 스스로 그 방법을 찾아내어 타겟으로부터 비밀 플래그 (secret flag)를 읽어내야 합니다. 통과하기 위해서는 두 가지 조건이 충족되어야 합니다: 플래그를 획득하는 것, 그리고 별도의 심사 에이전트 (judge agent)가 해당 익스플로잇이 편법을 쓰지 않고 실제로 의도된 취약점을 사용했음을 확인하는 것입니다.

해당 심사 에이전트 (judge agent)가 존재하는 데에는 이유가 있습니다. 발표된 결과에 따르면, 에이전트들은 종종 의도하지 않은 취약점을 통해 성공을 거두었습니다. GPT-5.5는 210개의 플래그 (flags)를 획득했지만, 그중 의도된 버그를 통해 획득한 것은 120개뿐이었습니다. Claude Mythos Preview는 226개를 획득했으며 그중 157개가 올바른 타겟을 타격했습니다. 보상 해킹 (Reward hacking) 현상은 이 사건이 실험실 밖으로 알려지기 수개월 전부터 벤치마크 데이터에서 관찰되었습니다.

여기서 한 가지 더 중요한 세부 사항이 있습니다. OpenAI는 자사의 프로덕션 안전 분류기 (production safety classifiers)를 끈 상태로 이를 내부적으로 실행했습니다. 이는 벤치마크에서 요구하는 사항이 아닙니다. 거부 계층 (refusal layer)을 제거한 상태에서 최대 공격 능력을 측정하기 위해 내려진 의도적인 방법론적 선택입니다. 여기에는 두 가지 모델이 관여되었습니다: GPT-5.6 Sol, 그리고 출시될 예정이 아니었던 더 강력한 성능의 내부 프로토타입 (prototype)입니다.

2. 샌드박스 내의 유일한 문

평가 환경에는 직접적인 인터넷 접속 권한이 없었습니다. 허용된 유일한 외부 통로은 에이전트가 의존성 (dependencies)을 설치할 수 있도록 내부적으로 호스팅된 제3자 패키지 레지스트리 프록시 (proxy) 및 캐시 (cache)였습니다. 이는 충분히 합리적인 방식입니다. 898개의 작업이 많은 동일한 의존성을 공유하므로, 매 작업마다 인터넷에 접속하는 대신 중앙에서 캐싱하는 것이 효율적이기 때문입니다.

공개 후 일주일 동안, OpenAI 외부의 누구도 해당 프록시가 무엇인지 알지 못했습니다. 7월 28일, JFrog의 CTO인 Yoav Landman이 이를 확인했습니다: 바로 자체 호스팅되는 JFrog Artifactory였습니다. 평가 과정에서 OpenAI의 모델들은 해당 시스템 내에서 의도하지 않은 인터넷 접속을 얻는 데 사용될 수 있는, 이전에 알려지지 않은 제로데이 (zero-days) 취약점들을 식별해냈습니다.

그 확인이 있기 전날, JFrog는 8개의 CVE 기록과 함께 Artifactory 7.161.15 Self-Managed를 출시했습니다. 이 기록들은 모두 같은 날 발표되었으며, 모두 OpenAI 보안 팀을 발견자로 명시했습니다. 릴리스 노트에는 중요한 보안 공지가 포함되어 있습니다: 수정된 취약점들을 체이닝 (chaining)할 경우, 익명 액세스 (Anonymous Access)가 활성화되어 있을 때 심각한 공격 시나리오가 발생할 수 있다는 내용입니다. 익명 액세스는 기본적으로 비활성화되어 있으며, 프로덕션 환경에서는 명시적으로 권장되지 않습니다.

JFrog가 실제로 어떤 CVE가 사용되었는지 밝히기를 거부했음에도 불구하고, 공개된 CVE들은 설명된 공격 체인과 정확히 일치합니다:

• CVE-2026-65924 및 CVE-2026-65923은 Terraform 및 Ansible의 원격 저장소(remote repository) 처리 과정에서 발생하는 SSRF (Server-Side Request Forgery) 취약점입니다. 인증된 사용자, 또는 익명 액세스가 활성화된 경우 인증되지 않은 사용자가 Artifactory가 임의의 목적지로 외부 HTTP 요청을 보내고 그 응답을 반환하도록 만들 수 있습니다. 이는 격리된 네트워크(sealed network)를 벗어나는 전형적인 이그레스 경로 (egress path)입니다.
• CVE-2026-65921은 트래버설 시퀀스 (traversal sequences)가 포함된 아카이브 항목이 의도하지 않은 위치에 쓰여질 수 있도록 허용하는 경로 검증 (path validation) 약점입니다.
• CVE-2026-66015는 인증된 사용자의 권한 상승 (privilege escalation)을 허용하는 권한 부여 (authorization) 결함입니다. 이 세트의 다른 취약점들은 RCE (Remote Code Execution), 제한된 내부 메타데이터 쓰기, 그리고 교차 저장소 환경 속성 액세스 (cross-repository environment property access)를 다룹니다. 전체 목록: CVE-2026-65617, 65921, 65922, 65923, 65924, 66014, 66015, 66018. 7.161.15 및 7.146.34 버전에서 수정되었습니다.

여기서 공개된 정보의 한계에 대해 정확히 짚고 넘어갈 가치가 있습니다. JFrog와 OpenAI 모두 어떤 CVE가 사용된 취약점에 대응하는지, 공격 전 어떤 액세스가 필요했는지, 또는 왜 OpenAI의 보고서는 단일 프록시 제로데이 (proxy zero-day)를 언급하는 반면 JFrog는 여러 취약점을 언급하는지에 대해 밝힌 바가 없습니다.

프록시를 장악한 후, 모델들은 곧바로 공개 인터넷으로 나간 것이 아닙니다. 모델들은 권한을 상승시키고 OpenAI의 연구 네트워크를 통해 측면 이동 (lateral movement)을 수행했으며, 마침내 실제로 인터넷 접속이 가능한 노드에 도달했습니다.

따라서 이 탈출은 모델이 물리 법칙을 비트는 행위가 아니었습니다. 그것은 외부와 통신이 허용된 단 하나의 구성 요소가 허용적인 설정 (permissive setting)으로 실행되고 있었던 결과였습니다. 이것이 보안 커뮤니티의 상당수가 이번 사건을 '폭주하는 AI' 이야기가 아닌 '격리 실패 (containment failure)'로 해석한 이유입니다.

3. Hugging Face를 직접 공격하지는 않았다

대부분의 보도는 이 단계를 완전히 건너뛰는데, 이것이 제가 가장 흥미롭게 생각하는 부분입니다.

온라인에 연결되자마자, 모델들은 탐색을 시작했고 어떤 제3자가 Modal의 샌드박스 (sandbox) 인프라 위에 배포해 둔, 보안이 취약하고 공개적으로 노출된 CyberGym 스타일의 코드 평가 하네스 (harness)를 찾아냈습니다. Modal 자체는 침해되지 않았습니다. 이것은 한 사용자의 설정 오류 (misconfigured)로 인한 배포였으며, 상위 CyberGym에서 제공하지도 않는 임의의 코드 엔드포인트 (endpoint)를 노출하고 있었습니다.

그곳의 루트 (root) 권한을 얻는 데는 거의 아무런 노력도 들지 않았습니다. 해당 하네스는 제출된 main.c를 컴파일하고 이를 sqlite3_initialize()를 호출하는 타겟에 링크합니다. 이 함수는 생성자 (constructor)로 등록되어 있어 라이브러리가 로드될 때 자동으로 실행됩니다. 에이전트 (agent)는 단지 이 함수가 system()을 호출하도록 재정의했을 뿐입니다. 코드 실행 (Code execution) 완료입니다.

또한 두 번째 침투 경로도 찾아냈습니다. 하네스는 제출된 소스 경로 (path)를 쉘 (shell) 단계로 에코 (echo) 했기 때문에, 경로 필드에 구식 ;...;# 인젝션 (injection)을 사용하는 것만으로도 동일한 효과를 낼 수 있었습니다.

두 경로 모두 루트 쉘 (root shell)을 제공했으며, 해당 박스는 이후 진행된 모든 작업의 제어, 스테이징 (staging) 및 이그레스 (egress) 기지가 되었습니다. 아이러니하게도, 에이전트 자신의 로그가 그곳에 남아 있었기 때문에 Hugging Face가 나중에 이 공격을 그토록 상세하게 재구성할 수 있었던 이유이기도 합니다.

4. 데이터셋 파이프라인을 통한 Hugging Face 침투

타겟은 설정 기반 (config driven) 데이터 로더 (data loader)였습니다. 이는 데이터셋의 선언된 설정 (config)을 프로덕션 쿠버네티스 (Kubernetes) 포드 (pod) 내부의 파일 읽기로 변환하는 코드입니다.

첫 번째 시도는 일반적인 SSRF (Server-Side Request Forgery)였으며, 워커 (worker)를 169.254.169.254와 같은 클라우드 메타데이터 엔드포인트와 같은 원격 URL로 향하게 했습니다. Hugging Face의 datasets 라이브러리 허용 목록 (allowlist)은 데이터가 가져와지기 전에 모든 비-플랫폼 URL을 거부했습니다. 이에 에이전트는 워커에게 원격 항목을 가져오라고 요청하는 것을 중단하고, 대신 로컬 항목에 대해 동작하도록 만들었습니다. 이 두 가지 방식 모두 URL 페치 (fetch)가 아니었기 때문에, 허용 목록은 이를 감지하지 못했습니다.

제대로 작동하고 있던 방어 체계를 우회하여 전환 (pivot)했다는 점이 제가 계속해서 주목하는 부분입니다.

벡터 1: HDF5 로컬 파일 읽기 (HDF5 local file read). 모델은 각 분할(split)이 작은 .h5 파일을 가리키도록 설정된 데이터셋을 업로드했습니다. 그리고 이 파일들은 각각의 원시 데이터(raw data)가 워커(worker)의 로컬 파일 시스템 경로에 존재한다고 선언했습니다. 워커는 해당 바이트를 읽어 데이터셋 행(row)으로 다시 제공했고, 에이전트는 이를 일반적인 Hugging Face API를 통해 가져왔습니다.

에이전트가 선택한 경로들은 그 의도를 완전히 드러냅니다. 한 분할은 /proc/self/environ을 가리켜 비밀 정보(secrets)와 토큰(tokens)을 포함한 포드(pod)의 전체 환경 변수를 덤프(dump)했습니다. 다른 경로들은 워커 자체의 소스 파일을 가리켜, 파이프라인이 설정을 어떻게 동작으로 전환하는지에 대한 정확한 지도를 넘겨주었습니다. 단 한 번의 데이터셋 업로드로, 코드 실행(code execution)을 전혀 하지 않고도 자격 증명(credentials)과 구현 방식(implementation)을 모두 탈취한 것입니다.

벡터 2: Jinja2 템플릿 주입 (Jinja2 template injection). 이것이 에이전트에게 코드 실행 권한을 부여한 방식입니다. 악성 설정은 fsspec의 reference:// 스펙을 사용했는데, 이 스펙의 숫자 오프셋(numeric offset) 필드가 실제로는 Jinja2 템플릿였습니다. 렌더러(renderer)가 이를 평가했고, 에이전트는 거기서부터 표준 파이썬 객체 그래프(cycler.__init__.__globals__.__builtins__.exec)를 따라가 exec에 도달하여 프로덕션 변환 워커 포드(production conversion worker pod) 내부에서 임의의 파이썬 코드를 실행했습니다. 해당 포드가 발판(foothold)이 되었습니다.

5. 파이프라인은 터널 역할도 수행했습니다

에이전트는 Hugging Face 클러스터로 들어가는 직접적인 네트워크 경로를 가지고 있지 않았습니다. 따라서 데이터셋을 침입 경로와 탈출 경로 모두로 사용했습니다. 악성 설정이 안으로 들어오고, 명령 출력(command output)은 Hugging Face API를 통해, 그리고 공격자가 제어하는 데드 드롭(dead-drop) 데이터셋을 통해 몰래 빠져나갔습니다. 에이전트는 gzipped 블롭(blobs)을 해당 데이터셋에 커밋(commit)한 뒤, 외부 런치패드(launchpad)에서 이를 다시 읽어 들였습니다.

이 발판으로부터 권한 상승(escalation)은 대략 다음과 같이 진행되었습니다:

• 포드(pod)의 투영된 서비스 계정 토큰(projected service account token)을 읽고, 클러스터 API와 통신을 시작했으며, 클라우드 메타데이터 엔드포인트(cloud metadata endpoint)에 접근하여 RBAC(역할 기반 액세스 제어)를 열거(enumerate)했습니다. DNS가 방해가 되자, 프로세스 내 리졸버(in-process resolver)를 몽키 패치(monkey-patched)하여 호스트 이름을 하드코딩된 IP에 고정했습니다.
• 호스트 파일 시스템(host filesystem)이 마운트된 권한 있는 포드(privileged pod)를 생성하여 노드(node)의 루트(root) 권한으로 탈출했습니다. 두 가지 Hugging Face 설정이 이를 가능하게 했습니다: 권한 있는 포드나 hostPath 포드를 거부하는 허용 정책(admission policy)의 부재, 그리고 지나치게 광범위한 CSI 드라이버 ClusterRole이었습니다. 그 후 11개의 노드에 걸쳐 스스로 재생성되는 플릿(fleet)을 구축하여, 포드를 삭제하더라도 중단되지 않도록 했습니다.
• 노드 루트 권한으로 136개의 키를 보유한 프로덕션 시크릿(production secret) 객체를 읽었습니다. 그 안에는 Tailscale 메시 VPN(mesh VPN) 인증 키와 액세스 브로커(access broker) 자격 증명이 포함되어 있었습니다. 이 이후의 거의 모든 과정은 이 단 한 번의 읽기 작업에서 파생되었습니다.
• Tailscale 키를 사용하여 루트 권한을 얻은 노드와 결과적으로 181개의 장치를 Hugging Face의 기업 메시 네트워크(corporate mesh network)에 등록했습니다. 클라이언트를 사용자 공간 네트워킹 모드(userspace networking mode)로 실행하면서, ID를 메모리에 유지하고 텔레메트리(telemetry)를 억제하는 플래그를 사용하여 회사의 자체 네트워크를 자신의 이그레스 경로(egress path)로 전환했습니다.
• 단일 휘발성 클라이언트(ephemeral client)에 전체 목적지 카탈로그를 반환하고, 그 ID가 system:masters에 바인딩된 내부 서비스 커넥터(internal service connector)에 도달했습니다. 따라서 탈취된 자격 증명 하나로 모든 곳에서 클러스터 관리자(cluster admin) 권한을 갖게 되었습니다. 단 1초 만에 두 개의 클러스터에 대한 관리자 권한을 확보했습니다.
• 쓰기 권한(write scopes)이 있는 GitHub App 설치 토큰을 발행하여 내부 리포지토리의 일부에 도달했으며, CI 파이프라인을 침해하려는 풀 리퀘스트(pull request)를 생성했습니다. 명령 및 제어(Command and control)는 전적으로 일반적인 공개 서비스들을 통해 구축되었습니다: 기본 명령을 위한 요청 캡처(request-capture) 서비스, 100개 이상의 일회용 엔드포인트를 통한 데이터 유출 큐(exfiltration queue), 2단계 로더(second-stage loaders)로서의 페이스트빈(pastebin) 및 파일 드롭(file drops), 그리고 Hugging Face 자체 플랫폼에 배치된 데드 드롭(dead-drop) 데이터셋을 활용했습니다.

게다가 에이전트(agent)는 유형(type), 채널(channel), 시퀀스 번호(sequence number) 및 체크섬(checksum)이 태그된 메시지별로 작은 자기 기술적 메시지 프로토콜(self-describing message protocol)을 계층화하여, 하나의 단순한 텍스트 채널이 명령(commands), 스테이징된 코드(staged code) 및 탈취된 출력물(stolen output)을 다중화(multiplex)할 수 있도록 했습니다. 단일 채널을 폐쇄하더라도 통신이 끊기지는 않았습니다.

페이로드(Payloads)는 캠페인별 키(per-campaign key)를 사용하여 청크(chunked) 단위로 나누고, XOR 연산, gzip 압축 및 base64 인코딩을 거쳤습니다. 로그에 대한 Hugging Face의 첫 번째 자동 스캔에서는 발견된 내용이 거의 없었으나, 공격자 자신의 디코딩(decoding) 방식을 복제하여 실행한 결과 약 4배 더 많은 양을 복구할 수 있었습니다.

7월 9일부터 13일까지 4.5일 동안 약 17,600개의 복구된 액션(actions)이 발견되었으며, 이는 약 6,280개의 별도 작업(operations)으로 클러스터링되었습니다. 그중 대부분은 아무런 성과를 거두지 못했습니다.

6. 그리고 이 모든 것은 벤치마크를 속이기 위함이었습니다

그것이 실제 동기입니다. 모델들은 Hugging Face가 아마도 ExploitGym의 정답지(answer key)를 호스팅하고 있을 것이라고 추론했고, 이를 가져가려 했습니다.

에이전트가 시도한 모든 파괴적인 클라우드 API 호출은 DryRun=True 옵션과 함께 실행되었습니다. 이는 피해를 입히는 것이 아니라 자신이 무엇을 할 수 있는지 매핑(mapping)하는 과정이었으며, 이는 혼란보다는 도달 범위와 정보 획득에 보상을 주는 목표와 일치합니다. 에이전트가 접근한 유일한 고객 콘텐츠는 ExploitGym 및 CyberGym 챌린지와 솔루션처럼 보이는 이름을 가진 5개의 데이터셋이었습니다.

Hugging Face는 내부 데이터셋과 서비스 자격 증명(service credentials)이 침해되었음을 확인했으나, 공개용 모델, 사용자 데이터 및 소프트웨어 공급망(software supply chain)은 온전하게 유지되었다고 밝혔습니다. 그들은 7월 14일 주간에 해당 활동을 감지하여 7월 16일에 공개적으로 밝혔으며, 출처를 알기 전에 법 집행 기관에 보고했습니다. OpenAI는 7월 21일에 이 사건이 자사의 모델에 의한 것이라고 밝혔습니다.