การ POST หนึ่งครั้งโดยไม่ผ่านการยืนยันตัวตนไปยัง Management API ของ Bifrost ทำให้เกิดการเริ่มคำสั่งในฐานะผู้ใช้ Gateway

เมื่อวันที่ 14 กันยายน 2026 JFrog Security Research ได้เผยแพร่ CVE-2026-90898 ซึ่งเป็นช่องโหว่ที่ทำให้สามารถรันคำสั่งได้ใน Bifrost — เกตเวย์ AI โอเพนซอร์สที่ดูแลโดย Maxim — และให้คะแนน 9.8 จาก 10 การโจมตีใช้เพียงคำขอ HTTP หนึ่งครั้ง คำขอที่ไม่ผ่านการยืนยันตัวตนที่ส่งไปยัง POST /api/mcp/client จะลงทะเบียนไคลเอนต์ stdio MCP ซึ่ง Bifrost อ่านเป็นชื่อโปรแกรมพร้อมรายการอาร์กิวเมนต์และเริ่มทำงานทันที ก่อนการจับมือ MCP ใด ๆ โดยทำงานในฐานะผู้ใช้ที่รันเกตเวย์ บนอิมเมจทางการ ผู้ใช้นั้นคือ appuser เกตเวย์ยังเป็นที่เก็บคีย์ผู้ให้บริการและคีย์เสมือนของผู้ปฏิบัติงาน ดังนั้นกระบวนการที่รันอยู่ที่นั่นจึงเข้าถึงข้อมูลรับรองได้ สิ่งที่ทำให้คำขอนี้ไม่ระบุตัวตนคือค่าเริ่มต้นที่จัดส่งมาพร้อมผลิตภัณฑ์: governance.auth_config.is_enabled เป็น false และตามถ้อยคำของ JFrog "การปิดการยืนยันตัวตนหมายความว่าผู้เรียกทุกรายเป็นผู้ดูแลระบบภายในเครื่อง" ไม่มีแหล่งที่อ้างอิงใดรายงานว่าช่องโหว่นี้เคยถูกใช้ประโยชน์ แหล่งข้อมูลของบันทึกนี้เอง ระดับความรุนแรง และการประเมินความเชื่อมั่นอยู่ใน คลังเหตุการณ์ AI ควบคู่กับช่องโหว่ของเกตเวย์ AI และ MCP อื่น ๆ ที่มีเอกสารบันทึกไว้ในปีที่ผ่านมา

Bifrost เป็นบริการเดียวที่ทำหน้าที่อยู่ระหว่างแอปพลิเคชันกับโมเดลภาษาที่แอปพลิเคชันเรียกใช้ รีโพซิทอรีของมันอธิบายว่าเป็นเกตเวย์โอเพนซอร์สที่ได้รับอนุญาตภายใต้ Apache-2.0 ซึ่ง "รวมการเข้าถึงผู้ให้บริการ 23+ ราย ... ไว้ผ่าน API เดียวที่เข้ากันได้กับ OpenAI" โดยมีคุณสมบัติต่างๆ เช่น การพร็อกซี MCP, คีย์เสมือน, งบประมาณ และการ баланโหลดแยกตามผู้ให้บริการ และมีดาว GitHub ประมาณ 9,150 ดวง ณ วันที่ 28 ตุลาคม 2026 การรวมกันนี้เองคือเหตุผลทั้งหมดที่ทำให้การได้ shell บนโฮสต์นี้สมควรได้รับคะแนนระดับวิกฤต: กระบวนการที่กำหนดเส้นทางคำขอเป็นกระบวนการเดียวกันกับที่ถือข้อมูลรับรองสำหรับทุก upstream ที่มันกำหนดเส้นทางไป The Hacker News ซึ่งรายงานข้อบกพร่องนี้เมื่อวันที่ 22 กันยายน กล่าวถึงผลลัพธ์อย่างตรงไปตรงมา — เนื่องจากเกตเวย์เก็บคีย์ API สำหรับผู้ให้บริการทุกรายที่เชื่อมต่อ การรันคำสั่งบนกระบวนการเกตเวย์จึงทำให้ผู้โจมตีเข้าถึงข้อมูลรับรองเหล่านั้นได้

