LLM API Router: 9 จาก 428 ตัวกลางแอบฉีดโค้ดใส่ Agent
งานวิจัยเดือนเมษายน 2026 เผย LLM API Router หลายแห่งแอบเปลี่ยนคำสั่งและขโมยข้อมูล พร้อมแนะทางแก้ที่ต้องรอให้ผู้ให้โมเดลลงลายเซ็นดิจิทัล
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- งานวิจัยเดือนเมษายน 2026 ตรวจสอบ LLM API Router 428 ตัว พบ 9 ตัวฉีดโค้ดอันตราย
- สถาปัตยกรรมตัวกลางตัดการเชื่อมต่อเข้ารหัส เปิดอ่านข้อมูลและคีย์ API ได้ทั้งหมด
- พบตัวกลางใช้เทคนิคหลบเลี่ยง ปรับตัวยิงโค้ดอันตรายหลังผ่านไป 50 คำขอ
- การป้องกันปัจจุบันยังมีข้อจำกัดเรื่องการยืนยันที่มา ต้องรอผู้ให้โมเดลลงลายเซ็นดิจิทัล
เมื่อผู้พัฒนาใช้งาน AI Agent ผ่านเครื่องมือตัวกลางหรือ LLM API Router เพื่อความสะดวกและประหยัดค่าใช้จ่ายในการเข้าถึงโมเดลหลายค่าย สิ่งที่มักมองข้ามคือสถาปัตยกรรมของตัวกลางที่ตั้งค่าเป็นปลายทาง ทำให้การเชื่อมต่อถูกถอดรหัสและเปิดอ่านข้อมูลได้ในระดับแอปพลิเคชัน ไม่ว่าจะเป็นคำสั่งที่ผู้ใช้พิมพ์ คีย์ API หรือรายการเครื่องมือที่ AI ขอเรียกใช้โดยไม่ต้องอาศัยการดักฟังที่ซับซ้อน
งานวิจัยที่ตีพิมพ์ในเดือนเมษายน 2026 ซึ่งตรวจสอบตัวกลางจำนวน 428 ตัว แบ่งเป็นตัวที่ซื้อจากตลาดในจีนและ Shopify จำนวน 28 ตัว และตัวฟรีจากชุมชนสาธารณะ 400 ตัว พบว่ามีตัวกลางที่จ่ายเงิน 1 ตัว และตัวฟรี 8 ตัว กำลังฉีดโค้ดอันตรายเข้าไปในคำสั่งที่ส่งกลับมา โดยในบางกรณีมีการเปลี่ยนชื่อแพ็กเกจ เช่น จาก requests เป็น reqeusts เพื่อให้ผ่านด่านตรวจชื่อโดเมนเดิมที่เชื่อถือได้แต่ติดตั้งแพ็กเกจปลอมของผู้โจมตีแทน
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
นอกจากนี้ยังมีตัวกลางที่ใช้เทคนิคหลบแบบปรับตัว โดยจะเริ่มยิงโค้ดอันตรายเฉพาะหลังจากผ่านไป 50 คำขอ หรือทำงานเฉพาะในเซสชันที่ตั้งค่าให้ทำทุกอย่างอัตโนมัติโดยไม่ต้องยืนยัน ทำให้การทดสอบระยะสั้นไม่พบความผิดปกติ นอกจากนี้ยังพบตัวกลาง 17 ตัวที่เข้าถึงข้อมูลรับรองทดสอบ และ 1 ตัวที่ดูดเงินออกจากกุญแจส่วนตัวคริปโต
"ด่านนี้จะยืนได้ก็ต่อเมื่อมันอยู่ในตัวรันของ agent ไม่ใช่ในตัวกลาง"
@bygregorr
การที่ LLM API Router สามารถอ่านและแก้ไขข้อมูลได้ทั้งหมดเกิดจากความไว้วางใจในสถาปัตยกรรมแบบรวมศูนย์ การป้องกันปัญหานี้จึงไม่ใช่แค่การตรวจจับเนื้อหา แต่เป็นการสร้างกลไกยืนยันที่มาที่ชัดเจน เช่น การที่ผู้ให้โมเดลลงลายเซ็นดิจิทัลกำกับคำตอบ เพื่อให้ฝั่งลูกค้าตรวจสอบได้ว่าคำสั่งไม่ได้ถูกแก้ไขระหว่างทาง
งานวิจัยยังได้ทดลองด่านฝั่งลูกค้า 3 แบบ ได้แก่ ด่านตรวจคำสั่งที่มีความเสี่ยงสูงซึ่งบล็อกได้ทั้งหมดที่อัตราเตือนผิด 1.0 เปอร์เซ็นต์, การคัดกรองความผิดปกติฝั่งคำตอบที่ตรวจจับได้ 89.0 เปอร์เซ็นต์แต่อัตราเตือนผิด 6.7 เปอร์เซ็นต์ และบันทึกตรวจสอบแบบเขียนต่อท้ายขนาด 1.26 ไบต์ต่อรายการที่ไม่ป้องกันแต่มีประโยชน์ในการสืบสวนย้อนหลัง
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น