Hugging Face 침해사고…내부 데이터셋과 인증정보 영향

Hugging Face 침해사고로 내부 데이터셋과 인증정보가 영향을 받은 사건

유의사항

본 글은 Hugging Face의 공식 설명과 2026년 7월 21일까지 공개된 첨부 자료를 바탕으로 작성한 해설 콘텐츠입니다.

Hugging Face는 이번 공격이 처음부터 끝까지 자율형 AI 에이전트 시스템에 의해 주도됐다고 밝혔습니다. 다만 보도 시점에는 이러한 판단을 외부에서 독립적으로 검증할 수 있는 충분한 기술적 증거가 공개되지 않았습니다.

현재 침해사고의 전체 영향 범위에 대한 조사가 진행 중이므로, 이후 발표에 따라 일부 내용이 달라질 수 있습니다.


AI 모델과 데이터셋 공유 플랫폼 Hugging Face에서 일부 내부 데이터셋과 서비스 인증정보가 영향을 받은 사이버 침해사고가 발생했습니다.

Hugging Face는 공격에 이용된 취약점을 수정하고, 영향을 받은 인증정보와 보안 토큰을 폐기하거나 새로 발급했다고 밝혔습니다. 이용자들에게도 Hugging Face에 저장한 액세스 토큰과 API 키를 교체하고 계정의 최근 활동을 확인할 것을 요청했습니다.

다만 고객이나 협력사의 데이터가 실제로 탈취됐는지는 아직 조사 중입니다.


악성 데이터셋이 데이터 처리 시스템의 취약점을 악용

이번 공격은 임직원의 비밀번호를 탈취하거나 외부 서버에서 직접 침투하는 일반적인 방식과 달랐습니다.

공격자는 Hugging Face에 악성 데이터셋을 업로드한 뒤, 플랫폼이 해당 데이터셋을 처리하는 과정에서 서버가 악성 코드를 실행하도록 만들었습니다.

공개된 설명에 따르면 공격에 이용된 경로는 다음과 같습니다.

  1. 원격 코드를 사용하는 데이터셋 로더
  2. 데이터셋 설정 파일의 템플릿 삽입 취약점

데이터셋 로더는 플랫폼이 업로드된 데이터의 구조와 내용을 읽고 처리하기 위해 사용하는 기능입니다.

일반적으로 데이터셋은 단순한 파일처럼 보이지만, 일부 데이터셋은 데이터를 불러오거나 변환하기 위한 코드를 함께 포함할 수 있습니다. 이러한 처리 기능에 취약점이 존재하면 데이터셋을 읽는 과정이 서버의 코드 실행으로 이어질 수 있습니다.

공격자는 데이터셋 처리 서버에서 코드를 실행한 뒤 노드 수준의 접근 권한을 확보한 것으로 조사됐습니다.

이후 클라우드와 내부 클러스터에서 사용하는 인증정보를 수집하고, 여러 내부 시스템으로 이동하는 횡적 이동을 시도했습니다.

즉, 정상적인 데이터셋처럼 보이는 파일을 플랫폼에 등록한 뒤, Hugging Face의 데이터 처리 시스템이 스스로 악성 명령을 실행하도록 유도한 공격입니다.


Hugging Face “공격 전 과정이 AI 에이전트에 의해 주도”

Hugging Face는 이번 공격이 처음부터 끝까지 자율형 AI 에이전트 시스템에 의해 주도됐다고 설명했습니다.

이는 AI가 공격 과정의 일부 작업만 보조했다는 의미가 아닙니다.

Hugging Face의 설명대로라면 초기 침투 이후 권한 확대, 인증정보 수집, 내부 시스템 탐색과 이동 등 공격 실행의 전체 과정이 AI 에이전트 시스템에 의해 자동으로 이어졌다는 의미입니다.

회사 측에 따르면 공격 시스템은 수많은 단기 샌드박스에서 개별 작업을 반복적으로 수행했습니다. 또한 공개 서비스를 이용해 자체적으로 이동하는 명령·제어 환경을 구성한 것으로 분석됐습니다.

샌드박스는 프로그램을 다른 시스템과 분리된 환경에서 실행하기 위한 임시 공간입니다.

공격자가 수많은 단기 샌드박스를 반복적으로 사용하면 특정 실행환경이 차단되거나 종료되더라도 새로운 환경에서 공격 작업을 계속할 수 있습니다.