การโจมตีทั้งหมดเป็นการ POST เพียงครั้งเดียว

คำแนะนำของ JFrog ซึ่งเผยแพร่ภายใต้รหัสอ้างอิง JFSA-2026-001686326 อธิบายถึง endpoint ที่มีอยู่เพื่อให้ผู้ดูแลระบบเพิ่มเซิร์ฟเวอร์ MCP ได้ โดยไคลเอนต์แบบ stdio ในข้อกำหนดของ MCP ไม่ใช่ URL แต่เป็นคำสั่งและอาร์กิวเมนต์ของคำสั่ง ซึ่งโปรแกรมโฮสต์คาดว่าจะเป็นตัวเรียกให้ทำงาน Bifrost ยอมรับการกำหนดค่านั้นผ่าน management API และเริ่มโปรแกรมทันทีที่เพิ่มไคลเอนต์ ไม่มีการเจรจาความสามารถ ไม่มีการตรวจสอบตัวตนของเซิร์ฟเวอร์ และไม่จำเป็นต้องมีแฮนด์เชกที่สำเร็จก่อน — คำแนะนำระบุชัดเจนว่าการแฮนด์เชกไม่ใช่สิ่งที่เริ่มกระบวนการ

proof of concept ใน advisory เป็น JSON body สั้น ๆ ที่ถูก POST ไปยัง gateway โดยปล่อย authentication ไว้ที่ค่าเริ่มต้น มันลงทะเบียน client ที่มี command เป็น /bin/sh และมี arguments ที่เขียนไฟล์ marker แล้วอ่าน marker กลับมา JFrog เสริมรายละเอียดเชิงปฏิบัติการที่สำคัญระหว่างการตอบสนองต่อเหตุการณ์: คำขอ HTTP อาจ timeout ขณะที่ Bifrost รอ handshake ที่ไม่เคยมาถึง และ timeout ใน logs ไม่ได้หมายความว่า command เริ่มทำงานไม่สำเร็จ เมื่อถึงตอนนั้น process กำลังทำงานอยู่แล้ว

บันทึก CVE ซึ่งกำหนดโดย JFrog ในฐานะหน่วยงานกำหนดหมายเลข CVE ระบุว่าข้อบกพร่องดังกล่าวตรงกับ CWE-306 การขาดการยืนยันตัวตนสำหรับฟังก์ชันสำคัญ และ CWE-284 การควบคุมการเข้าถึงที่ไม่เหมาะสม พร้อมระบุชื่อไฟล์สองไฟล์ที่บรรจุตัวจัดการและมิดเดิลแวร์ของตัวจัดการนั้น ได้แก่ transports/bifrost-http/handlers/mcp.go และ transports/bifrost-http/handlers/middlewares.go โมดูลที่ได้รับผลกระทบคือ github.com/maximhq/bifrost/transports บน Linux และ macOS สำหรับทุกเวอร์ชันที่ต่ำกว่า 2.1.0

ค่าเริ่มต้นที่ทำให้คำขอไม่ระบุตัวตน

ไม่มีสิ่งใดในนั้นจะถูกใช้โจมตีได้หากไม่มีเงื่อนไขที่สอง และเงื่อนไขที่สองคือค่าเริ่มต้นของผลิตภัณฑ์เอง มิดเดิลแวร์การยืนยันตัวตนสำหรับการจัดการของ Bifrost ถูกควบคุมด้วย governance.auth_config.is_enabled ซึ่งมาพร้อมค่า false เมื่อปิดอยู่ มิดเดิลแวร์จะถือว่าผู้เรียกทุกคนเป็นผู้ดูแลระบบภายในเครื่อง — สรุปของประกาศคำแนะนำเองระบุว่าการปิดการยืนยันตัวตนหมายความว่าผู้เรียกทุกคนเป็นผู้ดูแลระบบภายในเครื่อง — ดังนั้นการตรวจสอบที่จะหยุดคำขอนั้นจึงไม่เคยอยู่ในเส้นทางการทำงาน

