Wiz: เกือบ 1 ใน 10 ของเกตเวย์ LiteLLM ที่เปิดเผยต่อสาธารณะยอมรับคีย์ผู้ดูแลระบบตัวอย่าง sk-1234

เมื่อวันที่ 9 กันยายน 2026 Wiz Research ได้เผยแพร่การศึกษเกี่ยวกับ LiteLLM ซึ่งเป็นเกตเวย์ AI แบบโอเพนซอร์สที่อยู่ระหว่างแอปพลิเคชันกับผู้ให้บริการโมเดลที่พวกเขาจ่ายเงินให้ และรายงานว่า 294 จาก 3,074 การติดตั้ง LiteLLM ที่เข้าถึงได้บนอินเทอร์เน็ตสาธารณะ — 9.6% เกือบหนึ่งในสิบ — ยอมรับ sk-1234 ซึ่งเป็นมาสเตอร์คีย์ตัวอย่างที่พิมพ์อยู่ในเอกสารการตั้งค่าของโครงการเอง หรือไม่ต้องการข้อมูลรับรองใด ๆ เลย สตริงดังกล่าวไม่ใช่คีย์ API ทั่วไป: ใน LiteLLM มันเป็นทั้งข้อมูลรับรองของผู้ดูแลระบบและสวิตช์ที่เปิดใช้การรับรองความถูกต้อง ดังนั้นใครก็ตามที่ส่งสตริงนี้มาสามารถอ่านคีย์ของผู้ให้บริการโมเดลทุกคีย์ที่จัดเก็บไว้บนเกตเวย์ ดูทุกพรอมต์และผลลัพธ์ที่สร้างขึ้นซึ่งผ่านเกตเวย์ และเข้าถึงเซิร์ฟเวอร์เครื่องมือทุกตัวที่เชื่อมต่อผ่าน Model Context Protocol ได้ ผู้ร่วมเขียนของ Wiz คือ Amitai Cohen และ Yaara Shriki ได้เชื่อมโยงการเข้าถึงนั้นกับการรันโค้ดระดับรูทและการขโมยข้อมูลรับรอง IAM ของคลาวด์บนโฮสต์ บันทึกนี้ตั้งอยู่บนรายงานของ Wiz คำแนะนำด้านความปลอดภัยของ LiteLLM เอง และรายการ Known Exploited Vulnerabilities ของ CISA ที่ตามมา และ คลังเหตุการณ์ AI เก็บบันทึกนี้ไว้พร้อมกับรายการข้างเคียง โดยแต่ละรายการมีแหล่งที่มา ระดับความรุนแรง และระดับความเชื่อมั่นของตนเอง

วันที่เผยแพร่เป็นวันที่เดียวที่บันทึกมีอยู่ และมันเป็นวันที่เผยแพร่ การสแกนที่อยู่เบื้องหลังพาดหัวข่าวนั้นดำเนินการในเดือนกุมภาพันธ์ 2026 ช่องโหว่โค้ดสองรายการที่ Wiz อธิบายได้รับการแก้ไขและเผยแพร่แล้วอย่างช้าที่สุดภายในกลางเดือนพฤษภาคม ในรีลีสที่บันทึกของโครงการเองระบุว่าออกในเดือนมีนาคมและพฤษภาคม หมายเลข CVE ถูกออกในเดือนกรกฎาคม และรายการในแคตตาล็อกปรากฏในเดือนกันยายน เกือบทุกอย่างในรายงานล้าสมัยไปแล้วเมื่อถึงเวลาที่มันถูกพิมพ์ ซึ่งเป็นส่วนสำคัญของสิ่งที่รายงานโต้แย้ง

ตัวเลข 9.6% มาจากการสแกนเพียงครั้งเดียว และ Wiz ระบุว่าการติดตามผลในเดือนสิงหาคมของบริษัทเองไม่สามารถนำมาเปรียบเทียบกับตัวเลขนี้ได้

