CISA เพิ่มช่องโหว่การข้ามการยืนยันตัวตน MCP ของ LiteLLM เข้า KEV: Bearer Token ใดก็ตามก็เพียงพอ

เมื่อวันที่ 2 กันยายน 2026 หน่วยงานความมั่นคงปลอดภัยไซเบอร์และโครงสร้างพื้นฐานของสหรัฐฯ (CISA) ได้เพิ่ม CVE-2026-59822 เข้าสู่แคตตาล็อกช่องโหว่ที่ถูกใช้ประโยชน์จริง (Known Exploited Vulnerabilities) ในชื่อ "ช่องโหว่การยืนยันตัวตนที่ไม่เหมาะสมของ BerriAI LiteLLM" ซึ่งเป็นหนึ่งในเจ็ดช่องโหว่ของชุดในวันนั้น ปัญหานี้อยู่ในปลายทาง MCP Streamable HTTP ของ LiteLLM กล่าวคือ เมื่อการตรวจสอบคีย์ LiteLLM ล้มเหลว กลไกสำรองแบบ OAuth2 passthrough กลับใส่ออบเจ็กต์ UserAPIKeyAuth() ที่ว่างเปล่าเข้าไปแทนการปฏิเสธคำขอ ดังนั้นเฮดเดอร์ Authorization Bearer ที่ถูกกุขึ้นมาใด ๆ จึงสามารถเปิดเซสชัน MCP ที่ผ่านการยืนยันตัวตนได้ ผู้โจมตีที่เข้าถึงปลายทางนั้นได้สามารถแสดงรายการและเรียกใช้เครื่องมือ MCP ทุกตัวที่เกตเวย์ถูกกำหนดค่าไว้ และผ่านเครื่องมือเหล่านั้นเข้าถึงบริการที่อยู่เบื้องหลังได้ ทุกเวอร์ชันก่อน 1.84.0 ได้รับผลกระทบ และหน่วยงานพลเรือนของรัฐบาลกลางมีกำหนดแก้ไขให้เสร็จภายในวันที่ 16 กันยายน บันทึกนี้ — รายการใน KEV สำหรับการข้ามการยืนยันตัวตนของ MCP ใน LiteLLM — เป็นหนึ่งรายการในOrcaRouter AI Incident Archive ซึ่งเก็บชุดบันทึกฉบับเต็มและรายการอื่น ๆ ที่อยู่ใกล้เคียงของเหตุการณ์นี้

เหตุผลที่บั๊กในพร็อกซีมีความสำคัญมากกว่าที่คะแนน CVSS บ่งชี้ อยู่ที่สิ่งที่อยู่เบื้องหลังพร็อกซี ทีมวิจัยภัยคุกคามของ Wiz กล่าวไว้อย่างตรงไปตรงมาว่า "พร็อกซี LiteLLM สามารถเก็บคีย์สำหรับผู้ให้บริการโมเดลทุกรายที่มันกำหนดเส้นทางไป รวมถึง OpenAI, Anthropic, Azure และ Gemini มันยังอาจทำงานด้วยสิทธิ์ IAM ของคลาวด์และเชื่อมต่อกับบริการภายในผ่านเซิร์ฟเวอร์เครื่องมือ MCP การถูกบุกรุกเพียงครั้งเดียวสามารถให้ผู้โจมตีเข้าถึงข้อมูลรับรองและบริการที่ปลายน้ำของพร็อกซี ไม่ใช่แค่ตัวพร็อกซีเอง" Wiz Research กล่าวว่าพวกเขาค้นพบช่องโหว่นี้ และฮันนีพอตของ Wiz ต่อมาบันทึกความพยายามใช้ช่องโหว่นี้

กลไก: การตรวจสอบที่ล้มเหลวซึ่งส่งคืนเซสชันที่ถูกต้อง

