LiteLLM 1.107.0 ฝังตัวขโมยกุญแจ AI แค่เริ่ม Python ก็เสี่ยง

อัปเดต 27 ต.ค. 2026: รุ่นสะอาดล่าสุดตอนนี้คือ 1.106.4 (ขึ้น PyPI 25 ต.ค. 16:32 น. เวลาไทย) ส่วน 1.106.2 คือรุ่นสุดท้ายก่อนเกิดเหตุ ทั้งสองรุ่นไม่ได้รับผลกระทบ ตั้งแต่ 1.106.3 ทีมเปลี่ยนกุญแจ cosign ที่ใช้เซ็น image ใหม่ และ LiteLLM ออกรายงานต้นเหตุฉบับทางการเมื่อ 23 ต.ค. ผมแก้บทความตามนั้นและเพิ่มร่องรอยที่ใช้ตรวจเครื่อง ดูวิธีเช็กและแก้ทีละขั้นใน คู่มือเช็กและแก้แพตช์สายเดฟ

LiteLLM ซึ่งเชื่อมบริการโมเดล AI มากกว่า 100 ผู้ให้บริการผ่านช่องทางเดียว ถูกพบมัลแวร์ในไฟล์ติดตั้งสำเร็จรูปทั้ง 7 ชุดของรุ่น 1.107.0 ที่เผยแพร่เมื่อ 21 ตุลาคม 2026 และในชุดโปรแกรม Docker ทางการด้วย ตามการตรวจสอบของ StepSecurity เรื่องนี้เกี่ยวกับทั้งเงินและข้อมูล เพราะสิ่งที่มัลแวร์มุ่งขโมยมีตั้งแต่รหัสผ่านในเบราว์เซอร์ ไปจนถึงกุญแจเรียกใช้บริการ AI ที่เก็บอยู่ในระบบของบริษัท (Datadog Security Labs)

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

สรุป 30 วินาที: เกิดอะไรขึ้น

• รุ่นที่ยืนยันว่ามีปัญหาคือ LiteLLM 1.107.0 บน PyPI ซึ่งเป็นแหล่งแจกแพ็กเกจหรือชุดโปรแกรมเสริมของ Python ไฟล์แบบ wheel หรือชุดติดตั้งที่เตรียมไว้พร้อมใช้ทั้ง 7 ชุดมีมัลแวร์ และ PyPI นำรุ่นนี้ออกแล้ว (LiteLLM)
• Docker image คือชุดโปรแกรมพร้อมสภาพแวดล้อมสำหรับนำไปรัน รุ่น v1.107.0 และป้ายชื่อ latest, main-latest, main-stable เคยชี้ไปยังชุดที่มีมัลแวร์ด้วย ก่อนถูกนำออกหรือเปลี่ยนให้ชี้ไปยังชุดที่ตรวจสอบแล้ว (LiteLLM)
• มัลแวร์มีทั้งส่วนขโมยข้อมูลยืนยันตัวตน และส่วนทำงานเบื้องหลังที่คอยตรวจหาคำสั่งโปรแกรมจากภายนอกทุกชั่วโมง ไม่ต้องเรียกใช้ LiteLLM โดยตรงก็เริ่มทำงานได้ (StepSecurity)
• รุ่นที่แหล่งข่าวแนะนำให้ระบุใช้อย่างชัดเจนตอนเกิดเหตุคือ 1.106.2 ซึ่งเป็นรุ่นสุดท้ายก่อนเกิดเหตุ ตอนนี้รุ่นสะอาดล่าสุดคือ 1.106.4 (GitHub) แต่การถอยกลับไปใช้รุ่นสะอาดเพียงอย่างเดียวไม่ใช่การกู้คืนที่ครบถ้วน ยังต้องจัดการเครื่องและเปลี่ยนข้อมูลลับที่อาจถูกขโมย (Datadog Security Labs)

