LiteLLM 1.107.0 บน PyPI และ Docker ถูกวางยา — ผู้โจมตีใช้โทเคน GitHub ของวิศวกร 3 คนปล่อยรุ่นฝังมัลแวร์ขโมยข้อมูลรับรองและแบ็กดอร์

สรุปสั้น

แพ็กเกจ Python ชื่อ LiteLLM ซึ่งเป็นเกตเวย์ยอดนิยมสำหรับเรียกใช้โมเดลภาษาขนาดใหญ่หลายผู้ให้บริการผ่านอินเทอร์เฟซเดียว ถูกวางยาอีกครั้งในการโจมตีซัพพลายเชน โดยเวอร์ชัน 1.107.0 ที่เผยแพร่ทั้งเป็นไฟล์ wheel บน PyPI และเป็นอิมเมจ Docker ฝังมัลแวร์ 2 ส่วน คือตัวขโมยข้อมูลรับรองที่เรียกตัวเองว่า privcollect และแบ็กดอร์ที่ตรวจ dead drop บน GitHub ทุกชั่วโมงแล้วรันโค้ด Python ที่ผู้โจมตีส่งมา ปัจจุบัน PyPI กักแพ็กเกจรุ่นนี้ไว้แล้ว และอิมเมจ Docker ที่เป็นอันตรายถูกถอดออกแล้ว รายงานมาจากบริษัท SafeDep, Socket, StepSecurity และ Upwind

นาย Oliver Jensen ผู้อำนวยการฝ่ายความปลอดภัยของ LiteLLM ระบุว่าการกระทำที่เป็นอันตรายเกิดผ่านบัญชี GitHub ของวิศวกร 3 คน ซึ่งดูเหมือนใช้โทเคน OAuth ของ GitHub CLI ที่ถูกขโมยไป ผู้โจมตีใช้บัญชีหนึ่งสั่งรันขั้นตอนปล่อยรุ่น แล้วใช้อีกบัญชีอนุมัติเอง ทำให้ข้ามการอนุมัติสองคนได้ทั้งที่มีอยู่ ทีมยังไม่รู้ว่าผู้โจมตีได้โทเคนมาอย่างไร จึงยืนยันไม่ได้ว่าไม่มีการเข้าถึงบัญชีเหล่านี้อีก ที่น่ากังวลคือมัลแวร์ทำงานทันทีที่ Python เริ่มทำงานผ่านไฟล์ .pth แม้โปรแกรมไม่ได้ import LiteLLM เลย ซึ่งเป็นเทคนิคเดียวกับที่พบตอน LiteLLM ถูกเจาะในแคมเปญ TeamPCP เมื่อเดือนมีนาคม 2569 (ดูโพสต์ 08/155) ผู้ที่ติดตั้งรุ่นนี้ต้องถือว่าข้อมูลรับรองทั้งหมดบนเครื่องรั่วแล้ว

รายละเอียดข่าว

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 21 ตุลาคม 2569 ว่า LiteLLM เวอร์ชัน 1.107.0 ถูกวางยาในการโจมตีซัพพลายเชนที่ส่งมัลแวร์ขโมยข้อมูลรับรองและแบ็กดอร์ไปยังผู้ใช้ ตามรายงานของ SafeDep, Socket, StepSecurity และ Upwind รุ่นที่ได้รับผลกระทบเผยแพร่ทั้งผ่านไฟล์ wheel บน PyPI และอิมเมจ Docker โดย PyPI กักแพ็กเกจไว้แล้ว ส่วนอิมเมจ Docker ที่เป็นอันตรายถูกลบออกแล้ว

นาย Oliver Jensen ระบุว่าการสืบสวนยังดำเนินอยู่ และทีมยังไล่หาช่องทางแรกที่ผู้โจมตีใช้เผยแพร่รุ่นอันตราย “เราพบว่าการกระทำที่เป็นอันตรายเกิดขึ้นผ่านบัญชี GitHub ของวิศวกร 3 คน ซึ่งดูเหมือนเป็นการใช้โทเคน OAuth ของ GitHub CLI ที่ถูกขโมย ผู้ก่อภัยใช้บัญชีของผู้ใช้คนหนึ่งสั่งรัน project-releaser และใช้บัญชีของอีกคนอนุมัติ โทเคนทั้งหมดที่เกี่ยวข้องถูกเพิกถอนแล้ว”