คำแนะนำของ BerriAI เอง GHSA-7488-6r32-c95q อธิบายข้อบกพร่องนี้ในสองประโยค: "ตัวจัดการการยืนยันตัวตน MCP รองรับ OAuth2 passthrough สำหรับเซิร์ฟเวอร์ MCP ต้นทาง แต่เส้นทาง fallback อาจแทนที่การตรวจสอบคีย์ LiteLLM ที่ล้มเหลวด้วยอ็อบเจกต์ UserAPIKeyAuth() ที่ว่างเปล่า สิ่งนี้ทำให้คำขอที่มี Authorization header ปลอมสามารถเข้าถึงเครื่องมือ MCP ได้โดยไม่มีคีย์ LiteLLM ที่ถูกต้อง" คำสำคัญคือ fallback โค้ดมีสาขาสำหรับการปรับใช้ที่ส่ง OAuth token ของเซิร์ฟเวอร์ MCP ต้นทางผ่านไปโดยตรง และเมื่อคีย์ LiteLLM ตรวจสอบไม่ผ่าน สาขานั้นส่งคืนอ็อบเจกต์การยืนยันตัวตนที่ว่างเปล่าแทนที่จะเป็นข้อผิดพลาด

ออบเจกต์การรับรองความถูกต้องที่เป็นค่าว่างไม่เหมือนกับการไม่มีออบเจกต์การรับรองความถูกต้องเลย โค้ดปลายน้ำเห็น UserAPIKeyAuth ที่สร้างขึ้นสำเร็จแล้วและดำเนินการต่อ โดยไม่มี tenant ไม่มีผู้ใช้ และไม่มี scope ผูกอยู่กับออบเจกต์นั้น บทความของ Wiz พูดตรงกว่าถึงผลกระทบในทางปฏิบัติว่า: "เมื่อการตรวจสอบโทเค็นล้มเหลว แทนที่จะปฏิเสธคำขอ เซิร์ฟเวอร์กลับส่งออบเจกต์ UserAPIKeyAuth() ที่ว่างเปล่าและไม่มีข้อจำกัดใด ๆ โทเค็น Bearer ใด ๆ (แม้เพียงอักขระเดียว เช่น x) ก็ให้สิทธิ์เข้าถึง MCP ได้เต็มรูปแบบ"

สิ่งที่ผู้โจมตีได้ไปคือเมนูรายการหนึ่ง โปรโตคอล MCP เปิดเผยรายการเครื่องมือ ดังนั้นเซสชันที่ผ่านการรับรองความถูกต้องจะส่งคืนชื่อและสคีมาของทุกเครื่องมือที่เกตเวย์ได้รับการกำหนดค่าให้เข้าถึง เช่น ฐานข้อมูล ที่เก็บโค้ด และ API ภายใน ตามตัวอย่างของ Wiz ประกาศจากผู้จำหน่ายระบุผลกระทบไว้อย่างชัดเจนว่า "ผู้โจมตีอาจใช้สิ่งนี้เพื่อแสดงรายการและเรียกใช้เครื่องมือ MCP ที่กำหนดค่าไว้ และเข้าถึงบริการที่เชื่อมต่อซึ่งเปิดเผยผ่าน MCP" จากนั้นการเรียกเครื่องมือจะทำงานด้วยสิทธิ์ใดก็ตามที่พร็อกซีเองมีต่อแบ็กเอนด์เหล่านั้น ซึ่งเป็นปัญหาการรวมศูนย์ข้อมูลรับรองที่ Wiz อธิบายไว้

แพตช์ในเดือนพฤษภาคม CVE ในเดือนกรกฎาคม และกำหนดเส้นตายของรัฐบาลกลางในเดือนกันยายน