Hugging Face의 분석에 따르면 AI 에이전트 시스템은 다음과 같은 공격 과정을 연속적으로 수행한 것으로 보입니다.

  1. 데이터 처리 취약점을 이용한 초기 침투
  2. 노드 수준으로 권한 확대
  3. 클라우드와 클러스터 인증정보 수집
  4. 내부 시스템과 클러스터 탐색
  5. 다른 시스템으로 횡적 이동
  6. 단기 샌드박스를 이용한 작업 반복
  7. 공개 서비스를 이용한 명령·제어 기능 유지

다만 공격에 어떤 AI 모델이 사용됐는지는 확인되지 않았습니다.

Hugging Face는 공격자가 상용 AI 모델의 안전장치를 우회했는지, 이용 제한이 없는 오픈웨이트 모델을 사용했는지도 아직 알 수 없다고 밝혔습니다.


AI 에이전트 사용 주장은 추가 검증이 필요

Hugging Face의 공식 설명은 이번 공격이 처음부터 끝까지 자율형 AI 에이전트에 의해 주도됐다는 것입니다.

따라서 이를 공격의 일부가 AI로 자동화됐다거나 상당 부분을 AI가 수행했다고 표현하면 회사 측 주장의 강도를 낮추게 됩니다.

그러나 회사가 그렇게 판단했다는 사실과, 그 판단이 외부에서 독립적으로 검증됐다는 것은 구분해야 합니다.

TechCrunch는 Hugging Face에 외부 AI 에이전트가 공격을 수행했다는 근거를 요청했지만, 보도 시점에는 회사가 이를 뒷받침하는 구체적인 증거를 즉시 제공하지 않았다고 전했습니다.

따라서 현재 가장 정확한 표현은 다음과 같습니다.

Hugging Face는 이번 공격이 처음부터 끝까지 자율형 AI 에이전트 시스템에 의해 주도됐다고 밝혔지만, 이를 독립적으로 검증할 수 있는 충분한 기술적 증거는 아직 공개되지 않았습니다.

또한 처음부터 끝까지 AI 에이전트가 공격을 주도했다는 설명이 인간 공격자가 전혀 개입하지 않았다는 뜻은 아닙니다.

사람이 공격 대상과 목표를 정하고 취약점이나 공격 도구를 준비했을 가능성은 남아 있습니다. 핵심은 실제 침투가 시작된 이후의 공격 실행 과정이 AI 에이전트 시스템에 의해 자동으로 이어졌다는 것이 Hugging Face의 주장이라는 점입니다.


자체 이상탐지 시스템으로 공격 발견

Hugging Face는 자체 이상탐지 시스템을 통해 비정상적인 활동을 발견했다고 밝혔습니다.

침해사고와 관련해 시스템에는 1만 7천 건 이상의 이벤트가 기록됐습니다.

회사는 이 기록을 바탕으로 공격자가 어떤 순서로 시스템에 접근했는지, 어떤 인증정보를 수집했는지, 어느 내부 시스템으로 이동했는지를 분석했습니다.

사람이 수많은 서버 로그와 이벤트를 하나씩 확인하는 데에는 많은 시간이 필요합니다.

특히 AI 에이전트가 여러 단기 샌드박스에서 빠르게 작업을 수행했다면 짧은 시간 안에 남겨지는 로그의 양도 크게 증가할 수 있습니다.

Hugging Face는 공격의 전체 흐름과 영향을 받은 범위를 파악하기 위해 AI 모델을 이용해 서버 로그를 분석했습니다.

다만 로그 분석을 통해 공격 행동의 자동화 수준을 판단했더라도, 어떤 AI 모델이 실제 공격에 사용됐는지는 확인하지 못했습니다.


외부 상용 AI 모델은 포렌식 분석을 거부

Hugging Face는 처음에 외부 상용 AI 모델을 이용해 사고를 분석하려 했습니다.

그러나 실제 공격 명령과 악성 코드, 취약점 실행 코드, 명령·제어 정보가 포함된 요청이 AI 모델의 안전장치에 의해 차단된 것으로 전해졌습니다.

AI 모델은 입력된 명령이 실제 공격을 위한 것인지, 보안 담당자가 침해사고를 분석하기 위한 것인지 정확하게 구분하지 못할 수 있습니다.