เวลาทั้งหมดต่อไปนี้เป็นเวลาไทย วันที่ 21 ตุลาคม 2026 ทีม LiteLLM ระบุว่าไฟล์อันตรายถูกอัปโหลดประมาณ 18:39–18:40 น. และ PyPI นำออกภายใน 20:23 น. ส่วน Docker Hub มีช่วงเสี่ยงตั้งแต่ประมาณ 18:46 น. ถึง 21:20 น. จึงไม่ควรใช้เวลาปิดเหตุของ PyPI ไปตัดสินความปลอดภัยของ Docker ทั้งหมด (LiteLLM)

ทำไมเรื่องนี้เกี่ยวกับคุณ

LiteLLM เป็นโครงการเปิดเผยซอร์สโค้ดของ BerriAI ทำหน้าที่เป็นทั้งไลบรารี หรือชุดความสามารถที่โปรแกรมอื่นเรียกใช้ และพร็อกซี หรือระบบกลางที่รับคำขอก่อนส่งต่อไปยังผู้ให้บริการ AI โดยใช้รูปแบบ API ที่เข้ากับ OpenAI ได้ คำว่า API ในที่นี้คือช่องทางให้โปรแกรมคุยกับบริการอีกแห่ง LiteLLM จึงอาจอยู่ทั้งบนโน้ตบุ๊กนักพัฒนา ระบบสร้างและทดสอบโปรแกรมอัตโนมัติ และระบบกลางที่ให้บริการ AI จริงพร้อมเก็บกุญแจของผู้ให้บริการไว้ (StepSecurity)

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

สำหรับนักศึกษาและคนเขียนโปรแกรม ความเสี่ยงไม่ได้จำกัดอยู่ที่กุญแจ AI ของงานชิ้นเดียว รายการเป้าหมายที่นักวิจัยพบรวมถึงรหัสผ่านและคุกกี้ในเบราว์เซอร์ ซึ่งเป็นข้อมูลที่ช่วยให้เว็บจำการเข้าสู่ระบบ กุญแจ SSH สำหรับเข้าถึงเครื่องระยะไกล ข้อมูลเข้าบริการคลาวด์ และโทเคนของเครื่องมือช่วยเขียนโค้ดด้วย AI ซึ่งเป็นข้อมูลใช้ยืนยันสิทธิ์เข้าบริการเหล่านั้น (Datadog Security Labs) เครื่องทำงานเครื่องเดียวจึงควรได้รับการตรวจตามสิทธิ์ที่มันเข้าถึงได้ทั้งหมด

กรณีนี้ยังเป็นการเจาะการแจกจ่าย LiteLLM บน PyPI ครั้งที่สองของปี 2026 โดยครั้งก่อนในเดือนมีนาคมเกี่ยวข้องกับรุ่น 1.82.7 และ 1.82.8 ตาม StepSecurity อย่างไรก็ตาม Datadog ระบุว่ายังไม่พบหลักฐานเชื่อมโยงผู้ก่อเหตุสองครั้งเข้าด้วยกัน จึงไม่ควรสรุปว่าเป็นกลุ่มเดิมเพียงเพราะชื่อแพ็กเกจซ้ำ (Datadog Security Labs)

ทำงานยังไง

ปัญหานี้เป็นการโจมตีผ่านห่วงโซ่ซอฟต์แวร์ หมายถึงโค้ดอันตรายปะปนมากับสิ่งที่เรารับจากกระบวนการผลิตและแจกจ่ายโปรแกรมที่เชื่อถืออยู่ เปรียบเหมือน ร้านส่งของเจ้าประจำ แต่รอบนี้มีคนแอบใส่ของแปลกปลอมมาในกล่องตั้งแต่โรงงาน ในเหตุนี้แพ็กเกจและ Docker image ถูกเผยแพร่ผ่านช่องทางปกติของ LiteLLM แต่ชุดที่นำไปสร้างโปรแกรมมาจากคลังโค้ด GitHub ที่ผู้โจมตีควบคุมและตั้งชื่อคล้ายของจริง (Datadog Security Labs)

