ช่องโหว่ LiteLLM เปิดทางยึดแอดมิน—เวอร์ชัน 1.83.9 คือเส้นแก้ไข

เมื่อ 13 ตุลาคม 2026 Check Point Research เผยผลตรวจ LiteLLM Proxy เกี่ยวกับ CVE-2026-35029 และ CVE-2026-59823 โดยระบุว่าเวอร์ชัน 1.83.9 แก้ครบทั้งสองรายการ ช่องโหว่แรกทำให้บัญชีสิทธิ์ต่ำเปลี่ยนการตั้งค่าของเกตเวย์ระหว่างทำงานได้ ซึ่งเปิดทางไปสู่การอ่านไฟล์และยึดบัญชีผู้ดูแล ส่วนช่องโหว่อีกตัวอาจเบี่ยงคำขอพร้อมคีย์ผู้ให้บริการโมเดลไปยังปลายทางที่ผู้โจมตีเลือกได้

วันที่ 15 ตุลาคม 2026 รายงานของ ITPro ติดตามผลกระทบต่อสิทธิ์ผู้ดูแลและคีย์ API โดยระบุว่ารุ่น 1.83.9 รวมการแก้ไขทั้งคู่ไว้แล้ว สำหรับผู้ดูแลระบบ คำตอบเร่งด่วนจึงมีสามส่วน: เกตเวย์ที่รับคำขอจริงใช้รุ่นใด ใครเข้าถึงมันได้ และมีหลักฐานการเปลี่ยนการตั้งค่าหรือการส่งคำขอออกนอกปลายทางที่กำหนดหรือไม่ การเผยรายละเอียดในเดือนตุลาคมไม่ได้หมายความว่าแพตช์เพิ่งออกในเดือนนั้น

รุ่นใดเสี่ยง และเหตุใดจึงต้องแยกช่องโหว่

ประกาศความปลอดภัยของโครงการ LiteLLM ระบุว่า CVE-2026-35029 กระทบรุ่นก่อน 1.83.0 และแก้แล้วใน 1.83.0 ด้วยการกำหนดให้จุดเชื่อมต่อแก้การตั้งค่าต้องใช้บทบาท proxy_admin ดังนั้นรุ่น 1.83.0 ถึง 1.83.8 จึงพ้นจากข้อบกพร่องด้านสิทธิ์รายการนี้ แต่ยังอยู่ในช่วงที่กระทบจาก CVE-2026-59823 ซึ่งแก้ใน 1.83.9 การเรียกทุกเครื่องที่ต่ำกว่า 1.83.9 ว่าเสี่ยงต่อการยึดแอดมินในรูปแบบเดียวกันจะทำให้จัดลำดับตรวจสอบผิด

เครื่องที่ต่ำกว่า 1.83.0 ต้องพิจารณาทั้งการแก้การตั้งค่าโดยบัญชีสิทธิ์ต่ำและการเบี่ยงคำขอขาออก ส่วนเครื่องในช่วง 1.83.0 ถึง 1.83.8 ให้เน้นเส้นทาง SSRF และคีย์ที่อาจติดไปกับคำขอ การแยกเช่นนี้ช่วยกำหนดว่าต้องค้นหาหลักฐานชนิดใดก่อน แต่ทุกเครื่องในสองกลุ่มยังควรขึ้นอย่างน้อย 1.83.9 เพื่อปิดช่องโหว่ที่เป็นประเด็นนี้ให้ครบ

เวอร์ชันที่ใช้ตัดสินคือเวอร์ชันของกระบวนการ LiteLLM Proxy ที่กำลังรับทราฟฟิก ไม่ใช่หมายเลขในแผนเปลี่ยนระบบหรืออิมเมจที่เตรียมไว้ หากมีหลายอินสแตนซ์ ต้องนับตัวที่ยังอยู่หลังตัวกระจายโหลด ตัวสำรองที่เปิดรับคำขอ และบริการที่ฝังเกตเวย์ไว้ด้วย การตรวจเฉพาะเครื่องหลักอาจทำให้พลาดเส้นทางที่ผู้ใช้ยังเรียกถึงได้

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

บัญชีสิทธิ์ต่ำไปถึงสิทธิ์แอดมินได้อย่างไร