เขากล่าวต่อว่า “เรายังไม่พบกลไกที่ผู้ก่อภัยใช้ได้มาซึ่งโทเคนเหล่านั้น จึงยังยืนยันไม่ได้ว่าไม่มีการเข้าถึงบัญชี GitHub เหล่านี้เพิ่มเติม” ในระหว่างนี้ LiteLLM จึงถอดผู้ใช้ทุกคนออกจาก GitHub organization เหลือไว้เพียงคนเดียวที่ไม่ได้รับผลกระทบ และแก้ไขข้อมูลบน registry สาธารณะให้ไม่มีลิงก์ที่เชื่อถือ (trusted link) ไปยัง GitHub organization ของตน เพื่อกันการเผยแพร่แพ็กเกจอันตรายเพิ่ม

ไฟล์ที่ได้รับผลกระทบมี wheel 7 ไฟล์ ครอบคลุม macOS (x86_64 และ arm64), Linux แบบ manylinux และ musllinux (aarch64 และ x86_64) และ Windows (amd64) ส่วนไฟล์ซอร์ส litellm-1.107.0.tar.gz ไม่มีไฟล์ payload แต่มี pyproject.toml ที่ถูกดัดแปลง ข้อจำกัดของข้อมูลที่ควรทราบคือต้นฉบับยังไม่ระบุช่วงเวลาที่รุ่นอันตรายเปิดให้ดาวน์โหลด จำนวนผู้ดาวน์โหลด หรือ tag ของอิมเมจ Docker ที่ได้รับผลกระทบ และยังไม่มีการระบุตัวผู้ก่อเหตุ แม้เทคนิคจะซ้ำกับเหตุการณ์ในเดือนมีนาคม

อัปเดต 23 ต.ค. 2569: โทเคนรั่วจากล็อกของ AI gateway และข้อมูลรับรองที่ขโมยไปถูกใช้ทำ LLMjacking

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 22 ตุลาคม 2569 อ้างประกาศเหตุของ LiteLLM ว่าผู้โจมตีผ่าน “การควบคุมความปลอดภัยที่เป็นอิสระต่อกันหลายชั้น” เพื่อปล่อยรุ่นอันตราย ไปป์ไลน์ปล่อยรุ่นถูกยึดราว 04:00 น. ตามเวลา PST ของวันที่ 21 ตุลาคม 2569 รุ่นที่ถูกวางยาคือ v1.107.0 บน PyPI และ tag v1.107.0, latest, main-latest และ main-stable ทั้งบน Docker Hub และ GHCR ผู้ได้รับผลกระทบคือผู้ที่ติดตั้งผ่าน pip โดยไม่ยึดเวอร์ชันระหว่าง 11:39–13:23 UTC หรือใช้อิมเมจ Docker tag ดังกล่าวระหว่าง 11:46–14:20 UTC

หลังเหตุเมื่อเดือนมีนาคม LiteLLM ได้ย้ายการปล่อยรุ่นไปไว้ใน repository ส่วนตัว ทำให้ tag ของ Docker แก้ไขไม่ได้ และลงนามอิมเมจแล้ว แต่ลำดับเหตุการณ์ครั้งนี้คือ วันที่ 19 ตุลาคม ทีมขยายสิทธิ์ปล่อยรุ่นชั่วคราวให้วิศวกรภายใน 2 คนเพื่อปล่อยแพตช์ backport รายวันให้ลูกค้า ผู้โจมตีถือข้อมูลรับรอง GitHub CLI ของนักพัฒนา 3 ชุด หนึ่งในนั้นรัน GitHub workflow ได้ จากนั้นใช้โทเคนของเจ้าของ GitHub organization คนหนึ่งปิด branch protection และ force-push โค้ดอันตราย แล้วรัน workflow ที่ถูกแก้ให้ชี้ไปยัง repository ปลอมชื่อ Berri-AI/litellm แทน BerriAI/litellm ทำให้ artifact อันตรายถูกลงนามและเผยแพร่ตามปกติ

