LiteLLM 1.107.0 บน PyPI และ Docker ถูกฝังมัลแวร์ขโมย credential นาน ~2 ชม. — ผู้โจมตีใช้ token GitHub CLI ของวิศวกร 3 คนที่หลุดจาก log ของ LiteLLM ภายในบริษัทเอง และ Wiz เห็นการนำ AWS key ไปใช้แล้ว

อัปเดต 25 ต.ค. 2026: ผล root cause analysis ที่ LiteLLM เผยแพร่เมื่อ 23 ต.ค. แก้ข้อสันนิษฐานช่วงแรกที่โพสต์นี้อ้างถึง token ไม่ได้หลุดจาก log ของ deployment ภายใน และไม่เกี่ยวกับ Claude Code ต้นเหตุจริงคือ master key ของ LiteLLM Agent Platform ที่ถูก commit ในไฟล์ opencode.json ขึ้น repo สาธารณะเมื่อ 27 พ.ค. แล้วไม่ได้ revoke — อ่านรายละเอียดในโพสต์ติดตามผล

LiteLLM ไลบรารี/AI gateway โอเพนซอร์สที่นักพัฒนาใช้เรียกโมเดลกว่า 100 เจ้าผ่าน interface เดียว ประกาศเมื่อ 21 ต.ค. 2026 ว่า release pipeline ของตัวเองถูกเจาะ และ litellm==1.107.0 ที่ขึ้น PyPI กับ Docker image หลายแท็กมีมัลแวร์ขโมย credential พร้อมตัวโหลดโค้ดระยะไกล แพ็กเกจอยู่บน PyPI ราว 1 ชั่วโมง 44 นาที (11:39–13:23 UTC หรือ 18:39–20:23 น. เวลาไทย) ส่วน Docker tag v1.107.0, latest, main-latest และ main-stable ชี้ไปที่ image อันตรายตั้งแต่ 11:46 ถึง 14:20 UTC

ใครที่ pip install litellm แบบไม่ pin เวอร์ชัน หรือดึง image latest ในช่วงนั้น LiteLLM บอกตรง ๆ ว่า “ให้ถือว่าเครื่องนั้นถูกเจาะแล้ว” และนี่ไม่ใช่ความเสี่ยงในทฤษฎี: Wiz รายงานว่าเริ่มเห็นผู้โจมตี นำ AWS credential ที่ขโมยไปใช้จริง ราว 4.5 ชั่วโมงหลังการขโมย

มัลแวร์ทำอะไร

ตาม GitHub issue #47826 ที่ชุมชนวิเคราะห์ไว้ ทุก wheel ของ 1.107.0 มีไฟล์เกิน 3 ไฟล์ที่ pip ติดตั้งลงราก site-packages:

• cook.pth + cook.py — ไฟล์ .pth ทำให้ cook.py รัน ทุกครั้งที่ interpreter นั้นเริ่มทำงาน (รวมถึงตอนรัน pip เอง) เป็นตัวขโมยข้อมูลที่เรียกตัวเองว่า privcollect เก็บ SSH key, ประวัติ shell, credential ของ AWS/Azure/gcloud/kube/docker/gh, .env*, .npmrc, .pypirc, ไฟล์ *.pem/*.key, รหัสผ่านที่บันทึกใน Chromium/Firefox, token และ config ของเครื่องมือ AI อย่าง Claude, Codex, Gemini, Cursor, Windsurf, Copilot และ HF token, environment variable ของทุก process ที่อ่านได้ผ่าน /proc/*/environ และ credential จาก cloud metadata (ตรวจว่าใช้ได้ด้วย STS GetCallerIdentity)
• ถ้ามี DATABASE_URL มันจะเรียก prisma dump ตาราง LiteLLM_CredentialsTable และ LiteLLM_ProxyModelTable ออกไป — แปลว่า provider API key ทุกตัวที่ proxy เก็บไว้ หลุดหมด
• ข้อมูลถูกเข้ารหัส AES-256 + RSA-4096 แล้ว POST ไปที่ www.litellm[.]dev/healthcheck (โดเมนหน้าเหมือนของจริง) ดูจาก network capture ไม่ได้ว่าส่งอะไรไป
• sitecustomize.py fork daemon แยกตัว (ล็อก /tmp/remote_code_loader.lock) ที่ทุกชั่วโมงจะอ่านโดเมนจากไฟล์บน GitHub แล้วดาวน์โหลดโค้ดมา exec() — ตอนนี้ไฟล์ว่างและบัญชีถูกลบแล้ว แต่ SafeDep เตือนว่าเครื่องที่รันก่อนหน้าอาจได้โค้ดขั้นที่สองไปแล้ว