เส้นทางของ CVE-2026-35029 เริ่มที่ POST /config/update ซึ่งใช้เปลี่ยนการตั้งค่าขณะเกตเวย์ทำงาน จุดเชื่อมต่อนี้ตรวจว่าผู้เรียกผ่านการยืนยันตัวตน แต่ในรุ่นที่กระทบไม่ได้ตรวจบทบาทผู้ดูแลก่อนบันทึกค่า ขณะเดียวกันโทเค็นที่ออกให้การเข้าสู่ระบบผ่านหน้าเว็บถูกจัดเป็นโทเค็นของส่วนติดต่อผู้ใช้ และกฎอนุญาตเส้นทางยอมรับชื่อที่ขึ้นต้นด้วย /config จึงครอบคลุม /config/update ไปด้วย

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

ตัวอย่างแรกของผลกระทบคือการอ่านไฟล์ การแก้การตั้งค่าสามารถเปลี่ยน UI_LOGO_PATH ซึ่งเป็นพาธที่ /get_image ใช้ดึงไฟล์โลโก้ เมื่อค่าดังกล่าวชี้ไปยังไฟล์อื่นในเครื่อง จุดเชื่อมต่อภาพอาจส่งเนื้อหาไฟล์นั้นกลับมา ขอบเขตไฟล์ที่อ่านได้ขึ้นอยู่กับสิทธิ์ของกระบวนการ LiteLLM; ไฟล์ที่กระบวนการเข้าไม่ถึงไม่ได้เปิดให้อ่านโดยอัตโนมัติ

เส้นทางยึดแอดมินใช้สิทธิ์แก้ค่าเดียวกันกับ UI_USERNAME และ UI_PASSWORD ซึ่งการเข้าสู่ระบบของผู้ดูแลอ้างอิงอยู่ หากผู้โจมตีเขียนค่าของตนลงไปและเข้าสู่ระบบผ่านช่องทางดังกล่าวได้ ระบบจะมอบบทบาทผู้ดูแลเกตเวย์ให้ ความเสี่ยงจึงไม่ได้หยุดที่การเห็นข้อมูล แต่รวมถึงการเปลี่ยนผู้ควบคุมการตั้งค่าและข้อมูลรับรองที่เกตเวย์ถืออยู่

อีกผลกระทบหนึ่งเกี่ยวกับ pass-through endpoints ที่สามารถกำหนดตัวจัดการคำขอแบบกำหนดเองได้ งานวิจัยแสดงเส้นทางที่การตั้งค่าใหม่ชี้ไปยังโมดูล Python ในพื้นที่เก็บข้อมูลภายนอก แล้วเกตเวย์ดาวน์โหลดและโหลดโมดูลนั้น การโหลดทำให้โค้ดระดับบนสุดของโมดูลทำงานบนเครื่องเกตเวย์ได้ จึงเป็นเหตุให้ต้องตรวจการเปลี่ยนค่า endpoint และกิจกรรมของกระบวนการควบคู่กับประวัติการเข้าสู่ระบบผู้ดูแล

ทั้งการอ่านไฟล์ การเปลี่ยนข้อมูลเข้าสู่ระบบ และการโหลดโมดูลเป็นผลจากการแก้ runtime configuration โดยผู้ที่ไม่ควรมีสิทธิ์นั้น หลักฐานของแต่ละเส้นทางต่างกัน: การอ่านไฟล์อาจทิ้งคำขอไปยัง /get_image การยึดแอดมินอาจเห็นการเปลี่ยนค่ากับการเข้าสู่ระบบที่ตามมา ส่วนการโหลดโค้ดอาจมีรายการ pass-through endpoint และการติดต่อพื้นที่เก็บข้อมูลภายนอก ความต่างนี้มีประโยชน์เมื่อบันทึกของแต่ละระบบเก็บรายละเอียดไม่เท่ากัน

SSRF เบี่ยงคำขอพร้อมคีย์ออกจากผู้ให้บริการได้อย่างไร

CVE-2026-59823 เป็นอีกเส้นทางหนึ่ง ผู้เรียกที่มี virtual key ใช้งานได้สามารถใส่ user_config ในเนื้อหาคำขอ เพื่อให้เกตเวย์สร้างตัวกำหนดเส้นทางสำหรับคำขอนั้น ภายในค่านี้อาจซ่อน api_base ที่ชี้ไปยังโฮสต์อื่นได้ แม้การตรวจคำขอจะกั้น api_base ที่อยู่ระดับบนสุด แต่การตรวจเดิมไม่ครอบคลุมค่าที่ฝังอยู่ใน user_config