การวัดนั้นง่าย และ Wiz ระบุวิธีการอย่างตรงไปตรงมา: พบพร็อกซี LiteLLM ที่เปิดสู่อินเทอร์เน็ตจำนวน 3,074 รายการผ่าน Shodan ในเดือนกุมภาพันธ์ 2026 โดยแต่ละรายการถูกทดสอบว่าจะยืนยันตัวตนด้วยคีย์ตัวอย่างที่ระบุในเอกสารหรือไม่ ในจำนวนนั้น 294 รายการยืนยันตัวตนสำเร็จ ภายในกลุ่มนี้ 191 รายการไม่ได้กำหนดค่า master key ไว้เลยและจะยอมรับสตริงใดก็ตามที่ส่งเข้ามา ส่วนที่เหลือยังคงมีค่าตัวอย่างจากคู่มือการตั้งค่าอยู่ ภาวะล้มเหลวทั้งสองแบบไม่จำเป็นต้องอาศัยบั๊กของซอฟต์แวร์ ทั้งสองแบบเพียงต้องใช้ที่อยู่ของเกตเวย์และค่าที่พิมพ์ไว้ใน README ของโปรเจกต์เอง

นี่คือผลสแกนจากผู้ขายรายเดียวเช่นกัน ตัวเลขของ Wiz ถูกนำไปกล่าวซ้ำโดย AI Safety Initiative ของ Cloud Security Alliance เมื่อวันที่ 10 กันยายน และโดย The Hacker News ในวันเดียวกัน แต่ทั้งสองแห่งกล่าวซ้ำโดยระบุแหล่งที่มา และไม่พบการทำซ้ำอย่างอิสระของตัวเลข 3,074 สำหรับบทความนี้ Wiz ได้ทำการสแกนครั้งที่สองในเดือนสิงหาคม 2026 และพบอินสแตนซ์มากกว่า 85,000 รายการ ซึ่งมากกว่าจำนวนในเดือนกุมภาพันธ์ราวยี่สิบเจ็ดเท่า บริษัทกล่าวว่าสิ่งเหล่านั้นส่วนใหญ่ดูเหมือนเป็นฮันนีพอตหรือการติดตั้งสำหรับทดสอบ และจำนวนสองครั้งนั้นไม่สามารถเปรียบเทียบกันได้ ปัจจุบันไม่มีตัวเลขการเปิดเผยข้อมูล และบทความใดที่อ้างตัวเลขดังกล่าวก็กำลังอ้างตัวเลขจากเดือนกุมภาพันธ์

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

มาสเตอร์คีย์เป็นทั้งข้อมูลรับรองของผู้ดูแลระบบและสวิตช์ที่เปิดใช้งานการยืนยันตัวตน

การออกแบบของ LiteLLM ทำให้ความลับเพียงตัวเดียวต้องทำหน้าที่สองอย่าง โดย master key ใช้ยืนยันตัวตนสำหรับคำขอของผู้ดูแลระบบ และการมีอยู่ของมันคือสิ่งที่ทำให้การยืนยันตัวตนทำงานได้เลย: หากไม่มี master key และไม่มีการกำหนดค่า JWT หรือ OAuth2 พร็อกซีจะทำงานแบบเปิดและยอมรับทุกคำขอ Wiz เข้าถึงโค้ดเบสด้วย Claude Code ของ Anthropic เพื่อมองหาฟีเจอร์ที่รับอินพุตที่ผู้ใช้ควบคุมและส่งต่อไปยังบริบทการประมวลผล และตัวจัดการการยืนยันตัวตนเป็นหนึ่งในสามพื้นผิวที่มันระบุ

ก่อน v1.82.0-stable ผลที่ตามมาของงานที่สองนั้นร้ายแรงกว่าการเป็นพร็อกซีแบบเปิดเสียอีก Wiz พบว่าเมื่อไม่ได้ตั้งมาสเตอร์คีย์ ตัวจัดการการยืนยันตัวตนได้กำหนดบทบาท PROXY_ADMIN ให้กับทุกคำขอที่เข้ามา ดังนั้นผู้เรียกที่ไม่ได้ยืนยันตัวตนจึงไม่เพียงแต่ถูกอนุญาตให้เข้าเท่านั้น แต่ยังถูกอนุญาตในฐานะผู้ดูแลระบบอีกด้วย พูลรีเควสต์ #22095 ซึ่งอ้างถึงในรายงาน ได้เปลี่ยนบทบาทเริ่มต้นเป็น INTERNAL_USER และเพิ่มการตรวจสอบสิทธิ์ผู้ดูแลระบบให้กับเอนด์พอยต์ guardrail

