สรุปสั้น

มีการเปิดเผยช่องโหว่ร้ายแรงใน Bifrost ซึ่งเป็นเกตเวย์ AI แบบโอเพนซอร์สที่ทำหน้าที่ส่งต่อคำขอไปยังผู้ให้บริการโมเดลภาษาขนาดใหญ่ (LLM) มากกว่า 20 ราย โดยช่องโหว่นี้เปิดให้ผู้โจมตีที่ไม่ต้องยืนยันตัวตนสามารถรันคำสั่งใด ๆ บนเซิร์ฟเวอร์เกตเวย์ได้ด้วยคำขอ HTTP เพียงครั้งเดียว ช่องโหว่ถูกติดตามในรหัส CVE-2026-90898 มีคะแนนความรุนแรง CVSS สูงถึง 9.8 และกระทบ Bifrost HTTP transport ทุกเวอร์ชันก่อน 2.1.0 เมื่อปิดการยืนยันตัวตนของส่วนจัดการ ซึ่งเป็นค่าตั้งต้นของระบบ ผู้ค้นพบคือนาย Yuval Moravchick จาก JFrog Security Research จุดที่ทำให้ผลกระทบรุนแรงคือ เนื่องจากเกตเวย์เก็บ API key ของผู้ให้บริการทุกรายที่เชื่อมต่อไว้ การรันคำสั่งบนโพรเซสเกตเวย์ได้จึงเท่ากับผู้โจมตีเข้าถึงกุญแจเหล่านั้นทั้งหมด บริษัท Maxim ผู้พัฒนา Bifrost โต้แย้งว่าความเสี่ยงจริงต่ำกว่าที่คะแนนบ่งชี้ เพราะการโจมตีต้องอาศัยการเปิดหน้าจัดการสู่เครือข่ายที่ไม่น่าเชื่อถือ

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

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 22 กันยายน พ.ศ. 2569 ว่า พบช่องโหว่ร้ายแรงใน Bifrost เกตเวย์ AI แบบโอเพนซอร์สที่เปิดให้ผู้โจมตีที่ไม่ต้องล็อกอินรันคำสั่งบนเซิร์ฟเวอร์ได้ โดยมีการออกตัวแก้ไขแล้วในเวอร์ชัน transports/v2.1.0

นาย Yuval Moravchick จาก JFrog Security Research ผู้ค้นพบช่องโหว่ ระบุว่าผู้โจมตีสามารถลงทะเบียนไคลเอนต์ MCP ชนิด stdio ผ่านคำขอ POST ที่ไม่ต้องยืนยันตัวตนเพียงครั้งเดียวไปยังปลายทาง API ของส่วนจัดการที่ /api/mcp/client จากนั้น Bifrost จะเริ่มรันคำสั่งที่ระบุทันทีก่อนการจับมือ (handshake) ของ MCP ใด ๆ โดยรันในสิทธิ์ของผู้ใช้ที่โพรเซสเกตเวย์ทำงานอยู่ ซึ่งบนอิมเมจ Docker ทางการคือผู้ใช้ชื่อ appuser

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

ในถ้อยแถลงต่อ The Hacker News นาย Akshay Deo ประธานเจ้าหน้าที่ฝ่ายเทคโนโลยีและผู้ร่วมก่อตั้งบริษัท Maxim ซึ่งเป็นผู้อยู่เบื้องหลัง Bifrost กล่าวว่าความเสี่ยงในทางปฏิบัติต่ำกว่าที่ระดับความรุนแรงบ่งชี้ เพราะการโจมตีต้องให้ส่วนจัดการเข้าถึงได้จากเครือข่ายที่ไม่น่าเชื่อถือ และผู้ดูแลต้องปล่อยให้ไม่ได้ตั้งการยืนยันตัวตน โดยการติดตั้งตามค่าเริ่มต้นและตามเอกสารจะวางเกตเวย์ไว้ในเครือข่ายส่วนตัว บริษัทระบุว่ามองช่องโหว่นี้เป็นระดับความรุนแรงต่ำและกำลังทำงานร่วมกับ JFrog เพื่อทบทวนการประเมินความรุนแรงใหม่

รายละเอียดช่องโหว่

ผู้ที่ใช้งานเวอร์ชัน transports/v2.0.0 ยังคงได้รับผลกระทบจากช่องโหว่ MCP นี้ เพราะรุ่นดังกล่าวแก้เพียงช่องโหว่ปลั๊กอินตัวก่อนหน้าเท่านั้น และไม่ได้บล็อกการลงทะเบียนแบบไม่ยืนยันตัวตน ส่วนสาย 1.6.x ไปจนถึง 1.6.11 ไม่มีการแก้ไขทั้งสองจุด

