OWASP Top 10 for LLM 2026: 10 ช่องโหว่ของระบบ AI ที่ควรรู้

ลองนึกถึงพนักงานใหม่ที่ฉลาดมาก ทำงานได้ทั้งวันทั้งคืน แต่ทำตามทุกข้อความที่ตัวเองอ่าน ไม่ว่าจะมาจากหัวหน้า ลูกค้า หรือโน้ตที่ใครก็ไม่รู้แปะทิ้งไว้ LLM ที่อยู่ในแอปของเราก็มีนิสัยแบบนี้แหละครับ

OWASP GenAI Security Project เพิ่งออก Top 10 for LLM Applications ฉบับ 2026 เวอร์ชัน 1.0 เมื่อวันที่ 3 สิงหาคม 2026 เป็นรายการความเสี่ยงที่ทีมพัฒนาและทีม security ใช้ตั้งต้นเวลาตรวจแอปที่มี AI อยู่ข้างใน

ฉบับนี้อิงเหตุการณ์จริงเป็นครั้งแรก

ฉบับก่อน ๆ จัดอันดับจากการโหวตของผู้เชี่ยวชาญอย่างเดียว ฉบับ 2026 เพิ่มข้อมูลเหตุการณ์จริงเข้ามาด้วย ตามบทวิเคราะห์ของ Cloud Security Alliance ทีมงานรวบรวมเหตุการณ์ด้านความปลอดภัยที่เกี่ยวกับ AI ได้ 7,714 กรณี ในจำนวนนี้มี 6,639 กรณีที่มีรายละเอียดพอจะจัดหมวดได้

แต่ผลโหวตของผู้เชี่ยวชาญยังเป็นเสียงหลักอยู่ราว 75% ส่วนข้อมูลเหตุการณ์มีน้ำหนักราว 25% เหตุผลก็คือการโจมตีบางแบบถูกสกัดไว้ได้ก่อนจะกลายเป็นเหตุที่มีคนรายงาน ถ้าดูแค่ตัวเลขเหตุการณ์ ความเสี่ยงพวกนี้ก็จะดูเล็กกว่าความจริงนั่นเอง

อันดับขยับไปทางไหนบ้าง

ข้อที่อันดับขยับขึ้นมากที่สุดคือ Excessive Agency จากอันดับ 6 มาเป็น 3 และ Unbounded Consumption จาก 10 มาเป็น 6 ดูแล้วน่าจะสะท้อนว่า AI ใน production ไม่ได้มีหน้าที่แค่ตอบคำถามแล้ว แต่เริ่มลงมือทำงานเองมากขึ้น ค่าใช้จ่ายในการรันก็สูงขึ้นตามไปด้วย ส่วน Improper Output Handling ที่ลดจากอันดับ 5 ลงไปอยู่อันดับ 10 ก็ไม่ได้แปลว่าอันตรายน้อยลง เพียงแต่ข้ออื่นมีเหตุการณ์จริงมากกว่าจึงขึ้นไปอยู่อันดับสูงกว่า

ทีนี้เรามาไล่ดูกันทีละข้อ แต่ละข้อจะมีตัวอย่างเป็นแชตระหว่างคนกับ AI ให้เห็นภาพว่าความเสี่ยงนั้นเกิดขึ้นได้ยังไง ลองดูวิธีอ่านแชตกันก่อนนะครับ

LLM01 Prompt Injection

ผู้โจมตีแทรกคำสั่งลงในข้อมูลที่ AI อ่าน แล้ว AI ก็ทำตามคำสั่งนั้นแทนคำสั่งของเรา ปัญหาคือคำสั่งของเรากับข้อมูลจากคนแปลกหน้าไปรวมอยู่ในข้อความก้อนเดียวกัน และ LLM ยังไม่มีกลไกแยกสองอย่างนี้ออกจากกันได้เด็ดขาดแบบ parameterized query ใน SQL ฉบับนี้ยังขยายขอบเขตไปถึงคำสั่งที่ซ่อนมาในรูปภาพหรือเสียงด้วย

สมมติว่าบริษัทมีผู้ช่วย AI สรุปอีเมล แล้วมีอีเมลใบแจ้งหนี้ที่ซ่อนคำสั่งไว้เป็นตัวอักษรสีขาวเข้ามา

พนักงานเชื่อเพราะคิดว่าเป็นคำแนะนำจาก AI ของบริษัทเอง

วิธีป้องกัน:

• แยกข้อมูลจากภายนอกให้ชัด และบอกโมเดลว่าส่วนนั้นเป็นข้อมูล ไม่ใช่คำสั่ง
• ให้สิทธิ์เครื่องมือเท่าที่จำเป็น
• ให้คนยืนยันก่อน AI ทำอะไรที่มีผลจริง

LLM02 Sensitive Information Disclosure

AI เผยข้อมูลที่ไม่ควรเผย ทั้งข้อมูลในชุดฝึก ข้อมูลในระบบ หรือเอกสารที่ดึงมาใช้ตอบ ข้อนี้ไม่ต้องมีใครโจมตีก็เกิดได้ เช่น แชตบอต HR ที่อ่านตารางเงินเดือนได้ทั้งบริษัท