การแก้ไข ซึ่งเป็น pull request #6757 ถูก merge เข้าโปรเจกต์เมื่อวันที่ 2 กันยายน 2026 ก่อนที่ CVE จะถูกเผยแพร่สิบสองวัน และก่อนรีลีสที่มีการแก้ไขนี้อยู่หกวัน คำอธิบายของมันเปิดเผยอย่างตรงไปตรงมาอย่างผิดปกติเกี่ยวกับลักษณะของปัญหา: pull request นี้ปิด primitive การเข้าถึงโดยไม่ต้องยืนยันตัวตนสองรายการใน API การลงทะเบียนเดียวกัน ไม่ใช่เพียงรายการเดียว รายการแรกคือไคลเอนต์ stdio รายการที่สองคือไคลเอนต์ MCP แบบ http หรือ sse ที่ชี้ไปยังที่อยู่ลูปแบ็กหรือเครือข่ายส่วนตัว ซึ่งคำขอนี้เรียกมันว่าเป็น primitive แบบ SSRF ที่เจาะบริการภายใน "รวมถึงเอนด์พอยต์เมทาดาทาของคลาวด์ 169.254.169.254" ขณะนี้ทั้งสองรายการถูกปฏิเสธด้วย HTTP 403 เมื่อคำขอไปถึงแฮนด์เลอร์โดยไม่มีการตรวจสอบข้อมูลรับรองที่แท้จริง ผู้ดูแลระบบที่ผ่านการยืนยันตัวตนยังคงมีความสามารถทั้งสองอย่าง และผู้ดำเนินการยังสามารถจัดเตรียมไคลเอนต์ stdio ผ่าน config.json ได้

primitive ตัวที่สองนั้นไม่ปรากฏในข้อความ CVE มันอยู่ในแพตช์ และนี่คือเหตุผลที่การแก้ไขออกมาเป็นการวางเงื่อนไขกั้น (gate) มากกว่าการลบออกไป: ตัวฟีเจอร์นั้นไม่เคยเป็นบั๊กเลย การปฏิบัติต่อผู้เรียกที่ไม่ได้ยืนยันตัวตนเสมือนเป็นผู้ดูแลระบบต่างหากที่เป็นบั๊ก

ตำแหน่งที่ Management API กำลังรอรับการเชื่อมต่ออยู่จริง

ความสามารถในการเข้าถึงเป็นส่วนของบันทึกที่แหล่งข้อมูลอธิบายไว้สอดคล้องกันมากที่สุด และมีการวัดน้อยที่สุด คำแนะนำของ JFrog ระบุว่าค่าเริ่มต้นของไบนารีมาตรฐานคือ localhost:8080 ซึ่งจำกัดผู้โจมตีให้อยู่ภายในโฮสต์เอง คำแนะนำของทีมเดียวกันสำหรับช่องโหว่คู่กันระบุว่าอิมเมจ Docker อย่างเป็นทางการผูกกับ 0.0.0.0 แทน และ The Hacker News ก็กล่าวซ้ำว่า อิมเมจทำให้ management API เข้าถึงได้จากภายนอกคอนเทนเนอร์หากมีการเผยแพร่พอร์ต วิธีเริ่มต้นอย่างเร็วใน README ของ Bifrost เองรัน "docker run -p 8080:8080 maximhq/bifrost" และ -p ของ Docker จะเผยแพร่พอร์ตคอนเทนเนอร์บนทุกอินเทอร์เฟซของโฮสต์ เว้นแต่จะระบุที่อยู่ คำแนะนำบน GitHub สำหรับช่องโหว่นี้บันทึกว่าเส้นทางที่รายงานได้รับการตรวจสอบกับอิมเมจ maximhq/bifrost:latest ที่เผยแพร่แล้ว ซึ่งคำขอที่ไม่ผ่านการตรวจสอบสิทธิ์ได้เปิด /bin/sh และเขียน marker ในฐานะ appuser

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

