เตือนภัยด่วน! ช่องโหว่ LiteLLM AI Gateway ถูกโซ่กับ Starlette เปิดทางแฮกเกอร์สั่งรันโค้ด ไม่ต้องใช้รหัสผ่าน CVSS พุ่ง 10.0

• POST /mcp-rest/test/connection

• POST /mcp-rest/test/tools/list

ปลายทางทั้งสองยอมรับการตั้งค่าเซิร์ฟเวอร์ MCP ทั้งหมดในเนื้อหาคำขอ (Request Body) แบบ JSON รวมถึงฟิลด์ Cmd, args, และ env ที่การขนส่งแบบ stdio ใช้ในการเปิดโปรเซสเซิร์ฟเวอร์ เมื่อผู้ใช้ที่ผ่านการพิสูจน์ตัวตนเรียกปลายทางเหล่านี้ด้วยการตั้งค่าดังกล่าว LiteLLM จะนำค่า Cmd ที่ให้มาและสร้างมันเป็นโปรเซสย่อย (Subprocess) บนเครื่องโฮสต์ โดยรันด้วยสิทธิ์ของระบบปฏิบัติการเดียวกันกับตัวโปรเซสพร็อกซีของ LiteLLM เอง

เดิมที BerriAI เปิดเผยเรื่องนี้ว่าเป็นจุดบกพร่องการรันโค้ดระยะไกลที่ต้องผ่านการพิสูจน์ตัวตน นั่นคือผู้โจมตีจำเป็นต้องมี API Key ที่ถูกต้องเพื่อเข้าถึงปลายทาง และไม่มีการตรวจสอบตามบทบาท (Role-based Check) เพื่อจำกัดว่าใครเรียกใช้ได้บ้าง แม้แต่ผู้ใช้ภายในที่มีสิทธิ์ต่ำและมีกุญแจ API ของพร็อกซีก็สามารถรันคำสั่งใดๆ บนเครื่องโฮสต์ได้ แต่เรื่องราวไม่ได้จบแค่นั้น

ทางเลี่ยง Starlette BadHost ที่ลบข้อกำหนดการยืนยันตัวตน

ช่องโหว่ตัวที่สองคือ CVE-2026-48710 ซึ่งนักวิจัยตั้งชื่อเล่นว่า "BadHost" นี่คือข้อบกพร่องในการตรวจสอบ Host-Header ใน Starlette ซึ่งเป็นเฟรมเวิร์ค ASGI ขนาดเบาที่เป็นรากฐานของ FastAPI, vLLM และเว็บแอปพลิเคชัน Python อีกนับพันรายการ รวมถึง LiteLLM Starlette ทุกเวอร์ชันตั้งแต่ 0.8.3 ถึง 1.0.0 ได้รับผลกระทบ

สาเหตุหลักคือการตีความที่แตกต่างกันระหว่างวิธีที่ Starlette จัดเส้นทางคำขอเข้า กับวิธีที่มันสร้าง URL ใหม่สำหรับตรรกะของแอปพลิเคชัน เลเยอร์การจัดเส้นทางของ ASGI ใช้เส้นทาง HTTP ดิบจากคำขอเพื่อตัดสินใจว่าปลายทางใดจะจัดการมัน แต่ request.url — URL ที่มิดเดิลแวร์และดีโคราเตอร์ของแอปพลิเคชันเห็น — ถูกสร้างขึ้นใหม่โดยการนำค่า Host Header ดิบมาต่อกับเส้นทางคำขอ โดยไม่มีการตรวจสอบที่เหมาะสม

ด้วยการแทรกอักขระตัวคั่นระหว่างส่วน authority กับ path ของ URI เช่น ? หรือ # ลงใน Host Header ผู้โจมตีสามารถทำให้ request.url.path ดูแตกต่างจากเส้นทางจริงที่ถูกจัดเส้นทางไปอย่างสิ้นเชิง มิดเดิลแวร์เห็นเส้นทางที่ดูไม่อันตรายเช่น / ในขณะที่เราเตอร์ส่งต่อคำขอไปยังปลายทางเป้าหมายจริงที่อยู่เบื้องหลัง มิดเดิลแวร์ยืนยันตัวตนใดๆ ที่ใช้เส้นทางและเชื่อถือ request.url.path สามารถถูกเลี่ยงได้อย่างง่ายดาย