การเข้าถึงระดับผู้ดูแลระบบของเกตเวย์ไม่ใช่สิทธิ์ที่แคบเลย อินสแตนซ์นี้เก็บคีย์ API ของผู้ให้บริการทุกรายที่มันส่งต่อคำขอไป ซึ่งนั่นเองที่ทำให้มันเป็นเป้าหมายของ LLMjacking — การรันงานของโมเดลโดยเหยื่อเป็นคนจ่ายเงิน มันมองเห็นพรอมป์ต์และผลลัพธ์ที่ได้ มันเชื่อมต่อออกไปยังเซิร์ฟเวอร์เครื่องมือ MCP ซึ่งในการติดตั้งภายในองค์กรมีแนวโน้มที่จะรวมถึงระบบติดตามปัญหา แชท ฐานข้อมูล และไปป์ไลน์การดีพลอยด้วย

Wiz ยังได้สาธิตเส้นทางจากตำแหน่งผู้ดูแลระบบนั้นไปยังตัวตนบนคลาวด์ของโฮสต์ LiteLLM อนุญาตให้ผู้ดูแลระบบลงทะเบียนเส้นทางส่งผ่านไปยัง URL เป้าหมายใดก็ได้ โดยเป้าหมายไม่ถูกตรวจสอบกับช่วงที่อยู่ส่วนตัว localhost หรือที่อยู่เมทาดาทาของคลาวด์ การชี้เส้นทางไปยังบริการเมทาดาทาของอินสแตนซ์จะคืนข้อมูลรับรอง IAM ที่เวิร์กโหลดทำงานภายใต้ การเปลี่ยนบริการเมทาดาทาเป็น IMDSv2 ซึ่งโดยปกติจะป้องกันการปลอมแปลงคำขอประเภทนี้โดยกำหนดให้ต้องมีโทเค็นเซสชันที่ได้รับแยกต่างหาก ไม่ช่วยอะไร: LiteLLM จะส่งต่อเฮดเดอร์ใดก็ตามที่ขึ้นต้นด้วย x-pass- ไปยังเป้าหมายโดยตัดคำนำหน้าออก ดังนั้นเฮดเดอร์โทเค็นจึงสามารถถูกลักลอบส่งผ่านได้ Wiz กล่าวว่าฟีเจอร์นี้อาจถือได้ว่าทำงานตามที่ตั้งใจภายใต้แบบจำลองภัยคุกคามที่ไว้วางใจผู้ดูแลระบบ และดังนั้นจึงไม่มี CVE และไม่มีแพตช์แก้ไข

ย่อหน้าสุดท้ายนั้นเป็นการสาธิต ไม่ใช่การโจมตีที่ตรวจพบได้ The Hacker News ซึ่งรายงานงานวิจัยนี้เมื่อวันที่ 10 กันยายน ระบุว่าไม่มีแหล่งข่าวใดรายงานว่ามีใครดำเนินการดังกล่าวกับระบบที่ใช้งานจริง และการทำเช่นนั้นต้องมีสิทธิ์ผู้ดูแลระบบก่อน กรอบคำอธิบายของ Wiz ก็เป็นเช่นเดียวกัน: การส่งผ่าน (pass-through) เป็นคุณสมบัติของการออกแบบที่กลายเป็นช่องโหว่ได้ก็ต่อเมื่อข้อมูลรับรองของผู้ดูแลระบบเป็นสตริงจากเอกสารคู่มือ

8.8 และ 2.1 เป็นการให้คะแนนเชนเดียวกันจากจุดเริ่มต้นที่ต่างกัน

มี CVE สองรายการที่บรรจุข้อค้นพบทางเทคนิคไว้ และคะแนนที่เผยแพร่ของทั้งสองรายการแทบจะแตกต่างกันมากที่สุดเท่าที่จะเป็นไปได้

