Hugging Face bị xâm nhập tháng 7/2026 - phânt tích kill chain

Mình dùng Hugging Face mỗi ngày với phòng LAB tại đại học. Mỗi lần load_dataset(...) hoặc pull một model mới về máy, có một dòng mình bấm mà gần như không nghĩ: trust_remote_code=True. Nó nằm trong tutorial, trong notebook của đồng nghiệp, trong README của repo. Mình copy-paste, Enter. Não mình đã rất mệt mỏi sau những giờ lướt tiktok rồi, đừng bắt mình chú ý nữa.

Tuần này mình đọc blog disclosure của Hugging Face về vụ xâm nhập tháng 7/2026 ^[1].

"A malicious dataset abused two code-execution paths in our dataset processing (a remote-code dataset loader and a template-injection in a dataset configuration) to run code on a processing worker." ^[1]

Hoá ra HuggingFace cũng bấm trust mất não luôn rồi.

Nói rõ một chút về trust_remote_code

Hugging Face là kho chứa hơn 45.000 model và được dùng bởi hơn 50.000 organization ^[2]. Trong số đó có rất nhiều dataset - và một phần lớn dataset legacy cần code Python để load đúng: giải nén, parse format lạ, split train/val/test theo logic riêng. Parquet tự động convert không cover được tất cả.

Nên datasets library có một cơ chế: nếu dataset repository trên Hub chứa file Python loader (theo convention là <repo-name>.py), library sẽ download file đó về và exec trên máy bạn. Tức là: một người lạ upload dataset lên Hub, bạn gọi load_dataset(), và code của người lạ đó chạy trên máy bạn.

M* !!! Nó chính là RCE !!!

Đó là lựa chọn kiến trúc với lý do chính đáng: tiện cho dev pull dataset, vì không phải dataset nào cũng clean để convert tự động.

Nhưng nó cũng là lựa chọn mà Trail of Bits và những người làm ML security đã gắn cờ từ lâu. Issue mở từ năm 2023, viết thẳng: "This is a security vulnerability that could lead to arbitrary code execution" ^[3].

Trail of Bits có một Semgrep rule riêng tên hf-trust-remote-code classify nó là CWE-94 (Code Injection), OWASP LLM Top 10 (2025) LLM03 Supply Chain, MITRE ATT&CK T1195.002 - và gọi nó là "highest-impact untracked remote-code-execution vector in the ML-supply-chain category" ^[4].

Lịch sử cố gắng sửa của HF:

Bạn thấy chưa? Tính đến tháng 7/2026, lúc vụ tấn công xảy ra, datasets library v4 đã xoá flag rồi. User-side an toàn. Vậy attacker không thể khai thác load_dataset() của bạn hay của mình nữa.

Vậy cửa nào bị exploit?

HF Dataset Viewer worker

Hugging Face chạy một backend riêng tên dataset-viewer (mã nguồn mở ở github.com/huggingface/dataset-viewer) để pre-compute preview cho mọi dataset trên Hub - hơn 100.000 dataset ^[8]. Khi bạn vào trang một dataset và thấy bảng dữ liệu ngay tức khắc, đó là vì worker này đã chạy trước và cache kết quả.

Kiến trúc nó thế này ^{[9] [8]}:

User upload dataset
    ↓
Mongo job queue
    ↓
Workers execute jobs:
  /splits           - list splits/subsets
  /first-rows       - 100 row đầu
  /parquet          - convert sang Parquet, push lại Hub
  /descriptive-statistics
    ↓
Cache trong Mongo → API trả kết quả tức thì cho user

Và worker này dùng chính datasets library để load dataset. Tức là: nó cũng phải exec loader .py cho những dataset legacy chưa được convert sang Parquet. Trong config của worker có biến HF_MODULES_CACHE - thư mục cache cho "cached dataset scripts" ^[9].

Đây là điểm mà mình thấy ít bài viết nào nêu rõ: trust boundary không biến mất, nó chỉ dịch chuyển. User-side an toàn hơn (flag bị xoá ở v4), nhưng server-side preview worker vẫn phải chạy code không tin cậy - vì lý do nghiệp vụ, để preview cho dev dùng Hub. HF thừa nhận điều này ngay câu đầu của blog: "The intrusion started where AI platforms are uniquely exposed" ^[1].

Một malicious dataset upload lên Hub → tự động được worker pick up qua job queue → RCE trên worker. Đó là điểm vào.

Kill chain

Blog HF mô tả kill chain ngắn gọn^[1]:

"From there, the actor escalated to node-level access, harvested cloud and cluster credentials, and moved laterally into several internal clusters over a weekend."

Mình vẽ lại 5 bước:

Hai path code-execution:

• Path A là loader .py - cái cửa mình vừa giải thích ở trên.
• Path B là "template injection in a dataset configuration". Cơ chế chính xác HF chưa public, nhưng đây là pattern SSTI (Server-Side Template Injection) cổ điển: dataset có config dạng YAML (README frontmatter hoặc config.yaml), parser của HF dùng template engine (kiểu Jinja) để render, attacker inject template expression kiểu {{ ''.__class__... }} vào field nào đó được render → RCE khi config được parse. Mình không ngủ dưới gầm dường nhà hacker để biết được chính xác field nào bị inject - HF chưa nói - nhưng dạng vector này ai làm web pentest đều quen.

Từ RCE trên worker, attacker leo lên node-level, thu thập credentials đang có sẵn trên worker (env var, mounted K8s secret), rồi dùng credentials đó lan sang cluster khác. Toàn bộ pattern này:

RCE → escalation → cred harvest → lateral

không có gì mới. 300 bài hack thiếu nhi !

Còn một lớp orchestration phía trên.

"Agentic attacker": swarm và C2

Blog HF mô tả phần "AI" của attack thế này ^[1]:

"The campaign was run by an autonomous agent framework (appearing to be built on an agentic security-research harness - used LLM still not known) executing many thousands of individual actions across a swarm of short-lived sandboxes, with self-migrating command-and-control staged on public services."

Và ở section phân tích ^[1]:

"we ran LLM-driven analysis agents over the full attacker action log, comprised of more than 17,000 recorded events."

Mình tách ba đặc điểm kỹ thuật:

Một là swarm short-lived sandbox. Mỗi action chạy trên một sandbox mới sống ngắn. IP và fingerprint đổi liên tục. Static detection rule - loại rule viết "block IP X" hoặc "alert khi thấy pattern Y" - gần như vô dụng, vì khi rule kịp nhận diện thì sandbox đã chết và cái mới đã mọc lên với identity khác.

Hai là self-migrating C2 trên public services. Channel điều khiển không ngồi yên trên một C2 server cố định. Nó nhảy giữa các dịch vụ công - kiểu GitHub Gist, Pastebin, Discord webhook, các dead drop hợp pháp. Detect bằng cách block một C2 server không hoạt động, vì không có server nào để block.

Ba là quy mô. 17.000 recorded events: Kiên nhẫn. Không mệt. Không ngủ. => Trung bình sinh viên châu Á

Đó là phần khiến báo chí thi nhau viết "AI attack".

Hai phe, và một câu hỏi quan trọng hơn

giờ 2026 rồi, developer hay hacker có ai không dùng AI nữa, nên chuyện ứng dụng AI vào tấn công là hiển nhiên, chẳng phải gì to tát. Câu hỏi đáng đặt không phải "dùng AI chưa", mà "AI của hacker có đánh lừa được AI bảo vệ của HF không".

Phe "agent thật". 17.000 events quy lớn, khó có script cổ điển duy trì được độ bền đó mà không vướng alert sớm. Swarm sandbox + self-migrating C2 là pattern của agent framework hiện đại, không phải pattern của bash script. HF là target xứng đáng - 45.000+ model, 50.000+ org, một nút thắt của toàn bộ ML open-source community ^[2]. Industry đã forecast "agentic attacker" từ lâu, và HF tự nhận "matches the scenario" ^[1]. LLM降低 cost của broad, patient, multi-stage campaign - lowers the bar - nên chuyện xảy ra chỉ là thời gian.

Phe "script thường dán nhãn AI". Kill chain RCE → escalation → cred harvest → lateral là pattern cổ điển, không cần AI. 17.000 events hoàn toàn match được bằng batch script + container orchestration + CronJob. Swarm short-lived sandbox = đúng kiểu Kubernetes pod sinh chết liên tục - không gì mới. Self-migrating C2 = cũng làm được bằng script + public dead drop.

Hơn nữa, HF có động cơ PR: narrative "AI attack"

• (a) hợp lý hóa breach tốt hơn là "kiến trúc trust boundary của mình bị khai thác bằng kỹ thuật cổ điển"
• (b) tạo câu chuyện hay cho báo chí
• (c) che chỗ kiến trúc bị chỉ trích. Commenter u/LLMsMustUpvoteThis trên r/cybersecurity nói thẳng: "What they've said in this article could be achieved with human recon and deterministic software" ^[10]. Trên Hacker News, u/charcircuit phủ nhận luôn "machine speed" của LLM: "A human can definitely be faster than these trillion parameter thinking models" ^[11].

Cả hai phe đều đúng một phần.

Câu đúng - và là câu HF chưa công bố dù có data để điều tra - nằm ở một dòng khác trong blog của họ ^[1]:

"The attack was initially surfaced through AI-assisted detection. Our anomaly-detection pipeline uses LLM-based triage over security telemetry to separate real signals from the daily noise, and it was the correlation of those signals that flagged the compromise."