การรวมกันเป็นลูกโซ่: จาก 8.7 กลายเป็น 10.0

ดีโคราเตอร์ยืนยันตัวตนของ LiteLLM จะตรวจสอบ request.url.path เพื่อตัดสินว่าคำขอจำเป็นต้องมี API Key ที่ถูกต้องหรือไม่ ทางเลี่ยง BadHost ทำให้ผู้โจมตีสามารถเปลี่ยนแปลง URL นั้นเพื่อให้มิดเดิลแวร์เห็นเส้นทางที่ไม่ต้องยืนยันตัวตน ในขณะที่เราเตอร์ ASGI ส่งคำขอไปยังหนึ่งในปลายทางที่มีช่องโหว่ Command Injection ของ MCP พร้อมๆ กัน

สิ่งนี้จะลบประตูควบคุมการเข้าถึงเพียงจุดเดียวที่กั้นระหว่างอินเทอร์เน็ตกับการรันคำสั่งตามอำเภอใจ ผู้โจมตีที่ไม่มี Credential และไม่เคยเข้าถึงเครือข่ายมาก่อน สามารถส่งคำขอ HTTP ที่สร้างขึ้นมาเป็นพิเศษเพียงครั้งเดียว เพื่อเลี่ยงการยืนยันตัวตนทั้งหมดและรันคำสั่งระบบปฏิบัติการบนเครื่องโฮสต์ของพร็อกซี LiteLLM ได้ Horizon3.ai ยืนยันว่าลูกโซ่การโจมตีนี้ทำงานได้สมบูรณ์ และให้คะแนน CVSS รวมที่ 10.0 ซึ่งเป็นระดับความรุนแรงสูงสุด เพราะมันบรรลุการรันโค้ดระยะไกลโดยไม่ต้องผ่านการพิสูจน์ตัวตน

สิ่งที่ผู้โจมตีทำได้เมื่อเข้าถึงได้

การโจมตีที่สำเร็จทำให้ผู้โจมตีรันคำสั่งได้ด้วยสิทธิ์ของโปรเซสพร็อกซี LiteLLM จากจุดนั้น พื้นผิวภัยคุกคามจะขยายตัวอย่างรวดเร็ว:

• การรันคำสั่งตามอำเภอใจ: ผู้โจมตีสามารถติดตั้งแบ็คดอร์, มัลแวร์, โปรแกรมขุดคริปโต หรือซอฟต์แวร์อื่นๆ ที่สิทธิ์ของโปรเซสโฮสต์อนุญาต
• การขโมย Credential ครั้งใหญ่: พร็อกซี LiteLLM ทำหน้าที่เป็นตัวกลางระหว่างแอปพลิเคชันกับผู้ให้บริการ LLM มากมาย มันเก็บ API Key สำหรับ OpenAI, Anthropic, Azure, AWS Bedrock, Google และบริการอื่นๆ ที่เชื่อมต่ออยู่ในฐานข้อมูลหรือตัวแปรสภาพแวดล้อม การใช้ช่องโหว่นี้ทำให้ผู้โจมตีสามารถขโมยทุก Credential ที่เก็บไว้ได้ในการดำเนินการครั้งเดียว
• การเคลื่อนย้ายภายหลัง (Lateral Movement) ผ่านโครงสร้าง AI: ด้วยกุญแจ API คลาวด์ที่ถูกขโมยและการเข้าถึง Shell บนเครื่องโฮสต์ของพร็อกซี ผู้โจมตีสามารถขยับขยายไปยังบริการคลาวด์ที่เชื่อมต่อ, เซิร์ฟเวอร์ MCP ภายใน, ฐานข้อมูลเวกเตอร์ และเฟรมเวิร์ค Agent ปลายทางได้
• ผลกระทบต่อระบบนิเวศที่กว้างขึ้น: ข้อบกพร่อง BadHost ของ Starlette ส่งผลต่อโปรเจกต์ที่ต้องพึ่งพามากกว่า 400,000 โปรเจกต์ รวมถึงแอปพลิเคชัน FastAPI, เซิร์ฟเวอร์ vLLM, การติดตั้งเซิร์ฟเวอร์ MCP และเฟรมเวิร์ค AI Agent ใดก็ตามที่ใช้มิดเดิลแวร์ยืนยันตัวตนแบบอิงเส้นทางบน Starlette เวอร์ชันก่อน 1.0.1 ล้วนเสี่ยงต่อการถูกเลี่ยงการยืนยันตัวตนในลักษณะเดียวกัน