เอนด์พอยต์เดียว สองข้อบกพร่อง สาเหตุรากเดียว

แปดวันก่อนประกาศแนะนำเรื่อง MCP ในวันที่ 6 กันยายน 2026 ทีมวิจัยเดียวกันได้เผยแพร่ CVE-2026-86242 ซึ่งเป็นเส้นทางที่สองที่ไม่ต้องผ่านการยืนยันตัวตนเข้าสู่โปรเซสเดียวกัน ค้นพบโดย Or Peles และได้คะแนน 8.1 โดยอาศัยช่องโหว่ใน POST /api/plugins: Bifrost ยอมรับปลั๊กอินแบบกำหนดเองที่เปิดใช้งานอยู่ซึ่งมีพาธเป็น HTTP URL ตัวโหลด shared object จะถือว่าพาธที่ขึ้นต้นด้วย http เป็นการดาวน์โหลด เขียนเนื้อหาลงไฟล์ .so ชั่วคราว แล้วส่งไฟล์นั้นให้ plugin.Open ของ Go หากโหลดสำเร็จ ฟังก์ชัน Init ที่เป็นทางเลือกจะทำงานทันทีด้วยการกำหนดค่าของผู้โจมตี ในฐานะผู้ใช้ของเกตเวย์

รูปแบบการ build เป็นตัวกำหนดว่าผู้โจมตีจะได้อะไร ใน build แบบ dynamically linked ที่โปรเจกต์ dokument ไว้สำหรับ Go plugin แบบกำหนดเอง การโหลดคาดว่าจะสำเร็จ ซึ่ง advisory เรียกว่า unauthenticated remote code execution บน Docker image แบบ statically linked ที่เผยแพร่ plugin.Open จะล้มเหลวด้วย "Dynamic loading not supported" คำขอเดียวกันจึงลดระดับเป็น server-side request forgery plugin ที่โหลดได้ยังต้องตรงกับ Go version ระบบปฏิบัติการ สถาปัตยกรรม และ linkage ของ host ด้วย ซึ่งเป็นข้อจำกัดจริง ไม่ใช่แค่พิธีการ การแก้ไขคือ transports/v2.0.0 ผ่าน pull request #5763 และช่วงที่ได้รับผลกระทบคือทุกเวอร์ชันที่ต่ำกว่านั้น

กับดักอยู่ที่ลำดับการเผยแพร่รีลีส v2.0.0 แก้ไขเส้นทางของปลั๊กอินแต่ไม่ได้แก้ไขเส้นทาง MCP — The Hacker News ระบุไว้อย่างชัดเจน และคำแนะนำด้านความปลอดภัยเกี่ยวกับ MCP ของ JFrog ยืนยันว่า v2.0.0 ยังอนุญาตการลงทะเบียนผ่าน stdio โดยไม่มีการยืนยันตัวตน ผู้ดูแลระบบที่ติดแพตช์อย่างรวดเร็วหลังคำแนะนำเมื่อวันที่ 6 กันยายน ยังคงเผชิญความเสี่ยงในประเด็นนั้นเพียงประเด็นเดียวจนกว่า transports/v2.1.0 จะเผยแพร่เมื่อวันที่ 8 กันยายน ข้อบกพร่องทั้งสองสรุปเหลือประโยคเดียวกันในคำแนะนำทั้งสองฉบับและในพูลรีเควสต์ของผู้จำหน่ายเอง: ค่าเริ่มต้นคือปิดใช้งานการยืนยันตัวตน

สิ่งที่แหล่งข้อมูลยืนยัน และสิ่งที่ไม่ได้ยืนยัน

กลไก ช่วงเวอร์ชัน การแก้ไข และเครดิต มีความสอดคล้องตรงกันทั้งในประกาศคำเตือน บันทึก CVE ที่ JFrog กำหนด pull request และ release notes ของโครงการเอง และ The Hacker News ข้อโต้แย้งที่เหลืออยู่เกี่ยวกับระดับความรุนแรง และมันเป็นเรื่องจริง