CVE-2026-59822 คือช่องโหว่การข้ามการตรวจสอบสิทธิ์ของ MCP และประกาศคำเตือนของ LiteLLM จัดให้อยู่ในระดับสูง 8.8 ภายใต้ CVSS 4.0 โดยไม่ต้องมีสิทธิ์พิเศษ ไม่ต้องมีการโต้ตอบจากผู้ใช้ และไม่มีข้อกำหนดในการโจมตี ปลายทาง MCP มีตัวจัดการการตรวจสอบสิทธิ์ของตนเอง ซึ่งสร้างมาเพื่อรับคีย์ LiteLLM หรือโทเคน OAuth2 ที่มุ่งไปยังเซิร์ฟเวอร์เครื่องมือต้นทาง เมื่อโทเคนไม่ผ่านการตรวจสอบของ LiteLLM ตัวจัดการจะจับข้อผิดพลาด 401 และแทนที่ด้วยออบเจ็กต์การตรวจสอบสิทธิ์แบบว่างเปล่าแทนการปฏิเสธคำขอ ดังนั้นโทเคน Bearer ใดก็ตามจึงสร้างเซสชัน MCP ที่ถูกต้องได้ รวมถึงโทเคนที่มีอักขระเพียงตัวเดียว: หลักฐานเชิงประจักษ์ของ Wiz ส่งโทเคน bearer ที่มีตัวอักษรหนึ่งตัวและได้รับตัวระบุเซสชันกลับมา ข้อบกพร่องนี้ได้รับการแก้ไขในเวอร์ชัน 1.84.0

CVE-2026-59821 เป็นช่องโหว่ใน guardrail และคำแนะนำของโครงการเดียวกันจัดให้อยู่ในระดับ Low, 2.1 โดยต้องมีสิทธิ์ระดับสูงและมีเงื่อนไขการโจมตี ฟีเจอร์ guardrail แบบโค้ดกำหนดเองอนุญาตให้ผู้ดูแลระบบส่ง Python ที่เซิร์ฟเวอร์คอมไพล์และรัน endpoint สำหรับทดสอบของ Web UI ตรวจสอบโค้ดกับรายการรูปแบบต้องห้ามและตัด builtins ออกก่อนรัน แต่ endpoint สำหรับสร้างและอัปเดตใน production ไม่ได้ทำทั้งสองอย่าง Python เติม builtins กลับมาเมื่อไม่มี builtins เหล่านั้น ดังนั้นโค้ดที่ส่งมาจึงเข้าถึง standard library ได้ หลักฐานเชิงประจักษ์ของ Wiz ลงทะเบียน guardrail ที่รันคำสั่ง shell ณ เวลาลงทะเบียน — ก่อนคำขอใด ๆ ต่อโมเดล — และส่งคืนผลลัพธ์ของคำสั่งเป็นเหตุผลในการบล็อก ซึ่งในการทดสอบของมันส่งกลับมาเป็น root ช่องโหว่นี้ได้รับการแก้ไขใน v1.82.0-stable

คำอธิบายทั้งสองอย่างเข้ากันได้ และประโยคที่ช่วยเชื่อมให้สอดคล้องกันนั้นอยู่ในคำแนะนำเอง: LiteLLM ระบุว่าในการติดตั้งใช้งานที่ไม่ได้กำหนด master key ผู้เรียกอาจถูกปฏิบัติเสมือนเป็นผู้ดูแลพร็อกซี ซึ่งเป็นสิ่งที่ทำให้ปลายทาง guardrail อยู่ในระยะเอื้อมถึง A 2.1 สมมติว่าผู้ใช้เป็นผู้ใช้ที่มีสิทธิ์พิเศษ ห่วงโซ่ของ Wiz คือสิ่งที่เกิดขึ้นเมื่อคีย์เริ่มต้นทำให้ผู้เรียกทุกรายมีสิทธิ์พิเศษ ไม่มีคะแนนใดผิดเกี่ยวกับจุดตั้งต้นของตนเอง พวกเขาเห็นต่างกันว่าจุดนั้นว่างบ่อยเพียงใด

มีข้อแม้ประการหนึ่งประกอบกับคำกล่าวอ้างของ {{1}}Wiz{{/1}} ที่ว่าหลังจาก 1.82.0 ผู้โจมตีที่ถือคีย์เริ่มต้นจะสามารถรันโค้ดได้เพียงภายในแซนด์บ็อกซ์เท่านั้น {{2}}The Hacker News{{/2}} ชี้ไปยังประกาศแยกต่างหากเมื่อเดือนพฤษภาคม 2026 คือ CVE-2026-40217 ซึ่งอธิบายการหลุดออกจากแซนด์บ็อกซ์นั้นผ่านเทคนิคไบต์โค้ดในเวอร์ชันตั้งแต่ 1.81.8 จนถึงแต่ไม่รวม 1.83.10 ภายในโปรเซสพร็อกซีที่ประกาศระบุว่ารันในฐานะรูทในอิมเมจคอนเทนเนอร์เริ่มต้น การเข้าถึงปลายทางดังกล่าวต้องใช้ข้อมูลรับรองของผู้ดูแลพร็อกซี ซึ่งก็คือมาสเตอร์คีย์นั่นเอง

