LLM Top 10 (2026)

พอ OWASP เอา incident 6,639 รายการมาใช้ประกอบการจัดอันดับ Prompt Injection กลับไม่ติดสิบอันดับแรกหากดูเฉพาะข้อมูล incident แล้วทำไมผลรวมยังให้อยู่ที่ 1?

ฉบับ 2026 เป็นปีแรกที่อันดับไม่ได้มาจากความเห็นผู้เชี่ยวชาญอย่างเดียว ทีมงานเอา incident หลายพันรายการจากฐานข้อมูลช่องโหว่มาจัดหมวด แล้วประกอบกับผลโหวตของ practitioner โดยให้น้ำหนักผลโหวตมากกว่า ข้อจำกัดสำคัญคือ incident สาธารณะสะท้อนเฉพาะสิ่งที่ถูกค้นพบ รายงาน และจัดหมวดได้ จึงไม่ใช่ค่าความชุกที่สมบูรณ์

ตัวเลขเบื้องหลังการจัดอันดับ

รวบรวม 7,714 รายการ จากฐาน CVE และฐาน AI-harm · คัดรายการที่มีรายละเอียดพอ 6,639 รายการ · คะแนนรวมให้น้ำหนักโหวต 75% และข้อมูล incident 25% (OWASP LLM Top 10 2026)

จุดที่ผลโหวตกับข้อมูล incident ต่างกันน่าสนใจกว่าจุดที่ตรงกัน Prompt Injection ได้อันดับ 1 จากการโหวต แต่หลุดสิบอันดับแรกเมื่อเรียงเฉพาะ incident ส่วน Misinformation เคลื่อนไปอีกทาง คือผลโหวตต่ำแต่ข้อมูล incident สูงกว่าอย่างชัดเจน คำอธิบายเรื่อง “defense effect” เป็นการตีความของคณะทำงาน ไม่ใช่หลักฐานว่าการป้องกันเป็นสาเหตุโดยตรง

Stop trying to build a model that cannot be fooled. Build the system around it, so that when the model is fooled, and it will be, nothing important breaks.

— Steve Wilson & Rock Lambros, Project Leads · preface ฉบับ 2026

อันดับปีนี้ขยับกันเยอะ Excessive Agency ขยับสำคัญสุด (6 ขึ้น 3) Improper Output Handling ตกแรงสุด (5 ร่วง 10) ส่วน System Prompt Leakage เปลี่ยนชื่อเป็น Hidden Context Exposure ตารางเทียบอันดับเต็มอยู่ท้ายหน้า

รายข้อ

LLM01:2026 Prompt Injection · คงที่ที่ 1

รากของปัญหาอยู่ที่สถาปัตยกรรมของโมเดลเอง LLM ไม่แยก "คำสั่ง" กับ "ข้อมูล" ทุกอย่างเป็น token สายเดียวกันหมด เลยไม่มีอะไรเทียบเท่า parameterized query ให้ใช้แบบฝั่ง SQL ปีนี้ขยาย scope คลุม cross-modal ด้วย คือคำสั่งซ่อนในภาพหรือเสียงที่ตามองไม่เห็น แต่ vision encoder ดึงออกมาเป็น payload ได้

LLM01 ตัวเลขที่ควรจำ

Nasr et al. ประเมิน defense 12 วิธีด้วย adaptive attacks และรายงาน attack success สูงกว่า 90% สำหรับ defense ส่วนใหญ่ แม้งานเดิมจำนวนมากรายงานผลใกล้ศูนย์บน static evaluation (paper) ตัวเลขนี้เป็นผลในเงื่อนไขการทดลอง ไม่ใช่อัตราสำเร็จของทุกระบบ production

ผลดังกล่าวชี้ว่าการกรอง input ไม่ควรเป็น control เพียงชั้นเดียว ระบบควรออกแบบภายใต้สมมติฐานว่า injection อาจผ่านการป้องกันได้ แล้วจำกัดว่าโมเดลทำอะไรและส่ง output ไปถึงระบบใดได้บ้าง