คะแนน 9.8 เป็นคะแนนของ JFrog ในฐานะ CNA ผู้กำหนดคะแนน และเป็นคะแนนที่ NVD นำมาใช้ โดยระเบียนของ NVD ระบุว่า reefs@jfrog.com เป็นแหล่งที่มาของเมตริก และ ณ วันที่ 28 ตุลาคม 2026 ยังคงแสดงรายการนี้ในสถานะ "Awaiting Analysis" ซึ่งหมายความว่า NVD ได้เผยแพร่เวกเตอร์ของผู้กำหนดคะแนนแทนการวิเคราะห์ของ NVD เอง การประเมิน SSVC ของผู้ประสานงาน CISA ที่แนบมากับระเบียนเดียวกัน ซึ่งประทับเวลา 14 กันยายน 2026 ระบุว่าการถูกใช้ประโยชน์เป็น "none" ความสามารถในการทำงานอัตโนมัติเป็น "yes" และผลกระทบทางเทคนิคเป็น "total" แบบจำลอง EPSS ของ FIRST ประเมินความน่าจะเป็นของการถูกใช้ประโยชน์ใน 30 วันข้างหน้าไว้ที่ร้อยละ 2.3 ณ วันที่ 27 ตุลาคม 2026 อยู่ในเปอร์เซ็นไทล์ที่ 83 เมื่อเทียบกับ CVE ทั้งหมดที่ได้รับการให้คะแนน และทั้ง CVE นี้และ CVE-2026-86242 ต่างไม่ปรากฏในแคตตาล็อกช่องโหว่ที่ถูกใช้ประโยชน์จริงที่รู้จักของ CISA (CISA Known Exploited Vulnerabilities) ฉบับลงวันที่ 27 ตุลาคม 2026

ในทางกลับกัน Maxim โต้แย้งการให้คะแนนดังกล่าว ในแถลงการณ์ที่ส่งถึง The Hacker News, Akshay Deo ประธานเจ้าหน้าที่ฝ่ายเทคโนโลยีและผู้ร่วมก่อตั้งบริษัท กล่าวว่าความเสี่ยงในทางปฏิบัติต่ำกว่าที่คะแนนระดับวิกฤตบ่งชี้ เนื่องจากการโจมตีต้องอาศัยให้อินเทอร์เฟซการจัดการนั้นเข้าถึงได้จากเครือข่ายที่ไม่น่าไว้วางใจ และผู้ปฏิบัติงานต้องปล่อยให้การรับรองตัวตนไม่ได้ถูกตั้งค่าไว้ เขากล่าวว่าการติดตั้งตามค่าเริ่มต้นและตามที่ระบุในเอกสารนั้นวางเกตเวย์ไว้ภายในเครือข่ายส่วนตัว The Hacker News รายงานว่า Maxim มองว่าช่องโหว่นี้มีความรุนแรงระดับต่ำ และกำลังร่วมงานกับ JFrog ซึ่งเป็นผู้กำหนดหมายเลข CVE เพื่อทบทวนการประเมินดังกล่าว แถลงการณ์นั้นปรากฏในสื่อดังกล่าวเพียงแห่งเดียว ไม่พบสิ่งพิมพ์อื่นใดที่อ้างอิงจุดยืนของ Maxim และไม่มีการเผยแพร่การทบทวนใด ๆ ณ วันที่ 28 ตุลาคม 2026 — บันทึก CVE ได้รับการอัปเดตล่าสุดเมื่อวันที่ 14 กันยายน และรายการ NVD เมื่อวันที่ 18 กันยายน โดยทั้งสองยังคงอยู่ที่ 9.8

