LiteLLM ข้ามการยืนยันตัวตน MCP ถูกโจมตีจริง CVE-2026-59822
ผู้ดูแล LiteLLM รุ่นก่อน 1.84.0 ที่เปิด MCP Streamable HTTP ควรอัปเดตหรือปิดเส้นทาง MCP ทันที เพราะมีการโจมตีจริงแล้ว
สรุปใน 1 นาที
- อาการ/ปัญหา
- การตรวจคีย์ LiteLLM ล้มเหลวแต่เส้นทางสำรองยังยอมให้สร้างเซสชัน MCP ด้วย Bearer token ที่ไม่มีคีย์ถูกต้องรองรับ
- ใครควรอ่าน
- ระบบ LiteLLM รุ่นก่อน 1.84.0 ที่เปิดให้เข้าถึง MCP Streamable HTTP endpoint
- ทางแก้แบบสั้น
- อัปเดตเป็น 1.84.0 ขึ้นไป หรือปิด MCP routes และบล็อก endpoint ที่เกี่ยวข้องระหว่างรออัปเดต
พอดีไล่ฟีด CISA KEV เจอประกาศ BerriAI LiteLLM หมายเลข CVE-2026-59822 เป็นช่องโหว่ยืนยันตัวตนที่กระทบ MCP Streamable HTTP endpoint ผู้โจมตีไม่ต้องมีคีย์ LiteLLM ที่ถูกต้องก็สร้างเซสชัน MCP ที่ระบบยอมรับได้ จุดนี้ควรรีบตรวจถ้าใช้ LiteLLM เป็นทางผ่านไปยังเครื่องมือหรือบริการอื่น
เกิดอะไรขึ้น
LiteLLM เป็น proxy หรือ AI Gateway สำหรับเรียก LLM API ส่วน MCP ใช้เชื่อมต่อเครื่องมือ ปัญหาอยู่ในขั้นตอนตรวจสิทธิ์ที่รองรับ OAuth2 passthrough ไปยัง MCP server ปลายทาง เมื่อคีย์ LiteLLM ไม่ผ่านการตรวจ โค้ด fallback กลับสร้างออบเจ็กต์ UserAPIKeyAuth() ว่างให้แทน คำขอเลยไปถึงเครื่องมือได้ ดู ระเบียน CVE ของโครงการ CVE
ผู้โจมตีใส่ Bearer token ที่สร้างเองใน Authorization header แล้วเปิดเซสชัน MCP ได้โดยไม่มี LiteLLM key ที่ถูกต้อง จากนั้นดูรายการและเรียกเครื่องมือที่ตั้งค่าไว้ รวมถึงเข้าถึงบริการที่เชื่อมผ่าน MCP ได้ ผลกระทบขึ้นกับเครื่องมือที่แต่ละระบบเปิดให้ใช้ ประกาศผู้พัฒนา ให้ระดับ High และ CVSS 4.0 ที่ 8.8
CISA เพิ่มช่องโหว่นี้เข้า KEV วันที่ 2 กันยายน 2026 และยืนยันว่ามีการนำไปโจมตีจริงแล้ว กำหนดแก้ไขในรายการคือ 16 กันยายน 2026 ผู้ดูแลควรใช้สถานะการโจมตีจริงเป็นเหตุผลเร่งจัดลำดับงาน ไม่รอให้พบความผิดปกติก่อนเริ่มแก้ ข้อมูลวันที่และเส้นตายตรวจสอบได้จากฟีดทางการของ CISA
ใครโดนและรุ่นที่แก้
ให้ตรวจ LiteLLM proxy ที่เปิด MCP Streamable HTTP ทั้งรุ่นแพ็กเกจที่รันจริงและเส้นทาง MCP ที่เข้าถึงได้ การดูแค่รายการ dependency ยังไม่บอกว่าระบบเปิด endpoint นี้อยู่หรือไม่
| แพ็กเกจ / ส่วนที่กระทบ | รุ่นที่มีช่องโหว่ | รุ่นที่แก้ |
|---|---|---|
litellm บน pip / MCP Streamable HTTP |
ก่อน 1.84.0 |
1.84.0 ขึ้นไป |
ผู้พัฒนาระบุรุ่นที่แก้ไว้เป็นช่วงเดียวตามตาราง ไม่ได้แยกเลขแพตช์สำหรับสายรุ่นอื่นในประกาศนี้
ต้องทำอะไร
เริ่มจากตรวจเวอร์ชันใน environment หรือ container ที่ให้บริการจริง แล้วอัปเดตเป็นรุ่นที่มีแพตช์ตามวิธี deploy ของระบบ หากใช้ไฟล์ล็อก dependency หรือ image ที่ตรึงเวอร์ชันไว้ ให้แก้ต้นทางนั้นด้วยเพื่อให้การ deploy ครั้งต่อไปยังใช้รุ่นที่แก้แล้ว หลังเปลี่ยนให้ตรวจว่า process ที่รับคำขอรันแพ็กเกจรุ่นใหม่จริง
ถ้ายังอัปเดตไม่ได้ ให้ปิด MCP routes หรือบล็อกการเข้าถึง /mcp/ และ MCP endpoints ที่เกี่ยวข้องที่ reverse proxy หรือ API gateway
หลังแก้ ให้ทดสอบด้วยเครื่องมือที่ไม่เปลี่ยนข้อมูล ผู้ใช้ที่มีสิทธิ์ต้องทำงานได้ และคำขอที่ใช้ข้อมูลยืนยันตัวตนผิดต้องถูกปฏิเสธ ถ้าเลือกบล็อกชั่วคราว ให้ตรวจว่าครอบคลุมเส้นทาง MCP ทั้งหมด พร้อมตรวจ log การเรียกเครื่องมือที่ผิดปกติด้วย
ส่วนตัวผมให้แพตช์ทันทีถ้าเปิด MCP อยู่ เพราะเป็นช่องโหว่ที่มีการโจมตีจริงแล้ว ที่มา: CVE-2026-59822 (https://www.cve.org/CVERecord?id=CVE-2026-59822), ประกาศ BerriAI LiteLLM และ CISA KEV เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ
อยากให้เราทำให้ไหม?
ให้เราช่วยติดตั้ง ตั้งค่า ย้ายระบบ หรือแก้ปัญหาเซิร์ฟเวอร์ เพื่อให้คุณมีเวลาไปทำงานที่สำคัญกว่า
เคยเจองานแบบนี้ไหม? ติดตรงไหน?
มาแลกวิธีกันต่อในบอร์ด LinuxThai
ความคิดเห็น 0
ยังไม่มีความคิดเห็น — เป็นคนแรกเลย