ต้นตอที่ LiteLLM สงสัยคือล็อกของตัวเอง ทีมระบุว่า “พบสถานการณ์เฉพาะที่ Claude Code จะฝังโทเคน OAuth ของ GitHub CLI ของผู้ใช้ลงใน response body และในกรณีที่ response body ถูกบันทึกล็อก โทเคนเหล่านี้อาจปรากฏในล็อกของ LiteLLM” ทีมยังพบ “บัญชีผู้ใช้ที่ไม่คาดคิดและตั้งชื่อให้ดูไม่มีพิษภัย” ในระบบ LiteLLM ภายในที่เปิดสู่อินเทอร์เน็ต จึงสันนิษฐานว่าผู้โจมตีเข้าระบบนี้ได้ ดึงโทเคน GitHub CLI จากล็อก แล้วใช้ยึด workflow ปล่อยรุ่น ยังไม่ชัดว่าระบบนี้เปิดสู่สาธารณะได้อย่างไรและผู้โจมตีเข้าไปได้อย่างไร LiteLLM คาดว่าน่าจะผ่านช่องโหว่ที่เพิ่งแพตช์ไปไม่นาน

ด้านมัลแวร์ บริษัท Aikido และ Wiz ระบุว่านอกจาก cook.pth แล้ว ตัวแปลภาษายังพยายามรัน sitecustomize.py ซึ่งทำงานเฉพาะบน Linux และ macOS โดยแยกดีมอนเบื้องหลังที่ล็อกไฟล์ /tmp/remote_code_loader.lock กันการรันซ้ำ แล้ววนดึงโดเมนสั่งการจาก raw[.]githubusercontent[.]com/letters9813/pythonclient-test/main/domain[.]txt ทุกชั่วโมง Wiz ระบุว่าไฟล์นี้มีเพียงค่าทดสอบก่อน GitHub ถอดออกราว 13:30 UTC และการใช้ทั้งไฟล์ .pth กับ sitecustomize.py พร้อมกัน “ดูเป็นกรณีแรกที่มีการบันทึกว่าพบในการโจมตีจริง”

Wiz ยังพบการนำข้อมูลรับรองที่ขโมยไปใช้จริงราว 4.5 ชั่วโมงหลังส่งออก ผู้โจมตีตรวจข้อมูลรับรอง AWS instance role ที่ได้จาก CI runner และ Kubernetes node ที่ติดมัลแวร์ จาก IP 168.100.8[.]57 และ 165.227.201[.]8 ระหว่าง 16:20–17:01 UTC โดยเรียก sts:GetCallerIdentity ตามด้วย bedrock:ListFoundationModels และ ListModels ซึ่ง Wiz ระบุว่าสอดคล้องกับ LLMjacking หรือการยึดสิทธิ์ใช้โมเดล AI บนคลาวด์ของเหยื่อ ในบาง environment ผู้โจมตียังไล่ดู IAM (ListRoles, ListUsers, ListAccessKeys) และสำรวจทั่วไป เช่น ListAccounts และ DescribeTrails

เรื่องผู้ก่อเหตุ แม้การใช้ไฟล์ .pth จะเหมือนการโจมตีของกลุ่ม TeamPCP เมื่อเดือนมีนาคม แต่บริษัท Socket ระบุว่าหลักฐานสาธารณะยังไม่เชื่อมโยงสองเหตุการณ์ เพราะกุญแจ RSA สาธารณะที่ฝังไว้ วิธีส่งข้อมูลออก และพฤติกรรมแบ็กดอร์ต่างกัน แม้จะไม่ตัดความเป็นไปได้ว่าเป็นผู้ก่อเหตุเดิมที่ใช้เครื่องมือต่างไป และยังไม่ยืนยันว่าข้อมูลรับรองที่ถูกขโมยเมื่อเดือนมีนาคมมีส่วนหรือไม่

อัปเดต 24 ต.ค. 2569: ต้นตอที่แท้จริงคือ master key ที่หลุดขึ้น GitHub สาธารณะตั้งแต่พฤษภาคม ไม่ใช่ล็อกของ AI gateway

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 24 ตุลาคม 2569 อ้างผลสอบสวนล่าสุดของ LiteLLM ว่าสมมติฐานเรื่องโทเคนรั่วจากล็อกของระบบ LiteLLM ภายใน (หัวข้ออัปเดต 23 ต.ค. ด้านบน) ถูกตัดทิ้งแล้ว นาย Oliver Jensen ยอมรับว่า “การสืบสวนเป็นกระบวนการที่เราได้ข้อมูลใหม่ต่อเนื่อง สมมติฐานบางข้อจึงพิสูจน์ภายหลังว่าไม่ถูกต้องหรือไม่ครบถ้วน” ต้นตอจริงคือเมื่อวันที่ 27 พฤษภาคม 2569 ไฟล์คอนฟิกที่ถูก commit ขึ้น repository สาธารณะ LiteLLM-Labs/lite-harness มี master key ของ LiteLLM Agent Platform ซึ่งเป็นเครื่องมือโอเพนซอร์สที่ทีมใช้จัดการเอเจนต์ติดไปด้วย ทีมพบความผิดพลาดเร็ว force-push ทับ commit และระบุว่าต้องเพิกถอนคีย์ที่หลุด แต่ master key ตัวนี้ไม่ได้ถูกเพิกถอนจริง