ยังมีช่องว่างอีกสองจุดที่ควรระบุให้ชัดแทนที่จะกลบเกลื่อน advisories บน GitHub ของโปรเจกต์ ซึ่งเผยแพร่เมื่อวันที่ 23 กันยายน 2026 และให้เครดิตนักวิจัยของ JFrog ในฐานะผู้รายงาน ยังคงระบุคะแนน 9.8 สำหรับช่องโหว่ MCP และ 8.1 สำหรับช่องโหว่ของปลั๊กอิน โดยไม่มีสัญญาณของการแก้ไขตามที่ Maxim อธิบายไว้ และช่วงที่ได้รับผลกระทบใน advisories เหล่านั้นเขียนโดยอิงกับเวอร์ชัน Go module — ต่ำกว่า 1.5.27 และต่ำกว่า 1.6.3 — แทนที่จะเป็นแท็ก release ของ transports ที่ advisories ของ JFrog ใช้ ดังนั้นผู้ดูแลระบบที่นำเอกสารฉบับหนึ่งไปเทียบกับอีกฉบับจึงต้องทำให้รูปแบบการนับเลขสองแบบสอดคล้องกันก่อนตัดสินว่าบิลด์ใดได้รับผลกระทบ

มีอะไรเปลี่ยนแปลงไป และผู้ปฏิบัติงานได้รับแจ้งให้ทำอะไร

ลำดับเวลานี้ย้อนกลับจากเหตุการณ์เปิดเผยข้อมูล ซึ่งเป็นส่วนที่สวนสามัญสำนึกที่สุดของบันทึก Pull request #6757 ถูก merge เมื่อวันที่ 2 กันยายน 2026 transports/v2.1.0 ซึ่งเป็นรีลีสที่ประกาศความปลอดภัยระบุว่าเป็นเวอร์ชันแรกที่มีการแก้ไข ถูกเผยแพร่เมื่อวันที่ 8 กันยายน — หกวันก่อนที่ CVE-2026-90898 จะถูกเผยแพร่ในวันที่ 14 กันยายน การแก้ไขปลั๊กอินของโปรเจกต์เกิดขึ้นก่อนประกาศของตัวเองในลักษณะเดียวกัน: transports/v2.0.0 เปิดตัวเมื่อวันที่ 26 สิงหาคม สิบเอ็ดวันก่อน CVE ประจำวันที่ 6 กันยายน ผู้ดูแลระบบที่ติดตามรีลีสแทนที่จะติดตามฟีดมีแพตช์อยู่ในมือก่อนที่จะได้รับคำเตือน

สิ่งที่การอัปเกรดนี้ให้มาคือขอบเขตที่แคบและเฉพาะเจาะจง ในเวอร์ชัน 2.1.0 ขึ้นไป การลงทะเบียนผ่าน stdio ที่ไม่ผ่านการรับรองความถูกต้องจะส่งคืน 403 และคำสั่งจะไม่เริ่มทำงาน ผู้ดูแลระบบที่ผ่านการรับรองความถูกต้องยังคงใช้ความสามารถนี้ได้ และการจัดเตรียมผ่าน config.json ยังคงทำงานได้ มาตรการชั่วคราวในคำแนะนำสำหรับผู้ที่ไม่สามารถอัปเกรดได้ คือตั้งค่า governance.auth_config.is_enabled เป็น true ใช้ข้อมูลรับรองผู้ดูแลระบบที่คาดเดายาก และแยก listener สำหรับการจัดการออกจากเครือข่ายที่ไม่น่าเชื่อถือ คำแนะนำของ JFrog สำหรับอินสแตนซ์ที่เปิดใช้งานโดยปิดการรับรองความถูกต้อง คืออย่าสืบสวนแล้วหวังว่าจะปลอดภัย ให้ถือว่าถูกบุกรุกแล้ว และหมุนเวียน virtual keys และข้อมูลรับรองของผู้ให้บริการ