กรอบคิดที่เอกสารหยิบมาใช้คือ “lethal trifecta” ของ Simon Willison กับ Rule of Two ของ Meta ใจความร่วมคือไม่ควรให้ agent อ่าน input ที่ไม่น่าเชื่อถือ เข้าถึงข้อมูลลับ และส่งข้อมูลออกภายนอกได้พร้อมกัน วิธีลดความเสี่ยงคือเอาความสามารถอย่างน้อยหนึ่งด้านออกหรือคั่นด้วย control ที่บังคับใช้โดยระบบ

LLM02:2026 Sensitive Information Disclosure · คงที่ที่ 2

ช่องรั่วไม่ได้มีแค่คำตอบสุดท้าย tool-call argument, reasoning trace, chunk ที่ retrieve มา, log, embedding แม้แต่คุณสมบัติที่วัดจากภายนอกอย่างความยาว token หรือ latency ก็เป็น disclosure surface ได้หมด

หลักฐานมีทั้งการทดลองและ incident จริง ตัวอย่างเช่น Whisper Leak เป็นงานทดลอง side-channel บนโมเดล 28 ตัว โดย 17 ตัวได้ AUPRC สูงกว่า 98% ในการจำแนกหัวข้อจากขนาดและจังหวะ packet ที่เข้ารหัส ผลนี้วัดในชุดทดสอบของงานวิจัยก่อน vendor mitigation และไม่ควรอ่านเป็น “ความแม่น 98% ในทุกสภาพแวดล้อม” (paper)

สามหลักที่เอกสารย้ำ embedding ที่รั่วเท่ากับเอกสารต้นทางรั่ว เพราะ inversion กู้ข้อความคืนได้แล้ว reasoning trace เป็น output ชั้นหนึ่ง ต้อง redact เท่าคำตอบจริง และ authorization ต้องเกิดก่อน retrieval ในตัว index query ไม่ใช่มากรองทีหลัง เพราะ chunk ที่ถึงมือโมเดลแล้วเรียกคืนไม่ได้

LLM03:2026 Excessive Agency · ขึ้นจาก 6 ขยับสำคัญสุด

Excessive Agency ทำให้ข้อผิดพลาดของโมเดลกลายเป็น action ที่สร้างผลกระทบจริง ไม่ว่าต้นเหตุจะเป็น prompt injection หรือ hallucination ปัญหาหลักมีสามรูปแบบ: functionality เกินความจำเป็น เช่น agent สำหรับอ่านอีเมลมีความสามารถส่งอีเมลด้วย; permission กว้างเกิน เช่น identity เดียวเข้าถึงไฟล์ของผู้ใช้ทุกคน; และ autonomy สูงเกิน เช่น action ที่มีผลกระทบสูงทำได้โดยไม่ต้องขออนุมัติ

แนวป้องกันเรียงจากต้นทาง ตัด tool ที่ไม่จำเป็นทิ้งก่อน เลี่ยง tool ปลายเปิดพวก shell หรือ fetch URL ไปใช้ tool แคบ ๆ ที่ validate schema แทน รันในสิทธิ์ของ user คนนั้นให้ต่ำที่สุด แล้วปิดท้ายด้วย complete mediation คือให้ logic เป็นคนตัดสินว่า action ผ่านไหม ไม่ใช่ปล่อยให้โมเดลตัดสินเอง ที่ขยับขึ้นมาอันดับ 3 เพราะรอบนี้ทั้งโหวตและ incident ชี้ตรงกันว่าความเสียหายไปกองที่ deployment แบบ agentic

LLM04:2026 Supply Chain · ลงจาก 3

Supply chain ของ LLM กว้างกว่า dependency ปกติเยอะ โมเดล pre-trained, dataset, LoRA adapter, ขั้น conversion กับ quantization ไปจนถึง registry ล้วนเป็นผิวโจมตี เอกสารยกเคสมาสี่แบบ

ตัวอย่างมีทั้ง torchtriton ปลอมบน PyPI ที่ขโมยข้อมูลจากเครื่องนักพัฒนา, PoisonGPT ที่แก้ weight ให้ปล่อย misinformation โดยยังผ่าน benchmark ทั่วไป, namespace reuse หลังเจ้าของโมเดลเดิมลบบัญชี และกรณี Ultralytics ที่ workflow สำหรับ release ถูกโจมตีจน artifact อันตรายถูกเผยแพร่จาก infrastructure ของโครงการเอง แต่ละกรณีควรอ่านเป็น failure mode คนละแบบ ไม่ใช่หลักฐานว่า signing หรือ provenance ไม่มีประโยชน์