วันที่ 10 ตุลาคม 2569 ผู้โจมตีจาก IP 69.48.229[.]143 ใช้ master key ที่ยังใช้งานได้เข้า Agent Platform แล้วดึงโทเคน OAuth ของ GitHub CLI ที่ตั้งไว้ให้เอเจนต์บนคลาวด์ส่ง pull request ได้ออกมา โทเคนนี้ “ไม่ได้จำกัดขอบเขต” และผูกกับบัญชีเจ้าของ GitHub organization ผู้โจมตีจึงได้สิทธิ์ระดับเจ้าของในทุก repository ขององค์กร ลำดับเหตุการณ์หลังจากนั้นมีดังนี้

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

บริษัท Socket กู้ commit อันตราย 2 ตัวได้ ทั้งคู่เพิ่มไฟล์ .github/workflows/cache.yml ด้วยข้อความ commit เดียวกันว่า “ci: bump cache config” ผู้โจมตีสร้าง branch ชื่อ ci-tmp-<hex> (ci-tmp-a351cc และ ci-tmp-4d8517) แตกจาก commit ที่ถูกต้องล่าสุด push workflow ที่ตั้ง on: [push] ให้รันทันที แล้วลบ branch ทิ้งภายในไม่กี่นาที ประวัติปกติของ repository จึงแทบไม่เหลือร่องรอย workflow รอบแรกเก็บโทเคน GitHub, คีย์ของ Linear, LiteLLM deployment, Together AI และ ID กับ signing key ของ GitHub App ส่วนรอบ 12 ตุลาคมขยายไปถึงคีย์ API ของ Anthropic, OpenAI, AWS Bedrock, Tavily, คีย์ของ GitGuardian ซึ่งเป็นระบบสแกนความลับเอง, Playwright storage state ที่เปิดทางเข้า Linear ได้โดยไม่ต้องใช้รหัสผ่านหรือ MFA, ข้อมูลเชื่อมต่อ PostgreSQL และรหัสผ่าน Redis ส่วนโดเมน litellm[.]dev ที่ใช้ส่งข้อมูลออกถูกจดเมื่อวันที่ 13 ตุลาคม 2569 ซึ่งเป็นวันหลังจากขโมยความลับรอบที่สอง

ด้านมัลแวร์ ทีม Microsoft Security Research ยืนยันว่าไฟล์ startup อยู่นอกไดเรกทอรีของแอป LiteLLM การลบเฉพาะไฟล์ของแอปจึงอาจทิ้งส่วนประกอบอันตรายไว้ และตัวขโมยข้อมูลยังเก็บโทเคนของ npm, PyPI, pip, Yarn, Maven, Gradle, Composer, RubyGems และ Cargo รวมถึงข้อมูลรับรอง Git และ GitLab ด้วย

วิธีการโจมตี

มัลแวร์ถูกปลุกให้ทำงานก่อนที่ LiteLLM จะถูก import ผ่านไฟล์ path configuration ชื่อ cook.pth ซึ่ง Python จะประมวลผลอัตโนมัติทุกครั้งที่ตัวแปลภาษาเริ่มทำงาน ไฟล์นี้มีเพียงบรรทัดเดียวคือ import cook ซึ่งเรียกโมดูลตัวเก็บข้อมูลรับรองขึ้นมา ผลคือแค่ติดตั้งแพ็กเกจไว้ใน environment แล้วรัน Python ด้วยเหตุผลใดก็ตาม มัลแวร์ก็ทำงานแล้ว เทคนิคเดียวกันนี้เคยพบเมื่อ LiteLLM ถูกเจาะในแคมเปญซัพพลายเชนของกลุ่ม TeamPCP เมื่อเดือนมีนาคม 2569

