보안 사고 공개 — 2026년 7월

당사는 제한된 내부 데이터셋과 서비스에 사용되는 여러 자격 증명(credentials)에 대한 무단 접근을 확인했습니다. 어떤 파트너나 고객 데이터가 영향을 받았는지 여부에 대한 평가를 계속 진행 중이며, 필요한 경우 영향을 받은 당사자에게 직접 연락할 것입니다. 공개적이고 사용자에게 노출되는 모델, 데이터셋 또는 Spaces에는 변조의 증거가 없었으며, 당사의 소프트웨어 공급망(container images 및 게시된 패키지)은 깨끗한 것으로 확인되었습니다.

침입은 AI 플랫폼이 고유하게 취약한 지점, 즉 데이터 처리 파이프라인에서 시작되었습니다. 악성 데이터셋이 데이터셋 처리 과정의 두 가지 코드 실행 경로(원격 코드 데이터셋 로더 및 데이터셋 구성의 템플릿 주입)를 악용하여 처리 워커에서 코드를 실행했습니다. 그곳에서 공격자는 노드 수준 접근으로 에스컬레이션하고, 클라우드 및 클러스터 자격 증명을 수집했으며, 주말 동안 여러 내부 클러스터로 측면 이동(moved laterally)했습니다.

이 캠페인은 자율 에이전트 프레임워크(에이전틱 보안 리서치 하네스 기반으로 보이는 에이전트형(agentic) 사용 LLM을 이용한 것으로 추정됨)가 수행했으며, 단명하는 샌드박스 군집 전반에 걸쳐 수천 개의 개별 행동을 실행했습니다. 또한 공용 서비스를 기반으로 자체 이동식 명령 및 제어(command-and-control) 시스템이 구축되었습니다. 이는 업계가 예측해 온 '에이전트형 공격자(agentic attacker)' 시나리오와 일치합니다.

• 초기 접근에 사용된 데이터셋 코드 실행 경로라는 근본적인 취약점을 수정했습니다.
• 영향을 받은 클러스터 전반에 걸쳐 공격자의 거점을 제거하고 손상된 노드를 재구축했습니다.
• 영향을 받은 자격 증명과 토큰을 폐기 및 순환(rotate)시켰으며, 더 광범위한 예방적 비밀번호 순환을 시작했습니다.
• 클러스터에 추가적인 가드레일(guardrails)과 엄격한 입실 제어(admission controls)를 배포했습니다.
• 탐지 및 경고 시스템을 개선하여 높은 심각도의 신호가 주중 어느 날이든 몇 분 안에 담당자에게 전송되도록 했습니다.

저희는 문제를 조사하고 보안 정책 및 절차를 검토하기 위해 외부 사이버 보안 포렌식 전문가들과 협력하고 있습니다. 또한, 이 사건을 법 집행 기관에도 보고했습니다.

예방 조치로, 모든 액세스 토큰을 재설정(rotating)하고 계정에 대한 최근 활동 내역을 검토할 것을 권장합니다. 만약 본인이 영향을 받았다고 생각하거나 보안 문제를 신고하려면 [email protected]로 문의해 주십시오.

Hugging Face 전반의 팀들이 24시간 동안 대응해 준 것에 감사드리며, 이로 인해 발생한 모든 혼란에 대해 사과드립니다. 보안은 결코 끝이 없으며, 저희는 계속해서 기준을 높여나갈 것입니다.

이번 공격은 AI 지원 탐지를 통해 처음 발견되었습니다. 당사의 이상 징후 탐지 파이프라인(anomaly-detection pipeline)은 보안 원격 측정 데이터(security telemetry)에 기반한 LLM 기반 분류(triage)를 사용하여 실제 신호와 일상적인 노이즈를 분리하며, 이 신호들의 상관관계가 침해 사실을 감지하는 계기가 되었습니다.

수만 건의 자동화된 행동들이 무엇을 했는지 이해하기 위해, 저희는 17,000건 이상의 기록된 이벤트로 구성된 전체 공격자 행동 로그(attacker action log)에 LLM 구동 분석 에이전트(LLM-driven analysis agents)를 실행했습니다. 이를 통해 타임라인을 재구성하고, 침해 지표(indicators of compromise)를 추출하며, 건드려진 자격 증명(credentials)을 매핑하고, 실제 영향과 미끼 활동을 분리할 수 있었습니다. 이러한 접근 방식 덕분에 저희는 보통 며칠이 걸릴 작업을 몇 시간 만에 처리할 수 있었고, 적대자의 속도에 맞설 수 있었습니다.

이번 분석에 사용할 모델의 선택은 예상치 못한 방식으로 제약되어 있었으며, 이에 대해서는 아래에서 설명하겠습니다.

로그 분석을 시작했을 때, 우리는 먼저 상용 API 뒤에 있는 프론티어 모델들을 사용했습니다. 하지만 이는 작동하지 않았습니다. 분석에는 대량의 실제 공격 명령어, 익스플로잇 페이로드(exploit payloads), 그리고 C2 아티팩트(C2 artifacts)를 제출해야 했는데, 이러한 요청들은 제공업체들의 안전 가드레일(safety guardrails)에 의해 차단되었습니다. 이 가드레일은 인시던트 대응자(incident responder)와 공격자를 구별할 수 없었습니다. 그래서 우리는 자체 인프라에서 오픈 웨이트 모델인 zai-org/GLM-5.2를 사용하여 포렌식 분석을 진행했습니다. 이것은 두 번째 장점도 있었습니다. 즉, 공격자의 데이터나 그 모델이 참조한 어떤 자격 증명(credentials)도 우리 환경을 벗어나지 않았다는 것입니다.

이 경험은 계획할 가치가 있는 격차를 지적합니다. 우리는 공격자의 에이전트를 구동시킨 모델이 무엇인지 알 수 없습니다. 그것이 탈옥된(jailbroken) 호스팅 모델인지, 아니면 제약 없는 오픈 웨이트 모델인지는 알 수 없지만, 어느 쪽이든 공격자는 사용 정책에 묶여 있지 않았습니다. 반면에 우리가 처음 시도했던 호스팅 모델들의 가드레일에는 우리의 포렌식 작업이 차단당했습니다. 방어자들을 위한 실질적인 교훈은 다음과 같습니다. 사고가 발생하기 전에, 가드레일 잠금(guardrail lockout)을 피하고 공격자의 데이터와 자격 증명이 환경을 벗어나지 않도록 할 수 있는 역량 있는 모델을 자체 인프라에서 검증하고 준비해 두어야 합니다. 이것이 호스팅 모델의 안전 조치에 반대하는 주장은 아니며, 우리는 관련 제공업체들에게 이 피드백을 공유하고 있습니다.

자율적이고 AI 기반의 공격 도구는 더 이상 이론적인 것이 아닙니다. 이는 광범위하고 인내심 있는 다단계 캠페인을 실행하는 비용을 낮추고, 기계 속도로 작동합니다. 온라인 플랫폼을 방어한다는 것은 이제 데이터와 모델 표면(model surface)을 일급 공격 표면(first-class attack surface)으로 취급하고, 발맞추기 위해 AI를 방어에 사용하는 것을 의미하며, 우리는 그곳에 계속 투자하고 배운 것을 공유할 것입니다.