การคำนวณเวอร์ชันเป็นส่วนที่ถูกอ่านผิดได้ง่ายที่สุด v2.0.0 ไม่ได้แก้ข้อบกพร่องนี้ สาย 1.6.x จนถึง 1.6.11 ก็ไม่มีแพตช์แก้ไขเช่นกัน และแท็กในซีรีส์ 1.6 ใหม่ล่าสุดของโปรเจกต์คือ transports/v1.6.11 ซึ่งเผยแพร่เมื่อวันที่ 14 สิงหาคม 2026 โดย ณ วันที่ 28 ตุลาคม 2026 ไม่มีสาย 1.7 อยู่ในรีโพซิทอรี — ดังนั้นจึงไม่มีรีลีสที่แพตช์แล้วภายในซีรีส์นั้น และผู้ใช้งาน 1.6.x ต้องอัปเกรดข้ามไปยัง 2.1.0 หรือใหม่กว่า แทนที่จะรอแบ็กพอร์ต สายรีลีสปัจจุบันเลยจุดนั้นไปไกลแล้ว: transports/v2.3.2 เผยแพร่เมื่อวันที่ 20 ตุลาคม 2026

มีสองสิ่งเกิดขึ้นหลังการเผยแพร่ที่ผู้ป้องกันสามารถนำไปใช้ประโยชน์ได้ ประกาศด้านความปลอดภัยบน GitHub ของโปรเจกต์ — GHSA-86gf-xh3g-rvxq สำหรับช่องโหว่ MCP ที่ระดับความรุนแรงวิกฤต และ GHSA-2qp8-4xgm-fw6g สำหรับช่องโหว่ปลั๊กอินที่ระดับสูง — ถูกเผยแพร่เมื่อวันที่ 23 กันยายน 2026 ทำให้ฟีด dependency และ advisory มีตัวระบุที่สองสำหรับใช้จับคู่ และเมื่อวันที่ 13 ตุลาคม 2026 เทมเพลตการตรวจจับสำหรับ CVE-2026-90898 ได้ถูก merge เข้า repository สาธารณะ nuclei-templates ซึ่งหมายความว่าการตรวจสอบความพยายามลงทะเบียนโดยไม่ผ่านการยืนยันตัวตนตอนนี้เป็นสิ่งที่ pipeline การสแกนสามารถรันได้ แทนที่จะเป็นสิ่งที่แต่ละทีมต้องเขียนเอง

สิ่งที่ยังคงเปิดอยู่คือระดับความรุนแรง และจะได้ข้อยุติหรือไม่นั้นขึ้นอยู่กับสององค์กรที่ยังคงหารือกันเรื่องนี้ ตำแหน่งของ Maxim ตามที่มีรายงานคือ 9.8 เป็นการประเมินที่เกินจริงสำหรับช่องโหว่ที่กว่าจะมีนัยสำคัญต้องมี listener ที่เปิดเผยและค่าดีฟอลต์ที่ยังไม่ได้ตั้งค่า — ข้อกล่าวอ้างที่สามารถทดสอบได้ในหลักการแต่ยังไม่มีการทดสอบต่อสาธารณะ เพราะยังไม่มีใครเผยแพร่ว่ามีกี่ดีพลอยเมนต์ที่เข้าเงื่อนไขทั้งสองข้อนั้น ตำแหน่งของ JFrog คือคะแนนที่ตนกำหนดในฐานะ CNA ซึ่งยังคงอยู่ในบันทึก CVE และใน NVD จนกว่าหนึ่งในสองฝ่ายจะเผยแพร่ฉบับแก้ไข การตีความเชิงปฏิบัติการก็เหมือนกันไม่ว่าจะทางใด: ช่องโหว่นี้เป็นของจริงและได้รับการตรวจสอบแบบ end to end บน container image ที่เผยแพร่แล้ว แพตช์ออกก่อนคำเตือน ซีรีส์ 1.6 ไม่มีแพตช์เลย และอินสแตนซ์ใดก็ตามที่รันโดยปิดการรับรองความถูกต้องบน listener ที่เข้าถึงได้ ควรถือเป็นเหตุการณ์ด้านข้อมูลรับรองมากกว่าจะเป็นแพตช์ที่ต้องจัดตาราง