ของใหม่ปีนี้มีทั้ง backdoor ที่แสดงผลหลัง quantization และ slopsquatting ซึ่งผู้โจมตีจดชื่อ package ที่โมเดลมีแนวโน้มสร้างขึ้นผิด ๆ แนวรับหลักคือ AIBOM หรือ ML-BOM ร่วมกับ signing และ hash pinning ทั้งนี้ provenance พิสูจน์แหล่งที่มาและความต่อเนื่องของ artifact ไม่ได้พิสูจน์ว่า artifact ปลอดภัย จึงยังต้องมีการตรวจและ sandbox ตอนโหลดหรือรัน

LLM05:2026 Data & Model Poisoning · ลงจาก 4

ต่างจากบั๊กซอฟต์แวร์ตรงที่ patch ไม่ได้ เพราะพิษฝังอยู่ในกระบวนการเรียนรู้ของโมเดล จะแก้ทีต้อง revalidate ข้อมูลหรือ retrain กันใหม่

LLM05 ตัวเลขที่ล้มสมมติฐาน

Souly et al. พบว่าเอกสารพิษประมาณ 250 ชิ้น ทำให้โมเดลทดลองขนาด 600M–13B เรียนรู้ backdoor แบบสร้างข้อความไร้ความหมายเมื่อพบ trigger ได้ โดยจำนวนที่ต้องใช้ใกล้เคียงกันเมื่อ dataset โตขึ้น (paper) ผลนี้เป็น backdoor และชุดโมเดลเฉพาะในการทดลอง ยังสรุปแทน poisoning ทุกชนิดไม่ได้

ผลนี้หักล้างสมมติฐานว่า dataset ที่ใหญ่ขึ้นจะทำให้การโจมตีชนิดดังกล่าวต้องใช้ข้อมูลพิษเพิ่มตามสัดส่วน แต่ยังไม่ครอบคลุม backdoor ทุกแบบ งาน Sleeper Agents ของ Hubinger et al. ยังแสดงในเงื่อนไขทดลองว่าพฤติกรรมแฝงบางชนิดอาจคงอยู่หลัง safety training จึงควรทดสอบพฤติกรรมหลัง fine-tuning และ alignment แทนการถือว่ากระบวนการดังกล่าวล้าง backdoor แล้ว

งานที่แก้ chat template หรือ tokenizer config เพื่อฝัง trigger ชี้ว่า artifact รอบโมเดลก็เปลี่ยนพฤติกรรมตอน runtime ได้ บทเรียนเชิงระบบคือ chat template, tokenizer config, adapter และ quantization artifact ควรถูก version, sign, hash, diff และ review เช่นเดียวกับ source code ตัวเลขผลกระทบเฉพาะงานควรอ้างพร้อมเงื่อนไขทดลองก่อนนำมาใช้เปรียบเทียบผลิตภัณฑ์

LLM06:2026 Unbounded Consumption · ขึ้นจาก 10

ประเด็นหลักคือ cost asymmetry: input ต้นทุนต่ำอาจทำให้ระบบใช้ compute ในมูลค่าสูง รูปแบบสำคัญได้แก่ Denial of Wallet, reasoning-loop exhaustion ซึ่ง prompt สั้นอาจกระตุ้นให้ reasoning model ใช้ทรัพยากรจำนวนมาก และ context growth ใน agent session ซึ่งต้นทุนสะสมเพิ่มขึ้นโดยที่ request แต่ละรายการยังไม่เกิน rate limit

LLM06 บิลที่โตเงียบ ๆ

context ในเซสชัน agentic เทิร์นแรก $0.001 พอถึงเทิร์นที่ 100 ตกเทิร์นละ ~$0.50 ไต่ขึ้นทีละนิดจนไม่มี request ไหนสะดุด rate limit

เอกสารบอกชัดว่า rate limit แบบนับ request ไม่พอแล้ว ต้องคุมเป็น token ต่อนาที ตั้งงบเป็นเพดานแข็งที่หยุด inference ได้จริง ไม่ใช่แค่ยิง alert แล้วปล่อยวิ่งต่อ แล้วใส่ circuit breaker ฝั่ง agent ไว้จำกัด step, recursion depth กับ cost ต่อ run ข้อนี้ขยับจาก 10 มา 6 เพราะ practitioner เริ่มเจอบิลจริงกันเยอะ