เมื่อเกตเวย์นำค่าที่ฝังไปใช้ คำขอที่ควรส่งให้ผู้ให้บริการโมเดลอาจไปถึงเซิร์ฟเวอร์ที่ผู้เรียกกำหนดแทน นี่คือ SSRF หรือการทำให้บริการฝั่งเซิร์ฟเวอร์ส่งคำขอไปยังปลายทางที่ผู้เรียกเลือก ผลกระทบครอบคลุมได้ทั้งโฮสต์ภายนอกและบริการภายในที่เกตเวย์มองเห็น แต่ผู้เรียกต้องมีข้อมูลรับรองสำหรับเรียกเกตเวย์ตามเงื่อนไขของช่องโหว่

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

ความต่างจากช่องโหว่สิทธิ์มีผลต่อการสืบสวนโดยตรง สำหรับ SSRF การไม่พบการเปลี่ยนค่า /config/update หรือการเข้าสู่ระบบแอดมินที่ผิดปกติยังบอกไม่ได้ว่าคีย์ปลอดภัย ร่องรอยที่เกี่ยวข้องอยู่ในข้อมูลกำหนดเส้นทางของคำขอ การเชื่อมต่อขาออก และบันทึกการใช้คีย์ฝั่งผู้ให้บริการมากกว่า หากเกตเวย์เข้าถึงบริการภายในได้ การตรวจปลายทางภายในที่ไม่อยู่ในเส้นทางงานปกติก็เป็นส่วนหนึ่งของการกำหนดขอบเขตเหตุการณ์

คีย์ที่รั่วอาจถูกใช้เรียกบัญชีขององค์กรกับผู้ให้บริการโมเดลและก่อค่าใช้จ่ายตามการใช้งาน แม้การติดตั้งเกตเวย์จะยังตอบคำขอปกติอยู่ก็ตาม จึงต้องแยกคำถามว่า «ช่องทางถูกปิดแล้วหรือยัง» ออกจาก «มีข้อมูลรับรองใดออกไปก่อนปิดช่องทางหรือไม่» การอัปเกรดตอบคำถามแรก ส่วนการตรวจหลักฐานย้อนหลังตอบคำถามหลัง

ลำดับรับมือสำหรับเกตเวย์ที่ยังใช้รุ่นเสี่ยง

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

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

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

การตรวจย้อนหลังควรแบ่งตามรุ่นเดิมของเครื่อง หากต่ำกว่า 1.83.0 ให้ค้นหาคำขอแก้ค่า /config/update จากบัญชีที่ไม่ใช่ผู้ดูแล การเปลี่ยน UI_LOGO_PATH หรือข้อมูลเข้าสู่ระบบผู้ดูแล คำขอ /get_image ที่ผิดจากการโหลดโลโก้ และ pass-through endpoint ที่เพิ่มขึ้นหรือชี้ไปยังโมดูลภายนอก จากนั้นเทียบกับการเข้าสู่ระบบแอดมินและกิจกรรมของกระบวนการเกตเวย์ในช่วงเวลาเดียวกัน

สำหรับทุกเครื่องที่ต่ำกว่า 1.83.9 ให้ตรวจคำขอโมเดลที่ใช้ user_config และเทียบปลายทางขาออกกับรายชื่อผู้ให้บริการที่องค์กรตั้งใจใช้ มองหาการติดต่อโฮสต์ที่ไม่คุ้นเคย โดยเฉพาะเมื่อคำขอนั้นอาจแนบคีย์ผู้ให้บริการ หากไม่เก็บเนื้อหาคำขอไว้ บันทึกไฟร์วอลล์ พร็อกซีขาออก หรือข้อมูลฝั่งผู้ให้บริการอาจช่วยจำกัดช่วงเวลาและคีย์ที่เกี่ยวข้องได้ แต่ความละเอียดของข้อสรุปจะขึ้นกับหลักฐานที่มีจริง

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

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

หลังอัปเกรด รายการที่ยังต้องปิดให้ครบคืออินสแตนซ์เก่าที่อาจรับทราฟฟิก ปลายทางขาออกที่อธิบายไม่ได้ และข้อมูลรับรองที่หลักฐานชี้ว่าเคยถูกเปิดเผย เพราะแพตช์ปิดเส้นทางโจมตีในคำขอใหม่ได้ แต่ไม่เพิกถอนคีย์ที่อาจออกจากเกตเวย์ไปก่อนหน้า

อ่านเพิ่มเติม:

• ช่องโหว่ GitLab AI Gateway ได้ 9.9—ผู้ใช้คลาวด์ไม่ต้องแก้เหมือนกัน
• Microsoft อุด 1,411 ช่องโหว่ แต่หนึ่งจุดถูกโจมตีแล้ว