Hugging Face ถูกเจาะระบบโดย "ฝูง AI agent" อัตโนมัติ — และต้องใช้โมเดล open-weight สืบสวน เพราะ API เจ้าใหญ่บล็อกงานสืบสวนของตัวเอง

วันที่ 16 กรกฎาคม 2026 Hugging Face — แพลตฟอร์มที่นักพัฒนา AI ทั่วโลกใช้โหลดโมเดลและ dataset ทุกวัน — เปิดเผยว่าถูกบุกรุก production infrastructure บางส่วน และเหตุการณ์นี้ “ต่างจากทุกครั้งที่เคยเจอ” ในจุดสำคัญจุดเดียว: การโจมตีถูกขับเคลื่อนโดยระบบ AI agent อัตโนมัติตั้งแต่ต้นจนจบ ไม่ใช่มนุษย์นั่งพิมพ์คำสั่ง และทีม Hugging Face ก็ต้องใช้ AI ของตัวเองเข้าไปตรวจจับและถอดรื้อมันเช่นกัน

นี่คือสิ่งที่วงการเตือนกันมาตลอดว่า “จะเกิด” ในนาม agentic attacker — และตอนนี้มันเกิดกับแพลตฟอร์ม AI ที่ใหญ่ที่สุดแห่งหนึ่งของโลกแล้วจริง ๆ สิ่งที่ทำให้โพสต์นี้ควรอ่านไม่ใช่แค่ตัวเหตุการณ์ แต่คือบทเรียนที่ Hugging Face เจอระหว่างสืบสวน ซึ่งกระทบวิธีที่ทีมพัฒนาทุกทีมควรเตรียมตัว

เกิดอะไรขึ้น — เริ่มจาก dataset ที่เป็นพิษ

จุดเริ่มต้นอยู่ตรงที่ “แพลตฟอร์ม AI เปราะบางเป็นพิเศษ” นั่นคือ data-processing pipeline

• dataset ที่ถูกวางยา ใช้ช่องทางรันโค้ดสองทางใน pipeline ประมวลผล dataset ของ Hugging Face — ได้แก่ remote-code dataset loader และ template-injection ใน dataset configuration — เพื่อรันโค้ดบน processing worker
• จากนั้นผู้โจมตียกระดับสิทธิ์ไปถึง node-level access แล้วเก็บเกี่ยว credential ของ cloud และ cluster
• และเคลื่อนตัวออกด้านข้าง (lateral movement) เข้าไปในหลาย internal cluster ตลอดช่วงสุดสัปดาห์

ลักษณะการโจมตีคือ agent framework อัตโนมัติ (ดูเหมือนสร้างบน agentic security-research harness — ยังไม่รู้ว่าใช้ LLM ตัวไหน) ที่ยิง คำสั่งเดี่ยว ๆ หลายพันถึงหลายหมื่นครั้ง ผ่าน ฝูง sandbox อายุสั้น พร้อม command-and-control ที่ ย้ายตัวเองไปเรื่อย ๆ โดยอาศัยบริการสาธารณะเป็นที่พัก

ขอบเขตความเสียหาย และสิ่งที่คุณต้องทำ

Hugging Face ระบุว่าพบการเข้าถึงโดยไม่ได้รับอนุญาตต่อ internal dataset จำนวนจำกัด และ credential ของ service หลายตัว ส่วนที่ยังประเมินไม่จบคือมีข้อมูลของพาร์ทเนอร์หรือลูกค้าได้รับผลกระทบหรือไม่ — ถ้ามี บริษัทจะติดต่อโดยตรง

ข่าวดีสำหรับคนส่วนใหญ่:

• ไม่พบหลักฐานการแก้ไข โมเดล, dataset หรือ Spaces ที่เป็นสาธารณะ
• software supply chain สะอาด — ทั้ง container images และ package ที่เผยแพร่ ผ่านการตรวจสอบแล้ว

สิ่งที่ Hugging Face ทำไปแล้ว: ปิดช่องรันโค้ดที่เป็นต้นเหตุ, กวาดล้างจุดยึดของผู้โจมตีและ rebuild node ที่โดน, เพิกถอนและหมุน credential ที่กระทบพร้อมเริ่มหมุน secret ในวงกว้างเพื่อความปลอดภัย, เพิ่ม guardrail และ admission control ที่เข้มขึ้นบน cluster, และปรับระบบตรวจจับให้สัญญาณระดับสูงเรียกคนรับมือได้ภายในไม่กี่นาที ทุกวันในสัปดาห์ นอกจากนี้ยังดึงผู้เชี่ยวชาญ forensic ภายนอกเข้ามา และแจ้งหน่วยงานบังคับใช้กฎหมายแล้ว