ค่า 8.8 ก็ไม่ได้เป็นค่าสากลเช่นกัน บันทึกการวิจัยของ Cloud Security Alliance ตั้งข้อสังเกตว่าคำแนะนำของ GitLab ระบุคะแนนฐาน 8.2 สำหรับช่องโหว่เดียวกัน และไม่ขอตัดสินระหว่างสองระเบียบวิธี โดยระบุเพียงว่าทั้งสองอยู่ในช่วงสูง ระดับความรุนแรง "high" ของบันทึกไม่ได้ขึ้นอยู่กับว่าจะใช้ตัวเลขใด

มี CVE หนึ่งรายการถูกใช้โจมตีในสภาพแวดล้อมจริง ส่วนการเปิดเผยคีย์เริ่มต้นยังไม่มีเหยื่อที่ระบุชื่อได้

CISA ได้เพิ่ม CVE-2026-59822 เข้าในแค็ตตาล็อก Known Exploited Vulnerabilities เมื่อวันที่ 2 กันยายน 2026 และกำหนดเส้นตายการแก้ไขไว้ที่วันที่ 16 กันยายน 2026 สำหรับหน่วยงานพลเรือนของรัฐบาลกลาง โดยรายการในแค็ตตาล็อกระบุ CWE-287 และ CWE-306 ซึ่งเป็นการพิสูจน์ตัวตนที่ไม่เหมาะสมและการไม่มีการพิสูจน์ตัวตน บันทึกของ Cloud Security Alliance รายงานว่าผู้ติดตามสถานการณ์ในอุตสาหกรรมได้อธิบายช่องโหว่นี้ว่าเป็นข้อบกพร่องเฉพาะ MCP รายแรกในรายการดังกล่าว Wiz ได้เผยแพร่การโจมตีที่ตนสังเกตพบ โดยตั้งแต่ 7 กรกฎาคม 2026 ฮันนีพอตของบริษัทได้บันทึกคำขอที่พาโทเค็นแบบ bearer ซึ่งมีอักขระเพียงตัวเดียวเข้ามาสำรวจเอนด์พอยต์การแสดงรายการโมเดล และ Wiz ระบุว่าไม่มีการใช้ช่องโหว่นี้ในลักษณะอื่น

ไม่มีสิ่งใดเทียบเท่าได้สำหรับคีย์เริ่มต้น ไม่มีผู้เสียหายถูกระบุชื่อ ไม่มีเกตเวย์ใดถูกระบุว่าถูกยึดครองผ่าน sk-1234 และไม่มีข้อมูลเทเลเมทรีแสดงว่าโฮสต์ 294 เครื่องถูกใช้งาน รายการในคลังบันทึกว่าไม่มีความเสียหายจริง ซึ่งเป็นข้อความเกี่ยวกับหลักฐานมากกว่ากลไก: การเปิดเผยถูกวัดปริมาณ ไม่ได้ถูกเห็นการใช้งาน

สองรายการอื่นมักถูกบันทึกไว้เคียงข้างสิ่งเหล่านี้ และไม่ใช่สิ่งเดียวกัน CVE-2026-42271 ซึ่งเป็นการรันคำสั่งผ่าน endpoint ทดสอบ MCP สองจุด เป็นช่องโหว่ของ LiteLLM ที่ผู้โจมตีใช้รันโค้ดจริง honeypot ของ Wiz บันทึกว่ามีการติดตั้ง cryptocurrency miner กรณีเดือนสิงหาคม 2026 ที่ Microsoft เผยแพร่ ซึ่งผู้บุกรุกอ่านตัวแปรสภาพแวดล้อมของคอนเทนเนอร์เกตเวย์ กู้คืนมาสเตอร์คีย์ คีย์ของผู้ให้บริการ และสตริงการเชื่อมต่อฐานข้อมูล แล้วคัดลอกบันทึกจากตาราง model และ virtual-key ของ LiteLLM นั้นแสดงให้เห็นว่าเกตเวย์ที่ถูกบุกรุกมีมูลค่าเพียงใด มากกว่าจะเป็นช่องทางเข้าใหม่ The Hacker News รายงานว่า Microsoft ประเมินจุดเข้าถึงว่าเป็นห่วงโซ่ CVE-2026-42271

