สแกน 7.6 เพตะไบต์ของ training data บน Hugging Face เจอ API key ที่ยังใช้งานได้จริง 221,303 ตัว — และ 44% ถูกก๊อปข้ามหลายชุดข้อมูล

วันที่ 31 กรกฎาคม 2026 Dylan Ayrey จาก Truffle Security (ทีมเบื้องหลัง TruffleHog) เผยแพร่ผลการสแกนที่บริษัทเรียกว่าใหญ่ที่สุดเท่าที่เคยทำ: ไล่สแกน dataset repository บน Hugging Face ราว 815,000 ชุด (สแกนจบสมบูรณ์ราว 670,000 ชุด) รวม 186.9 ล้านไฟล์ ปริมาณ 7.6 เพตะไบต์ เพื่อหา credential ที่หลุดปนอยู่ในข้อมูลฝึกโมเดล

ผลลัพธ์คือ 221,303 credential ที่ verify แล้วว่ายังมีชีวิต — ไม่ใช่ pattern ที่ “หน้าตาเหมือนคีย์” แต่คือคีย์ที่ทีมงานยิงไปตรวจแล้วระบบปลายทางตอบรับ กระจายอยู่ใน 6,003 ชุดข้อมูล ทีมงานระบุว่าสเกลนี้ ใหญ่กว่างานสแกนระดับเว็บครั้งก่อนของตัวเองราว 19 เท่า (ครั้งก่อนอยู่ที่ 400 เทระไบต์)

ประเด็นสำหรับคนที่ทำงานกับ AI ไม่ใช่แค่ “มีคีย์หลุด” — แต่คือ training data เป็นช่องทางรั่วที่ลบยากที่สุดในบรรดาช่องทางทั้งหมด

ตัวเลขที่ควรรู้

จากรายงาน สิ่งที่พบแยกตามประเภทได้ประมาณนี้:

ประเภท	จำนวนที่ยังใช้งานได้	ผลกระทบที่รายงานระบุ
GCP service-account key	8,557	กระจายใน 3,811 โปรเจกต์
Database login	8,594	เข้าถึงข้อมูลได้รวม 3.5 TB
API key ของผู้ให้บริการ AI	11,496	OpenAI 742, Gemini 1,429, DeepSeek 667, xAI Grok 162, Anthropic 26, Azure OpenAI 174 deployment
GitHub personal access token	349	ในนั้น 223 ตัวเขียน repository ได้
Docker Hub token	318	push image ได้

สองแถวล่างคือส่วนที่น่ากลัวที่สุดในเชิง supply chain: token ที่ เขียนโค้ดกลับเข้าไปในสิ่งที่คนอื่นติดตั้ง ได้จริง หัวข้อแรกของรายงานถึงตั้งชื่อตรง ๆ ว่า “Tokens that can push code into things you install”

Truffle Security ยังประเมินมูลค่าความเสียหายเฉพาะฝั่ง inference ที่ถูกขโมยไว้ที่ อย่างน้อย 920,000 ดอลลาร์ต่อปี โดยคิดจากเพดานการใช้จ่าย default ของแต่ละผู้ให้บริการเท่านั้น — ซึ่งเป็นการประเมินแบบอนุรักษ์นิยม และยังมีเคสหนึ่งที่ credential ตัวเดียวเปิดทางเข้าถึงข้อมูลส่วนบุคคล (PII) ขนาด 393 GB

ทีมงานย้ำว่าใช้ credential เหล่านี้ เพื่อ verify และตรวจ metadata ระดับผลกระทบเท่านั้น ไม่ได้เข้าไปอ่านข้อมูลที่เก็บอยู่หรือแก้ไขระบบใด

จุดที่สำคัญกว่าตัวเลข: คีย์เดียวถูกก๊อปไปทั่วทั้งระบบนิเวศ

ส่วนที่ผมคิดว่าเป็นข้อค้นพบจริงของงานนี้ ไม่ใช่ยอด 221,303 แต่คือรูปแบบการแพร่กระจาย

รายงานพบว่า 44% ของ unique live secret ทั้งหมด โผล่อยู่ในมากกว่าหนึ่งชุดข้อมูล และมี 19,380 ตัวที่โผล่ในตั้งแต่ 10 ชุดข้อมูลขึ้นไป ตัวอย่างสุดขั้วคือ Infura key ตัวเดียวที่ถูกพบใน 1,131 ชุดข้อมูล