สิ่งที่นักพัฒนาควรทำตอนนี้: Hugging Face แนะนำให้ หมุน (rotate) access token ทุกตัว และ ตรวจสอบกิจกรรมล่าสุดในบัญชี เพื่อความปลอดภัย ถ้าสงสัยว่าได้รับผลกระทบ ติดต่อ security@huggingface.co

ถ้าทีมคุณฝัง HF_TOKEN ไว้ใน CI, Docker image หรือ notebook — นี่คือวันที่ควรไล่หมุนมันให้ครบ

AI จับ AI: สืบสวน 17,000 เหตุการณ์ได้ในหลักชั่วโมง

สิ่งที่ทำให้เรื่องนี้น่าสนใจสำหรับคนสร้างระบบ คือฝั่งตั้งรับก็เป็น AI เหมือนกัน

การโจมตีถูกจับได้จาก การตรวจจับด้วย AI — pipeline ตรวจจับความผิดปกติของ Hugging Face ใช้ LLM คัดกรอง (triage) telemetry ด้านความปลอดภัย เพื่อแยกสัญญาณจริงออกจากสัญญาณรบกวนประจำวัน และการเชื่อมโยงสัญญาณเหล่านั้นเข้าด้วยกันคือสิ่งที่จุดชนวนว่ามีการบุกรุก

จากนั้น เพื่อเข้าใจว่าฝูง action อัตโนมัติหลายหมื่นครั้งทำอะไรไปบ้าง ทีมงานปล่อย LLM-driven analysis agent ไล่อ่าน log การกระทำของผู้โจมตีทั้งหมดกว่า 17,000 เหตุการณ์ เพื่อประกอบไทม์ไลน์ใหม่, ดึง indicator of compromise, แมพว่ามี credential ใดถูกแตะบ้าง และแยก “ผลกระทบจริง” ออกจาก “กิจกรรมลวง” ผลคือทำงานที่ปกติใช้เวลาหลายวันให้จบใน หลักชั่วโมง — ทันความเร็วของคู่ต่อสู้

ปัญหา “ความไม่สมมาตร” — guardrail บล็อกฝ่ายป้องกัน แต่ไม่บล็อกฝ่ายโจมตี

นี่คือส่วนที่สำคัญที่สุดของโพสต์ และเป็นบทเรียนที่ Hugging Face บอกเองว่า “ไม่ได้คาดคิดมาก่อน”

ตอนเริ่มวิเคราะห์ log ทีมงานลองใช้ โมเดลระดับ frontier ผ่าน commercial API ก่อน — แต่ใช้ไม่ได้ เพราะงานสืบสวนต้องส่งคำสั่งโจมตีจริง, exploit payload และ artifact ของ C2 เข้าไปเป็นจำนวนมาก และคำขอเหล่านั้น ถูก guardrail ด้านความปลอดภัยของผู้ให้บริการบล็อก — เพราะ guardrail แยกไม่ออกระหว่าง “ผู้รับมือเหตุการณ์” กับ “ผู้โจมตี”

ทีมงานจึงหันไปรันงาน forensic บน GLM 5.2 ซึ่งเป็นโมเดล open-weight บนโครงสร้างพื้นฐานของตัวเอง และได้ประโยชน์ข้อที่สองแถมมาด้วย: ข้อมูลของผู้โจมตีและ credential ที่ถูกอ้างถึงในนั้น ไม่ต้องออกจากระบบของบริษัทเลย

Hugging Face สรุปความไม่สมมาตรนี้ไว้คมมาก: ไม่มีใครรู้ว่า agent ของผู้โจมตีใช้โมเดลอะไร — จะเป็นโมเดล hosted ที่ถูก jailbreak หรือ open-weight ที่ไม่มีข้อจำกัดก็ตาม — แต่ไม่ว่าทางไหน ผู้โจมตีไม่ถูกผูกด้วย usage policy ใด ๆ ขณะที่งานสืบสวนของฝ่ายป้องกันกลับถูก guardrail ของโมเดล hosted บล็อก

บทเรียนเชิงปฏิบัติที่บริษัทฝากไว้กับฝ่ายป้องกันคือ: จงมีโมเดลที่เก่งพอและรันบนโครงสร้างพื้นฐานของตัวเองได้ ตรวจสอบและเตรียมไว้ให้พร้อม ก่อน เกิดเหตุ ทั้งเพื่อไม่ให้ถูก guardrail ล็อกเอาต์ และเพื่อไม่ให้ข้อมูลผู้โจมตีกับ credential หลุดออกนอกองค์กร — ทั้งนี้บริษัทย้ำว่านี่ไม่ใช่การคัดค้านมาตรการความปลอดภัยบนโมเดล hosted และได้ส่ง feedback นี้ให้ผู้ให้บริการที่เกี่ยวข้องแล้ว

มุมมอง AI Curator

