Railway และ LiteLLM ถูกเจาะ คือเหตุความปลอดภัย 2 เหตุที่เกิดเมื่อ 21 ตุลาคม 2569 (ค.ศ. 2026) Railway แพลตฟอร์มที่มีผู้ใช้ราว 4.8 ล้านรายแจ้งว่าระบบเก็บ environment variables ของลูกค้าถูกเข้าถึง ส่วน LiteLLM ถูกปล่อยเวอร์ชัน 1.107.0 ที่ฝังมัลแวร์ขโมยคีย์ บทความนี้เหมาะกับทีม dev สตาร์ทอัพ และ DPO ไทยที่ต้องตัดสินใจว่าจะหมุน key และแจ้งเหตุอย่างไร
ลองนึกภาพสตาร์ทอัพฟินเทค 15 คน (ตัวอย่างสมมติ) ที่ deploy แอปบน Railway และใช้ LiteLLM รวมคีย์ AI ในไฟล์ .env มีรหัสผ่านฐานข้อมูลลูกค้า 80,000 ราย ถ้าคีย์ชุดนั้นหลุด คนนอกก็ไม่ต้องเจาะฐานข้อมูลเลย แค่ใช้กุญแจที่ได้มาเปิดเข้าไป
สรุปสั้น: เมื่อ 21 ตุลาคม 2569 Railway แจ้งว่า environment variables ของลูกค้าอาจถูกเข้าถึง บางส่วนเป็นค่าที่ถอดรหัสแล้ว และ LiteLLM เวอร์ชัน 1.107.0 บน PyPI และ Docker ถูกฝังมัลแวร์ขโมยคีย์คลาวด์และคีย์ AI ทีมที่เกี่ยวข้องต้องหมุนทุก secret จากเครื่องที่สะอาด ล็อก LiteLLM ไว้ที่ 1.106.2 และประเมินว่าต้องแจ้ง สคส. ภายใน 72 ชั่วโมงตาม PDPA มาตรา 37(4) หรือไม่
Railway และ LiteLLM ถูกเจาะ คืออะไร เกิดอะไรขึ้น
Railway และ LiteLLM ถูกเจาะ เป็นสองเหตุแยกกันที่เกิดในวันเดียวกัน ข่าวที่มีไม่ได้ระบุว่าทั้งสองเหตุเชื่อมโยงกัน จุดร่วมคือทั้งคู่ทำให้ “กุญแจ” ของนักพัฒนา เช่น API key รหัสผ่านฐานข้อมูล และ credential คลาวด์ เสี่ยงตกไปอยู่ในมือคนนอก
ฝั่ง Railway ตรวจพบความผิดปกติในระบบที่เก็บ environment variables บุคคลภายนอกอาจเข้าถึงค่าที่เข้ารหัสไว้ และบางส่วนได้ค่าที่ถอดรหัสแล้ว Railway หยุดการ deploy ทั้งหมดชั่วคราว ให้ลูกค้าหมุนทุก secret รวมถึง credential ของ private registry และยังไม่เปิดเผยจำนวนบัญชีที่ได้รับผลกระทบ
ฝั่ง LiteLLM ถูกยึด release pipeline โดย build ถูกดึงจาก fork ชื่อเลียนแบบ Berri-AI/litellm LiteLLM ระบุว่าต้นเหตุคือ GitHub OAuth token ของวิศวกร 3 คนที่ถูกขโมย และเป็นครั้งที่ 2 ของปี 2569 (ครั้งก่อนเดือนมีนาคม) ยังไม่มีตัวเลขว่าเวอร์ชันอันตรายถูกดาวน์โหลดกี่ครั้ง
| ประเด็น | Railway | LiteLLM |
|---|---|---|
| วันที่ | 21 ต.ค. 2569 | 21 ต.ค. 2569 |
| ขนาด | ผู้ใช้ราว 4.8 ล้านราย บริการกว่า 16 ล้านรายการ | ยังไม่มีตัวเลขการดาวน์โหลดเวอร์ชันอันตราย |
| สิ่งที่หลุด/เสี่ยง | environment variables บางส่วนถอดรหัสแล้ว | คีย์คลาวด์ SSH key ไฟล์ .env คีย์ AI คุกกี้และรหัสผ่านในเบราว์เซอร์ |
| สิ่งที่ผู้ให้บริการแนะนำ | หมุนทุก secret รวม private registry | ถือว่าเครื่องที่ติดตั้ง 1.107.0 ถูกเจาะ ใช้ 1.106.2 |
LiteLLM เวอร์ชันอันตรายอยู่บนระบบช่วงไหน (เวลาไทย)
LiteLLM 1.107.0 อยู่บน PyPI ตั้งแต่ 11:39 UTC หรือ 18:39 น. เวลาไทยของ 21 ตุลาคม 2569 ทีมที่ติดตั้งหรือ build image ในช่วงนี้ควรถือว่าเสี่ยง (เวลาไทย = UTC+7)
- 18:39 น. — LiteLLM 1.107.0 ขึ้น PyPI
- ราว 20:20–20:23 น. — PyPI กักกันเวอร์ชันอันตราย
- ราว 21:20 น. — image บน Docker Hub และ GHCR ยังชี้ไปเวอร์ชันอันตรายถึงช่วงนี้
มัลแวร์ใช้ไฟล์ cook.pth, cook.py และ sitecustomize.py ที่ทำงานทุกครั้งที่ Python เริ่มรัน แม้โค้ดไม่ได้ import LiteLLM เลย เครื่องนักพัฒนาที่แค่ติดตั้งแพ็กเกจไว้จึงโดนได้
Railway และ LiteLLM ถูกเจาะ กระทบธุรกิจไทยอย่างไร
Railway และ LiteLLM ถูกเจาะ กระทบสตาร์ทอัพ software house และเอเจนซีไทยที่ deploy บน Railway หรือใช้ LiteLLM เป็น AI gateway โดยตรง ความเสี่ยงไม่ได้อยู่แค่ค่าใช้ API ที่ถูกขโมยใช้ แต่อยู่ที่คีย์ชุดเดียวกันมักเปิดทางเข้าฐานข้อมูลลูกค้าได้ (การวิเคราะห์ของผู้เขียน)
คีย์หลุดแต่ยังไม่เห็นข้อมูลลูกค้ารั่ว ต้องแจ้ง สคส. หรือไม่
คีย์หลุดอย่างเดียวยังไม่ใช่เหตุที่ต้องแจ้งเสมอไป แต่ผู้ควบคุมข้อมูลต้องประเมินทันทีว่ามีการเข้าถึงข้อมูลส่วนบุคคลหรือมีความเสี่ยงต่อเจ้าของข้อมูลหรือไม่ ถ้ามี ต้องแจ้ง สคส. ภายใน 72 ชั่วโมงนับแต่ทราบเหตุตาม PDPA มาตรา 37(4) ขั้นตอนช่วงแรกสรุปไว้ใน ข้อมูลรั่ว ต้องทำอะไรบ้างใน 72 ชั่วโมงแรก
ทีม dev และ software house ต้องรับผิดชอบอะไร
software house ที่ดูแลระบบให้ลูกค้ามักอยู่ในฐานะผู้ประมวลผลข้อมูล ซึ่งต้องมีมาตรการรักษาความปลอดภัยและแจ้งเหตุต่อผู้ควบคุมข้อมูลตาม PDPA มาตรา 40 ถ้าเครื่อง dev ติดมัลแวร์จาก LiteLLM แล้วคีย์ของลูกค้าหลุด ผู้รับจ้างต้องแจ้งลูกค้าเร็วพอให้ลูกค้านับ 72 ชั่วโมงทัน
ทำไม AI gateway เสี่ยงกว่าที่คิด
AI gateway คือตู้เซฟรวมกุญแจของทุกโมเดล มัลแวร์ใน LiteLLM จึงเล็งคีย์ผู้ให้บริการ AI ที่เก็บในฐานข้อมูล proxy และไฟล์ credential ของ Codex, Claude, Gemini และ Cursor ด้วย บทเรียนคล้ายกันเคยเกิดใน OpenCode ถูกเจาะ API key ของ OpenAI Anthropic Google รั่ว บางรายโดนเก็บเงินเกิน 1,000 ดอลลาร์ ทีม dev ไทยต้องหมุน key และเช็ก PDPA
เทียบกับกฎหมายไทย: Railway และ LiteLLM ถูกเจาะ ต่างจาก PDPA อย่างไร
กฎหมายไทยไม่ได้ดูว่าเหตุเกิดที่ผู้ให้บริการต่างประเทศ แต่ดูว่าข้อมูลส่วนบุคคลที่บริษัทไทยดูแลเสี่ยงหรือไม่ หน้าที่จึงตกกับผู้ควบคุมข้อมูลไทยเต็ม ๆ
| ประเด็น | สิ่งที่ผู้ให้บริการทำ (ตามข่าว) | กฎหมายไทย |
|---|---|---|
| ความปลอดภัยของ secret | Railway หยุด deploy และให้หมุนทุก secret | PDPA ม.37(1) มาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม |
| แจ้งเหตุ | เปิดเผยต่อสาธารณะ ยังไม่บอกจำนวนบัญชี | PDPA ม.37(4) แจ้ง สคส. ภายใน 72 ชม. ถ้ามีความเสี่ยงต่อเจ้าของข้อมูล |
| ผู้รับจ้าง/แพลตฟอร์ม | แนะนำลูกค้าให้จัดการเอง | PDPA ม.40 ผู้ประมวลผลต้องมีมาตรการและแจ้งเหตุต่อผู้ควบคุม |
| ใช้คีย์ที่ขโมยมาเข้าระบบ | มัลแวร์ขโมย credential | พ.ร.บ.คอมพิวเตอร์ ม.5 และ ม.7 เข้าถึงระบบและข้อมูลโดยมิชอบ |
| หน่วยงาน CII | ไม่ระบุ | ต้องรายงานเหตุตาม พ.ร.บ.การรักษาความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562 ด้วย |
ช่องว่างที่เห็นคือสัญญาจ้างพัฒนาและ DPA ส่วนใหญ่ไม่มีข้อเรื่อง pin version, SBOM หรือเวลาแจ้งเหตุ supply chain ที่ชัด เมื่อเกิดเหตุแบบ LiteLLM จึงไม่มีใครรู้ว่าใครต้องแจ้งใครภายในกี่ชั่วโมง
ถ้าไม่ทำอะไรเลย จะเสี่ยงอะไร
ถ้าไม่หมุนคีย์ คนนอกที่ถือ secret อยู่สามารถเข้าฐานข้อมูลและคลาวด์ได้เหมือนพนักงาน โดยไม่ต้องเจาะอะไรเพิ่ม และถ้าข้อมูลลูกค้ารั่ว บริษัทจะอธิบายต่อ สคส. ได้ยากว่ามีมาตรการเหมาะสม เพราะผู้ให้บริการแจ้งเตือนแล้วแต่ไม่ได้ทำตาม
ความเสี่ยงอีกด้านคือบิลค่า API ที่ถูกขโมยใช้ และเครื่อง dev ที่ยังติด RAT ซึ่งให้คนนอกกลับเข้ามาได้อีกแม้หมุนคีย์แล้ว
ทีม dev และสตาร์ทอัพไทยควรทำอะไรภายใน 72 ชั่วโมง
ทีมที่ใช้ Railway หรือ LiteLLM ควรทำ 5 ขั้นนี้ทันที เรียงตามลำดับ เพราะเหตุ Railway และ LiteLLM ถูกเจาะ ทำให้คีย์ที่ใช้อยู่ไม่ควรถือว่าปลอดภัยอีกต่อไป
- 1. หัวหน้าทีม dev ตรวจเวอร์ชันภายในชั่วโมงแรก ค้น lockfile และ image digest ว่ามี LiteLLM 1.107.0 หรือไม่ ถ้ามี ให้ถือว่าเครื่องนั้นถูกเจาะและแยกออกจากเครือข่าย
- 2. DevOps หมุนทุก secret จากเครื่องที่สะอาด ทั้ง API key รหัสผ่านฐานข้อมูล credential คลาวด์ SSH key และ private registry อย่าหมุนจากเครื่องที่อาจติดมัลแวร์
- 3. ล็อกเวอร์ชันทันที pin LiteLLM ไว้ที่ 1.106.2 และตั้งให้ build ดึงด้วย digest แทน tag อย่าง latest
- 4. ทีมความปลอดภัยไล่ log ย้อนถึง 21 ตุลาคม 2569 ดูการเข้าถึงคลาวด์และฐานข้อมูลจาก IP แปลก และการเรียก API ที่ผิดปกติ
- 5. DPO ประเมินและตัดสินเรื่องแจ้ง สคส. ภายใน 72 ชั่วโมงนับแต่ทราบเหตุ บันทึกเหตุผลไว้แม้ตัดสินใจไม่แจ้ง และถ้าเป็นผู้รับจ้าง ให้แจ้งลูกค้าก่อน
หลังเคลียร์เหตุแล้ว ตรวจหน้าเว็บที่เปิดสู่สาธารณะด้วย เครื่องมือสแกนความเสี่ยงเว็บไซต์ของ Kooru และทบทวนบทเรียนเรื่องคีย์ AI ใน AI API Key รั่ว: บทเรียนด่วนจากรายงาน Anthropic ที่ธุรกิจไทยต้องอ่าน ส่วนการนับ 72 ชั่วโมงเมื่อเหตุเกิดที่ผู้ให้บริการภายนอก มีตัวอย่างใน ConnectWise ถูกเจาะ 162 ผู้เช่า Microsoft 365 ถูกบุกรุก MFA ไม่ช่วย องค์กรไทยต้องตรวจแอปบุคคลที่สามและนับ 72 ชั่วโมงอย่างไร
มุมมองผู้เชี่ยวชาญ
ข้อสังเกตเชิงวิชาชีพของผมคือ หลายบริษัทยังคิดว่าความเสี่ยง PDPA เริ่มที่ฐานข้อมูล แต่เหตุนี้ชี้ว่ามันเริ่มที่ไฟล์ .env กุญแจที่หลุดก็คือประตูที่เปิดแล้ว ต่อให้ยังไม่มีใครเดินเข้าไป จุดที่องค์กรมักพลาดคือหมุนคีย์แล้วจบ แต่ไม่ไล่ log ช่วงที่คีย์อยู่ในมือคนนอก จึงตอบ สคส. ไม่ได้ว่ามีการเข้าถึงข้อมูลหรือไม่ สัญญาจ้างพัฒนาควรเขียนเรื่อง pin version และเวลาแจ้งเหตุ supply chain ไว้ตั้งแต่วันเซ็น
— Phuwara Krobtaku —
LL.M. (IP & IT) | M.S. (IT) | Thai Barrister & Attorney-at-Law
ประวัติผู้เขียน · นโยบายบรรณาธิการ
คำถามที่พบบ่อยเกี่ยวกับ Railway และ LiteLLM ถูกเจาะ
LiteLLM เวอร์ชันไหนอันตราย และควรใช้เวอร์ชันไหน
เวอร์ชันอันตรายคือ 1.107.0 ที่ปล่อยบน PyPI, Docker Hub และ GHCR เมื่อ 21 ตุลาคม 2569 LiteLLM แนะนำให้ใช้ 1.106.2 และถือว่าเครื่องที่ติดตั้ง 1.107.0 ถูกเจาะแล้ว
ไม่ได้ import LiteLLM ในโค้ด จะปลอดภัยไหม
ไม่ปลอดภัย มัลแวร์ใช้ไฟล์ที่ทำงานทุกครั้งที่ Python เริ่มรัน แม้ไม่ได้ import LiteLLM ถ้าเครื่องหรือ image มีแพ็กเกจเวอร์ชัน 1.107.0 อยู่ ก็ต้องถือว่าเสี่ยง
ใช้ Railway แต่ไม่ได้ใช้ LiteLLM ต้องทำอะไร
ต้องหมุนทุก secret ที่เก็บใน environment variables ของ Railway รวมถึง credential ของ private registry ตามที่ Railway แนะนำ เพราะ Railway ยังไม่เปิดเผยว่าบัญชีใดได้รับผลกระทบ
บริษัทไทยต้องแจ้ง สคส. เพราะเหตุ Railway และ LiteLLM หรือไม่
ขึ้นกับผลประเมิน ถ้าคีย์ที่หลุดเปิดทางเข้าข้อมูลส่วนบุคคลและมีความเสี่ยงต่อเจ้าของข้อมูล ต้องแจ้งภายใน 72 ชั่วโมงนับแต่ทราบเหตุตาม PDPA มาตรา 37(4) ถ้าไม่แจ้ง ควรบันทึกเหตุผลไว้
อ่านต่อ: ความรู้ที่เกี่ยวกับเรื่องนี้
- ผู้รับจ้างทำข้อมูลรั่ว ใครต้องแจ้งใคร ภายในกี่ชั่วโมง — software house หรือแพลตฟอร์มที่ทำคีย์ลูกค้าหลุด ต้องรู้ว่าหน้าที่แจ้งเหตุของผู้รับจ้างกับผู้ว่าจ้างต่างกันอย่างไร (aipdpa.com)
แหล่งอ้างอิง
- BleepingComputer — Railway warns devs to rotate secrets after potential breach — อ่านข่าวที่ BleepingComputer
- BleepingComputer — LiteLLM release pipeline hacked to distribute info-stealer malware — อ่านข่าวที่ BleepingComputer
- Railway Blog — (อ่านต้นฉบับ) — ประกาศด้านความปลอดภัยของ Railway
- Socket, LiteLLM Docs และ Datadog Security Labs (อ้างตามสรุปข่าว)
บทความนี้เป็นการสรุปข่าวและให้ข้อมูลทั่วไป ไม่ใช่คำแนะนำทางกฎหมาย หากต้องการคำปรึกษาเฉพาะกรณีของธุรกิจคุณ ควรปรึกษาผู้เชี่ยวชาญ