วิธีป้องกัน:

• ให้ AI เห็นข้อมูลไม่เกินสิทธิ์ของผู้ใช้ที่กำลังคุยด้วย
• ใส่ข้อมูลอ่อนไหวเข้าไปในระบบ AI ให้น้อยที่สุด
• กรองผลลัพธ์ก่อนส่งถึงผู้ใช้

LLM03 Excessive Agency

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

ลองนึกถึงผู้ช่วยจัดปฏิทินที่ได้สิทธิ์ทั้งกล่องอีเมลมา "เผื่อไว้"

ถ้าตอนแรกเราให้สิทธิ์แค่อ่านปฏิทิน เรื่องนี้ก็คงไม่เกิดขึ้นใช่ไหมครับ

วิธีป้องกัน:

• ให้เฉพาะเครื่องมือที่งานนั้นต้องใช้ ไม่ต้องให้เผื่อ
• แยกสิทธิ์อ่านกับสิทธิ์เขียนออกจากกัน
• งานที่ส่งผลกระทบสูง เช่น โอนเงิน ลบข้อมูล หรือส่งอีเมล ต้องมีคนอนุมัติก่อน

LLM04 Supply Chain

ช่องโหว่ในโมเดลสำเร็จรูป ชุดข้อมูล ปลั๊กอิน หรือไลบรารีที่เราหยิบมาใช้ จะติดมากับทุกอย่างที่สร้างต่อบนมัน ฉบับนี้เพิ่มเรื่องไฟล์น้ำหนักโมเดลที่ถูกแก้ และรูปแบบไฟล์ที่รันโค้ดได้ตอนโหลดเข้ามาด้วย เช่น ทีมดาวน์โหลดโมเดลที่ชื่อเหมือนโมเดลดังแทบทุกตัวอักษร แต่ในไฟล์มีโค้ดฝังไว้ พอโหลดโมเดลขึ้นมา โค้ดนั้นก็รันบนเซิร์ฟเวอร์ทันที

วิธีป้องกัน:

• ใช้โมเดลจากแหล่งที่ตรวจสอบได้ และเช็กที่มาของไฟล์ทุกครั้ง
• เลือกรูปแบบไฟล์ที่ไม่รันโค้ดตอนโหลด
• ทำรายการส่วนประกอบของระบบ AI ไว้ จะได้รู้ว่าต้องแก้ตรงไหนเมื่อมีช่องโหว่ใหม่

LLM05 Data and Model Poisoning

ผู้โจมตีแอบใส่ข้อมูลผิด ๆ ลงในข้อมูลที่ใช้ฝึก fine-tune หรือสร้าง embedding ทำให้โมเดลเพี้ยนหรือลำเอียงไปตามที่เขาต้องการ สมมติผู้ช่วยแนะนำสินค้าที่ fine-tune จากรีวิวลูกค้า

วิธีป้องกัน:

• รู้ที่มาของข้อมูลทุกชุดที่ใช้ฝึก
• ตรวจหาข้อมูลผิดปกติก่อนเข้า pipeline
• ทดสอบพฤติกรรมโมเดลหลัง fine-tune ทุกครั้ง

LLM06 Unbounded Consumption

ผู้โจมตีทำให้ระบบประมวลผลเกินควบคุม จนค่าใช้จ่ายพุ่งหรือระบบช้าลง ข้อนี้รวมถึงสิ่งที่เรียกกันว่า Denial of Wallet คือระบบไม่ล่ม แต่บิลค่า API ทำให้บริษัทแทบล่มแทน และกรณีที่คำขอเดียวแตกไปเรียกเครื่องมือหรือ agent ย่อยอีกจำนวนมาก

ภาพที่เห็นได้ง่ายคือแชตบอตฟรีหน้าเว็บที่ไม่จำกัดจำนวนครั้ง

วิธีป้องกัน:

• จำกัดจำนวนคำขอต่อผู้ใช้ (rate limit)
• ตั้งเพดานค่าใช้จ่ายต่อผู้ใช้และต่อวัน
• จำกัดความยาวของ input และ output แล้วตั้งแจ้งเตือนเมื่อค่าใช้จ่ายผิดปกติ

LLM07 Misinformation

AI ตอบผิดแต่น้ำเสียงมั่นใจ เมื่อก่อนเรื่องนี้ถูกมองว่าเป็นแค่ปัญหาคุณภาพ แต่พอคำตอบของ AI ถูกนำไปสั่งเครื่องมือ เขียนโค้ด หรืออนุมัติงานต่อ คำตอบผิดก็กลายเป็นการกระทำผิดได้ทันที

ตัวอย่างที่คนเขียนโค้ดน่าจะคุ้นกันคือ AI แนะนำไลบรารีที่ไม่มีอยู่จริง

วิธีป้องกัน:

• ให้ AI ตอบโดยอิงแหล่งข้อมูลที่ตรวจสอบได้
• ให้คนตรวจก่อนนำคำตอบไปใช้ในเรื่องสำคัญ
• บอกผู้ใช้ตรง ๆ ว่าคำตอบจาก AI อาจผิดได้