HF dùng LLM để detect. Attacker dùng LLM (có thể) để tấn công. Vậy trong 17.000 events ấy, có lúc nào AI-of-attacker thực sự đối đầu AI-of-defender không? Có event nào mà agent-of-attacker cố gàng evade anomaly-detection-LLM của HF không? Anomaly-detection-LLM có catch được pattern nào mà rule-based miss không - và ngược lại, có pattern nào agent-of-attacker lỡ qua LLM-of-defender không?

Đó mới là điều đáng kể. Không phải "AI tấn công" - ai cũng dùng AI 2026. Mà AI-vs-AI đã thực sự xảy ra chưa, và nếu có thì ai thắng. HF có log 17.000 events, họ có thể trả lời. Họ chưa công bố.

"HF có nói hết không?"

HF tuyên bố:

• "limited set of internal datasets" - nhưng không có con số cụ thể. "Limited" theo định nghĩa ai?
• "several credentials used by our services" - nhưng không có loại credential, scope quyền, window thời gian.
• "no evidence of tampering with public, user-facing models, datasets, or Spaces" - "no evidence" ≠ "không xảy ra". HF control evidence pipeline.
• "software supply chain (container images and published packages) was verified clean" - "verified" bằng gì? Internal review hay third-party audit? Ai verify?
• "working with outside cybersecurity forensic specialists" - không tên firm, không scope.
• "reported this incident to law enforcement agencies" - không agency nào, không case number.

Mình không buộc tội HF cũng không phải là "HuggingFace con". Disclosure tốt thì cần thời gian, và HF mới công bố có vài ngày. Nhưng mình muốn ghi rõ: tính đến ngày 16/07/2026 disclosure, các tuyên bố trên không thể kiểm chứng độc lập từ bên ngoài. So với một disclosure tốt - có con số dataset/record, có danh sách credential type + scope, có IOCs công khai (hash, IP, sample malicious dataset), có timeline chi tiết, có methodology của third-party firm - thì disclosure của HF còn thiếu nhiều.

Đặc biệt, không có IOCs công khai. Không có hash của malicious dataset, không có C2 indicators, không có sample loader .py. Red team và SOC ở các org khác không có gì để hunt trong log của mình. Mình đang dùng HF hằng ngày, và mình không có cách nào kiểm tra xem mình đã pull dataset nào trùng với dataset độc hại của attacker chưa.

Đây là một dấu hiệu của pattern lớn hơn.

Pattern lặp: Spaces 2024 và Dataset 2026

Hơn hai năm trước, ngày 31/05/2024, HF disclosed một incident khác ^[14]:

"Earlier this week our team detected unauthorized access to our Spaces platform, specifically related to Spaces secrets. As a consequence, we have suspicions that a subset of Spaces' secrets could have been accessed without authorization."

Mình đặt hai disclosure cạnh nhau:

Cùng dạng impact (credentials exfil), cùng language mơ hồ, cùng lack IOCs, cùng remediation pattern - rotate, recommend fine-grained tokens. Hai năm apart ^[15].

Mình không nói HF không cố gắng. Họ cố. Nhưng bản chất platform của họ - chạy code không tin cậy + lưu credentials để worker làm việc - là attack surface lặp lại. Vụ 7/2026 không phải "lần đầu hack". Nó là lần thứ N trong chuỗi, và lần này narrative "AI" phủ lên trên để khiến nó trông mới.

Commenter u/nkwin trên blog HF đặt đúng ^[1]: "tools should be restricted in servers that isn't required for the data processing operations. SELinux, Secomp, Apparmor, rbac etc. Moving laterally and compromising many nodes & clusters is not really expected when you have stronger infrastructure security." Đây không phải chỉ trích HF - là chỉ ra rằng kiến trúc trust boundary của ML platform nói chung cần refactor, không phải thêm guardrail ở lớp trên.

HF đã làm gì, và vì sao từng bị thiếu

Năm bước remediation của HF ^[1]. Mình đi qua từng bước, vì mỗi bước đều trả lời câu "vì sao từng thiếu":

1. "Fixed the root vulnerability: the dataset code-execution paths used for initial access are closed." Hai path (loader + template injection) là cửa vào. Loader path là lựa chọn kiến trúc có chủ đích để preview dataset cho dev dùng Hub - không phải 0-day. Nó đã được flag từ 2023 ^[3] nhưng user-side mới fix năm 2025 (datasets v4). Server-side worker vẫn đang trong quá trình refactor khi attacker đánh.

2. "Eradicated the attacker's foothold across the affected clusters and rebuilt the compromised nodes." Assume breach. Attacker có thể đã plant persistence (cron, systemd, backdoor binary). Rebuild từ image sạch là cách duy nhất chắc. Đây cũng là lời ngầm thừa nhận rằng HF không tin mình đã scan hết persistence - build lại thì chắc hơn scan.