StepSecurity อธิบายว่า “payload แรกคือตัวขโมยข้อมูลรับรองที่เรียกตัวเองว่า privcollect ส่วน payload ที่สองแยกโปรเซสเป็นดีมอนเบื้องหลัง ตรวจ dead drop บน GitHub ทุกชั่วโมง และรันโค้ด Python อะไรก็ได้ที่ผู้โจมตีส่งมา” ตัวขโมยข้อมูลเก็บโทเคนคลาวด์ บัญชีนักพัฒนาและกุญแจส่วนตัว ไฟล์ JSON ข้อมูลรับรองของเครื่องมือพัฒนา AI ข้อมูลเบราว์เซอร์ตระกูล Chromium และ Firefox รวมถึงตัวแปรสภาพแวดล้อม (environment variables)

มัลแวร์ยังเล็งการติดตั้ง LiteLLM ที่ทำหน้าที่เป็น proxy โดยตรง เพื่อดึงข้อมูลรับรองที่ proxy บันทึกไว้และการตั้งค่าโมเดลออกมา ซึ่งหมายถึงคีย์ API ของผู้ให้บริการโมเดลทุกรายที่องค์กรรวมไว้ในเกตเวย์ ข้อมูลที่เก็บได้ถูกบีบอัดเป็นไฟล์ TAR แบบ GZIP แล้วส่งออกด้วย HTTP POST ไปที่ litellm[.]dev/healthcheck ซึ่งตั้งชื่อให้ดูคล้ายโดเมนของโครงการเพื่อกลบเกลื่อน

ส่วนแบ็กดอร์จะอ่านไฟล์ domain.txt ใน repository บน GitHub ของบัญชี letters9813 ถ้าไฟล์มีชื่อโดเมนอยู่ จะรันตัวขโมยข้อมูลซ้ำ แล้วส่งคำขอ HTTP GET ไปที่ <domain>/codepy และรันสิ่งที่ได้กลับมาเป็นโค้ด Python ทำให้ผู้โจมตีเปลี่ยนเซิร์ฟเวอร์สั่งการได้ตลอดโดยไม่ต้องแก้มัลแวร์ ปัจจุบัน repository ดังกล่าวตอบกลับเป็น 404 แล้ว แต่ดีมอนที่ติดตั้งไปแล้วยังรออยู่บนเครื่องเหยื่อ

ผลกระทบ

LiteLLM ตั้งอยู่ตรงจุดที่คีย์ของผู้ให้บริการโมเดลทั้งหมดขององค์กรถูกรวมไว้ด้วยกัน การวางยาแพ็กเกจนี้จึงให้ผลตอบแทนสูงกว่าไลบรารีทั่วไป ทั้งคีย์ API ของผู้ให้บริการ AI ข้อมูลรับรองคลาวด์ และกุญแจ SSH ของนักพัฒนาและเครื่อง CI/CD ที่ดึงรุ่นล่าสุดมาโดยอัตโนมัติ โดยเฉพาะสภาพแวดล้อมที่ไม่ยึดเวอร์ชันหรือใช้อิมเมจ Docker tag แบบลอย ซึ่งจะได้รุ่นอันตรายไปทันทีที่ปล่อยออกมา

เหตุการณ์นี้ยังชี้ว่ากลไกอนุมัติแบบสองคนไม่ช่วยถ้าผู้โจมตีถือโทเคนของทั้งสองคน และเป็นครั้งที่สองในปีนี้ที่ LiteLLM ถูกใช้เป็นช่องทางกระจายมัลแวร์ ก่อนหน้านี้เว็บไซต์นี้รายงานการเจาะในเดือนมีนาคมผ่าน Trivy ที่ไม่ได้ยึดเวอร์ชันไว้ในไปป์ไลน์บิลด์ (โพสต์ 08/155) และช่องโหว่ของ LiteLLM ในโพสต์ 05/018 และ 06/111 การที่ทีมยังไม่รู้ว่าโทเคนรั่วจากที่ใดหมายความว่าความเสี่ยงที่จะถูกวางยาซ้ำยังไม่หมดไป (อัปเดต 24 ต.ค. 2569: ต้นตอยืนยันแล้วว่าเป็น master key ที่หลุดขึ้น GitHub ตั้งแต่พฤษภาคมแต่ไม่ถูกเพิกถอน ผู้โจมตีแฝงอยู่ 11 วันก่อนปล่อยรุ่นอันตราย บทเรียนหลักคือการลบคีย์ออกจาก Git ไม่เท่ากับการเพิกถอน และโทเคนที่ให้เอเจนต์ AI ใช้ต้องจำกัดขอบเขต)

คำแนะนำ

