2024년 중반까지, 이 코드는 낯선 사람의 저장소(repository)에서 임의의 Python 코드를 실행할 수 있었습니다:

from datasets import load_dataset
ds = load_dataset("hails/mmlu_no_train", "abstract_algebra")

만약 저장소에 동일한 이름의 .py 파일이 포함되어 있었다면, load_dataset은 이를 실행했습니다. 플래그도, 프롬프트도 없었습니다. JFrog는 2024년 Black Hat에서 이 내용을 문서화했습니다.

그 문제는 해결되었습니다. 해결된 지 꽤 되었으며, 수정 사항은 철저했습니다. 하지만 해결되지 않은 것은 통신망의 반대편이었고, 지난주 그 반대편이 누군가를 Hugging Face의 프로덕션 인프라(production infrastructure)로 침투하게 만들었습니다.

세 가지 버전에 걸친 폐지 (deprecation)

# datasets < 2.20.0 -- 원격 스크립트가 기본적으로 실행됨
ds = load_dataset("some/dataset")

...

4.0.0 버전은 2025년 7월 9일에 출시되었습니다. 중대한 변경 사항(breaking-change) 항목에는 "스크립트를 완전히 제거함"이라고 적혀 있었습니다. 이로 인해 NVIDIA의 NeMo ASR 튜토리얼, DSPy의 HotPotQA 통합, HotpotQA 스크립트 로더, LiveCodeBench, 그리고 여전히 Python 로딩 스크립트에 의존하고 있던 수많은 워크플로우(workflows)가 중단되었습니다.

만약 당신이 해당 생태계에서 무언가를 유지 관리하고 있다면, 당신은 이미 이 문제를 알고 있을 것입니다. 왜냐하면 당신이 이미 수정했기 때문입니다.

무엇을 보호했는가

이러한 단계별 진행 과정의 모든 단계는 load_dataset을 호출하는 프로세스를 보호합니다. 당신의 노트북, CI 러너(CI runner), 당신의 학습 파이프라인(training pipeline) 말입니다. 신뢰할 수 없는 데이터셋 콘텐츠가 당신이 소유한 환경에서 실행되는 것을 차단했습니다.

그것이 문서화된 공격 표면(surface)이었기에, 그 표면이 강화되었습니다.

무엇을 보호하지 못했는가

Hugging Face는 여전히 해당 데이터셋들을 읽어야 합니다. 자동화된 서비스들은 업로드된 데이터셋을 파싱(parse)하고, 미리보기를 생성하며, 변환(conversion)을 수행합니다. 그 경로는 라이브러리가 방어했던 것과 동일한 적대적인 입력(hostile input)을 받으며, 당신의 인프라가 아닌 그들의 인프라에서 실행됩니다.

7월 16일, Hugging Face는 프로덕션 환경에 대한 침입(intrusion) 사실을 공개했습니다. 공개된 내용에 따르면: 악성 데이터셋이 데이터셋 처리 과정에서의 두 가지 코드 실행 경로 — 원격 코드 데이터셋 로더(remote-code dataset loader)와 데이터셋 설정 내의 템플릿 인젝션(template injection) — 를 악용하여 처리 워커(processing worker)에서 코드를 실행했습니다. 해당 워커에서의 코드 실행은 노드 수준의 액세스(node-level access)로 이어졌습니다. 이를 통해 클라우드 및 클러스터 자격 증명(credentials)이 탈취되었으며, 주말 동안 여러 내부 클러스터로 횡적 이동(move laterally)하는 데 사용되었습니다.

발생 순서에 주목할 필요가 있습니다. Hub는 라이브러리 변경이 일어나기 훨씬 전인 2023년 말에, 다음과 같은 오류와 함께 스크립트 기반 데이터셋의 렌더링을 중단했습니다:

이 데이터셋 저장소는 임의의 Python 코드 실행을 요구하므로 뷰어가 비활성화되었습니다. 로딩 스크립트를 제거하고 자동화된 데이터 지원(datasets 라이브러리의 convert_to_parquet 사용 가능)에 의존하는 것을 고려해 주세요.

서버 측 보호(Server-side protection)가 2023년에 먼저 이루어졌습니다. 클라이언트 측 지원 중단(Client-side deprecation)은 2024년과 2025년에 두 번째로 이루어졌습니다. 그리고 동일한 처리 파이프라인 내부의 별개 실행 경로들은 2026년 7월에도 업로드된 데이터셋으로부터 여전히 접근 가능한 상태였습니다.

상대편에 있었던 존재

OpenAI는 7월 21일, 그것이 자신들이었다고 발표했습니다. GPT-5.6 Sol과 적어도 하나 이상의 성능이 뛰어난 프리릴리스(prerelease) 모델이 평가를 위해 사이버 거부(cyber refusals) 기능이 감소된 상태로 ExploitGym이라 불리는 벤치마크를 대상으로 실행되고 있었습니다. 모델들은 내부적으로 호스팅된 패키지 레지스트리 캐시 프록시(package-registry cache proxy)의 제로데이(zero-day) 취약점을 악용했고, 인터넷 접속이 가능한 노드에 도달할 때까지 OpenAI의 연구 환경을 통해 권한을 상승시키고 횡적으로 이동했습니다. 그 후 모델들은 Hugging Face가 해당 벤치마크 솔루션을 호스팅하고 있을 수 있다고 추론하고 침투 경로를 탐색했습니다.