3. "Revoked and rotated the affected credentials and tokens, and began a broader precautionary rotation of secrets." Credentials đã bị harvest. Rotate affected là tối thiểu. Broader precautionary rotation vì HF không biết chính xác scope - đó là sự thật thừa nhận trong chữ "precautionary".

4. "Deployed additional guardrails and stricter admission controls on our clusters." Admission control (Kiểm tra policy trước khi pod chạy) chặn pattern đáng ngờ ở layer orchestrator, độc lập với worker itself. Đây là lớp defense mà trước đó chưa đủ cứng.

5. "Improved our detection and alerting so a high-severity signal pages a responder in minutes, any day of the week." Breach chạy "over a weekend" - tức là detection có window chậm. 24/7 paging rút window đó xuống. HF thừa nhận bằng cách sửa.

Năm bước này không có gì sai. Nhưng mình thấy chúng là phản ứng, không phải phòng bị. Vấn đề kiến trúc - worker chạy untrusted code + có credential mounted - vẫn cần refactor tiếp. Pattern defense-in-depth cho một worker chạy code không tin cậy thì đã có sẵn playbook:

• Container hardened: seccomp profile deny syscall nguy hiểm, AppArmor/SELinux enforce.
• No network egress: worker chỉ cần pull từ Hub internal, không cần call ra internet. C2 self-migrating không sống được nếu worker không có egress.
• No credential mounted: worker dùng short-lived OIDC token, không env var static. Attacker RCE được cũng không có gì để harvest.
• Ephemeral: worker chết sau 1 job, không persist. Persistence không kịp plant.
• gVisor hoặc Kata Containers: sandbox cấp VM thay vì chỉ namespace, chống container escape.

Mình không biết HF đã làm tới đâu trong list này. Blog không nói. Nhưng nếu attacker RCE được worker rồi leo node-level và harvest credential, thì một trong các lớp trên chưa đủ cứng.

Vậy tuần tới mình pull dataset thì làm gì

Mình tổng kết lại cho bạn dev Việt Nam cũng dùng HF như mình. Ba việc cụ thể tuần này:

Một, rotate access token. Nếu bạn vẫn dùng classic read/write token, bỏ đi, chuyển sang fine-grained access token. HF khuyến nghị ngay từ vụ 2024 ^[14] và lặp lại trong vụ này. Fine-grained cho phép scope từng repo, từng permission, và rotate không đau.

Hai, mặc định trust_remote_code=False. Nếu bạn vẫn dùng datasets v3 hoặc cũ, set trust_remote_code=False mặc định trong config của project. Chỉ bật True khi bạn đã đọc loader .py của dataset đó - mở file lên, đọc, confirm không có gì lạ. V4 đã remove flag nên upgrade nếu được.

Ba, nếu bạn đang chạy dataset processing trên infra riêng (không phải worker của HF, mà là worker của bạn đang load dataset từ Hub), sandbox thật. Container + seccomp + no network egress. Đừng mount credential vào env var. Dùng short-lived token. Worker chết sau mỗi job.

Và một việc cuối, khó hơn: nếu bạn làm incident response và cần LLM phân tích log/payload, đừng phụ thuộc vào hosted API duy nhất. HF đã bị frontier model thương mại block khi submit real exploit payload cho forensic ^[1] - guardrail không phân biệt được IR responder với attacker. Hãy có sẵn một model tự host đủ mạnh, vetted trước khi có incident. Đây không phải bài toán của HF, là bài toán của tất cả org nào dùng LLM cho defense.

Mình kết bằng một câu hỏi mà mình vẫn chưa có câu trả lời, và mình nghĩ những bạn đọc bài này nên hỏi HF trực tiếp: trong 17.000 events ấy, AI-of-attacker có thực sự đối đầu AI-of-defender của các bạn không? Nếu có - đó là trận đấu đầu tiên được tài liệu hóa, và cách nó kết thúc sẽ nói cho chúng ta biết rất nhiều về tương lai của defense. Nếu không - thì "AI attack" chỉ là lớp sơn mới trên một lỗ hổng cũ, và việc đáng làm là refactor kiến trúc, không phải thêm guardrail ở lớp trên.

HF có data. Hãy công bố phân tích.

Ghi chú: bài viết này dựa hoàn toàn trên blog disclosure của HF ^[1], sources công khai ^{[13] [2]}, và thảo luận trên Hacker News với Reddit ^{[11] [12] [10]}. Mọi claim kỹ thuật đều có nguồn. Những chỗ mình suy luận (cơ chế template injection, chi tiết escalation) đều ghi rõ là suy luận. Bài không nhận tài trợ từ HF hay bất kỳ bên nào.

Bình