วันที่ต่าง ๆ ไม่ได้เรียงตรงกันอย่างที่ผู้อ่านอาจคิด และช่องว่างระหว่างวันที่เหล่านั้นคือส่วนที่น่าสนใจ LiteLLM 1.84.0 — เวอร์ชันแรกที่คำแนะนำด้านความปลอดภัยระบุว่าได้รับการแก้ไขแล้ว — ถูกอัปโหลดขึ้น PyPI เมื่อวันที่ 14 พฤษภาคม 2026 ตามข้อมูลเมตาการเผยแพร่ของดัชนีแพ็กเกจเอง ตัวระบุ CVE ถูกจองกับ CVE Program เมื่อวันที่ 7 กรกฎาคม 2026 และเผยแพร่บันทึกในวันถัดมา คือวันที่ 8 กรกฎาคม รายการ OSV PYSEC-2026-3479 ตามมาในวันที่ 23 กรกฎาคม การขึ้นทะเบียนใน KEV เกิดขึ้นในวันที่ 2 กันยายน โดยมีกำหนดเส้นตายในการแก้ไขเป็นวันที่ 16 กันยายน

มีสองประเด็นตามมา ประเด็นแรก บิลด์ที่ได้รับการแพตช์แล้วเปิดให้สาธารณะมากกว่าสามเดือนก่อนที่ CISA จะระบุว่าช่องโหว่นี้ถูกใช้ประโยชน์จริง ดังนั้นองค์กรที่ถูกผูกพันด้วยกำหนดเวลานั้นจึงมีอัปเกรดที่ใช้งานได้ตลอดเวลาตั้งแต่แรก และการเพิ่มเข้าใน KEV ก็ไม่ใช่จุดที่แพตช์แก้ไขเพิ่งปรากฏ ประเด็นที่สอง ช่องว่างของเวอร์ชันกว้างขึ้นตั้งแต่นั้นมา: รีลีส LiteLLM ปัจจุบันบน PyPI คือ 1.106.5 ซึ่งอัปโหลดเมื่อ 27 ตุลาคม 2026 การติดตั้งที่ยังคงอยู่บนเวอร์ชันใดก็ตามที่ต่ำกว่า 1.84.0 ตอนนี้ล้าหลังกว่ายี่สิบรีลีสไมเนอร์ ไม่ใช่แค่ขาดแพตช์เดียว

สิ่งที่ประกาศนี้กำหนดไว้ และสิ่งที่ไม่ได้กำหนดไว้

คำเตือนของ CISA สำหรับชุดนี้ระบุว่าการเพิ่มรายการนั้นทำ "โดยอิงจากหลักฐานการถูกโจมตีใช้ประโยชน์จริง" และรายการที่เครื่องอ่านได้ในแคตตาล็อกสำหรับ CVE-2026-59822 ระบุวันที่เพิ่มเป็น 2 กันยายน 2026 วันที่ครบกำหนดเป็น 16 กันยายน 2026 ค่า known-ransomware-campaign-use เป็น "Unknown" และมีจุดอ่อนสองรายการ ได้แก่ CWE-287 (การพิสูจน์ยืนยันตัวตนที่ไม่เหมาะสม) และ CWE-306 (การขาดการพิสูจน์ยืนยันตัวตนสำหรับฟังก์ชันสำคัญ)

• ยืนยันแล้ว: CISA ประเมินว่าช่องโหว่นี้ถูกใช้ประโยชน์อย่างจริงจังและบรรจุไว้ในรายการแก้ไขของรัฐบาลกลาง บันทึก SSVC ของ NVD ซึ่งระบุว่าเป็นของผู้ประสานงาน CISA และประทับเวลา 2 กันยายน 2026 บันทึกสถานะการใช้ประโยชน์เป็น "active" ความสามารถในการทำงานอัตโนมัติเป็น "yes" และผลกระทบทางเทคนิคเป็น "partial"