เมื่อโปรแกรมติดตั้งนำ wheel รุ่นอันตรายเข้ามา มันนำโค้ดเพิ่มเติมไปไว้ในส่วนที่ Python ใช้เริ่มต้นระบบด้วย Python มีกลไกเรียกโค้ดเริ่มต้นบางประเภทอัตโนมัติ จึงเกิดการทำงานทุกครั้งที่เปิด Python ในสภาพแวดล้อมนั้น โดยไม่ต้องสั่งนำ LiteLLM เข้ามาใช้ในโปรแกรม ฐานข้อมูลความปลอดภัย OSV ก็ระบุพฤติกรรมนี้ตรงกัน (OSV)

ส่วนแรกมุ่งรวบรวมข้อมูลลับ ตั้งแต่เบราว์เซอร์ เครื่องมือพัฒนา และบริการคลาวด์ ไปจนถึงกุญแจผู้ให้บริการ AI ที่พร็อกซีเก็บในฐานข้อมูล จากนั้นเข้ารหัสข้อมูลก่อนส่งออก การเข้ารหัสตรงนี้เป็นวิธีที่มัลแวร์ใช้กับข้อมูลที่ขโมย ไม่ได้แปลว่าข้อมูลยังปลอดภัยสำหรับเจ้าของบัญชี (Datadog Security Labs)

ส่วนที่สองเป็นตัวรอรับและรันโค้ดเพิ่มเติมจากภายนอก ทำงานเบื้องหลังและตรวจทุกชั่วโมง ตามการวิเคราะห์ของ StepSecurity ขณะที่ Datadog ระบุว่าในช่วงที่ตรวจสอบยังไม่พบโค้ดโจมตีขั้นถัดไปถูกใช้จริงผ่านช่องทางนี้ ต้องแยกความสามารถที่เตรียมไว้กับสิ่งที่นักวิจัยเห็นแล้วออกจากกันครับ (StepSecurity, Datadog Security Labs)

ผลในทางปฏิบัติคืออย่าเริ่มแก้ด้วยการเปิด Python หรือเครื่องมือติดตั้งของสภาพแวดล้อมเดิมแบบทันที ทีม LiteLLM เตือนว่าการเปิดเครื่องมือเหล่านี้อาจเรียกมัลแวร์ซ้ำ และแนะนำว่าการสร้างชุดรันโปรแกรมหรือ image ใหม่จากต้นทางสะอาดดีกว่าการซ่อมของเดิมเพียงอย่างเดียว (LiteLLM)

ร่องรอยที่ทางการและฐานข้อมูลมัลแวร์ระบุไว้มีดังนี้ครับ ทีม LiteLLM ให้ค้นหาโฟลเดอร์ litellm-1.107.0.dist-info และไฟล์ cook.pth กับ sitecustomize.py ในเครื่อง พร้อมเตือนว่าเจอหนึ่งอย่างแปลว่าโดนแล้ว แต่ไม่เจอก็ไม่ได้พิสูจน์ว่าสะอาด ส่วนคอนเทนเนอร์ที่เคยรัน image digest sha256:1bbcb144…c339e ให้ถือว่าถูกเจาะ (LiteLLM) OSV เพิ่มไฟล์ร่องรอย /tmp/.pc_once_72129118c59f5636c0bb และปลายทางส่งข้อมูลออกที่โดเมน litellm.dev (OSV) ขณะที่ตัวทำงานเบื้องหลังถือไฟล์ล็อก /tmp/remote_code_loader.lock ไว้ (LiteLLM) ฐานข้อมูล GitHub ติดตามเหตุนี้ในชื่อ GHSA-92x9-889m-jgmw ควรค้นไฟล์เหล่านี้จาก shell ก่อน เพราะการเปิด Python หรือ pip ในสภาพแวดล้อมเดิมเพื่อเช็กรุ่นก็เรียกมัลแวร์ซ้ำได้