ตัว source tag v1.107.0 บน GitHub สะอาด — artifact ที่อันตรายถูก build จาก repo หน้าเหมือน Berri-AI/litellm (ของจริงคือ BerriAI/litellm) โดยใน pyproject.toml ของ sdist มีบรรทัด data = "cook" เพิ่มเข้ามาบรรทัดเดียว เวอร์ชันที่ตรวจแล้วว่าสะอาดคือ 1.106.2, 1.107.0rc1/rc2 และเวอร์ชันก่อนหน้า ลูกค้า Enterprise ที่ดึงจาก registry ส่วนตัวไม่ได้รับผลกระทบ

เจาะ pipeline ที่ “แข็งแรงขึ้นแล้ว” ได้อย่างไร

ที่น่าสนใจคือ LiteLLM เพิ่งโดน supply-chain attack มาแล้วเมื่อ มี.ค. 2026 (หนึ่งในคลื่นของกลุ่ม TeamPCP) และหลังจากนั้นได้ย้าย release ไป repo ส่วนตัว ใช้ Trusted Publishers, ทำ Docker tag ให้ immutable, เซ็น image และกำหนดว่าการ publish ต้องทำจาก บัญชีที่ผูกกับแล็ปท็อปเครื่องเดียวที่อยู่ในออฟฟิศตลอดเวลา แต่การโจมตีรอบนี้ก็ยังผ่านไปได้ เพราะ:

1. วันจันทร์ (19 ต.ค.) บริษัท ขยายสิทธิ์ release ชั่วคราว ให้วิศวกร 2 คนปล่อย bugfix backport รายวันให้ลูกค้า
2. ผู้โจมตีถือ GitHub CLI OAuth token ของนักพัฒนา 3 คน หนึ่งในนั้นเป็น owner ของ GitHub organization — ใช้ปิด branch protection แล้ว force push workflow ที่ชี้ไป repo ปลอม (10:08 UTC)
3. ใช้ token ของคนที่สองกด approve production gate (11:11 UTC) แล้ว pipeline ทางการก็ build, เซ็น และ publish ของปลอมให้เอง
4. ใช้ token ของคนที่สามลบ log ของ workflow ทิ้ง (11:53 UTC) ทำให้หลักฐานเหลือน้อยลง

token มาจากไหน? LiteLLM เขียนว่า “พบสถานการณ์เฉพาะที่ Claude Code จะฝัง GitHub CLI OAuth token ของผู้ใช้ไว้ใน response body” และเมื่อ response ถูก log ไว้ token ก็ไปโผล่ใน log ของ LiteLLM — บริษัทพบบัญชีผู้ใช้ชื่อไม่น่าสงสัยแปลกปลอมใน LiteLLM deployment ภายในที่เปิดสู่อินเทอร์เน็ต และเชื่อว่าผู้โจมตีเข้าทางนั้น “น่าจะผ่านช่องโหว่ที่เพิ่ง patch ไป” แต่ยังไม่ยืนยัน ข้อนี้ต้องอ่านอย่างระวัง: เป็นข้อสันนิษฐานของ LiteLLM ฝ่ายเดียว ยังไม่ได้บอกว่า Claude Code ทำแบบนั้นในสถานการณ์ไหน (นักพัฒนาใน issue ถามไว้ตั้งแต่ 22 ต.ค. 04:04 UTC แต่ยังไม่มีคำตอบ) และ Anthropic ยังไม่ได้ออกมาแสดงความเห็น — ประเด็นจริงคือ gateway ที่ log request/response เต็ม ๆ คือที่รวม secret ชั้นดี ไม่ว่า secret จะมาจาก agent ตัวไหน

ล่าสุด (02:19 UTC วันที่ 22 ต.ค.) LiteLLM บอกว่ากำลังหมุน token ทุกตัวในองค์กร registry ถูกล็อกไม่ให้ release ใหม่ และ release ปกติหยุดไว้ก่อน นอกจากนี้หน้า incident ยังเผยว่ามี release แบบ embargo ให้ลูกค้า enterprise แก้ช่องโหว่ที่จะเปิดเผยวันที่ 27 ต.ค. ด้วย