• อัปเดต 24 ต.ค. 2569: ไล่สแกนประวัติ commit (รวม commit ที่ถูก force-push ทับ) ของ repository สาธารณะหาคีย์ที่เคยหลุด และยืนยันว่าเพิกถอนแล้วจริงที่ระบบปลายทาง ไม่ใช่แค่ลบออกจาก Git · จำกัดขอบเขตโทเคนที่ให้เอเจนต์ AI ใช้ และอย่าผูกกับบัญชีเจ้าของ organization · แจ้งเตือนเมื่อมี workflow ใหม่ที่ตั้ง on: [push] ใน branch ชั่วคราว หรือมีการส่งข้อมูลไปยัง webhook[.]site
• ตรวจทุก environment, requirements/lock file และอิมเมจคอนเทนเนอร์ว่ามี litellm==1.107.0 หรือไม่ รวมถึงอิมเมจ Docker ที่ดึงมาในช่วงที่รุ่นนี้เผยแพร่
• ค้นหาไฟล์ cook.pth และโมดูล cook ในไดเรกทอรี site-packages ของทุก environment และตรวจหาโปรเซส Python เบื้องหลังที่ติดต่อ GitHub เป็นระยะ
• ถ้าพบ ให้ถือว่าเครื่องถูกยึด ล้างหรือสร้าง environment ใหม่ แล้ว เพิกถอนและออกข้อมูลรับรองใหม่จากเครื่องที่สะอาด ทั้งคีย์คลาวด์ กุญแจ SSH โทเคน GitHub/PyPI คีย์ API ของผู้ให้บริการ LLM และคีย์ที่ตั้งไว้ใน LiteLLM proxy
• ยึดเวอร์ชันไว้ที่ 1.106.2 โดยอ้างอิง digest/hash (เช่น pip install --require-hashes หรือ pin อิมเมจด้วย @sha256:) จนกว่า LiteLLM จะประกาศรุ่นที่ตรวจสอบแล้ว
• บล็อกและล่าย้อนหลังการเชื่อมต่อไปยัง litellm[.]dev ในล็อกพร็อกซี/DNS
• ค้นหาไฟล์ sitecustomize.py ที่ไม่รู้ที่มา ไฟล์ล็อก /tmp/remote_code_loader.lock และการเรียก /codepy บนเครื่อง Linux/macOS
• ตรวจ AWS CloudTrail หาการเรียก sts:GetCallerIdentity, bedrock:ListFoundationModels และการไล่ดู IAM จาก IP ในตาราง IoCs หรือจาก role ของ CI runner/Kubernetes node ที่เคยติดตั้งรุ่นนี้
• องค์กรที่รัน AI gateway เอง: ตรวจว่าล็อก request/response มีโทเคนหรือข้อมูลรับรองติดอยู่หรือไม่ ปิดหรือ redact การบันทึก response body และอย่าเปิดหน้าจัดการของ gateway สู่อินเทอร์เน็ต
• สำหรับองค์กรที่ดูแลโครงการโอเพนซอร์สเอง: กำหนดอายุและขอบเขตของโทเคน OAuth ของ GitHub CLI ให้สั้น ใช้ trusted publishing ที่ผูกกับ workflow เฉพาะ และแยกผู้อนุมัติการปล่อยรุ่นด้วยการยืนยันตัวตนที่ขโมยด้วยโทเคนอย่างเดียวไม่ได้

Indicators of Compromise (IoCs)

หมายเหตุ: indicator ด้านล่าง defang แล้ว

แหล่งอ้างอิง

• LiteLLM — Security Incident October 21, 2026: Attack Chain
• Socket — LiteLLM attack timeline
• Microsoft Security — Inside the LiteLLM 1.107.0 supply chain compromise
• The Hacker News — Leaked LiteLLM Master Key Let Attackers Steal GitHub Tokens and Hijack Release Pipeline
• LiteLLM — Security Incident October 21, 2026
• Wiz — LiteLLM compromised, steals credentials
• Aikido — LiteLLM compromised: infostealer and RAT
• The Hacker News — LiteLLM Suspects GitHub Token Leak in AI Gateway Logs Behind Malicious Package Release
• LiteLLM Compromised in Supply Chain Attack Delivering Credential Stealer and Backdoor — The Hacker News
• litellm 1.107.0 compromised: PyPI backdoored wheels, credential stealer — StepSecurity
• LiteLLM PyPI compromise: credential stealer and backdoor — SafeDep
• LiteLLM compromise — Socket
• BerriAI/litellm issue #47826 — GitHub