จุดยืนของผู้ดูแลคือการที่มาสเตอร์คีย์หายไปเป็นความผิดพลาดในการตั้งค่า ไม่ใช่ช่องโหว่

นโยบายความปลอดภัยของ LiteLLM ระบุไว้อย่างชัดเจน โดยจัดให้อยู่ในกลุ่มประเด็นนอกขอบเขต ได้แก่ "การโจมตีที่ต้องอาศัยการกำหนดค่าผิดพลาดในการตั้งค่า (เช่น การไม่ตั้งค่า master_key ในการกำหนดค่าพร็อกซี)" และระบุว่าสิ่งเหล่านี้อยู่นอกขอบเขตอย่างชัดเจนและไม่ถือว่าเป็นช่องโหว่ Wiz ได้ข้อสรุปที่สอดคล้องกันจากอีกแง่หนึ่ง เมื่อกล่าวว่าพฤติกรรม pass-through อาจถือได้ว่าทำงานตามที่ตั้งใจไว้

จุดยืนดังกล่าวถูกทดสอบต่อสาธารณะแล้ว เมื่อวันที่ 15 สิงหาคม 2026 นักวิจัยคนหนึ่งได้แจ้ง GitHub issue #37054 โดยรายงานว่าพร็อกซีที่ไม่ได้ตั้งค่า LITELLM_MASTER_KEY จะยืนยันตัวตนด้วยค่าคีย์ใดก็ได้ และไฟล์ docker-compose ที่จัดส่งมานั้นไม่ได้ตั้งค่าไว้ issue ถูกปิดภายใน 30 นาทีต่อมา และความคิดเห็นเดียวใน issue นั้นมาจากบัญชีเดียวกัน โดยอ้างถึงคำแนะนำในนโยบายความปลอดภัยที่ให้รายงานผ่านช่องทางรายงานช่องโหว่แบบส่วนตัวแทนการเปิด issue สาธารณะ ขอโทษที่แจ้งแบบสาธารณะ และระบุว่ารายงานฉบับเต็มกำลังถูกส่งผ่านช่องทาง advisory แทน ไม่มีคำตอบจากผู้ดูแลปรากฏในเธรด ดังนั้นบันทึกจึงแสดงให้เห็นว่าผู้รายงานเป็นฝ่ายถอนรายงานสาธารณะ มิใช่การตอบสนองของโครงการต่อรายงานดังกล่าว ไม่มีบันทึกสาธารณะใดระบุว่าการส่งแบบส่วนตัวนั้นลงเอยอย่างไร

ไม่พบแถลงการณ์สาธารณะใด ๆ จาก BerriAI ที่ปกป้องหรือแก้ไขจุดยืนดังกล่าวเกี่ยวกับรายงานเดือนกันยายนสำหรับบทความนี้ การตอบสนองที่มองเห็นได้ของบริษัทอยู่ในบันทึกการเผยแพร่ (release notes) และไฟล์การกำหนดค่าของบริษัท มากกว่าที่จะอยู่ในรูปแบบข้อความร้อยแก้ว

การบังคับใช้เกิดขึ้นเมื่อวันที่ 3 ตุลาคม ยี่สิบสี่วันหลังจากรายงาน