LLM07:2026 Misinformation · ขึ้นจาก 9

ประเด็นไม่ใช่เพียง “โมเดลตอบผิด” แต่คือคำตอบผิดที่คนหรือระบบปลายทางนำไปใช้ ในระบบที่ output ไปกำหนด tool call, state หรือการอนุมัติ ข้อผิดพลาดจึงอาจกลายเป็น action ที่มีผลจริง

ตัวอย่างสถานการณ์ในหมวดนี้ ได้แก่ agent รายงานว่า backup สำเร็จโดยไม่มีหลักฐานจากระบบสำรองข้อมูล หรือ agent หนึ่งส่งสถานะ “ยืนยันตัวตนแล้ว” ให้อีก agent นำไปอนุมัติธุรกรรม ตัวอย่างเหล่านี้อธิบาย failure mode; ไม่ควรเรียกว่า incident จริงหากไม่มีรายงานเหตุการณ์ที่ตรวจสอบย้อนกลับได้

แนวทางหนึ่งคือ claim-check-act: แยกการสร้างคำตอบ การตรวจสอบข้อกล่าวอ้าง และการ execute ออกจากกัน ไม่ให้ output จากโมเดลเปลี่ยน state โดยตรง อันดับของหมวดนี้สูงขึ้นเนื่องจากข้อมูล incident ให้น้ำหนักมากกว่าผลโหวตของ practitioner

LLM08:2026 Hidden Context Exposure · ลงจาก 7 เปลี่ยนชื่อ

หมวดนี้เดิมชื่อ System Prompt Leakage และในฉบับ 2026 ขยายขอบเขตเป็น hidden context ซึ่งรวม developer instructions, policy text จาก RAG และ tool schema

หลักปฏิบัติสำคัญคือไม่ฝัง secret ใน prompt และไม่ใช้การปกปิด prompt เป็น security boundary ระดับความรุนแรงขึ้นกับข้อมูลที่เปิดเผยและการนำไปใช้ต่อ เช่น internal policy, credential หรือข้อมูลที่ช่วยสร้าง exploit chain

LLM09:2026 Vector & Embedding Weaknesses · ลงจาก 8

การโจมตีในหมวดนี้ใช้คุณสมบัติของ embedding และ retrieval โดยไม่จำเป็นต้องใช้คำสั่งโจมตีโดยตรง ตัวอย่างได้แก่ inversion เพื่อกู้ข้อความจาก vector, cross-tenant probing ผ่าน timing หรือ score distribution, retrieval jamming ซึ่งทำให้เอกสารเป้าหมายไม่ถูกค้นคืน และ semantic cache poisoning ตัวเลขประสิทธิผลของแต่ละวิธีต้องอ่านพร้อมชนิด embedding, input length, dataset และ threat model ของงานวิจัย

Frame ที่เอกสารให้มาจำง่ายดี poisoning ทำให้ระบบตอบผิด inversion ทำให้รั่ว jamming ทำให้เงียบ ส่วน access-control พังทำให้ตอบข้ามสิทธิ์ และข้อสรุปสำคัญคือ backup ของ vector DB ต้องจัดชั้นความลับเท่าเอกสารต้นทาง

LLM10:2026 Improper Output Handling · ลงจาก 5 ตกแรงสุด

หลักคิดมีข้อเดียว ปฏิบัติกับ output ของโมเดลเหมือน input จาก user ที่ไม่น่าเชื่อถือ เพราะใครคุม prompt ได้ก็เท่ากับยิงตรงเข้า sink ปลายทาง เข้า shell หรือ eval เป็น RCE เข้า browser เป็น XSS เข้า SQL ที่ไม่ parameterize เป็น injection เข้า terminal พร้อม ANSI escape เป็น clipboard hijack และ chat UI ที่ auto-render markdown image ก็กลายเป็นท่อ exfiltrate ข้อมูลผ่าน URL ได้

ตกจาก 5 ไปอยู่ 10 ตาม incident record แต่ scope ขยายรับเรื่องโค้ดไม่ปลอดภัยที่ assistant generate ในระดับ scale ระบบที่ compile แล้ว deploy โค้ดจากโมเดลโดยไม่มีคน review คือ scenario ตรงตัวในเอกสาร