• ยืนยันแล้ว: พบการโจมตีโดยใช้ช่องโหว่ในสภาพแวดล้อมที่ควบคุม Wiz เผยแพร่ทราฟฟิกฮันนี่พอตที่แสดงคำขอซึ่งมีโทเค็นอักขระเดียวเพื่อตรวจสอบเอนด์พอยต์สำหรับการแจกแจงโมเดล: คำขอ GET ไปยัง /v1/models ที่แนบ "Authorization: Bearer x" The Hacker News ซึ่งรายงานชุด KEV เมื่อวันที่ 3 กันยายน อธิบายกิจกรรมเดียวกันว่า Wiz พบ "ความพยายามใช้ประโยชน์จากช่องโหว่ที่เกี่ยวข้องกับ CVE-2026-59822 ต่อฮันนี่พอตของตน เพื่อตรวจสอบเอนด์พอยต์การแจกแจงโมเดล"

• ยืนยันแล้ว:คะแนนความรุนแรงทั้งสองมีอยู่จริงและแตกต่างกันตามกรอบงาน คำแนะนำของ BerriAI ให้คะแนนช่องโหว่นี้ตาม CVSS 4.0 อยู่ที่ 8.8 ระดับสูง โดยมีการรักษาความลับอยู่ในระดับสูง ความถูกต้องสมบูรณ์อยู่ในระดับต่ำ และความพร้อมใช้งานไม่มีผลกระทบ; การประเมิน CVSS 3.1 ของ NIST เอง ซึ่งเป็นค่าหลักใน NVD ระบุไว้ที่ 8.2 ตัวเลขทั้งสองอธิบายข้อบกพร่องเดียวกันภายใต้ระบบการให้คะแนนที่แตกต่างกัน และไม่ควรนำมาเปรียบเทียบเสมือนว่าค่าหนึ่งได้เข้ามาแทนที่อีกค่าหนึ่ง

• ยังไม่ได้รับการยืนยัน:ไม่มีเหยื่อรายใดที่ระบุชื่อได้ ทั้งประกาศเตือนของ CISA คำแนะนำของ BerriAI บทวิเคราะห์ของ Wiz และการรายงานข่าวของ The Hacker News ต่างไม่ได้ระบุองค์กรใดที่มีเครื่องมือ MCP ถูกเข้าถึงผ่านช่องโหว่นี้ หรือรายงานข้อมูลรับรองหรือข้อมูลที่ถูกนำออกไปจากองค์กรใด บันทึกสาธารณะเกี่ยวกับการถูกใช้ประโยชน์คือข้อมูลเทเลเมทรีจากฮันนีพอตและการพิจารณาระดับรัฐบาลกลาง ไม่ใช่การละเมิดข้อมูลที่ถูกเปิดเผย

• ยังไม่เป็นที่ยืนยัน:ว่าไม่มีกลุ่มแรนซัมแวร์ใดใช้งานมัน ฟิลด์ KEV ระบุว่า "Unknown" ซึ่งเป็นค่าที่ CISA กำหนด ไม่ใช่ข้อค้นพบว่าไม่มีการใช้งานไม่ว่าทางใด

แบบอย่างเดือนมิถุนายน และห่วงโซ่การรันโค้ดจากระยะไกลที่สิ่งนี้ไม่ใช่

นี่เป็นช่องโหว่ LiteLLM ตัวที่สองที่เข้าสู่แคตตาล็อก KEV ในปี 2026 และตัวก่อนหน้านั้นทำให้สับสนกับตัวนี้ได้ง่าย CVE-2026-42271 ซึ่งถูกเพิ่มเมื่อวันที่ 8 มิถุนายน 2026 โดยมีกำหนดเส้นตายวันที่ 22 มิถุนายน เป็นการแทรกคำสั่ง (command injection) ใน endpoint ทดสอบเซิร์ฟเวอร์ MCP ของ LiteLLM: Wiz อธิบายว่า endpoint เหล่านี้ให้ผู้ใช้ทดสอบการกำหนดค่าเซิร์ฟเวอร์ MCP ก่อนบันทึก โดยฟิลด์ command ถูกส่งไปยังการเรียกใช้ subprocess โดยไม่มีการตรวจสอบ ผู้โจมตีส่งการกำหนดค่าเซิร์ฟเวอร์ stdio ปลอม ซึ่งคำสั่งในนั้นดาวน์โหลดและเรียกใช้ cryptominer และส่งคืน MCP handshake ที่ดูเหมือนถูกต้อง เพื่อให้การทดสอบดูเหมือนสำเร็จ รายการของ CISA สำหรับช่องโหว่นี้ระบุ CWE-78 และ CWE-77 — การแทรกคำสั่งและอาร์กิวเมนต์ ไม่ใช่การยืนยันตัวตน

