2026년 7월 28일 - Link Blog

프런티어 랩 에이전트 침입의 해부: 2026년 7월 사건의 기술적 타임라인. Hugging Face는 최근 OpenAI가 자사 인프라를 대상으로 수행한 의도치 않은 사이버 공격에 대한 매우 상세한 기술적 설명을 방금 공개했습니다. 이 공격은 매우 정교했으며, 결과물인 이 문서는 현대적인 적대적 보안 (adversarial security) 접근 방식에 대한 속성 과정 (crash-course) 역할도 겸하고 있습니다.

우리는 OpenAI의 에이전트가 어떻게 샌드박스 (sandbox)를 탈출했는지에 대한 더 자세한 세부 정보를 여전히 기다리고 있습니다. 에이전트가 제로데이 취약점 (zero-day vulnerability)을 발견한 패키지 프록시 (package proxy)는 이제 JFrog의 Artifactory로 확인되었으며, 'JFrog와 OpenAI의 JFrog 제로데이 보안 발견 협업'은 OpenAI 직원들에게 귀속된 8개의 별도 CVE를 나열한 Artifactory 7.161.15 릴리스 노트를 참조하고 있습니다.

HTTP 프록시를 통해 탈출한 후, 에이전트는 나머지 공격을 위한 작전 기지를 구축하는 것으로 시작했습니다:

[...] 에이전트는 인터넷과 연결된 주요 허용 네트워크 송출 (egress) 중 하나인 패키지 레지스트리 캐시 프록시 (package registry cache proxy)의 제로데이를 악용하여 샌드박스를 탈출한 다음, 제3자 제공업체의 인프라에서 호스팅되는 공개 코드 평가 (code-evaluation) 외부 샌드박스를 남용했습니다. 에이전트는 해당 외부 샌드박스에서 루트/관리자 (root/admin) 권한으로 명령을 실행할 수 있었으며, 이를 전체 캠페인을 위한 제어, 스테이징 (staging) 및 송출 (egress) 기지로 사용했습니다. 즉, 에이전트를 위한 외부 발사대 역할을 한 것입니다.

그 후 에이전트는 7월 8일 목요일부터 13일 월요일까지 5일간 전형적인 공격 패턴을 실행했습니다: C2 (명령 및 제어, command and control) 구축, 정찰 (reconnaissance), 권한 상승 (escalating privileges), 구성 정보 덤프 (dumping configuration information), 대상 데이터 유출 (exfiltrating the target data), 그리고 흔적 지우기 (cleaning up after itself).

(이 사건에 대한 첫 번째 Hugging Face 게시물은 16일 목요일에 올라왔고, OpenAI의 자백은 21일 화요일에 있었습니다.)

그 과정에서 에이전트는 온갖 종류의 멋진 기술들을 사용했습니다. 한 시점에서는 안전하지 않은 Jinja2 템플릿 실행을 발견하고 이를 사용하여 임의 코드 (arbitrary code)를 실행했습니다:

{{ cycler.__init__.__globals__.__builtins__.exec(
"import gzip,base64; exec(gzip.decompress(base64.b64decode('<payload>')))"
) }}

이는 Hugging Face 내의 컨테이너(container)를 탈출하여 Kubernetes 서비스 계정 토큰(service-account token)을 탈취했으며, 이를 사용하여 네트워크를 추가로 탐색했습니다.

또한 "DNS가 방해가 될 때" IP 주소를 하드코딩하기 위해 Python 소켓(socket) 라이브러리를 몽키 패치(monkey-patched)했습니다:

socket.getaddrinfo = lambda *a, **k: [(2, 1, 6, '', ('<pinned-ip>', 443))]

심지어 데이터 유출(exfiltrate)을 돕기 위해 자체적인 Tailscale 네트워크를 실행하기까지 했습니다!

tailscaled --tun=userspace-networking \
--state=mem: --socket=/tmp/ts.sock \
--socks5-server=127.0.0.1:1055 \
...

Hugging Face 팀은 인간 공격자도 동일한 취약점(exploits)을 발견하고 사용할 수 있었겠지만, 여기서 핵심적인 차이점은 바로 *속도(speed)*였다고 언급했습니다:

이러한 유형의 공격으로부터 얻은 교훈은, 기계 속도의 공격(machine-speed offense)이 방어자들에게 일반적인 취약점들을 더욱 비용이 많이 드는 문제로 만든다는 것입니다. LLM 에이전트는 공격자가 테스트할 수 있는 경로의 수, 실패한 경로를 교체하는 속도, 그리고 방어자가 해석해야 하는 증거의 양 측면에서 한 단계 높은 수준의 증가를 가져옵니다.

이 사건을 통해 제가 명확히 느낀 점은, 추가적인 가드레일(guardrails)에 구애받지 않는 최상급 프런티어 모델(frontier models)은 만약 찾아낼 수 있는 취약점이 있다면 반드시 찾아낼 것이라는 사실입니다.

소프트웨어 산업 전체가 보안 수준을 높여야 합니다.

최근 기사

• OpenAI의 Hugging Face 대상 우발적 사이버 공격은 실제로 일어난 SF다 - 2026년 7월 22일
• Claude Code 팀의 Cat 및 Thariq와 함께하는 Fireside Chat - 2026년 7월 21일
• Kimi K3, 그리고 pelican 벤치마크에서 우리가 여전히 배울 수 있는 것 - 2026년 7월 16일