ทำไมการเคลื่อนไหวของ CISA ถึงเพิ่มความเร่งด่วน

การที่ CISA เพิ่ม CVE-2026-42271 ลงในแคตตาล็อก KEV เมื่อวันที่ 8 มิถุนายน 2026 ยืนยันว่าช่องโหว่นี้ไม่ได้เป็นแค่ทฤษฎี — ผู้โจมตีกำลังใช้มันเป็นอาวุธอย่างแข็งขันในตอนนี้ ภายใต้คำสั่งปฏิบัติการผูกมัด (Binding Operational Directive) 22-01 หน่วยงานฝ่ายบริหารพลเรือนของรัฐบาลกลางสหรัฐฯ ทั้งหมดต้องแก้ไขช่องโหว่ที่อยู่ในรายชื่อ KEV ภายในกรอบเวลาที่กำหนด CISA ยังแนะนำอย่างแข็งขันให้ทุกองค์กร ทั้งภาครัฐและเอกชน จัดลำดับความสำคัญการแก้ไขรายการที่ถูกเพิ่มใน KEV เป็นกรณีฉุกเฉิน

ขั้นตอนการแก้ไขทันที

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

1. อัปเกรด LiteLLM เป็นเวอร์ชัน 1.83.7 หรือใหม่กว่า รุ่นนี้จะลบความสามารถในการรันคำสั่งที่ผู้ใช้เป็นผู้ระบุออกจากปลายทางทดสอบ MCP ซึ่งปิดเวกเตอร์การแทรกคำสั่งลงอย่างสมบูรณ์
2. อัปเกรด Starlette เป็นเวอร์ชัน 1.0.1 หรือใหม่กว่า แพตช์นี้จะตรวจสอบ Host Header ที่เข้ามากับข้อกำหนดของ URL และจะไม่สนใจ Header ที่มีอักขระที่ไม่ถูกต้อง ป้องกันกลลวงการสับสนเส้นทางที่เป็นหัวใจหลักของการเลี่ยงการยืนยันตัวตน
3. เปลี่ยนทุก Credential ที่เก็บไว้ทันที สันนิษฐานว่า API Key, Access Token หรือ Credential ฐานข้อมูลใดๆ ก็ตามที่พร็อกซี LiteLLM เคยเก็บไว้ ได้ถูกบุกรุกแล้ว เปลี่ยนกุญแจทั้งหมดของ OpenAI, Anthropic, Azure, AWS และผู้ให้บริการอื่นๆ และตรวจสอบแดชบอร์ดการเรียกเก็บเงินเพื่อหาการใช้งานที่ไม่ได้รับอนุญาต
4. บล็อกปลายทางที่มีปัญหาที่ Reverse Proxy หรือ WAF เพื่อเป็นมาตรการป้องกันเชิงลึกขณะที่กำลังทยอยอัปเดตแพตช์ ให้ตั้งค่า Reverse Proxy หรือ Web Application Firewall ของคุณให้ดรอปคำขอใดๆ ที่ส่งไปยัง

   POST /mcp-rest/test/connection

   และ

   POST /mcp-rest/test/tools/list

   ก่อนที่มันจะไปถึงแอปพลิเคชัน
5. ตรวจสอบย้อนหลังเพื่อหาการเข้าถึงที่ไม่ได้รับอนุญาต ตรวจสอบบันทึกของพร็อกซี LiteLLM เพื่อหากิจกรรมที่ผิดปกติบนปลายทางทดสอบ MCP โดยเฉพาะคำขอจากที่อยู่ IP ที่ไม่คาดคิด หรือคำขอที่มีการแก้ไข Host Header

ด้วยคะแนนความรุนแรง CVSS 10.0, การโจมตีที่กำลังเกิดขึ้นจริง และการถูกจัดให้อยู่ในรายชื่อ KEV ของ CISA หมายความว่าองค์กรที่ใช้บริการของ LiteLLM หรือ Starlette ควรมองว่านี่คือเหตุการณ์ฉุกเฉินที่ต้องรีบแก้ไขและเปลี่ยนคีย์ทันที ช่องว่างระหว่างการเริ่มโจมตีกับการขโมย Credential ได้เปิดกว้างขึ้นแล้ว