공격 명령과 악성 코드가 포함돼 있다는 이유만으로 요청을 거부하면, 보안 담당자도 정상적인 디지털 포렌식과 사고 대응 작업을 수행하기 어려워질 수 있습니다.

Hugging Face는 이후 자체 인프라에서 실행할 수 있는 Z.ai의 오픈웨이트 모델 GLM 5.2를 사용해 포렌식 분석을 진행했다고 밝혔습니다.

로컬 환경에서 AI 모델을 실행하면 다음과 같은 장점이 있습니다.

  1. 공격 로그를 외부 AI 사업자의 서버로 전송하지 않아도 됨
  2. 계정정보와 인증정보가 포함된 민감한 자료를 내부에서 분석할 수 있음
  3. 외부 서비스의 이용 정책이나 안전장치에 의해 분석이 중단될 가능성이 낮음
  4. 긴급 상황에서 보안 담당자가 필요한 방식으로 모델을 조정할 수 있음

이번 사례는 AI 모델의 안전장치가 공격 악용을 막는 데 필요하지만, 정상적인 보안 분석까지 차단할 수 있다는 문제도 보여줍니다.


공개 모델과 데이터셋 변조 증거는 발견되지 않아

Hugging Face는 현재까지 이용자에게 공개된 자산이 변조됐다는 증거는 발견하지 못했다고 밝혔습니다.

확인 대상에는 다음과 같은 항목이 포함됩니다.

  1. 공개 AI 모델
  2. 공개 데이터셋
  3. AI 애플리케이션을 운영하는 Spaces
  4. 컨테이너 이미지
  5. 배포된 소프트웨어 패키지
  6. Hugging Face의 소프트웨어 공급망

이는 공개 모델과 데이터셋이 최종적으로 안전하다고 확정됐다는 의미는 아닙니다.

현재까지 진행된 조사에서 변조 흔적이 발견되지 않았다는 의미이며, 침해사고의 전체 범위에 대한 조사는 계속되고 있습니다.


Hugging Face가 실시한 대응 조치

Hugging Face는 공격에 사용된 데이터셋 처리 취약점을 수정했습니다.

또한 공격자가 내부 시스템에 구축한 거점을 제거하고, 영향을 받은 노드를 다시 구축했습니다.

회사 측이 공개한 주요 대응 조치는 다음과 같습니다.

  1. 초기 침투에 이용된 코드 실행 취약점 수정
  2. 영향을 받은 클러스터에서 공격자의 접근 지점 제거
  3. 침해된 노드 재구축
  4. 영향을 받은 인증정보와 토큰 폐기 및 교체
  5. 예방 차원의 추가 비밀정보 교체
  6. 클러스터 접근 통제 강화
  7. 새로운 보안 가드레일 적용
  8. 이상탐지와 경보 기능 개선
  9. 수사기관에 침해사고 신고
  10. 외부 사이버보안 포렌식 전문가와 공동 조사

Hugging Face는 이용자들에게도 액세스 토큰을 교체하고 계정의 최근 활동을 확인할 것을 요청했습니다.


이용자가 확인해야 할 사항

Hugging Face 계정이나 저장소를 사용하는 이용자는 다음 사항을 확인할 필요가 있습니다.

  1. 사용 중인 Hugging Face 액세스 토큰 교체
  2. 플랫폼에 저장한 API 키와 인증정보 교체
  3. 사용하지 않는 토큰 폐기
  4. 계정의 최근 로그인과 활동 내역 확인
  5. 저장소의 커밋과 파일 변경 내역 확인
  6. Spaces와 연결된 외부 서비스 점검
  7. 클라우드와 배포 환경의 비정상적인 접근 기록 확인
  8. 동일한 인증정보를 다른 서비스에서도 사용했는지 확인

특히 Hugging Face의 토큰이나 키가 클라우드, 모델 배포 서버, 자동화 시스템과 연결돼 있다면 해당 환경의 로그도 함께 점검해야 합니다.

인증정보가 탈취됐더라도 실제 악용 흔적이 바로 나타나지 않을 수 있으므로, 단순히 비밀번호만 변경하는 것보다 토큰과 API 키를 새로 발급하는 것이 중요합니다.


Hugging Face 침해사고가 중요한 이유

Hugging Face는 단순히 파일을 저장하는 웹사이트가 아닙니다.