จุดหักมุม: โค้ดต้นฉบับดูสะอาด แต่ของที่แจกมีพิษ

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

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

ทีม LiteLLM รายงานว่าพบการใช้ข้อมูลยืนยันตัวตนของนักพัฒนาหลายบัญชี และหลังเหตุเดือนมีนาคมได้เพิ่มมาตรการควบคุมการปล่อยรุ่นไว้แล้ว (LiteLLM) ส่วนทางเข้า รายงานต้นเหตุที่ทีมประกาศเมื่อ 23 ต.ค. และเรียกตัวเองว่าแหล่งข้อมูลหลักระบุว่า กุญแจหลักของระบบ LiteLLM Agent Platform หลุดไปกับไฟล์ตั้งค่าที่ถูก commit ขึ้นคลังโค้ดสาธารณะตั้งแต่ 27 พฤษภาคม จากนั้นวันที่ 10 ตุลาคม ผู้โจมตีใช้กุญแจนั้นดึงโทเคน GitHub CLI ของเจ้าของ organization ออกมา ทีมยอมรับเองว่าที่เคยสงสัยว่าโทเคนหลุดจากบันทึกระบบภายในนั้นไม่ถูกต้อง (LiteLLM)

เรื่องเงิน / ผลกระทบ

กุญแจ API คือข้อมูลลับที่บริการใช้ตรวจสิทธิ์ของผู้เรียกใช้งาน หากหลุด การใช้งานที่ไม่ได้อนุญาตอาจไปเกี่ยวข้องกับบัญชีและค่าใช้บริการของเจ้าของกุญแจได้ ในเหตุนี้มีหลักฐานที่ต้องใส่ใจมากกว่าความสามารถบนกระดาษ: Wiz รายงานเพียงแหล่งเดียวในชุดข้อมูลนี้ ว่าพบการนำข้อมูลคลาวด์ที่ขโมยมาไปตรวจสอบและสำรวจบริการ AI แล้ว โดยช่วงที่รายงานคือ 23:20 น. วันที่ 21 ตุลาคม ถึง 00:01 น. วันที่ 22 ตุลาคม เวลาไทย (Wiz)

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

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

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

เวลาปิดเหตุไม่ได้เป็นตัวเลขเดียวกันทุกแหล่ง Wiz และ Datadog ระบุว่า PyPI กักรุ่นอันตรายเวลา 20:20 น. วันที่ 21 ตุลาคม เวลาไทย ส่วนทีม LiteLLM ระบุว่านำออกภายใน 20:23 น. คำว่ากักกับนำออกเป็นสถานะที่รายงานต่างกัน จึงควรบอกทั้งสองเวลา แทนเลือกเวลาหนึ่งเป็นข้อยุติ (Wiz, Datadog Security Labs, LiteLLM)

เวลาถอน Docker ต่างกันมากกว่านั้น Wiz และ Datadog สรุปไว้ราว 20:53 น. ส่วนรายงานผู้พัฒนาระบุว่าตรวจพบป้ายชื่อที่ได้รับผลกระทบบน GHCR ใช้ไม่ได้แล้วเวลา 20:51 น. แต่ Docker Hub ยังต้องรอถึง 21:20 น. ส่วนเวลาเริ่ม ผู้พัฒนาระบุเริ่มเผยแพร่ 18:46:56 น. และ StepSecurity ฉบับอัปเดตก็ใช้ช่วง 18:46–21:20 น. ตรงกันแล้ว ทั้งหมดเป็นวันที่ 21 ตุลาคม เวลาไทย การตรวจควรดูแหล่งรับ image และประวัติของตัวเองด้วย (Wiz, Datadog Security Labs, LiteLLM, StepSecurity)