นอกจากนี้ยังมีช่องโหว่ที่เกี่ยวข้องอีกตัวที่นาย Or Peles จากทีมวิจัยเดียวกันค้นพบและเปิดเผยเมื่อวันที่ 6 กันยายน คือ CVE-2026-86242 (คะแนน CVSS 8.1) ซึ่งเปิดให้ผู้โจมตีที่ไม่ต้องยืนยันตัวตนลงทะเบียนปลั๊กอินแบบกำหนดเองที่มีเส้นทางเป็น URL แบบ HTTP จากนั้น Bifrost จะดาวน์โหลดไฟล์ เขียนเป็น shared object ชั่วคราว แล้วโหลดผ่านฟังก์ชัน plugin.Open ของภาษา Go บนบิลด์แบบเชื่อมโยงไดนามิก (ซึ่ง Bifrost ต้องใช้สำหรับปลั๊กอิน Go แบบกำหนดเอง) ปลั๊กอินจะถูกโหลดและโค้ดจะรันในสิทธิ์ผู้ใช้ของโพรเซสเกตเวย์ ส่วนบนบิลด์แบบเชื่อมโยงสถิต รวมถึงอิมเมจ Docker ทางการ ฟังก์ชัน plugin.Open จะล้มเหลวและผลลัพธ์จะกลายเป็นเพียง server-side request forgery (SSRF) เท่านั้น

ช่องโหว่ทั้งสองมีต้นตอเดียวกันคือ ส่วนจัดการ API ของ Bifrost มาพร้อมการปิดการยืนยันตัวตนเป็นค่าเริ่มต้น ทั้งสองรายการเป็นช่องโหว่ตัวที่สองและสามที่ถูกเปิดเผยในโครงการนี้ภายในเวลาไม่ถึงหนึ่งเดือน หลังจากช่องโหว่ SSRF ที่ไม่เกี่ยวข้องกัน (CVE-2026-55245) ซึ่งแก้ไปเมื่อปลายเดือนสิงหาคม อนึ่ง ช่องโหว่ MCP ตัวนี้เดินตามรูปแบบที่เคยนำไปสู่การโจมตีจริงมาแล้ว โดยในเดือนมิถุนายนช่องโหว่ command injection ที่คล้ายกันใน LiteLLM ซึ่งเป็นเกตเวย์ AI อีกตัว ถูกใช้โจมตีจริงและถูกเพิ่มเข้าแคตตาล็อก KEV ของ CISA อย่างไรก็ตาม CVE ของ Bifrost ทั้งสองตัวยังไม่ปรากฏในแคตตาล็อก KEV ณ เวลาที่เผยแพร่ข่าว

ผลกระทบ

ช่องโหว่นี้กระทบองค์กรที่รัน Bifrost เป็นชั้นกลางในการเชื่อมต่อไปยังผู้ให้บริการ LLM หลายราย โดยเฉพาะผู้ที่ใช้อิมเมจ Docker ทางการซึ่งผูกส่วนจัดการไว้กับ 0.0.0.0 และเปิดพอร์ตออกมา เนื่องจากเกตเวย์รวมศูนย์ API key ของผู้ให้บริการทุกรายไว้ที่เดียว การถูกเจาะจึงไม่ได้จบแค่เครื่องเกตเวย์ แต่ลามไปถึงบัญชีของผู้ให้บริการปลายทางทั้งหมด ทำให้ผู้โจมตีสามารถเรียกใช้โมเดลโดยคิดค่าใช้จ่ายกับเหยื่อ ดูดข้อมูลที่ไหลผ่าน หรือใช้กุญแจเหล่านั้นต่อยอดโจมตีระบบอื่น JFrog จึงแนะนำให้ถือว่าอินสแตนซ์ใดก็ตามที่เคยรันโดยปิดการยืนยันตัวตนและเปิดส่วนจัดการออกสู่ภายนอกเป็นระบบที่ถูกเจาะแล้ว และให้หมุนเปลี่ยน virtual key กับ API key ของผู้ให้บริการทั้งหมด

คำแนะนำ

ผู้ดูแลระบบควรอัปเกรดเป็น transports/v2.1.0 ซึ่งจะคืนค่า 403 เมื่อมีผู้เรียกที่ไม่ยืนยันตัวตนพยายามลงทะเบียนไคลเอนต์ MCP ชนิด stdio สำหรับผู้ที่ยังอัปเกรดทันทีไม่ได้ ควรตั้งค่า governance.auth_config.is_enabled ให้เป็น true ใช้ข้อมูลรับรองที่แข็งแรง และไม่เปิดตัวรับฟังของส่วนจัดการสู่เครือข่ายที่ไม่น่าเชื่อถือ นอกจากนี้ควรตรวจสอบว่าเคยเปิดส่วนจัดการออกสู่ภายนอกโดยปิดการยืนยันตัวตนหรือไม่ หากเคย ให้ถือว่าถูกเจาะและหมุนเปลี่ยนกุญแจทั้งหมดตามคำแนะนำของ JFrog

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