개발자와 기업이 AI 모델, 데이터셋, 개발도구와 애플리케이션을 공유하고 배포하는 AI 생태계의 핵심 플랫폼입니다.

하나의 계정이나 서비스 인증정보가 탈취되면 해당 계정이 접근할 수 있는 저장소와 배포 환경까지 영향을 받을 수 있습니다.

공격자가 충분한 권한을 확보할 경우 다음과 같은 공급망 공격으로 확대될 가능성이 있습니다.

  1. 정상 모델을 악성 파일이 포함된 모델로 교체
  2. 학습 데이터셋에 조작된 데이터를 삽입
  3. 모델이나 데이터셋을 불러오는 코드에 악성 기능 추가
  4. 신뢰받는 개발자 계정으로 악성 모델 배포
  5. API 키를 이용해 연결된 클라우드 환경에 접근
  6. 자동 배포 시스템을 통해 악성 코드 확산
  7. 모델을 내려받는 다수의 이용자에게 피해 전파

현재까지 이러한 변조가 실제로 발생했다는 증거는 발견되지 않았습니다.

그러나 일부 내부 데이터셋과 서비스 인증정보가 영향을 받았다는 사실만으로도 공격자가 확보한 권한과 접근 범위를 정확히 확인하는 작업이 중요합니다.


AI 플랫폼에서는 데이터 자체가 공격 경로가 될 수 있다

일반적인 웹서비스에서는 이용자가 업로드한 파일을 저장하거나 화면에 보여주는 데 그치는 경우가 많습니다.

반면 AI 플랫폼은 업로드된 데이터셋의 구조를 분석하고, 미리보기를 만들고, 데이터를 변환하거나 모델 학습과 연결합니다.

이 과정에서 데이터셋에 포함된 설정과 코드가 서버에서 실제로 실행될 수 있습니다.

따라서 AI 플랫폼에서는 모델과 데이터셋을 단순한 콘텐츠가 아니라 실행 가능한 소프트웨어와 유사한 공격 표면으로 관리해야 합니다.

이번 공격은 AI 플랫폼에서 다음과 같은 보안 통제가 필요하다는 점을 보여줍니다.

  1. 업로드된 데이터셋의 코드를 격리된 환경에서 실행
  2. 데이터 처리 노드에 최소 권한 적용
  3. 처리 노드와 내부 클러스터의 접근 권한 분리
  4. 작업마다 단기 인증정보 사용
  5. 작업 종료 후 인증정보 자동 폐기
  6. 데이터셋 설정 파일의 입력값 검증
  7. 모델과 데이터셋의 서명 및 무결성 확인
  8. 대량의 샌드박스 생성과 반복 작업 탐지
  9. 비정상적인 인증정보 수집 행위 감시
  10. 내부 시스템 간 횡적 이동 차단

AI 에이전트는 공격의 속도와 규모를 바꿀 수 있다

기존의 사이버 공격에서도 자동화 도구는 사용돼 왔습니다.

취약점 스캐너, 악성 코드, 봇넷, 자동 로그인 도구도 사람이 수행해야 할 반복 작업을 대신합니다.

그러나 AI 에이전트는 단순히 미리 정해진 명령을 반복하는 것을 넘어, 실행 결과를 확인하고 다음 행동을 선택하는 방식으로 작동할 수 있습니다.

예를 들어 하나의 접근 경로가 차단되면 다른 경로를 탐색하거나, 새로 발견한 인증정보를 이용해 접근 가능한 시스템을 확인하는 방식입니다.

Hugging Face의 주장이 사실로 확인된다면 이번 사건은 AI 에이전트가 다음과 같은 다단계 공격을 처음부터 끝까지 연결할 수 있음을 보여주는 사례가 됩니다.

  1. 환경 분석
  2. 공격 경로 선택
  3. 명령 실행
  4. 결과 확인
  5. 다음 목표 탐색
  6. 다른 실행환경으로 이동
  7. 공격 과정 반복

이러한 자동화는 공격자가 적은 인력으로 더 많은 시스템을 더 오랜 시간 탐색할 수 있게 합니다.

또한 공격이 사람의 작업 속도가 아니라 시스템의 처리 속도에 가까워질수록 기존 보안 인력만으로 대응하기 어려워질 수 있습니다.


공격과 방어 모두 AI를 사용하는 구조