กลไกที่ทำให้เป็นแบบนี้ชัดเจนมาก: 99.3% ของคีย์ที่ไปโผล่ตั้งแต่ 10 ชุดข้อมูลขึ้นไป ผ่านหนึ่งใน scrape corpus ใหญ่ ๆ เสมอ โดยรายงานชี้ไปที่

• The Stack และตระกูลที่ derive ต่อจากมัน — พบ live key ที่ต่างกัน 51,571 ตัว
• ตระกูล Dolma ของ AllenAI — 28,110 ตัว

พูดง่าย ๆ คือ นักพัฒนาคนหนึ่ง commit คีย์ลง GitHub โดยไม่ตั้งใจ → corpus ยักษ์ดูดไป → dataset นับร้อยที่ derive ต่อจาก corpus นั้นก็พาคีย์ไปด้วยทุกชุด กว่าจะรู้ตัว คีย์หนึ่งตัวก็อยู่ในที่ที่ต้องตามลบเป็นพันแห่ง ในระเบียบวิธี ทีมงานต้อง แผ่ Parquet, Arrow, JSONL, archive และ binary ออกมาเป็นข้อความก่อน จึงจะสแกนได้ ซึ่งเป็นเหตุผลว่าทำไมคีย์พวกนี้ถึงรอดสายตาเครื่องมือทั่วไปมานาน — มันไม่ได้อยู่ในไฟล์ .env ที่ใครก็ grep เจอ

รายงานยังมีหัวข้อที่เจ็บแสบว่า “Sometimes the company leaked its own key” และ “Models you’ve heard of, trained on live keys” — สื่อว่าโมเดลที่หลายคนใช้อยู่ ถูกฝึกบนข้อมูลที่มีคีย์ใช้งานได้จริงปนอยู่

ฝั่ง Hugging Face ร่วมมือเชิงรุก โดย CTO Julien Chaumond ลงมือส่งโค้ดเข้า TruffleHog เองเพื่อเพิ่มความสามารถสแกน storage bucket แบบ native อย่างไรก็ตาม รายงานมีหัวข้อชื่อ “221,303 keys is hard to disclose” ซึ่งยอมรับตรง ๆ ว่าจำนวนขนาดนี้แจ้งเจ้าของทีละรายไม่ไหว และเสนอให้ผู้ให้บริการ เปิดความสามารถ revoke แบบยกชุด (bulk revocation)

สิ่งที่ทีมพัฒนาควรทำวันนี้

ข้อเสนอหลักจากรายงานสั้นและตรงไปตรงมา:

1. สแกน dataset ก่อน publish และก่อนนำไป train — ไม่ใช่แค่สแกน source repository เพราะจุดรั่วเกิดที่ชั้น dataset ด้วย
2. หมุนคีย์ทุกตัวที่เคยแตะพื้นผิวสาธารณะ — สมมติว่าหลุดแล้วไว้ก่อน
3. ฝั่งผู้ให้บริการ ควรมี bulk revocation เพราะสเกลของปัญหาเกินกำลังการแจ้งเตือนรายบุคคล

มุมมอง AI Curator

ผมคิดว่าคุณค่าที่แท้จริงของรายงานนี้ไม่ได้อยู่ที่ตัวเลข 221,303 — ตัวเลขสร้างพาดหัวได้ แต่จะจางไปในสัปดาห์เดียว สิ่งที่ควรเก็บไว้ในหัวคือประโยคที่เป็นชื่อหัวข้อหนึ่งของรายงานเอง: training data คือการรั่วที่ถาวรที่สุด

ลองเทียบกับการรั่วแบบอื่น คีย์หลุดใน git history → rewrite history แล้ว force push ได้ คีย์หลุดใน log → หมุนคีย์แล้วลบ log ได้ แต่คีย์ที่หลุดเข้า training corpus ยักษ์แล้วถูก derive ต่อไปอีกพันชุด ไม่มีปุ่มถอน คุณลบต้นทางได้ แต่ลบสำเนาที่คนอื่นดาวน์โหลดไปแล้ว ที่ถูก mirror ไว้ ที่กลายเป็น dataset ลูกหลานไปแล้ว ไม่ได้ ตัวเลข “คีย์เดียวใน 1,131 ชุดข้อมูล” คือภาพของปัญหานี้ในรูปแบบที่ชัดที่สุด และมันอธิบายว่าทำไมสัดส่วน 44% ถึงสำคัญกว่ายอดรวม — ปัญหาไม่ได้กระจายตัวแบบสุ่ม แต่ถูก ขยายผ่านคอขวดไม่กี่จุด คือ scrape corpus ใหญ่ ๆ ซึ่งแปลว่าถ้าจะแก้ให้ได้ผลจริง จุดที่ต้องใส่การสแกนคือชั้นนั้น ไม่ใช่ให้ทุกคนไปไล่สแกนกันเอง