ช่องโหว่นั้นคือช่องโหว่ที่สามารถนำไปเชื่อมต่อเป็นลูกโซ่ได้ Wiz กล่าวว่า CVE-2026-42271 “สามารถนำไปเชื่อมต่อกับช่องโหว่การข้ามการตรวจสอบส่วนหัวโฮสต์ของ Starlette (CVE-2026-48710) เพื่อให้ได้ RCE โดยไม่ต้องยืนยันตัวตนเลย” และนักวิจัยภายนอกได้เชื่อมโยงกลุ่มแรนซัมแวร์ Qilin เข้ากับการใช้งานช่องโหว่แบบลูกโซ่ดังกล่าวในทางปฏิบัติจริง CVE-2026-48710 ถูกเพิ่มเข้าแคตตาล็อก KEV ในชุดวันที่ 2 กันยายนเดียวกันกับการข้ามการตรวจสอบของ LiteLLM โดยมีกำหนดเวลาสิ้นสุดวันที่ 16 กันยายนเดียวกัน และบันทึกแคตตาล็อกของ CISA เองสำหรับช่องโหว่ Starlette ระบุว่าสามารถนำไปเชื่อมต่อกับ CVE-2026-42271 ได้ ความเชื่อมโยงกับ Qilin นั้นเกี่ยวข้องกับการจับคู่ดังกล่าว ไม่ใช่ข้อค้นพบเกี่ยวกับ CVE-2026-59822 และไม่มีสิ่งใดในแหล่งข้อมูลที่ตรวจสอบซึ่งเชื่อมโยงกลุ่มแรนซัมแวร์เข้ากับช่องโหว่การข้ามการยืนยันตัวตน

รายละเอียดด้านการบริหารอย่างหนึ่งเป็นสิ่งที่ทำให้รายการ LiteLLM สองรายการแตกต่างกัน: การดำเนินการที่ต้องดำเนินการในรายการเดือนมิถุนายนอ้างถึง BOD 22-01 ซึ่งเป็นคำสั่งปฏิบัติการที่มีผลผูกพันฉบับเก่ากว่า ขณะที่รายการเดือนกันยายนอ้างถึง BOD 26-04 "Prioritizing Security Updates Based on Risk" คำเตือนของ CISA ไม่ได้อธิบายถึงการเปลี่ยนแปลงนี้ และแคตตาล็อกก็ไม่ได้ใส่คำอธิบายประกอบไว้

อะไรเปลี่ยนไปหลังจากนั้น

เส้นทางการแก้ไขนั้นสั้น คำแนะนำของ BerriAI แนะนำให้อัปเกรดเป็น 1.84.0 หรือใหม่กว่า และเสนอวิธีเลี่ยงสำหรับทีมที่ไม่สามารถดำเนินการได้ทันที: "ปิดใช้งานเส้นทาง MCP หรือบล็อกการเข้าถึง /mcp/ และ endpoint MCP ที่เกี่ยวข้องที่ reverse proxy หรือ API gateway ของคุณ" วิธีเลี่ยงนั้นเป็นเครื่องมือที่หยาบ — มันตัดความสามารถออกไปแทนที่จะควบคุมการเข้าถึง — แต่มันเป็นมาตรการบรรเทาเพียงอย่างเดียวที่ผู้จำหน่ายระบุสำหรับการติดตั้งที่ยังไม่ได้แพตช์