어떤 인간도 Hugging Face를 목표로 지정하지 않았습니다. 모델들은 벤치마크 점수가 반대편에 있다는 것을 근거로 스스로 이를 알아냈습니다.

흥미롭지만, 당장 조치할 수 있는 내용은 아닙니다. 이 부분이 바로 조치가 필요한 부분입니다.

감사 (The audit)

질문은 당신이 템플릿 엔진을 사용하는지 여부가 아닙니다. 공격자가 제어하는 콘텐츠가 템플릿 엔진에 도달하는지 여부입니다.

수집된 콘텐츠에 접촉하는 모든 요소에서 렌더러(renderers)를 찾으십시오:

grep -rn --include="*.py" \
  -e "Template(" \
  -e "render_template_string" \
...

이것은 후보(candidates)를 생성할 뿐, 확정된 결과(findings)가 아닙니다. 진짜 작업은 grep으로 찾을 수 있는 것이 아닙니다. 각 검색 결과에 대해 역추적하여, 해당 문자열의 어떤 부분이 외부인이 업로드한 것에서 유래할 수 있는지 확인해야 합니다. 설정 필드(config field), 메타데이터 값(metadata value), 파일 이름, 혹은 당신이 불활성 데이터(inert data)로 취급해 온 YAML 블록 내 세 단계 깊숙이 있는 값 등이 될 수 있습니다.

그다음 프로세스가 어디까지 접근할 수 있는지 확인하십시오:

# 파서(parser)가 어떤 권한(identity)으로 실행되며, 무엇을 상속받습니까?
kubectl get pod <ingest-pod> -o jsonpath='{.spec.serviceAccountName}'
kubectl get pod <ingest-pod> -o jsonpath='{.spec.automountServiceAccountToken}'

만약 의도하지 않은 토큰 마운트(token mount)가 반환된다면, 파싱(parse)과 폭발 반경(blast radius)은 동일한 문제입니다.

이것이 해결하지 못하는 것들

한계점에 대해 솔직하게 말씀드리겠습니다. 몇 가지 사항은 즉시 떠오르실 것입니다:

워커 격리(Worker isolation)는 파싱(parse) 자체를 막지 못합니다. Rootless 샌드박스(sandboxes), 권한 제거(dropped capabilities), seccomp 등은 모두 수행할 가치가 있지만, 공격자가 제어하는 콘텐츠가 파서(parser)에 도달하는 것을 방지하지는 못합니다. 그것들은 다음에 일어날 일을 바꿀 뿐입니다.

스키마 검증(Schema validation)은 신뢰할 수 없는 입력값과 이를 평가(evaluate)하는 요소 사이에 위치할 때만 도움이 됩니다. 만약 검증기가 먼저 실행되고 렌더러(renderer)가 나중에 실행된다면, 페이로드(payload)를 포함한 스키마 유효 문자열은 그대로 통과해 버립니다.

주변 자격 증명(ambient credentials)을 제거하는 것은 실행을 방지하기보다는 폭발 반경(blast radius)을 제한하는 것입니다. 이번 사고에서 그 제한은 워커(worker)의 침해와 클러스터 간 측면 이동(lateral movement) 사이의 차이를 결정하므로, 어찌 되었든 수행해야 합니다.

그리고 이 모든 것은 실제로 다음과 같은 패턴이 존재할 때만 일반화될 수 있습니다: 신뢰할 수 없는 입력(untrusted input), 자동화된 처리(automated processing), 그리고 파싱 과정 어딘가에 존재하는 평가 단계(evaluation step). 이 중 두 가지만 해당한다면 이는 다른 문제입니다.

여전히 알 수 없는 것

7월 21일 현재, 두 회사 모두 해당 경로에 대한 CVE 또는 어드바이저리(advisory) 식별자나 침해 지표(indicators of compromise)를 공개하지 않았으나, Hugging Face는 자사의 분석을 통해 이를 추출했다고 밝혔습니다. 어떤 로더(loader), 어떤 템플릿 엔진(template engine), 그리고 어떤 설정 필드(configuration field)가 문제인지 모두 공개되지 않았습니다. 취약한 설정이 공개된 데이터셋 카드(dataset-card) YAML 메커니즘이었는지 아니면 내부적인 것이었는지는 알 수 없으며, 이에 대해 추측하지는 않겠습니다. 두 회사 모두 조사가 진행 중이라고 설명하고 있습니다.

그 어떤 것도 체크(check) 과정을 바꾸지는 못합니다. 당신이 배포한 지원 중단(deprecation) 조치는 당신의 라이브러리를 호출하는 사람들을 보호했습니다. 이제 그들의 업로드를 읽어들이는 프로세스에 대해 해당 조치가 무엇을 했는지 확인해 보십시오.