LiteLLM เปิดผล RCA เหตุ 1.107.0 ถูกฝังมัลแวร์ — ต้นเหตุคือ master key ใน opencode.json ที่หลุดขึ้น repo สาธารณะตั้งแต่ 27 พ.ค. แต่ไม่เคยถูก revoke จน agent platform คืน token GitHub ระดับ owner ให้ผู้โจมตี

เมื่อ 23 ต.ค. 2026 (21:00 UTC) LiteLLM เผยแพร่ root cause analysis ฉบับสมบูรณ์ ของเหตุที่ litellm==1.107.0 บน PyPI และ Docker ถูกฝังมัลแวร์ขโมย credential เมื่อ 21 ต.ค. (เราเขียนถึงเหตุการณ์นี้ไว้เมื่อ 22 ต.ค.) ทีมระบุว่าเอกสารนี้คือ “canonical source of truth” และยอมรับว่าข้อมูลที่อัปเดตระหว่างสอบสวนช่วงแรกบางส่วน “ไม่ถูกต้องหรือไม่ครบ”

ประเด็นที่ต้องแก้ชัดที่สุดคือแหล่งที่ token หลุด ช่วงแรก LiteLLM สันนิษฐานว่า token ของวิศวกรหลุดจาก log ของ deployment ภายใน (ซึ่งเราก็รายงานตามนั้น) แต่ผล RCA ระบุว่าต้นเหตุจริงคือ master key ของ “LiteLLM Agent Platform” ที่ถูก commit อยู่ในไฟล์ opencode.json ขึ้น repo สาธารณะ LiteLLM-Labs/lite-harness ตั้งแต่ 27 พ.ค. 2026 ทีมเห็นและ force-push ทับไปแล้ว แต่ “key revocation did not occur for the master key” key นี้จึงยังใช้ได้อยู่อีก 4 เดือนครึ่ง

ห่วงโซ่การโจมตี 7 ขั้น

1. 10 ต.ค. 21:27 UTC: ผู้โจมตีใช้ master key เรียก GET /api/v1/managed_agents/agents?limit=100 ของ Agent Platform (ระบบทดลองที่ให้ agent เปิด PR บน GitHub) API ตอบกลับมาพร้อม config ของ agent ทุกตัว และในนั้นมี GitHub CLI OAuth token ของ org owner ที่ไม่ใช่ service account และไม่ได้จำกัดสิทธิ์
2. 22:11 UTC: ใช้ token ของ owner push branch ทิ้ง ci-tmp-a351cc เข้า BerriAI/litellm ให้ workflow ส่ง secret 6 ตัวไป webhook.site หนึ่งในนั้นคือ GH_TOKEN ซึ่งเป็น token ของ maintainer คนที่สอง แล้วลบ run ทิ้งภายใน 3 นาที
3. 24 วินาทีต่อมา ทำแบบเดียวกันที่ BerriAI/litellm-auto ได้ RELEASE_PLEASE_TOKEN ของ maintainer คนที่สาม จากนั้น 12 ต.ค. ดูด secret ของ repo ส่วนตัวอีกหลายตัว
4. 21 ต.ค. 10:08: ลอง push commit “ci: release from a fork source repository” เข้า repo project-releaser ด้วย token คนที่สอง ถูก branch protection ปฏิเสธ 5 วินาทีต่อมา ใช้ token ของ owner ปิด protection แล้ว force-push สำเร็จ จากนั้นสั่ง build จาก fork ปลอมชื่อ Berri-AI/litellm (มีขีดกลาง)
5. 11:11: ใช้ token คนที่สองกดอนุมัติ production gate แล้ว pipeline ก็ sign และ publish wheel 7 ตัวขึ้น PyPI ตอน 11:39–11:40
6. 11:53: ใช้ token คนที่สามลบ run record ทั้ง staging และ production ทำให้ log หายไปจาก repo
7. 12:09–12:24: ใช้ token ของ owner revert และ force-push main กลับไปที่ commit เดิม override ทั้ง branch protection และ force-push block

จุดอ่อนที่ทำให้สำเร็จ

• ไม่ revoke key ที่รู้อยู่แล้วว่าหลุด ทีมเห็นตั้งแต่ พ.ค. และระบุว่า key นี้ต้อง revoke แต่สุดท้ายไม่ได้ทำ
• agent เก็บ token ส่วนตัวของ owner ไว้ใน config และ API ส่ง config นั้นออกมาทั้งก้อน LiteLLM เขียนเองว่า GitHub CLI token เป็น “post-2fa” จึงไม่ต้องผ่านการยืนยัน 2FA ซ้ำเมื่อทำ action ที่อ่อนไหว
• secret ใน CI อ่านได้จาก branch ใดก็ได้ ใครที่ push branch ได้ก็ดึง secret ออกมาผ่าน workflow ได้
• ผ่อนกฎ release ในสัปดาห์เดียวกับที่ถูกโจมตี ปกติต้องอนุมัติด้วยบัญชีพิเศษที่ผูกกับอุปกรณ์จริงในออฟฟิศ แต่ช่วงนั้นผ่อนให้ “วิศวกร 2 คนใดก็ได้” กดสั่งและอนุมัติ เพื่อให้ออก bugfix ได้เร็วขึ้น LiteLLM ยอมรับว่าถึงไม่ผ่อน owner token ก็ปิดกฎนี้เองได้อยู่ดี แต่ผู้โจมตีเลือกใช้ token แยกคนเพื่อให้ audit log ดูปกติ
• GitHub แสดง commit ของ fork ผ่าน URL ของ repo ต้นทางได้ commit 20535d8f ที่มีอยู่แค่ใน fork ปลอมจึงเปิดดูได้ที่ github.com/BerriAI/litellm/commit/20535d8f ราวกับเป็นของจริง