ข้อความการดำเนินการที่จำเป็นของ CISA สำหรับจุดเข้าดังกล่าวทำให้หน่วยงานรัฐบาลกลางต้องเผชิญกับการแลกเปลี่ยนเดียวกัน: ใช้มาตรการบรรเทาตามคำแนะนำของผู้จำหน่ายและให้สอดคล้องกับ BOD 26-04 “หรือเลิกใช้ผลิตภัณฑ์หากไม่มีมาตรการบรรเทา” โดยแต่ละหน่วยงานมีหน้าที่รับผิดชอบในการประเมินการเปิดเผยต่ออินเทอร์เน็ตของสินทรัพย์ คำสั่งนี้มีผลผูกพันเฉพาะหน่วยงานสาขาบริหารฝ่ายพลเรือนของรัฐบาลกลางเท่านั้น; CISA สนับสนุนให้องค์กรอื่นนำการจัดลำดับความสำคัญตามความเสี่ยงเดียวกันไปใช้โดยไม่บังคับ

ไม่เป็นที่เปิดเผยต่อสาธารณะว่ามีใครนอกฮันนีพอตได้ดำเนินการตามกำหนดเวลาหรือไม่ ทั้ง CISA และ BerriAI ต่างไม่ได้เผยแพร่ตัวเลขว่ามีการติดตั้งใช้งาน LiteLLM จำนวนเท่าใดที่ถูกเปิดเผย จำนวนเท่าใดที่ได้รับการแพตช์ก่อนวันที่ 16 กันยายน หรือจำนวนเท่าใดที่ถูกเข้าถึงผ่านช่องทางบายพาส

สิ่งที่ยังคงเปิดอยู่

มีช่องว่างสามข้อที่ควรกล่าวถึงมากกว่าจะกลบเกลื่อน ไม่มีรายงานเหตุการณ์สาธารณะที่เชื่อมโยง CVE-2026-59822 เข้ากับการบุกรุกครั้งใดครั้งหนึ่งโดยเฉพาะ ดังนั้นการอยู่ในรายการ KEV จึงอาศัยหลักฐานการนำช่องโหว่ไปใช้ประโยชน์ของ CISA และข้อสังเกตฮันนีพอตของ Wiz มากกว่าจะอาศัยเหยื่อที่มีการบันทึกไว้ ไม่มีคำแถลงของผู้จำหน่ายเกี่ยวกับว่าเส้นทางสำรองถูกเขียนเช่นนั้นได้อย่างไร หรือมีอยู่มานานเท่าใดก่อน 1.84.0 — ประกาศคำแนะนำอธิบายข้อบกพร่องและการแก้ไข ไม่ได้อธิบายประวัติของมัน และกำหนดเส้นตายของชุดรายการก็ไม่เหมือนกัน: ห้ารายการจากเจ็ดรายการที่เพิ่มเมื่อวันที่ 2 กันยายน มีกำหนดเส้นตายวันที่ 5 กันยายน ขณะที่รายการ LiteLLM และ Starlette มีกำหนดวันที่ 16 กันยายน CISA ไม่ได้ระบุเหตุผล

สิ่งที่ได้ข้อยุติกันนั้นแคบกว่าและมีประโยชน์กว่าตัวคะแนน อักขระเพียงตัวเดียวใน Authorization header บนเวอร์ชันที่ได้รับผลกระทบนั้นแยกไม่ออกจากคีย์ที่ถูกต้องสำหรับ MCP endpoint และเวอร์ชันที่ทำงานในลักษณะนั้นก็ไม่ได้เป็นเวอร์ชันปัจจุบันอีกต่อไปตั้งแต่เดือนพฤษภาคม 2026