보안 사고 공개 — 2026년 7월

• 보안 사고 공개 — 2026년 7월
  • 무슨 일이 있었나요
  • 수행한 작업
  • 우리 커뮤니티를 위한 안내
  • AI 주도 침입 분석
    • 비대칭성 문제
  • 이것이 의미하는 바

이 글은 Hugging Face 블로그의 Security incident disclosure — July 2026를 한국어로 번역한 글입니다.

이번 주 초에 운영 인프라의 일부에 대한 침입을 탐지하고 대응했습니다. 이번 침입은 한 가지 중요한 점에서 그동안 다뤄온 어떤 사례와도 달랐습니다. 처음부터 끝까지 자율 AI 에이전트 시스템이 주도했고, 이를 탐지하고 면밀히 분석하는 데에도 주로 자체 AI를 활용했습니다.

내부 데이터셋 일부와 서비스에서 사용하는 여러 자격 증명에 대한 무단 접근을 확인했습니다. 파트너나 고객 데이터에 영향이 있었는지 여부에 대한 평가를 아직 완료하지 못했으며, 필요한 경우 영향을 받는 당사자에게 직접 연락하겠습니다. 공개적으로 사용자에게 노출된 모델, 데이터셋, 또는 Spaces의 변조 여부는 발견되지 않았고, 소프트웨어 공급망(컨테이너 이미지 및 게시된 패키지)은 문제가 없는 것으로 확인되었습니다.

무슨 일이 있었나요

침입은 AI 플랫폼이 특히 노출되기 쉬운 지점인 데이터 처리 파이프라인에서 시작되었습니다. 악의적인 데이터셋은 데이터 처리에서 두 개의 코드 실행 경로를 악용해 처리 워커에서 코드를 실행했습니다(원격 코드 데이터셋 로더와 데이터셋 구성의 템플릿 주입). 그다음 행위자는 노드 수준의 접근 권한까지 권한을 상승시켰고, 클라우드 및 클러스터 자격 증명을 수집했으며, 주말 동안 여러 내부 클러스터로 수평 이동했습니다.

공격은 자율 에이전트 프레임워크가 실행한 것으로, 에이전트형 보안 연구용 하네스를 기반으로 구성된 것으로 보입니다(사용된 LLM은 아직 확인되지 않았습니다). 이 프레임워크는 수명이 짧은 여러 샌드박스에서 수천 건의 개별 동작을 실행했고, 공개 서비스에 배치한 명령·제어(C2) 인프라를 스스로 옮겨 가며 운영했습니다. 이는 산업계가 예측해 온 ‘에이전트형 공격자’ 시나리오와 일치합니다.

수행한 작업

• 근본 취약점을 수정했습니다: 초기 접근에 사용된 데이터셋 코드 실행 경로를 차단했습니다.
• 영향 클러스터 전반에서 공격자의 거점을 제거하고 손상된 노드를 재구축했습니다.
• 영향받은 자격 증명과 토큰을 폐기하고 재발급했으며, 보안 시크릿을 광범위하게 예방적으로 교체하기 시작했습니다.
• 클러스터에 추가적인 가드레일과 더 엄격한 클러스터 진입 제어를 배치했습니다.
• 높은 심각도 신호가 요일과 관계없이 몇 분 안에 대응자에게 알림이 전달되도록 탐지 및 경보 체계를 개선했습니다.

우리는 이 문제를 조사하고 보안 정책과 절차를 검토하기 위해 외부 사이버 보안 포렌식 전문가들과 협력하고 있습니다. 끝으로 이 사건을 법집행기관에 보고했습니다.

우리 커뮤니티를 위한 안내

예방 차원에서 모든 액세스 토큰을 교체하고 계정의 최근 활동을 검토하시길 권장합니다. 영향받았다고 생각되거나 보안 이슈를 신고하고 싶으시면 security@huggingface.co로 연락해 주세요.

24시간 대응해 준 Hugging Face 전 팀께 감사드리며, 이로 인해 불편을 드려 죄송합니다. 보안은 결코 끝나지 않으며, 우리는 계속 기준을 높여 나가겠습니다.

AI 주도 침입 분석

공격은 처음에는 AI 보조 탐지를 통해 나타났습니다. 이상 탐지 파이프라인은 보안 텔레메트리에 LLM 기반 초기 분류를 적용해 실제 신호와 일상적인 잡음을 구분했으며, 이러한 신호들의 상관관계가 침해를 식별해 냈습니다.

수만 건에 이르는 자동화된 행동 무리가 무엇을 했는지 이해하기 위해, 전체 공격자 행동 로그에 대해 LLM 기반 분석 에이전트를 실행했습니다. 이 로그는 17,000건이 넘는 기록된 이벤트로 구성되어 있습니다. 이를 통해 타임라인을 재구성하고, 침해 지표(indicators of compromise)를 추출하고, 접근한 자격 증명을 매핑하며, 실제 영향과 미끼 활동을 구분했습니다. 이 접근 방식 덕분에 보통 며칠이 걸리는 작업을 몇 시간 안에 수행했고, 상대의 속도에 맞출 수 있었습니다.

이 분석에 사용할 수 있는 모델의 선택에는 예상하지 못한 제약이 있었습니다. 자세한 내용은 아래에서 설명합니다.

비대칭성 문제

로그 분석을 시작했을 때, 먼저 상용 API 뒤에 있는 프런티어 모델을 사용했습니다. 이는 제대로 작동하지 않았습니다. 분석을 수행하려면 실제 공격 명령, 익스플로잇 페이로드, 명령·제어(C2) 관련 자료를 대량으로 제출해야 하는데, 공급자의 안전 가드레일은 이러한 요청을 차단하며 사고 대응자와 공격자를 구분하지 못합니다. 대신 자체 인프라에서 가중치 공개 모델인 zai-org/GLM-5.2를 사용해 포렌식 분석을 수행했습니다. 여기에는 두 번째 이점도 있었습니다. 공격자 데이터와 그 데이터에 포함된 자격 증명이 우리 환경 밖으로 나가지 않았다는 점입니다.

이 경험은 대비할 가치가 있는 격차를 보여줍니다. 공격자의 에이전트가 어떤 모델로 작동했는지, 탈옥된 호스팅 모델이었는지 아니면 제한 없는 오픈 웨이트 모델이었는지는 아직 알 수 없습니다. 어느 쪽이든 공격자는 사용 정책의 제약을 받지 않았고, 반면 우리의 포렌식 작업은 처음 시도한 호스팅 모델의 가드레일에 의해 차단되었습니다. 방어자를 위한 실용적 교훈은 분명합니다. 사건이 발생하기 전에 자체 인프라에서 검증되고 준비된 충분한 성능의 모델을 확보해 두면, 가드레일 차단을 피하고 공격자 데이터와 자격 증명이 환경을 벗어나지 않도록 할 수 있습니다. 이는 호스팅 모델의 안전 조치에 대한 반대 주장이 아니며, 관련 공급자들에게 이 피드백을 공유하고 있습니다.

이것이 의미하는 바

자율적이고 AI 주도적인 공격 도구는 더 이상 이론적이지 않습니다. 광범위하고 인내심 있는 다단계 캠페인을 실행하는 비용을 낮추고, 기계 속도로 작동합니다. 온라인 플랫폼을 방어하려면 이제 데이터와 모델 영역을 핵심 공격 표면으로 간주하고, 방어에도 AI를 활용해 공격 속도에 대응해야 합니다. 앞으로도 이 분야에 계속 투자하고, 그 과정에서 얻은 경험을 계속 공유하겠습니다.