ผู้ที่จับได้คือ LidorMachluf ซึ่งเปิด issue #47826 ภายในราว 20 นาทีหลัง publish ส่วนการสอบสวนได้ Socket และ Trail of Bits ช่วย

ต้องทำอะไรเพิ่มไหม

คำแนะนำสำหรับผู้ใช้ไม่เปลี่ยนจากประกาศแรก ใครติดตั้ง 1.107.0 หรือรัน image latest/main-stable ในช่วง 11:39–14:20 UTC ของ 21 ต.ค. ให้ถือว่าเครื่องถูกเจาะ และ rotate credential ทุกตัว ส่วน IoC ที่ใช้ค้นใน log ได้คือ IP 69.48.229.143 และ 199.91.221.39, org ปลอม Berri-AI และ branch ci-tmp-*

LiteLLM ยังบอกว่ากำลัง revoke token ทุกตัวในทุกระบบภายใน และจะเล่าเรื่องการปรับกระบวนการ “สัปดาห์หน้า” ในเธรดเดียวกัน maintainer แนะนำให้ผู้ใช้รัน proxy แบบ default-deny egress ที่ระดับเครือข่าย ส่วนคนที่ขอสวิตช์ OFFLINE_MODE ได้คำตอบว่าการจำกัดต้องทำที่ชั้นเครือข่ายถึงจะได้ผลจริง

มุมมอง AI Curator

ความผิดพลาดที่น่ากลัวที่สุดในรายงานนี้ไม่ใช่ตัวมัลแวร์ แต่เป็นไฟล์ opencode.json ซึ่งเป็น config ของ coding agent ที่มี master key ติดขึ้น repo สาธารณะ และ API ของ agent platform ที่ยอมส่ง token ระดับ org owner ออกมาทั้งก้อน การโจมตี supply chain ครั้งนี้เริ่มจากโครงสร้างของ agent เอง ทีมที่กำลังให้ agent เปิด PR หรือรัน CI แทนคนควรถามตัวเองว่า agent ถือ token ของใครอยู่ ถ้าคำตอบคือ token ส่วนตัวของ admin ก็เท่ากับแขวนกุญแจทั้งองค์กรไว้ที่ระบบซึ่งยังเป็นแค่ alpha

บทเรียนข้อที่สองคือ “รู้แล้วแต่ไม่ revoke” force-push ทับ commit ไม่ได้ทำให้ secret หายไป เพราะ bot ที่สแกน GitHub เก็บไปตั้งแต่ไม่กี่วินาทีแรก ทางเดียวที่ปลอดภัยคือ revoke ทันที ผู้โจมตีรายนี้ยังอดทนมาก ได้ token ตั้งแต่ 10 ต.ค. แต่รอถึง 21 ต.ค. ซึ่งเป็นสัปดาห์ที่ทีมผ่อนกฎ release พอดี แปลว่ากฎความปลอดภัยที่ผ่อนลงชั่วคราวก็มักจะเป็นช่วงที่ถูกโจมตีพอดี

สำหรับทีมในไทยที่ใช้ LiteLLM เป็น gateway เรียกหลายโมเดล (ซึ่งมีไม่น้อยในสตาร์ทอัพและทีม data ของธนาคาร) สิ่งที่ทำได้ทันทีมี 3 ข้อ (1) pin เวอร์ชันพร้อม hash และอย่าดึง tag latest ใน production (2) จำกัด egress ของ proxy ให้ออกได้เฉพาะปลายทางของผู้ให้บริการโมเดล และ (3) ตรวจ GitHub org ของตัวเองว่ามี secret ไหนที่ workflow บน branch ใดก็อ่านได้ และมี token ส่วนตัวของ owner ฝังอยู่ใน automation ตัวไหนบ้าง ข้อสุดท้ายนี้ทำได้ในบ่ายเดียว แต่ช่วยปิดเส้นทางแบบที่เกิดกับ LiteLLM ได้เกือบทั้งหมด

แหล่งข่าว

• LiteLLM — The attack chain behind the v1.107.0 LiteLLM release (23 ต.ค. 2026)
• LiteLLM — Security incident: litellm v1.107.0 (ประกาศแรก 21 ต.ค. 2026)
• GitHub — BerriAI/litellm issue #47826 (เธรดติดตามเหตุการณ์และคำตอบของ maintainer)