LLM08 Hidden Context Exposure

ข้อนี้เดิมชื่อ System Prompt Leakage ตอนนี้ขยายไปครอบคลุมทุกอย่างที่ผู้ใช้มองไม่เห็นแต่ถูกใส่ไว้ในบริบทของโมเดล เช่น system prompt นโยบายภายใน และค่าตั้งระบบ หลักคิดง่าย ๆ คือให้ถือว่าทุกอย่างในบริบทมีคนขุดออกมาได้

สมมติบอตบริการลูกค้ามีกติกาใน prompt ว่าถ้าลูกค้าขู่ยกเลิกให้ส่วนลดด้วยรหัสพิเศษ

วิธีป้องกัน:

• ห้ามใส่รหัสผ่าน API key หรือความลับใด ๆ ไว้ในบริบทของโมเดล
• เรื่องสิทธิ์และส่วนลดต้องตัดสินที่ระบบหลังบ้าน ไม่ใช่ฝากไว้ใน prompt

LLM09 Vector and Embedding Weaknesses

ช่องโหว่ในระบบ RAG ที่ AI ค้นเอกสารจากคลังมาใช้ตอบ ผู้โจมตีอาจแทรกเอกสารพิษเข้าไปในคลัง หรือทำให้ AI ดึงเอกสารที่ผู้ใช้ไม่มีสิทธิ์เห็นมาตอบ

บอตตอบอย่างมั่นใจ เพราะข้อมูลมาจาก "คู่มือ" ในคลังของบริษัทเอง

วิธีป้องกัน:

• คุมสิทธิ์ว่าใครเพิ่มเอกสารเข้าคลังได้ และใครค้นเห็นเอกสารไหนได้บ้าง
• ตรวจเอกสารก่อนเข้าคลัง และเก็บที่มาของทุกไฟล์

LLM10 Improper Output Handling

เอาผลลัพธ์จาก AI ไปใช้ต่อในระบบอื่นโดยไม่ตรวจ ซึ่งก็คือ XSS หรือ SQL injection แบบเดิมที่เรารู้จักกันดี แค่ต้นทางเปลี่ยนจากผู้ใช้มาเป็น AI เช่น ระบบที่ให้ AI เขียนคำบรรยายสินค้าแล้วแสดงบนเว็บเป็น HTML ตรง ๆ

วิธีป้องกัน:

• ถือว่า output ของ AI เป็น input ที่ไม่น่าไว้ใจ
• escape ก่อนแสดงผล และใช้ parameterized query ก่อนเขียนลงฐานข้อมูล
• ห้ามส่ง output ไปรันเป็นคำสั่ง shell หรือโค้ดโดยตรง

ถ้า AI ลงมือทำเองได้ ต้องดูอีกรายการ

LLM Top 10 มอง AI เป็นชิ้นส่วนหนึ่งในแอปที่อ่าน คิด แล้วตอบ แต่ถ้า AI ของเราเรียกเครื่องมือได้ จำข้อมูลข้ามเซสชันได้ หรือสั่งงาน agent ตัวอื่นต่อได้ OWASP มีอีกรายการคือ Top 10 for Agentic Applications ที่ออกเมื่อเดือนธันวาคม 2025 ใช้รหัส ASI01 ถึง ASI10 เช่น Agent Goal Hijack และ Tool Misuse ระบบแบบนี้ควรดูทั้งสองรายการควบคู่กันไปด้วยครับ

เช็กระบบของเราก่อนขึ้น production

1. วาดภาพระบบให้เห็นทุกจุดที่ข้อมูลจากภายนอกเข้าถึง AI และทุกจุดที่ output ของ AI ไหลไปยังระบบอื่น
2. ลองโจมตีด้วย prompt injection รวมถึงผ่านรูปภาพและเอกสาร แล้วลองล้วงข้อมูลอ่อนไหวดู
3. ไล่ดูสิทธิ์ของ agent ทุกตัว ตัดเครื่องมือที่ไม่จำเป็น และใส่ขั้นอนุมัติให้งานที่ส่งผลกระทบสูง
4. ตรวจว่า output ของ AI ถูก validate ก่อนเข้าฐานข้อมูล shell หรือ API อื่น
5. เช็กว่าใน system prompt และบริบทที่ซ่อนไว้ไม่มีความลับอะไรอยู่
6. ตั้ง rate limit และเพดานค่าใช้จ่ายต่อผู้ใช้
7. ทำซ้ำทุกครั้งที่เพิ่มเครื่องมือ เพิ่มแหล่งข้อมูล หรือเปลี่ยนเวอร์ชันโมเดล

เราไม่ได้ไล่พนักงานใหม่ออกเพราะเขาเชื่อคนง่าย แต่เราก็ไม่ให้กุญแจห้องเซฟ ไม่ให้เซ็นเช็กคนเดียว และตรวจงานก่อนส่งถึงลูกค้า การดูแล AI ในระบบของเราก็คงคล้าย ๆ กันนั่นเองครับ