이번 사건에서는 공격을 수행한 것으로 지목된 시스템도 AI 에이전트였고, 공격을 발견하고 분석한 도구에도 AI가 사용됐습니다.

이는 앞으로 사이버보안이 사람과 사람의 대결만이 아니라 공격 자동화 시스템과 방어 자동화 시스템의 대결로 변화할 가능성을 보여줍니다.

공격자는 AI 에이전트를 이용해 취약점을 탐색하고 수많은 작업을 동시에 수행할 수 있습니다.

방어자는 AI를 이용해 대량의 로그를 분석하고, 비정상적인 행동을 찾아내며, 공격 경로를 빠르게 재구성해야 합니다.

다만 방어용 AI는 정확한 분석뿐 아니라 다음 조건도 충족해야 합니다.

  1. 민감한 로그를 외부로 전송하지 않아야 함
  2. 보안 분석과 실제 공격을 구분할 수 있어야 함
  3. 긴급 상황에서 이용 제한으로 중단되지 않아야 함
  4. 분석 결과를 사람이 검증할 수 있어야 함
  5. 잘못된 판단으로 정상 시스템을 차단하지 않아야 함

DANA NOTES 해설

이번 사건에서 가장 주목받는 부분은 공격 전 과정이 자율형 AI 에이전트 시스템에 의해 주도됐다는 Hugging Face의 주장입니다.

Hugging Face 공식 설명의 핵심은 AI가 공격의 일부를 보조했다는 것이 아닙니다.

초기 침투부터 권한 확대와 인증정보 수집, 내부 시스템 이동까지 공격 실행의 전체 과정이 AI 에이전트 시스템에 의해 이어졌다는 주장입니다.

따라서 이를 단순한 공격 자동화 사례로만 설명하면 회사 측 발표의 의미가 충분히 전달되지 않습니다.

다만 현재 공개된 보도만으로는 AI 에이전트가 실제로 어느 정도의 판단 권한을 가지고 공격을 수행했는지 확인하기 어렵습니다.

사람이 모든 공격 절차를 미리 설계하고 AI가 정해진 작업을 실행했는지, AI가 시스템 상태를 분석하면서 다음 행동을 스스로 선택했는지에 따라서 자율성의 수준은 달라집니다.

Hugging Face가 외부 AI 에이전트의 사용을 판단한 로그와 기술적 근거를 공개해야 공격의 자율성과 전체 구조를 정확하게 평가할 수 있습니다.

그럼에도 이번 사고에서 확인된 사실은 분명합니다.

악성 데이터셋이 데이터 처리 시스템의 코드 실행 취약점을 악용했고, 공격자는 노드 수준의 접근 권한을 확보한 뒤 내부 인증정보를 수집하고 다른 시스템으로 이동했습니다.

AI 플랫폼에서는 데이터셋이 보호해야 할 자산인 동시에 서버 코드 실행으로 이어질 수 있는 공격 경로가 될 수 있습니다.

결국 이번 사건의 핵심은 단순히 AI가 AI 기업을 공격했다는 것이 아닙니다.

AI 플랫폼의 모델과 데이터셋이 새로운 공급망 공격 표면이 되고 있으며, 공격과 방어 양쪽의 자동화 속도가 빠르게 높아지고 있다는 점입니다.


앞으로 주목할 점

이번 침해사고와 관련해 앞으로 확인해야 할 사항은 다음과 같습니다.

  1. 영향을 받은 내부 데이터셋의 정확한 범위
  2. 유출된 서비스 인증정보와 토큰의 종류
  3. 고객과 협력사 데이터의 실제 탈취 여부
  4. 탈취된 인증정보가 외부 시스템에서 사용됐는지
  5. 공개 모델과 데이터셋의 최종 무결성 조사 결과
  6. Spaces와 소프트웨어 공급망의 추가 점검 결과
  7. Hugging Face가 전체 이용자의 토큰과 세션을 폐기할지
  8. 모델과 데이터셋의 서명 검증을 의무화할지
  9. 공격에 사용된 AI 모델이 확인될지
  10. 인간 공격자의 개입 범위가 밝혀질지
  11. AI 에이전트가 공격 전 과정을 주도했다는 기술적 근거가 공개될지
  12. 공격 배후와 목적이 확인될지

댓글 달기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

위로 스크롤