รุ่นก่อนหน้าไม่ได้มีหลักฐานการตรวจละเอียดเท่ากันทุกชุด ผู้พัฒนาระบุว่ารุ่นก่อนหน้าปลอดภัย แต่ StepSecurity แจกแจงเฉพาะชุดที่ตรวจ และบอกชัดว่ายังไม่ได้ตรวจรุ่นทดลอง 1.107.0.dev1 ถึง dev3 ส่วน OSV ระบุว่า 1.106.2 และ 1.107.0rc1/rc2 ไม่ได้รับผลกระทบ ดังนั้นคำว่า “ก่อน 1.107.0” ไม่ควรใช้แทนการยืนยันว่าทุกไฟล์ของทุกรุ่นทดลองผ่านการตรวจแล้ว (LiteLLM, StepSecurity, OSV)

ระเบียน OSV มีข้อมูลคนละช่วงเวลาอยู่ร่วมกัน ระเบียน MAL-2026-2144 มีข้อมูลเดิมเกี่ยวกับรุ่นเดือนมีนาคม และเนื้อหาเกี่ยวกับ 1.107.0 ในเดือนตุลาคมด้วย ผมจึงใช้อ้างอิงเฉพาะข้อความเรื่องรุ่นและพฤติกรรมที่มันระบุ ไม่ใช้วันที่ของระเบียนเป็นวันเกิดเหตุใหม่ (OSV)

คำอธิบายต้นทางฉบับแรกถูกแทนแล้ว ตอนแรก LiteLLM เชื่อว่าผู้โจมตีได้โทเคนจากบันทึกของระบบภายใน และ Datadog เขียนไว้ว่ายังไม่ชัดว่าข้อมูลถูกขโมยครั้งแรกอย่างไร แต่วันที่ 23 ต.ค. LiteLLM ออกรายงานต้นเหตุที่บอกว่าบันทึกคำขอแสดงว่าโทเคนแรกมาจากบริการอื่น คือระบบ LiteLLM Agent Platform ที่ผู้โจมตีเข้าได้ด้วยกุญแจหลักซึ่งหลุดในคลังโค้ดสาธารณะ และหน้ารายงานเหตุการณ์เดิมก็เพิ่มหมายเหตุว่าสมมติฐานช่วงแรกบางส่วนไม่ถูกต้องหรือไม่ครบ (LiteLLM, Datadog Security Labs) ส่วนตัวรันโค้ดระยะถัดไป แม้มีอยู่จริง Datadog กับ Wiz ยังไม่พบการส่งโค้ดระยะนั้นจริงในช่วงวิเคราะห์ (LiteLLM, Datadog Security Labs, Wiz)

แล้วเราควรทำอะไร

ผู้ที่ติดตั้งหรือรัน 1.107.0 และผู้ที่ใช้ image ในช่วงเสี่ยง

1. ให้ทีมดูแลถือว่าสภาพแวดล้อมได้รับผลกระทบ โดยเฉพาะเมื่อเคยเริ่ม Python กับรุ่นนี้ ผู้พัฒนาระบุว่าถ้าเคยติดตั้งบนเครื่องที่ออกอินเทอร์เน็ตได้ ให้ตั้งสมมติฐานว่าการส่งข้อมูลออกสำเร็จ อย่าใช้การไม่พบร่องรอยเพียงอย่างเดียวสรุปว่าเครื่องสะอาด (LiteLLM)
2. วางแผนหยุดใช้งานสภาพแวดล้อมเสี่ยงและสร้างใหม่จากต้นทางสะอาด โดยระบุรุ่นให้ชัด หน้าเหตุการณ์ของ LiteLLM ยังเขียนว่า 1.106.2 ซึ่งเป็นรุ่นสุดท้ายก่อนเกิดเหตุ ส่วนรุ่นสะอาดล่าสุดคือ 1.106.4 (GitHub) ทั้งสองรุ่นไม่ได้รับผลกระทบ หลีกเลี่ยงการเริ่มเครื่องมือติดตั้งในชุดเดิมโดยไม่มีแผน เพราะอาจกระตุ้นมัลแวร์อีก การสร้างใหม่เป็นแนวทางที่ผู้พัฒนาระบุว่าดีกว่า (LiteLLM)
3. เปลี่ยนหรือเพิกถอนข้อมูลลับจากเครื่องสะอาด ครอบคลุมทุกอย่างที่เครื่องเดิมเข้าถึงได้ ทั้งรหัสผ่าน กุญแจคลาวด์ กุญแจเข้าระบบ โทเคนเครื่องมือ AI และกุญแจผู้ให้บริการในฐานข้อมูล จากนั้นตรวจประวัติการใช้สิทธิ์เหล่านั้นในช่วงเสี่ยง (Datadog Security Labs, StepSecurity)