เมื่อวานเราเพิ่งเขียนถึง GPT-Red ของ OpenAI — AI ที่ถูกฝึกให้โจมตีโมเดลตัวเองเพื่อหาช่องโหว่ก่อนคนร้ายจะเจอ วันนี้เราได้เห็นอีกด้านของเหรียญเดียวกัน: คนร้ายก็มี agent ของตัวเองแล้ว และมันไม่ได้อยู่ในสไลด์นำเสนออีกต่อไป — มันเข้าไปอยู่ใน cluster ของ Hugging Face มาทั้งสุดสัปดาห์ ช่องว่างระหว่าง “สถานการณ์สมมติ” กับ “รายงานเหตุการณ์จริง” ปิดลงภายในเวลาไม่ถึง 24 ชั่วโมงของข่าว

สิ่งที่ผมคิดว่าทีมไทยควรถอดบทเรียนมี 3 ข้อ

1. “ข้อมูลที่รับเข้ามา” คือพื้นที่โจมตีชั้นหนึ่ง ไม่ใช่เรื่องรอง ทางเข้าของการโจมตีนี้ไม่ใช่ VPN หรือรหัสผ่านหลุด แต่คือ dataset ที่ถูกวางยา ผ่าน remote-code loader และ template injection — กลไกที่ทีม ML แทบทุกทีมเปิดใช้แบบไม่คิดอะไร ใครที่ยังเรียก trust_remote_code=True กับ dataset หรือโมเดลจากอินเทอร์เน็ตแบบอัตโนมัติใน pipeline ควรถือว่านี่คือใบเตือนใบสุดท้าย และถ้าใช้ HF token ใน CI — หมุนมันวันนี้

2. บทเรียนเรื่อง guardrail คือข้อโต้แย้งที่ทรงพลังที่สุดของ open-weight ที่ผมเคยเห็น เราเถียงกันเรื่องโมเดลเปิดมานาน มักด้วยเหตุผลเรื่องราคา, ความเป็นส่วนตัว หรืออธิปไตยทางเทคโนโลยี แต่เคสนี้เพิ่มเหตุผลใหม่ที่รูปธรรมมาก: วันที่คุณโดนแฮ็ก โมเดลที่คุณจ่ายเงินรายเดือนอาจปฏิเสธที่จะช่วยคุณ เพราะงานสืบสวนหน้าตาเหมือนงานโจมตีเกินไป นี่ไม่ใช่ข้อบกพร่องที่ผู้ให้บริการแก้ง่าย ๆ — มันคือธรรมชาติของ guardrail ที่ตัดสินจาก “เนื้อหาคำขอ” โดยไม่รู้ “เจตนาของผู้ขอ” สำหรับองค์กรไทยที่มีทีม security เล็ก ๆ นี่แปลว่าการมีโมเดลเปิดที่รันเองได้ (GLM, Qwen, Llama หรือรุ่นที่เพิ่งออกอย่าง Inkling) ไม่ใช่ “ของเล่นประหยัดงบ” แต่คือ ความสามารถสำรองที่ต้องซ้อมไว้ก่อนเกิดเหตุ เหมือนซ้อมหนีไฟ

3. เรื่องนี้พันกับ PDPA ตรง ๆ ลองนึกภาพทีมไทยที่โดนบุกรุกแล้วต้องส่ง log ที่มีข้อมูลส่วนบุคคลของลูกค้า, credential และ payload ออกไปให้ API ต่างประเทศวิเคราะห์ — นั่นคือการส่งข้อมูลข้ามพรมแดนกลางเหตุการณ์ที่คุณควบคุมอะไรได้น้อยที่สุด ข้อดีที่ Hugging Face บอกว่า “ข้อมูลไม่ต้องออกจากระบบ” จึงไม่ใช่แค่ความสบายใจ แต่คือการลดภาระการปฏิบัติตามกฎหมายในนาทีที่คุณไม่มีเวลามานั่งคิดเรื่องนั้น

สุดท้าย จุดที่ควรชม: Hugging Face เลือกเล่าเรื่องนี้อย่างละเอียดทั้งที่ไม่จำเป็นต้องเล่า รวมถึงจุดที่ทำให้ตัวเองดูไม่ดี (เช่นการที่ผู้โจมตีอยู่ในระบบได้ทั้งสุดสัปดาห์ และการที่ต้องแก้ปัญหาด้วยการหนีไปใช้โมเดลจีน) ในอุตสาหกรรมที่รายงานเหตุการณ์ส่วนใหญ่ถูกเขียนโดยฝ่ายกฎหมายจนอ่านแล้วไม่ได้อะไร ความตรงไปตรงมาระดับนี้คือของหายาก — และมันมีค่ากับทุกทีมที่กำลังจะเจอ agentic attacker เป็นรายต่อไป

แหล่งข่าว

• Security incident disclosure — July 2026 — Hugging Face Blog (16 ก.ค. 2026)
• GLM-5.2 — zai-org บน Hugging Face
• ติดต่อทีมความปลอดภัยของ Hugging Face — security@huggingface.co