สรุปสั้น

นักวิจัยจากบริษัท Obsidian Security เปิดเผยช่องโหว่ร้ายแรง 3 รายการใน LiteLLM ซึ่งเป็น AI gateway แบบโอเพนซอร์สที่ใช้กันอย่างแพร่หลายสำหรับเชื่อมต่อกับ LLM provider กว่า 100 ราย โดยช่องโหว่ทั้งสามสามารถ chain ต่อกันได้ ทำให้ผู้ใช้ที่มีสิทธิ์ต่ำสุด (internal_user) สามารถยกระดับตนเองเป็น proxy admin และรันโค้ดอันตรายบนเซิร์ฟเวอร์ได้ทั้งระบบ ช่องโหว่ทั้งชุดได้รับคะแนน CVSS 9.9 ระดับ Critical

เมื่อเซิร์ฟเวอร์ถูกยึดครองแล้ว ผู้โจมตีจะสามารถเข้าถึง API key ของผู้ให้บริการ LLM ทุกราย ไม่ว่าจะเป็น OpenAI, Anthropic, Gemini หรือ Azure รวมถึงกุญแจเข้ารหัสที่ใช้ถอดรหัส credential ที่จัดเก็บไว้ในฐานข้อมูล และสามารถอ่าน prompt กับ response ทุกรายการที่ผ่านระบบได้ ทางบริษัท BerriAI ผู้ดูแลโปรเจกต์ได้แก้ไขช่องโหว่ทั้งหมดแล้วใน LiteLLM เวอร์ชัน 1.83.14-stable ซึ่งเผยแพร่เมื่อวันที่ 2 พฤษภาคม 2569

รายละเอียดข่าว

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 15 มิถุนายน พ.ศ. 2569 ว่านักวิจัยจากบริษัท Obsidian Security ได้เปิดเผยช่องโหว่ร้ายแรง 3 รายการใน LiteLLM ซึ่งเป็น AI gateway แบบโอเพนซอร์สที่ทำหน้าที่เป็นตัวกลางเชื่อมต่อกับผู้ให้บริการ LLM กว่า 100 รายผ่าน API ที่เข้ากันได้กับ OpenAI โดยช่องโหว่ทั้งสามสามารถ chain กันเป็นขั้นตอนเพื่อยึดครองเซิร์ฟเวอร์ได้ทั้งระบบ