ทีมพัฒนาที่อนุญาตให้อัปเดตรุ่นเอง หรือใช้ป้ายชื่อ image แบบเปลี่ยนได้

1. ตรวจ lockfile ซึ่งเป็นรายการรุ่นที่โครงการเลือกใช้จริง และประวัติการติดตั้งหรือสร้างระบบ การกำหนดแค่รุ่นขั้นต่ำโดยไม่มีขอบเขตอาจทำให้การติดตั้งใหม่หรือปรับรายการรุ่นรับ 1.107.0 มาได้ ตามที่ StepSecurity เตือน (StepSecurity)
2. ระบุรุ่นปลอดภัยให้แน่นอน และสำหรับ image ให้ยึด digest ซึ่งเป็นรหัสระบุเนื้อหาของ image แบบเฉพาะเจาะจง แทนพึ่งเพียงป้ายชื่อที่เปลี่ยนปลายทางได้ StepSecurity ฉบับอัปเดตแนะนำ litellm==1.106.4 หรือรุ่น backport 1.105.5, 1.104.7, 1.103.9 หรือ image ที่ระบุ digest (StepSecurity) ถ้ามีสคริปต์หรือนโยบายที่ตรวจลายเซ็น image ต้องเปลี่ยนไปใช้กุญแจ cosign ใหม่ด้วย เพราะตั้งแต่ 1.106.3 image ทุกชุดเซ็นด้วยกุญแจใหม่ และการตรวจด้วยกุญแจเดิมจะไม่ผ่าน (GitHub)
3. ตรวจให้ครอบคลุมเครื่องนักพัฒนา ระบบสร้างและทดสอบอัตโนมัติ และระบบให้บริการจริง เพราะ LiteLLM ใช้งานได้ในทุกบริบทเหล่านี้ หากพบรุ่นอันตรายให้เข้าสู่ขั้นตอนกู้คืนและเปลี่ยนข้อมูลลับ ไม่จบที่แก้หมายเลขรุ่นในโครงการ (StepSecurity)

ผู้บริหาร เจ้าของธุรกิจ และคนทั่วไปที่ใช้บริการ AI

1. ผมแนะนำให้ถามทีมภายในหรือผู้ให้บริการวันนี้ว่าใช้ LiteLLM หรือไม่ เคยรับ 1.107.0 หรือ image ช่วงเสี่ยงหรือไม่ และตรวจจากประวัติใด การตรวจต้องอิงสิ่งที่เคยใช้งาน ไม่ใช่ดูแค่รุ่นปัจจุบัน เพราะผู้พัฒนากำหนดขอบเขตจากการเคยติดตั้งหรือรันชุดที่ได้รับผลกระทบ (LiteLLM)
2. หากพบผลกระทบ ผมแนะนำให้ขอผู้รับผิดชอบและสถานะการสร้างระบบใหม่ เปลี่ยนกุญแจ และตรวจการใช้งานผิดปกติให้ครบ รายการนี้สอดคล้องกับการกู้คืนและตรวจบันทึกที่แหล่งข่าวแนะนำ (Datadog Security Labs)
3. แยกบริการที่ใช้จริงก่อนตัดสินใจ ผู้พัฒนาระบุว่าลูกค้าองค์กรที่รับรุ่น enterprise จากแหล่งแจกส่วนตัวของ LiteLLM ไม่ได้รับผลกระทบ ข้อยกเว้นนี้ผูกกับแหล่งแจกดังกล่าว ไม่ควรตีความครอบคลุมทุกองค์กรที่ใช้ LiteLLM (LiteLLM)