สำหรับทีมไทยและ SEA ผมเห็นความเสี่ยงเฉพาะหน้าสองข้อที่ตรงกับสิ่งที่หลายทีมกำลังทำอยู่พอดี

ข้อแรก — ทีมที่กำลัง fine-tune โมเดลด้วยข้อมูลองค์กร ตอนนี้การ fine-tune โมเดลเปิดด้วยข้อมูลภายในเป็นงานปกติของทีมไทยไปแล้ว และข้อมูลที่เอาไปใช้มักมาจากการรวบรวมภายในแบบเร่ง ๆ — export จาก ticket system, dump ของ log, ไฟล์ notebook เก่า, chat history ของทีม สิ่งเหล่านี้เต็มไปด้วย connection string และ token ที่คนโยนใส่กันตอนดีบัก ถ้า dataset นั้นถูกอัปขึ้น Hugging Face แม้จะตั้ง private ไว้ ก็ควรถือว่ามีความเสี่ยง เพราะการเผลอสลับเป็น public เกิดขึ้นบ่อยกว่าที่คิด การรัน secret scanner บน dataset ก่อนอัป ควรเป็นขั้นตอนบังคับใน pipeline ไม่ใช่สิ่งที่ทำเมื่อนึกได้

ข้อสอง — คีย์ AI provider คือเป้าหมายที่มีมูลค่าทันที ตัวเลข 11,496 คีย์และมูลค่า inference ที่ถูกขโมยอย่างน้อยปีละเกือบล้านดอลลาร์ บอกว่ามีคนเก็บเกี่ยวคีย์พวกนี้ไปใช้จริงเป็นระบบ ไม่ใช่แค่ทฤษฎี ทีมไทยจำนวนไม่น้อยตั้งคีย์ OpenAI/Gemini/Anthropic ไว้แบบไม่มีเพดานรายจ่ายเพื่อความสะดวก — ตั้ง hard spending cap และแยกคีย์ตามสภาพแวดล้อม (dev / staging / prod) ให้เป็นค่ามาตรฐาน เพราะเพดานรายจ่ายในเคสนี้ทำหน้าที่เป็นตัวจำกัดความเสียหายที่แท้จริง ไม่ใช่แค่เครื่องมือควบคุมงบ

สุดท้าย มีมุมที่ควรพูดถึงในเชิงโครงสร้าง: การที่ CTO ของ Hugging Face ลงมือส่งโค้ดสแกนเข้าเครื่องมือของอีกบริษัทเอง เป็นการตอบสนองที่ถูกต้องและควรได้เครดิต แต่มันก็ตอกย้ำว่าชั้นนี้ของระบบนิเวศ AI ยังไม่มีมาตรฐานความปลอดภัยแบบที่ registry ของภาษาโปรแกรมมีมานานแล้ว npm, PyPI และ GitHub มีการสแกน secret ในระดับแพลตฟอร์มมาหลายปี ขณะที่ dataset hub เพิ่งเริ่มเดินทางนี้ทั้งที่ปริมาณข้อมูลมหาศาลกว่ามาก ถ้าเทียบไทม์ไลน์กัน ระบบนิเวศ dataset วันนี้อยู่ประมาณจุดที่ package registry อยู่เมื่อสิบปีก่อน — ซึ่งแปลว่าเรารู้ล่วงหน้าว่าอะไรกำลังจะตามมา และไม่มีข้ออ้างที่จะไม่เตรียมตัว

แหล่งข่าว

• Scanning 7.6 Petabytes of HuggingFace Training Data for Secrets — Truffle Security, 31 ก.ค. 2026
• Scanning 7.6 Petabytes of HuggingFace Training Data for Secrets — Hacker News, 1 ส.ค. 2026
• TruffleHog — GitHub