ข้อบกพร่องในโค้ดทั้งสองถูกแก้ไขไปนานแล้วก่อนรายงานจะออก ไทม์ไลน์การเปิดเผยข้อมูลของ Wiz บันทึกการทำงานของโค้ด guardrail ที่รายงานเมื่อวันที่ 18 กุมภาพันธ์ 2026 และแก้ไขเมื่อวันที่ 25 กุมภาพันธ์ใน v1.82.0, การข้าม MCP ที่แก้ไขเมื่อวันที่ 25 เมษายนใน v1.84.0, การถูกโจมตีที่ตรวจพบเมื่อวันที่ 7 กรกฎาคม, ตัวระบุ CVE ที่เผยแพร่เมื่อวันที่ 8 กรกฎาคม และการขึ้นทะเบียนในแคตตาล็อกเมื่อวันที่ 2 กันยายน อาร์ติแฟกต์การเผยแพร่มีวันที่หลังการแก้ไข: ดัชนีแพ็กเกจระบุ v1.82.0 เมื่อวันที่ 1 มีนาคม 2026 และ v1.84.0 เมื่อวันที่ 14 พฤษภาคม ซึ่งเป็นวันที่การแก้ไขแต่ละรายการติดตั้งได้ ไม่ใช่วันที่การแก้ไขนั้นเกิดขึ้นจริง บันทึกการเผยแพร่ของเจ้าของผลิตภัณฑ์สองรายการระบุวันที่ของการแก้ไขเดียวกันนั้นช้ากว่าไทม์ไลน์ดังกล่าว การเผยแพร่ v1.82.0-stable บน GitHub ระบุวันที่ 11 มีนาคม 2026 และแพ็กเกจ 1.82.0 บน PyPI ระบุวันที่ 1 มีนาคม; v1.84.0 ลงวันที่ 14 พฤษภาคม 2026 ทั้งสองแห่ง ไม่มีสิ่งใดที่เผยแพร่แล้วอธิบายช่องว่างนี้ และมันไม่สำคัญต่อข้อโต้แย้ง เนื่องจากวันที่ทั้งหมดเหล่านั้นล้วนอยู่ก่อนรายงานในเดือนกันยายนหลายเดือน คำแนะนำด้านความปลอดภัยบน GitHub ทั้งสองรายการยังเพิ่มวันที่อีกวันที่หนึ่ง: พวกมันเผยแพร่เมื่อวันที่ 30 มิถุนายน 2026 ซึ่งเป็นสามสัปดาห์ก่อนตัวระบุ CVE ที่ Wiz กล่าวว่าออกในวันที่ 8 กรกฎาคม

สิ่งที่ไม่มีรีลีสใดในเหล่านั้นแก้ไขคือค่าดีฟอลต์ Wiz รายงานว่า ณ วันที่ 9 กันยายน มาสเตอร์คีย์ยังถูกตั้งเป็น sk-1234 เมื่อติดตั้ง LiteLLM ผ่าน Docker Compose หรือ pip install และ The Hacker News ยืนยันว่าคู่มือการตั้งค่ายังใช้ค่านี้ในวันนั้น การเปลี่ยนแปลงมาพร้อม v1.104.0 ซึ่งอัปโหลดขึ้น Python Package Index เมื่อวันที่ 3 ตุลาคม 2026 โดยบันทึกประจำรุ่นระบุว่าเป็นการเปลี่ยนแปลงที่ทำให้เกิดความเข้ากันไม่ได้: พร็อกซีจะไม่ยอมเริ่มทำงานหากมาสเตอร์คีย์ไม่ได้ตั้งค่า ว่างเปล่า หรือเป็นค่าที่เป็นที่รู้กันโดยสาธารณะ โดยระบุแหล่งที่มาของค่าที่ไม่ดีในข้อผิดพลาดขณะเริ่มระบบ และพิมพ์คำสั่งที่สร้างคีย์ที่ปลอดภัย รายการที่เกี่ยวข้องบันทึกการเปลี่ยนแปลงเพื่อหยุดประกาศค่ามาสเตอร์คีย์ที่อ่อนแอและเป็นที่รู้กันโดยสาธารณะในคอนฟิกและตัวอย่างที่จัดส่ง และไฟล์ docker-compose บนสาขาหลักของโปรเจกต์ไม่มีการตั้งค่าคีย์อีกต่อไป

นั่นคือลำดับที่ควรค่าแก่การคงไว้ โค้ดได้รับการแพตช์ในฤดูใบไม้ผลิ ค่าที่ทำให้แพตช์เหล่านั้นไม่เพียงพอ ยังคงอยู่ในคำแนะนำการติดตั้งจนถึงเดือนตุลาคม และเพิ่งถึงตอนนั้นที่ซอฟต์แวร์เริ่มปฏิเสธค่านั้น ไม่มีสิ่งใดในการแก้ไขทั้งสองครั้งที่ทำให้อีกฝ่ายต้องรอ