ผมมองว่า…

ผมมองว่า บทเรียนของเหตุนี้ ไม่ใช่การจำชื่อแพ็กเกจอันตราย แต่คือการรู้ว่าเครื่องทำงานของเราเข้าถึงความลับอะไรได้บ้าง นี่เป็นความเห็นของผมจากขอบเขตข้อมูลที่นักวิจัยพบ ซึ่งครอบคลุมทั้งงานพัฒนา บัญชีคลาวด์ เบราว์เซอร์ และฐานข้อมูลกุญแจ AI (Datadog Security Labs)

ในมุมผม การตอบว่า “อัปเดตกลับแล้ว” ยังสั้นเกินไปสำหรับเหตุขโมยข้อมูลยืนยันตัวตน คำตอบที่ควรขอเพิ่มคือเปลี่ยนสิทธิ์อะไรไปแล้ว และตรวจการใช้สิทธิ์หลังจากนั้นหรือยัง เหตุผลรองรับคือ Datadog แนะนำทั้งเปลี่ยนข้อมูลลับจากเครื่องสะอาดและตรวจบันทึก ขณะที่ผู้พัฒนาเตือนว่าการไม่พบร่องรอยไม่ได้พิสูจน์ว่าปลอดภัย (Datadog Security Labs, LiteLLM)

ปิดท้าย: สิ่งที่ต้องจับตา

ลำดับเหตุการณ์ฉบับทางการออกมาแล้วในรายงานต้นเหตุวันที่ 23 ต.ค. (LiteLLM) ส่วนหน้ารายงานเหตุการณ์เดิมยังแสดงเวลาอัปเดตล่าสุด 03:30 น. วันที่ 22 ตุลาคม เวลาไทย แต่เพิ่มหมายเหตุอัปเดตเวลา 04:50 น. วันที่ 24 ตุลาคม เวลาไทย ที่ชี้ไปยังรายงานฉบับใหม่ (LiteLLM) จึงควรแยกสถานะนำของอันตรายออกจากแหล่งแจก กับสถานะกู้คืนเครื่องที่เคยรับของนั้นไปแล้ว (LiteLLM)

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

Recap

• ตรวจว่าเคยติดตั้งหรือรัน LiteLLM 1.107.0 หรือไม่
• ตรวจประวัติ Docker วันที่ 21 ตุลาคม รวมป้ายชื่อที่เปลี่ยนปลายทางได้
• จำไว้ว่าการเริ่ม Python ในสภาพแวดล้อมอันตรายอาจเรียกมัลแวร์โดยไม่ต้องใช้ LiteLLM โดยตรง
• หากเข้าข่าย ให้ถือว่าเครื่องถูกเจาะและเตรียมสร้างสภาพแวดล้อมใหม่จากต้นทางสะอาด
• ระบุรุ่นสะอาดให้ชัด (ล่าสุด 1.106.4, รุ่นก่อนเกิดเหตุ 1.106.2) ตรวจ lockfile digest ของ image และอัปเดตกุญแจ cosign ใหม่
• เปลี่ยนข้อมูลลับทุกชุดที่เครื่องเข้าถึงได้ โดยทำจากเครื่องสะอาด
• ตรวจบันทึกการใช้บัญชี คลาวด์ และกุญแจ AI หลังช่วงเสี่ยง
• ให้ผู้รับผิดชอบรายงานผลตรวจจริง พร้อมติดตามผลสอบสวนที่ยังไม่ยืนยัน