ถ้าเคยติดตั้ง ต้องทำอะไร

ขั้นตอนจาก LiteLLM (เครดิต LidorMachluf ผู้ช่วยตรวจพบ):

• อย่าเริ่มด้วย pip install — การเปิด Python ทุกครั้งใน environment นั้นจะรันมัลแวร์ซ้ำ
• จาก shell ลบ cook.pth, cook.py, sitecustomize.py และ __pycache__/cook*.pyc, sitecustomize*.pyc ในทุก site-packages ที่โดน, kill daemon ที่ถือ /tmp/remote_code_loader.lock
• ติดตั้งใหม่แบบ pin litellm==1.106.2 — ดีที่สุดคือสร้าง venv/image ใหม่จากศูนย์
• ถ้าเครื่องต่ออินเทอร์เน็ตได้ ให้ถือว่าข้อมูลหลุดไปแล้ว และหมุนทุกอย่างที่เครื่องนั้นเข้าถึงได้: IAM role ของ instance/task, provider key ทุกตัวใน proxy DB, master/virtual key, รหัสผ่านใน DATABASE_URL และ secret ใน environment ของทุก process
• ตรวจ CloudTrail หา GetCallerIdentity ช่วงเวลาติดตั้ง และการใช้ credential ของ role จากนอกโครงสร้างของคุณ — Wiz พบผู้โจมตีตรวจ credential ด้วยคำสั่งนี้ แล้วนำไปเรียก Amazon Bedrock และ list model ซึ่งเป็นรูปแบบ LLMjacking (ขโมยโควต้าโมเดล) และบางที่มีการไล่สำรวจ IAM ต่อ

มุมมอง AI Curator

เหตุการณ์นี้เป็นบทเรียนที่ชัดว่า AI gateway คือเป้าหมายมูลค่าสูงสุดในสแต็ก AI เพราะมันรวม API key ของทุก provider, เห็น prompt/response ทั้งหมด และมักรันใน CI หรือ Kubernetes ที่มี cloud role ติดอยู่ มัลแวร์ตัวนี้ถูกเขียนมาเพื่อสแต็กนี้โดยเฉพาะ — ไล่เก็บ token ของ Claude, Codex, Cursor และ dump ตาราง credential ของ LiteLLM โดยตรง ไม่ใช่ stealer ทั่วไปที่บังเอิญติดมา

อีกเรื่องที่ควรคิดต่อคือ hardening ทุกอย่างที่ LiteLLM ทำหลัง มี.ค. ไม่ได้ผิด แต่ถูกข้ามด้วยของสองอย่าง: token ของ org owner ที่มีอำนาจปิด branch protection ได้ และ “การขยายสิทธิ์ชั่วคราว” ที่เกิดก่อนการโจมตีหนึ่งวัน Trusted Publishing รับประกันได้แค่ว่า artifact มาจาก workflow ของคุณ ไม่ได้รับประกันว่า workflow นั้นยังเป็นของคุณ ทีมที่ใช้ GitHub Actions ควรแยกบัญชี owner ออกจากบัญชีทำงานประจำวัน, บังคับ branch protection กับ admin ด้วย และเฝ้าดู event การแก้ ruleset

สำหรับทีมไทยที่ใช้ LiteLLM เป็น proxy กลางให้ทั้งองค์กร (ซึ่งพบบ่อยมากในบริษัทที่เริ่มใช้หลายโมเดล) สิ่งที่ควรทำวันนี้คือ pin เวอร์ชันและ digest ของ image — การรัน latest ใน production คือสาเหตุที่หลายคนโดนในหน้าต่างเพียง 2 ชั่วโมง และควรทบทวนว่า gateway ของคุณ log response body เต็ม ๆ หรือไม่ เพราะ agent สมัยนี้ทำงานกับ shell และ token จริง สิ่งที่ไหลผ่าน gateway อาจมี secret ที่คุณไม่ได้ตั้งใจส่งไปเลย

แหล่งข่าว

• LiteLLM — Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised (incident report)
• GitHub — BerriAI/litellm issue #47826 (วิเคราะห์ payload, IOC, status update)
• SafeDep — Compromised LiteLLM 1.107.0 on PyPI Installs a Credential Stealer and Backdoor
• Wiz — LiteLLM compromised, steals credentials (รวม post-exploitation activity)