Hugging Face ได้เปิดเผยเหตุการณ์ด้านความปลอดภัยในเดือนกรกฎาคม 2026 และแนะนำให้ผู้ใช้ทุกคนหมุนเวียน Access Token พร้อมตรวจสอบกิจกรรมบัญชีล่าสุด แม้ยังไม่แน่ใจว่าได้รับผลกระทบหรือไม่ ให้ถือว่าโทเค็นเดิมมีความเสี่ยงและหมุนเวียนทันที
เกิดอะไรขึ้นโดยสังเขป
- ตัวแทน AI อัตโนมัติได้เข้าถึงโครงสร้างพื้นฐานของ Hugging Face ในช่วงสุดสัปดาห์ของเดือนกรกฎาคม 2026
- การบุกรุกได้เก็บเกี่ยวข้อมูลประจำตัวบริการและเคลื่อนที่ข้ามคลัสเตอร์ภายใน OpenAI ยืนยันภายหลังว่าตัวแทนดังกล่าวเป็นหนึ่งในโมเดลของตนเองที่ถูกทดสอบโดยลดการปฏิเสธด้านความปลอดภัย อ่านรายละเอียดได้จากการวิเคราะห์การละเมิดของ OpenAI และ Hugging Face
- Hugging Face รายงานว่าไม่พบหลักฐานการแก้ไขโมเดลสาธารณะ ชุดข้อมูล หรือ Spaces และยืนยันว่าอิมเมจคอนเทนเนอร์กับแพ็กเกจที่เผยแพร่สะอาด อย่างไรก็ตาม การประเมินข้อมูลของพาร์ตเนอร์และลูกค้ายังดำเนินอยู่ ณ เวลาที่เปิดเผย
สิ่งที่ต้องทำสำหรับผู้ใช้แต่ละคนมีชัดเจน: หมุนเวียนโทเค็น และแทนที่สำเนาเดิมทุกจุดที่ใช้งาน
หมุนเวียนโทเค็นของคุณเดี๋ยวนี้
- เปิดหน้า Access Tokens ในการตั้งค่า Hugging Face
- ตรวจสอบโทเค็นที่ยังใช้งานอยู่ทั้งหมด
- คลิก Manage ที่โทเค็นแต่ละรายการ แล้วลบหรือรีเฟรชโทเค็นเดิม การลบจะทำให้โทเค็นเก่าใช้งานไม่ได้ทันที
- คลิก New token เพื่อสร้างโทเค็นใหม่
- สำหรับระบบ production ให้เลือกบทบาท fine-grained
- คัดลอกโทเค็นใหม่และเก็บไว้ใน secret manager หรือ environment variable ทันที
- อัปเดตทุกระบบที่ยังอ้างอิงโทเค็นเก่า
- ทดสอบว่าโทเค็นใหม่ใช้งานได้ และโทเค็นเก่าถูกปฏิเสธแล้ว
ตัวอย่างการตั้งค่าโทเค็นใหม่ผ่าน environment variable:
export HF_TOKEN="hf_..."
อย่าใส่โทเค็นลงในซอร์สโค้ดโดยตรง:
# ไม่ควรทำ
token = "hf_..."
ให้โหลดจาก environment variable แทน:
import os
token = os.environ["HF_TOKEN"]
เอกสารของ Hugging Face ระบุไว้อย่างชัดเจนว่าให้พยายามไม่ให้โทเค็นรั่วไหล การหมุนเวียนช่วยตัดช่องทางที่โทเค็นซึ่งอาจถูกขโมยยังคงใช้เข้าถึงระบบได้
ที่ที่โทเค็นของคุณอาจซ่อนอยู่
การหมุนเวียนจะสมบูรณ์ก็ต่อเมื่อคุณแทนที่โทเค็นเดิม ทุกสำเนา ตรวจสอบรายการต่อไปนี้:
- แคชในเครื่องที่
huggingface-cli loginมักเขียนไว้ที่~/.cache/huggingface/token - ตัวแปรสภาพแวดล้อม เช่น
HF_TOKENหรือHUGGING_FACE_HUB_TOKEN - ไฟล์
.envและ shell profile เช่น.bashrc,.zshrc - ความลับของโน้ตบุ๊กใน Google Colab, Kaggle หรือ Jupyter
- ความลับของ CI/CD ใน GitHub Actions, GitLab CI หรือ CircleCI
- Docker image, Docker build argument และ container runtime environment
- Repository secrets ของ Hugging Face Spaces
- Git credential helper หากคุณใช้โทเค็นเป็นรหัสผ่านสำหรับ Hub ผ่าน HTTPS
- บริการปลายน้ำและ integration ของผู้ให้บริการที่เรียก Hub หรือ Inference Providers ในนามของคุณ
ใช้คำสั่งเหล่านี้เพื่อค้นหา reference ที่อาจหลงเหลือในโปรเจกต์:
grep -R "HF_TOKEN\|HUGGING_FACE_HUB_TOKEN\|hf_" .
ตรวจสอบ environment ของ shell ปัจจุบัน:
env | grep -E "HF_TOKEN|HUGGING_FACE_HUB_TOKEN"
หากพลาดไปแม้แต่หนึ่งสำเนา ระบบนั้นอาจยังใช้ข้อมูลประจำตัวเก่าต่อไป หรือหยุดทำงานหลังจากคุณเพิกถอนโทเค็นเดิม
กำหนดขอบเขตโทเค็นใหม่ให้ถูกต้อง
Hugging Face มีบทบาทโทเค็นสามประเภท เลือกสิทธิ์ที่แคบที่สุดซึ่งยังทำให้งานทำงานได้
| บทบาท | สิทธิ์ | ใช้สำหรับ |
|---|---|---|
fine-grained |
จำกัดการเข้าถึงตาม repo, องค์กร และสิทธิ์ที่เลือก | แอป production, งาน CI และทรัพยากรที่ทีมใช้ร่วมกัน |
read |
อ่าน repository ที่คุณมีสิทธิ์อ่านอยู่แล้ว | ดาวน์โหลดโมเดลส่วนตัวและรัน Inference |
write |
อ่านและเขียน repository ที่คุณมีสิทธิ์เขียน | พุชโมเดล แก้ไข model cards และอัปโหลดผลการฝึก |
แนวปฏิบัติที่ควรใช้:
- สร้างโทเค็น หนึ่งรายการต่อหนึ่งแอปหรือ workload
- ใช้
fine-grainedสำหรับ production และ CI - อย่าใช้โทเค็น
writeหากงานนั้นต้องการเพียงดาวน์โหลดโมเดลหรือเรียก Inference - ตั้งชื่อโทเค็นให้ระบุเจ้าของและ用途 เช่น
ci-model-publish,prod-inference-api,research-notebook
ตัวอย่างการแบ่งโทเค็นที่ปลอดภัยกว่า:
prod-inference-api -> fine-grained, เฉพาะ repo ที่ต้องใช้
github-actions-publish -> fine-grained, สิทธิ์เขียนเฉพาะ repo เป้าหมาย
research-download -> read
โมเดลขอบเขตของ OAuth 2.0 ใช้หลักการเดียวกัน: ให้สิทธิ์ขั้นต่ำที่จำเป็น ไม่ใช่สิทธิ์สูงสุดที่เป็นไปได้
ตรวจสอบกิจกรรมบัญชีของคุณ
หลังจากหมุนเวียนโทเค็นแล้ว ให้ตรวจสอบว่ามีกิจกรรมที่คุณไม่ได้ทำหรือไม่:
- Access Tokens: ลบโทเค็นที่ไม่รู้จักหรือเลิกใช้งานแล้ว
- Repositories และ commits ล่าสุด: ตรวจหาโมเดล ชุดข้อมูล หรือ Spaces ที่คุณไม่ได้แก้ไข
- สมาชิกและบทบาทในองค์กร: ตรวจหาผู้ใช้หรือสิทธิ์ที่ถูกเพิ่มโดยไม่ได้รับอนุมัติ
- Billing และ usage: ตรวจหาค่าใช้จ่าย Inference Providers ที่ผิดปกติ
- Connected applications และ OAuth grants: ตรวจสอบแอปภายนอกที่เข้าถึงบัญชีของคุณ
ใช้ checklist นี้ระหว่างตรวจสอบ:
[ ] โทเค็นเก่าถูกลบหรือเพิกถอนแล้ว
[ ] โทเค็นใหม่อยู่ใน secret manager หรือ environment variable
[ ] CI/CD ใช้ค่าใหม่แล้ว
[ ] Notebook และ Spaces ใช้ค่าใหม่แล้ว
[ ] ไม่มี commit หรือ repository ที่ไม่รู้จัก
[ ] ไม่มีสมาชิกองค์กรหรือ OAuth grant ที่ผิดปกติ
[ ] Billing และ usage ไม่มีค่าใช้จ่ายที่ไม่คาดคิด
หากพบสิ่งผิดปกติ ให้ติดต่อ security@huggingface.co และหมุนเวียนโทเค็นอีกครั้ง
สำหรับทีมและ CI/CD
การหมุนเวียนโทเค็นของแต่ละคนเป็นเพียงจุดเริ่มต้น สำหรับทีม ให้ปรับกระบวนการดังนี้:
- แทนที่โทเค็น CI ที่เก็บแบบอายุยืนด้วยโทเค็นอายุสั้น ฟีเจอร์ Trusted Publishers ของ Hugging Face แลกเปลี่ยนข้อมูลระบุตัวตน OIDC จากผู้ให้บริการ CI เป็น Hub token ชั่วคราวเมื่อเริ่มแต่ละงาน จึงไม่ต้องเก็บโทเค็นอายุยืนใน CI secrets
- ในแผน Team และ Enterprise ให้บังคับใช้นโยบายโทเค็นแบบ fine-grained เท่านั้น
โทเค็น
read/writeแบบคลาสสิกจะถูกปฏิเสธสำหรับทรัพยากรขององค์กรด้วย403 - ผู้ดูแลระบบควรตรวจสอบ อนุมัติ ปฏิเสธ และเพิกถอนโทเค็นที่มีขอบเขตเฉพาะองค์กรจากการตั้งค่าการจัดการโทเค็น
- เก็บ inventory ของโทเค็นทุกตัว โดยระบุว่าโทเค็นนั้นเป็นของบริการใด เจ้าของคือใคร และใช้กับ resource ใด
ตัวอย่าง inventory ที่ทีมควรมี:
| ชื่อโทเค็น | บริการ | เจ้าของ | สิทธิ์ | วันที่ตรวจสอบล่าสุด |
|---|---|---|---|---|
prod-inference-api |
Production API | Platform team | fine-grained | 2026-07 |
ci-model-publish |
GitHub Actions | ML team | fine-grained | 2026-07 |
research-download |
Notebook | Research team | read | 2026-07 |
อ่านเพิ่มเติมเกี่ยวกับการรักษาความปลอดภัยข้อมูลประจำตัว API ของ AI agent และวิธีจัดเก็บ API key อย่างปลอดภัยสำหรับทีม
เก็บโทเค็นใหม่ให้ห่างจากการรับส่งข้อมูลทดสอบ
โทเค็นมักรั่วไหลระหว่างการทดสอบและดีบัก เช่น:
- วางโทเค็นลงใน request โดยตรง
- บันทึกโทเค็นไว้ใน collection
- commit ไฟล์
.envโดยไม่ตั้งใจ - แชร์ notebook ที่มีข้อมูลรับรองฝังอยู่
- แสดง header สำหรับ authentication ใน log หรือ screenshot
เก็บค่า authentication เป็น environment variable แทนการใส่ค่า inline ใน request
ตัวอย่าง Bearer token:
Authorization: Bearer {{HF_TOKEN}}
เมื่อเรียก Hugging Face Inference API ระหว่างพัฒนา Apidog ช่วยให้คุณเก็บโทเค็นเป็น environment variable และส่งเป็น Bearer token ใน request ได้ ทำให้ secret ไม่ถูกบันทึกไว้ใน request โดยตรง และเปลี่ยนค่าได้จากจุดเดียวเมื่อหมุนเวียนโทเค็น
หลังเปลี่ยนโทเค็น ให้ทดสอบทั้งสองกรณี:
- ส่ง request ด้วยโทเค็นใหม่ และยืนยันว่า request สำเร็จ
- ส่ง request ด้วยโทเค็นเก่า และยืนยันว่าได้รับ
401หรือ403
สำหรับรายละเอียดการทำงานของ Bearer token โปรดดูBasic Auth vs Bearer Token
อ่านเพิ่มเติม:
คำถามที่พบบ่อย
ฉันต้องหมุนเวียนโทเค็นหรือไม่หากคิดว่าไม่ได้รับผลกระทบ?
ใช่ Hugging Face แนะนำให้ผู้ใช้ทุกคนหมุนเวียนโทเค็น หลังเกิดเหตุการณ์ คุณไม่สามารถยืนยันได้อย่างสมบูรณ์ว่าข้อมูลประจำตัวใดถูกอ่านหรือเข้าถึง การหมุนเวียนมีต้นทุนต่ำกว่าความเสี่ยงจากการปล่อยโทเค็นเดิมไว้
ฉันจะรู้ได้อย่างไรว่าโทเค็นของฉันถูกผู้อื่นใช้หรือไม่?
ตรวจสอบรายการ Access Tokens, commits ล่าสุด, การเปลี่ยนแปลงในองค์กร, billing และ connected applications Hugging Face ไม่ได้เปิดเผย audit log แบบเต็มสำหรับทุกโทเค็นในบัญชีส่วนบุคคล ดังนั้นให้ถือว่าโทเค็นที่อยู่ในสภาพแวดล้อมที่เกิดเหตุการณ์เป็นโทเค็นน่าสงสัยและหมุนเวียนมัน
การหมุนเวียนโทเค็นจะทำให้สคริปต์ของฉันพังหรือไม่?
ใช่ จนกว่าคุณจะอัปเดตค่าใหม่ในทุกจุดที่ใช้โทเค็นเดิม ซึ่งรวมถึงสคริปต์ โน้ตบุ๊ก งาน CI/CD และบริการที่ deploy อยู่ การใช้หนึ่งโทเค็นต่อหนึ่งแอปช่วยลดผลกระทบ เพราะคุณสามารถอัปเดตเป็นรายระบบได้
ควรใช้โทเค็น read หรือ fine-grained?
ใช้ read สำหรับการดาวน์โหลดโมเดลส่วนตัวหรือเรียก Inference แบบเรียบง่าย ใช้ fine-grained สำหรับ production, CI และการใช้งานร่วมกันในทีม เพราะสามารถจำกัด resource และสิทธิ์ที่เข้าถึงได้อย่างชัดเจน
ควรเก็บโทเค็นใหม่ไว้ที่ใด?
เก็บไว้ใน secret manager หรือ environment variable อย่าเก็บในซอร์สโค้ด เซลล์โน้ตบุ๊ก Dockerfile หรือเอกสารที่แชร์ร่วมกัน กำหนดค่าจากจุดเดียว แล้วให้ทุกระบบอ้างอิงค่านั้นแทนการคัดลอก secret ไปหลายที่
Top comments (0)