สิ่งที่ไม่เปลี่ยนแปลงคือเส้นทางแบบ pass-through ไปยังบริการ metadata ของอินสแตนซ์ ยังไม่มี CVE และไม่มีวิธีแก้ไข เพราะโปรเจกต์ถือว่าผู้ดูแลระบบเป็นผู้ที่ไว้วางใจได้ รายการการแก้ไขของ Wiz จึงเป็นงานของผู้ปฏิบัติการเป็นส่วนใหญ่ ได้แก่ มาสเตอร์คีย์ที่แข็งแกร่งและไม่ซ้ำใคร การตรวจสอบ guardrails ที่ลงทะเบียนไว้ ตามด้วยการรีสตาร์ตโปรเซสเพื่อล้างโค้ดที่ค้างอยู่ในหน่วยความจำ การตรวจสอบปลายทาง pass-through ที่มีการจำกัด egress ของคอนเทนเนอร์ และบทบาท IAM แบบสิทธิ์น้อยที่สุด ไม่มีข้อใดในสี่ข้อนี้ที่ได้มาเพียงแค่การอัปเกรด

สิ่งที่บันทึกไม่ได้ยืนยัน

• ไม่พบการทำซ้ำโดยอิสระของการสแกนโฮสต์จำนวน 3,074 เครื่อง ตัวเลข 9.6% เป็นผลการวัดของ Wiz และทุกแหล่งอื่นที่กล่าวถึงตัวเลขนี้ล้วนอ้างอิงตัวเลขดังกล่าวโดยระบุแหล่งที่มา

• ยังไม่มีตัวเลขของระบบที่เปิดเผยต่อความเสี่ยงในปัจจุบัน การติดตามผลในเดือนสิงหาคมพบอินสแตนซ์มากกว่า 85,000 รายการ ซึ่ง Wiz กล่าวว่าโดยส่วนใหญ่เป็นฮันนี่พอตหรือการติดตั้งเพื่อทดสอบ และไม่สามารถนำไปเปรียบเทียบกับจำนวนในเดือนกุมภาพันธ์ได้

• ไม่มีผู้เสียหาย ไม่มีสิ่งใดในบันทึกที่ระบุชื่อเกตเวย์ ผู้ดำเนินการ หรือบัญชีคลาวด์ที่ถูกเจาะผ่านคีย์เริ่มต้น และการใช้ประโยชน์ที่ Wiz ระบุไว้ในเอกสารเป็นการเลี่ยง MCP ไม่ใช่ sk-1234

• ไม่มีหลักฐานว่าโฮสต์ทั้ง 294 เครื่องถูกใช้งานจริง การสแกนทดสอบว่าโฮสต์เหล่านั้นจะยืนยันตัวตนได้หรือไม่ ซึ่งเป็นข้อกล่าวอ้างที่อ่อนกว่าการแสดงให้เห็นว่ามีใครได้ใช้งานมันจริง

• ยังไม่มีข้อสรุปเรื่องระดับความรุนแรงของช่องโหว่ด้าน guardrail โดย Wiz และผู้ดูแลระบบอธิบายพฤติกรรมเดียวกันแต่ให้คะแนนความรุนแรงต่างกันมาก และความแตกต่างนั้นเกี่ยวกับสิทธิ์ที่แต่ละฝ่ายสมมติว่าผู้โจมตีมีอยู่แล้ว

Wiz ยังเป็นผู้จำหน่ายโซลูชันความปลอดภัยคลาวด์ที่ขายการตรวจจับสำหรับช่องโหว่ประเภทนี้ และรายงานปิดท้ายด้วยส่วนที่อธิบายว่าผลิตภัณฑ์ของตนระบุการติดตั้ง LiteLLM เวอร์ชันที่มีช่องโหว่ และอินสแตนซ์เงาได้อย่างไร นี่เป็นบริบทสำหรับการอ่านส่วนการแก้ไข ไม่ใช่เหตุผลที่จะลดความน่าเชื่อถือของผลการวัดที่รายละเอียดทางเทคนิคได้รับการยืนยันจากคำประกาศของผู้ดูแลเอง

ส่วนของระเบียนที่หลุดออกไปนอก LiteLLM คือช่วงเวลาระหว่างวันที่สองวัน ช่องโหว่ถูกปิดในฤดูใบไม้ผลิ ค่าเริ่มต้นที่ทำให้ช่องโหว่กลายเป็นเรื่องสำคัญสำหรับบุคคลภายนอกยังคงถูกพิมพ์อยู่ในคำแนะนำการติดตั้งในเดือนกันยายน และซอฟต์แวร์เพิ่งเริ่มปฏิเสธค่านั้นในเดือนตุลาคม ผู้ดูแลระบบที่เปลี่ยนสตริงไม่เคยต้องรอสิ่งใดเหล่านั้นเลย