ช่องโหว่แรก CVE-2026-47101 เป็นปัญหา authorization bypass เมื่อผู้ใช้ทั่วไปสร้าง virtual API key ระบบจะบันทึกค่า allowed_routes ที่ผู้ใช้ส่งมาโดยไม่ตรวจสอบสิทธิ์ ทำให้ผู้ใช้สามารถกำหนด wildcard /* เพื่อเข้าถึง route ทั้งหมดรวมถึง route ที่สงวนไว้สำหรับ admin ได้

ช่องโหว่ที่สอง CVE-2026-47102 เป็นปัญหา privilege escalation ที่ endpoint /user/update ซึ่งอนุญาตให้ผู้ใช้แก้ไขข้อมูลของตนเองได้โดยไม่จำกัดฟิลด์ ผู้โจมตีจึงสามารถเปลี่ยน user_role ของตนเองเป็น proxy_admin ได้ทันที โดย VulnCheck ให้คะแนนช่องโหว่นี้ที่ CVSS 8.8

ช่องโหว่ที่สาม CVE-2026-40217 เป็นปัญหา sandbox escape ในฟีเจอร์ Custom Code Guardrail ซึ่งคอมไพล์และรันโค้ด Python ที่ admin กำหนด แต่ระบบ production ใช้ exec() โดยไม่กรอง source code เมื่อ exec() ได้รับ globals dict ที่ไม่มี __builtins__ Python จะใส่โมดูล builtins เต็มเข้ามาโดยอัตโนมัติ ทำให้ผู้โจมตีสามารถเรียก os.system เพื่อเปิด reverse shell ได้

ที่น่าตกใจยิ่งกว่าคือทีม Obsidian ได้สาธิตการโจมตีผ่าน Claude Code ที่เชื่อมต่อผ่าน LiteLLM proxy ที่ถูกยึดครอง โดยผู้โจมตีใช้ callback mechanism ในตัวของ LiteLLM เพื่อสลับ response ของโมเดลเป็น tool call ปลอม และเขียนทับ context ของ safety check ให้ระบบอนุมัติคำสั่ง ในการสาธิต นักพัฒนาเพียงพิมพ์คำว่า “hello” แต่ผู้โจมตีสามารถเปิด reverse shell บนเครื่องของนักพัฒนาได้ทันที วิธีนี้ไม่ใช่ prompt injection แต่เป็นการปลอม response ระหว่างทาง (man-in-the-middle)

นอกจากนี้ยังมีช่องโหว่ CVE-2026-42271 ในระบบ MCP stdio ของ LiteLLM ที่ถูกใช้โจมตีจริง (in the wild) และถูกเพิ่มเข้าในแคตตาล็อก KEV ของ CISA แล้ว ทั้งนี้ LiteLLM เคยประสบปัญหาด้านความปลอดภัยมาก่อนหลายครั้งในปีนี้ ทั้ง supply-chain compromise บน PyPI ในเดือนมีนาคม และช่องโหว่ SQL injection ที่ถูกโจมตีภายใน 36 ชั่วโมงหลังเปิดเผยในเดือนเมษายน

รายละเอียดช่องโหว่

ช่องโหว่ทั้ง 3 รายการทำงานเป็นลูกโซ่ (chain) ดังนี้:

ขั้นที่ 1 — Bypass Route Gate (CVE-2026-47101): ผู้ใช้สิทธิ์ต่ำ (internal_user) สร้าง virtual API key พร้อมกำหนด allowed_routes: ["/*"] ซึ่งระบบบันทึกโดยไม่ตรวจสอบ ทำให้ key ดังกล่าวเข้าถึง admin-only route ได้ทุกเส้นทาง

ขั้นที่ 2 — Privilege Escalation (CVE-2026-47102): เมื่อเข้าถึง /user/update ได้แล้ว ผู้โจมตีส่ง request แก้ไข user_role ของตนเองเป็น proxy_admin ระบบรับค่าและบันทึกทันทีโดยไม่ตรวจสอบว่าฟิลด์ใดบ้างที่ผู้ใช้มีสิทธิ์แก้ไข

ขั้นที่ 3 — Remote Code Execution (CVE-2026-40217): ในฐานะ proxy_admin ผู้โจมตีสร้าง Custom Code Guardrail ที่มี Python payload อันตราย ระบบรันโค้ดผ่าน exec() โดยไม่กรอง ทำให้สามารถ import module ใดก็ได้และรัน system command ได้ นักวิจัยจาก X41 D-Sec พบวิธีเพิ่มเติมในการ bypass regex deny-list ผ่าน runtime bytecode rewriting อีกด้วย

เมื่อยึดเซิร์ฟเวอร์ได้แล้ว ผู้โจมตีจะได้รับ master key, salt key สำหรับถอดรหัส credential, database URL และ API key ของ provider ทุกราย รวมถึง OAuth token และ tool credential หากระบบทำหน้าที่เป็น MCP gateway ด้วย ที่สำคัญ LiteLLM อยู่ตรงกลางระหว่าง AI agent กับโมเดล ผู้โจมตีจึงสามารถดัดแปลง response ระหว่างทางเพื่อบังคับให้ agent ทำสิ่งที่ต้องการได้

ผลกระทบต่อไทย

LiteLLM เป็นเครื่องมือที่ได้รับความนิยมในหมู่นักพัฒนา AI ทั่วโลก รวมถึงในประเทศไทยที่มีการนำ LLM มาใช้งานในองค์กรมากขึ้น โดยเฉพาะในธุรกิจ fintech, healthtech และบริษัทเทคโนโลยีที่ใช้ LiteLLM เป็น proxy สำหรับเรียก API ของผู้ให้บริการ LLM หลายราย หากเซิร์ฟเวอร์ LiteLLM ถูกยึดครอง ผู้โจมตีจะเข้าถึง API key ทั้งหมดซึ่งอาจนำไปใช้สร้างค่าใช้จ่ายจำนวนมาก รวมถึงอ่านข้อมูลที่ส่งผ่านระบบซึ่งอาจมีข้อมูลส่วนบุคคลหรือความลับทางธุรกิจ นอกจากนี้การที่ผู้โจมตีสามารถปลอม response ของ AI ได้ยังเป็นภัยคุกคามต่อระบบ AI agent ที่ตัดสินใจอัตโนมัติอีกด้วย

คำแนะนำ

องค์กรที่ใช้ LiteLLM ควรอัปเดตเป็นเวอร์ชัน 1.83.14-stable หรือใหม่กว่าโดยเร่งด่วน จากนั้นตรวจสอบบัญชีผู้ใช้ทั้งหมดที่มีสิทธิ์ proxy_admin และปฏิบัติต่อสิทธิ์ดังกล่าวเสมือน host-level access ควรตรวจสอบ Custom Code Guardrail ทั้งหมดบน proxy และตรวจ callback ที่โหลดจาก config.yaml ใต้ litellm_settings.callbacks เนื่องจาก callback เหล่านี้ไม่แสดงใน console และเป็นจุดที่ผู้โจมตีมักซ่อนโค้ดหลังจากได้ RCE แล้ว หากสงสัยว่าถูกโจมตี ควร rotate API key ของ provider ทุกราย, database credential และ MCP token ทั้งหมด

แหล่งอ้างอิง