MaxKB แนบ Shell Tool ให้กับผู้ช่วยที่เปิดใช้งานเครื่องมือทุกตัว และไม่เคยจำกัดการเข้าถึงเลย

MaxKB ซึ่งเป็นแพลตฟอร์มผู้ช่วยองค์กรแบบโอเพนซอร์สที่เผยแพร่ภายใต้องค์กร GitHub ชื่อ 1Panel-dev ได้สร้างแชตเอเจนต์ของตนบนเฟรมเวิร์กที่เพิ่มเครื่องมือเชลล์อย่างเงียบ ๆ ทุกครั้งที่มีการส่งแบ็กเอนด์ที่รองรับเชลล์เข้ามา — และ MaxKB ไม่เคยนำเครื่องมือนั้นออกหรือขอให้ใครอนุมัติการใช้งาน ความบกพร่องนี้คือ CVE-2026-77521 ซึ่งเผยแพร่เป็นคำแนะนำ GitHub GHSA-f36j-f34j-h3rx เมื่อวันที่ 2 กันยายน 2026 และได้คะแนน 10.0 จาก 10 ภายใต้ CVSS 3.1 สำหรับกรณีของผู้ช่วยแบบสาธารณะหรือแบบฝัง Lasso Security ซึ่งเป็นผู้ค้นพบและรายงาน ได้สาธิตว่าข้อความแชต — หรือข้อความที่ผู้ช่วยเพียงแค่รับเข้ามาผ่านการดึงข้อมูลหรือเอกสารที่อัปโหลด — สามารถผลักดันให้โมเดลเรียกใช้คำสั่งได้: บนการติดตั้งแบบ bare-metal โดยตรงบนโฮสต์ และบนคอนเทนเนอร์ทางการผ่านตัวห่อที่นักวิจัยกล่าวว่าสามารถข้ามได้ด้วยเซมิโคลอน ไม่มีแหล่งอ้างอิงใดบันทึกว่าช่องโหว่นี้ถูกใช้ประโยชน์ในโลกจริง ระดับความรุนแรง การประเมินความเชื่อมั่น และรายการแหล่งที่มาของบันทึกนั้นอยู่ใน คลังเหตุการณ์ AI ควบคู่กับรายการ MaxKB และเครื่องมือเอเจนต์ที่อยู่ใกล้เคียงจากชุดการเปิดเผยเดียวกัน

MaxKB เป็นผลิตภัณฑ์แบบโฮสต์เองสำหรับสร้างผู้ช่วยแบบ retrieval-augmented: ผู้ดูแลระบบสร้างผู้ช่วยขึ้นมา แนบความสามารถต่าง ๆ เข้ากับผู้ช่วยนั้น — เครื่องมือ เซิร์ฟเวอร์ Model Context Protocol สกิล แอปพลิเคชันย่อย — เชื่อมต่อฐานความรู้ที่สร้างขึ้นจากเอกสารที่อัปโหลดหรือเว็บไซต์ที่ถูกครอว์ล และจากนั้นเปิดให้เข้าถึงผู้ช่วยผ่านคอนโซลที่ต้องยืนยันตัวตน หรือในรูปแบบวิดเจ็ตแชทสาธารณะที่ฝังได้ ความอเนกประสงค์นั้นเองคือจุดที่ถูกเปิดเผย เงื่อนไขการทริกเกอร์ของคำแนะนำด้านความปลอดภัยไม่ใช่การกำหนดค่าที่ผิดปกติ แต่เป็นการกำหนดค่าปกติทั่วไป: ผู้ช่วยใดก็ตามที่มีความสามารถอย่างน้อยหนึ่งรายการแนบอยู่จะกำหนดให้แชทของตนเดินผ่านเส้นทางเอเจนต์ที่ได้รับผลกระทบ ในขณะที่แชทที่ไม่มีความสามารถใด ๆ แนบอยู่จะไม่เป็นเช่นนั้น บทความของ Lasso ระบุว่าโปรเจกต์นี้เป็นหนึ่งในโปรเจกต์ที่ได้รับการนำไปใช้อย่างกว้างขวางมากกว่าในหมวดหมู่เดียวกัน และตั้งข้อสังเกตว่าโดยปกติแล้ว MaxKB ถูกติดตั้งใช้งานเป็นบริการแบบหลายผู้เช่า — ซึ่งวางคำสั่งที่ทำงานในฐานะผู้ใช้แอปพลิเคชันไว้ใต้โมเดลการเช่า แทนที่จะอยู่ภายในส่วนของผู้เช่ารายใดรายหนึ่ง

เครื่องมือ shell มาพร้อมกับเฟรมเวิร์ก ไม่ใช่ผลิตภัณฑ์

MaxKB สร้างเอเจนต์เหล่านี้ด้วยไลบรารี deepagents ของ LangChain โดยปักหมุดไว้ที่เวอร์ชัน 0.6.11 ในไฟล์ pyproject.toml ของโปรเจกต์ทั้งที่แท็กที่มีช่องโหว่และแท็กปัจจุบัน ในไฟล์ apps/application/flow/tools.py ที่บรรทัด 467 ของแท็ก v2.10.3-lts โปรเจกต์เรียก create_deep_agent โดยตั้งค่า backend เป็น SandboxShellBackend ซึ่งเป็นคลาสย่อยของ MaxKB ที่รันคำสั่งบนโฮสต์ ตามคำแนะนำด้านความปลอดภัย deepagents จะเพิ่มชุดเครื่องมือโดยอัตโนมัติทุกครั้งที่มีการส่ง shell backend ในลักษณะนั้น ได้แก่ execute, ls, read_file, write_file, edit_file, glob และ grep เครื่องมือเหล่านี้ไม่ได้อยู่ในอาร์กิวเมนต์ tools=list ซึ่งมีเพียงเครื่องมือของผู้ปฏิบัติงานเอง เครื่องมือ MCP และเครื่องมือสกิลเท่านั้น จึงไม่สามารถลบออกจากอินเทอร์เฟซหรือผ่านการกำหนดค่าได้

MaxKB ก็ไม่ส่ง excluded_tools ซึ่งเป็นอาร์กิวเมนต์ของไลบรารีที่จะตัดเครื่องมือเหล่านั้นออก คำเตือนด้านความปลอดภัยระมัดระวังในการอธิบายว่าเหตุใดเรื่องนี้จึงสำคัญแม้ในฐานะมาตรการแก้ไข: excluded_tools "นำเครื่องมือออกจากสิ่งที่โมเดลถูกบอก ไม่ใช่จาก executor" ความแตกต่างระหว่างเครื่องมือที่โมเดลไม่รู้จักกับเครื่องมือที่ไม่สามารถทำงานได้ คือบั๊กนี้ทั้งหมดในรูปแบบย่อ

ประตูที่ระบุเครื่องมือสามอย่างและละเว้นอย่างที่สี่

การควบคุมแบบ human-in-the-loop ใน call เดียวกันนั้นมีเพียงบรรทัดเดียว และระบุการดำเนินการสามอย่างไว้: interrupt_on={"write_file": False, "read_file": False, "edit_file": False} โดยมีการระบุชื่อการเขียนไฟล์ การอ่านไฟล์ และการแก้ไขไฟล์ ส่วนการเรียกใช้คำสั่ง (command execution) ไม่ได้เป็นคีย์ในดิกชันนารีเลย ตามการตีความของ advisory นั่นหมายความว่าจะไม่มีการขออนุมัติสำหรับ execute — การดำเนินการกับระบบไฟล์ทั้งสามถูกระบุชื่อและตั้งค่าไว้อย่างชัดเจนว่าไม่ให้ interrupt และเครื่องมือ shell ไม่ได้ถูกระบุชื่อไว้เลย

เมื่อนำมารวมกัน เส้นทางคือ: ข้อความที่ไม่น่าเชื่อถือไปถึงโมเดล โมเดลเรียกใช้ execute และคำสั่งก็ทำงาน คำแนะนำระบุสองวิธีที่ข้อความที่ไม่น่าเชื่อถือจะเข้ามาได้ วิธีตรงคือแชท — วิดเจ็ตสาธารณะหรือแบบฝัง หรือบทสนทนาของผู้เช่ารายอื่น วิธีทางอ้อมคือเนื้อหาที่ผู้ช่วยนำเข้า: เอกสาร RAG ไฟล์ที่อัปโหลด หรือหน้าเว็บที่แพลตฟอร์มดึงเข้ามาในฐานความรู้ โพสต์ของ Lasso ทำให้เส้นทางที่สองเป็นรูปธรรม โดยสังเกตว่า "กลุ่มคนที่สามารถวางข้อความไว้หน้าโมเดลมีขนาดใหญ่กว่ากลุ่มคนที่สามารถแชทกับโมเดลได้"

ในการติดตั้งแบบ bare-metal คำสั่งก็เป็นเพียงคำสั่งเท่านั้น

สิ่งที่ MaxKB ทำเกี่ยวกับการกักกัน (containment) เกิดขึ้นใน apps/application/flow/backend/sandbox_shell.py และใน v2.10.3-lts นั้นเริ่มต้นด้วยค่าดีฟอลต์ บรรทัดที่ 9 เขียนว่า _enable_sandbox = bool(int(CONFIG.get("SANDBOX", 0))) และ SANDBOX ไม่ปรากฏใน Config.defaults ใน apps/maxkb/conf.py หากไม่มีการตั้งค่า MAXKB_SANDBOX อย่างชัดเจน ค่าดังกล่าวจะเป็นศูนย์ สาขาตัวห่อ (wrapper branch) ที่บรรทัด 65 จะถูกข้ามไป และ execute จะไปถึง subprocess.run ด้วย shell=True โดยตรงบนโฮสต์ ในฐานะผู้ใช้ที่รันบริการ — ซึ่งก็คือ root ตามถ้อยคำในคำแนะนำ หากบริการนั้นรันในฐานะ root

นั่นคือการกำหนดค่าที่นักวิจัยใช้สำหรับต้นแบบพิสูจน์แนวคิดบนโฮสต์ของพวกเขา พวกเขารันโค้ดจริงของ MaxKB จากซอร์สโดยไม่ได้ตั้งค่า MAXKB_SANDBOX สร้างผู้ช่วยที่มีเครื่องมือหนึ่งรายการแนบอยู่ และส่งข้อความแชตเพียงข้อความเดียวเพื่อขอให้รันคำสั่งตรวจสอบข้อมูลระบบ เครื่องมือ execute ทำงานและเขียนไฟล์ซึ่งมีเนื้อหาเป็นผลลัพธ์ uname, id และ sw_vers ของโฮสต์เอง — ผลลัพธ์ที่เอกสารคำแนะนำระบุว่ายืนยันแล้วว่าไม่มีอยู่ภายในคอนเทนเนอร์ใด ๆ Lasso ยังบันทึกขีดจำกัดของสิ่งที่หยุดมันไว้ด้วย: ไฟล์ proof ที่ตั้งชื่ออย่างโจ่งแจ้งถูกโมเดลปฏิเสธ ขณะที่ถ้อยคำเชิงปฏิบัติการที่ดูไม่มีพิษภัยกลับไม่ถูกปฏิเสธ การจัดแนวโมเดล ในคำของพวกเขา คือ "อุปสรรคชั่วคราวเพียงบางส่วน ไม่ใช่มาตรการควบคุม"

บนอิมเมจทางการ แซนด์บ็อกซ์ทำงานได้และยังรั่วไหลอยู่

คอนเทนเนอร์อย่างเป็นทางการตั้งค่า MAXKB_SANDBOX=1 ในอิมเมจเบส ที่ installer/Dockerfile-base บรรทัดที่ 48 ดังนั้น wrapper จึงทำงานอยู่ที่นั่น — และ wrapper คือข้อบกพร่องที่สอง มันสร้างสตริงเดียวขึ้นมา: env -i LD_PRELOAD=/opt/maxkb-app/sandbox/lib/sandbox.so ตามด้วย gosu sandbox และจากนั้นคำสั่งที่โมเดลส่งมา ซึ่งถูกส่งให้เชลล์ที่ทำงานในฐานะ root เนื่องจากคำสั่งถูกแทรกเป็นข้อความ มีเพียงโทเคนแรกของคำสั่งเท่านั้นที่อยู่ภายใต้ gosu อักขระเซมิโคลอน ไพป์ การเปลี่ยนเส้นทาง หรือการแทนที่คำสั่งใด ๆ ในเอาต์พุตของโมเดล ถูกประเมินโดยเชลล์ root ภายนอกก่อนที่ sandbox จะได้เห็นมันเสียอีก

รายงานของ Lasso ระบุรูปแบบการทำงานของช่องโหว่นี้ว่า เป็นเพย์โหลดคำสั่ง env -i LD_PRELOAD=... PATH="$PATH" gosu sandbox ls; whoami; id โดยที่ ls ถูกจำกัดสิทธิ์ ส่วน whoami ไม่ถูกจำกัด และทุกอย่างหลังจากนั้นทำงานได้อย่างอิสระ ในการทดสอบ นักวิจัยสามารถเขียนไฟล์ที่มีเจ้าของเป็น root ด้วยการรีไดเรกต์ ขณะที่คำสั่งภายในแซนด์บ็อกซ์ถูกบล็อก ซ้ำร้าย ทั้ง installer/Dockerfile และ installer/Dockerfile-base ต่างก็ไม่มีคำสั่ง USER ดังนั้นอิมเมจแอปพลิเคชันจึงทำงานด้วย UID 0 — รายงานคำแนะนำยืนยันว่าพบสิทธิ์ root ขณะรัน ดังนั้นคอนเทนเนอร์จึงยังคงรันคำสั่งต่าง ๆ ได้อยู่ดี และแซนด์บ็อกซ์เพียงกำหนดว่าคำสั่งใดจะถูกมองว่าเป็นของผู้ใช้สิทธิ์ต่ำในเชิงภาพลักษณ์เท่านั้น

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

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

กลไก โหมดการปรับใช้ทั้งสอง โหมด การให้เครดิต และรีลีสที่แก้ไขแล้ว สอดคล้องกันในเอกสารสี่ฉบับ ได้แก่ คำแนะนำของ GitHub บันทึกของ NVD ที่เผยแพร่เมื่อวันที่ 21 กันยายน 2026 บทวิเคราะห์ทางเทคนิคของ Lasso เองเมื่อวันที่ 10 กันยายน 2026 และรายงานของ GBHackers เมื่อวันที่ 22 กันยายน 2026 ซึ่งเป็นการรายงานจากสื่ออิสระเพียงแห่งเดียวที่พบสำหรับ CVE นี้ ไม่มีแหล่งใดโต้แย้งส่วนใดของการค้นพบนี้ และคลังเก็บข้อมูลบันทึกรายการนี้ว่าไม่มีการโต้แย้งในระดับความเชื่อมั่นสูงสุด

สิ่งที่แหล่งข้อมูลเหล่านี้ไม่มีคือมาตรวัดการเปิดเผยใด ๆ ทั้งสิ้น ไม่มีจำนวนการติดตั้ง MaxKB ไม่มีจำนวนผู้ช่วยที่เชื่อมต่ออินเทอร์เน็ตหรือฝังตัวอยู่ ไม่มีผลการสแกน ไม่มีข้อมูลเทเลเมทรี และไม่มีผู้เสียหายที่ระบุชื่อได้ ไม่มีสิ่งใดในบันทึกที่แสดงว่าช่องโหว่นี้ถูกใช้โจมตีใคร และการประเมินการถูกใช้ประโยชน์ของ CISA เองก็เห็นพ้องกันว่า บล็อก SSVC ที่แนบมากับบันทึก NVD เมื่อวันที่ 22 กันยายน 2026 ให้คะแนนการถูกใช้ประโยชน์เป็น "poc" ความสามารถในการทำงานอัตโนมัติเป็น "yes" และผลกระทบทางเทคนิคเป็น "total" แบบจำลอง EPSS ของ FIRST ประเมินความน่าจะเป็นของการถูกใช้ประโยชน์ใน 30 วันข้างหน้าไว้ที่ 1.05 เปอร์เซ็นต์ ซึ่งอยู่ที่เปอร์เซ็นไทล์ที่ 64 ณ วันที่ 27 ตุลาคม 2026 และ CVE นี้ไม่ปรากฏในแคตตาล็อก Known Exploited Vulnerabilities ของ CISA ณ วันที่ 27 ตุลาคม 2026 ระดับการประเมินของคลังข้อมูลเองก็สะท้อนหลักฐานเดียวกัน คือ ความรุนแรงสูง และความเสียหายจริงเป็นเท็จ

คะแนน 10.0 นี้ควรระบุขอบเขตไว้ให้ชัดเจน เพราะเป็นตัวเลขที่มีแนวโน้มจะถูกยกมาอ้างโดยไม่มีบริบทมากที่สุด เป็นคะแนนสำหรับกรณีผู้ช่วยแบบสาธารณะหรือแบบฝังตัว ซึ่งเวกเตอร์ CVSS ระบุว่า AV:N/AC:L/PR:N/UI:N/S:C — เข้าถึงได้ผ่านเครือข่าย ไม่ต้องมีสิทธิ์ ไม่ต้องมีการโต้ตอบจากผู้ใช้ และมีการเปลี่ยนแปลงขอบเขต เนื่องจากคำสั่งภายในผู้ช่วยข้ามไปยังระบบปฏิบัติการโฮสต์ คะแนนนี้เป็นของ CNA และ CNA ในที่นี้คือโครงการให้คำแนะนำด้านความปลอดภัยของ GitHub ซึ่งเป็นจุดที่ตัวระบุแหล่งที่มาของบันทึก CVE ชี้ไปด้วย NVD มีเวกเตอร์เดียวกันเป็นเมตริกทุติยภูมิ และ ณ วันที่ 28 ตุลาคม 2026 ระบุรายการนี้ในสถานะ "Deferred" ซึ่งหมายความว่า NVD เผยแพร่การวิเคราะห์ของผู้กำหนดหมายเลข แทนที่จะเป็นการวิเคราะห์ของตนเอง

แพตช์ถูกปล่อยออกไปหนึ่งเดือนก่อนที่ประกาศคำแนะนำจะออกมา

ลำดับเหตุการณ์นั้นไล่ย้อนหลังจากการเผยแพร่ และเป็นส่วนที่ชวนให้เดาได้ยากที่สุดของบันทึกนี้ Lasso รายงานข้อบกพร่องนี้แบบส่วนตัวผ่านช่องทาง advisory ของ GitHub เมื่อวันที่ 8 กรกฎาคม 2026 MaxKB ตอบกลับในวันถัดมา โดยจำกัดขอบเขตของรายงานให้ครอบคลุมเฉพาะอิมเมจอย่างเป็นทางการ และขอ proof of concept ในรูปแบบคอนเทนเนอร์ นักวิจัยได้จัดส่งสิ่งนั้นพร้อมกับการข้ามผ่านแซนด์บ็อกซ์ให้ในวันที่ 10 กรกฎาคม คอมมิตที่แก้ไข 594f50f2 ถูกนำเข้าสู่โค้ดเมื่อวันที่ 9 กรกฎาคม — หนึ่งวันหลังการรายงาน — และเขียน sandbox_shell.py ใหม่ เพื่อให้สตริงคำสั่งของโมเดลถูกแยกวิเคราะห์ก่อน แล้วจึงเติมคำนำหน้า gosu ให้กับทุกคำสั่งอย่างง่าย แทนที่จะเติมให้เฉพาะคำสั่งแรกเท่านั้น โดยแต่ละรายการอาร์กิวเมนต์ถูกใส่เครื่องหมายคำพูดใหม่ เพื่อไม่ให้การแทนที่หลุดออกไปยังเชลล์แม่ได้ บทความของ Lasso อธิบายการเปลี่ยนแปลงนี้ว่าคือการเติมคำนำหน้า gosu "ให้กับทุกคำสั่งอย่างง่าย ไม่ใช่แค่คำสั่งแรก"

รีลีสที่มีการแก้ไขนี้ คือ v2.10.5-lts เผยแพร่เมื่อ 6 สิงหาคม 2026 คำแนะนำของ GitHub ถูกเผยแพร่เมื่อ 2 กันยายน NVD เผยแพร่ CVE เมื่อ 21 กันยายน บล็อก SSVC ของ CISA ถูกเพิ่มเข้ามา และ GBHackers รายงานเมื่อ 22 กันยายน ส่วนบทความของ Lasso เองปรากฏเมื่อ 10 กันยายน — อยู่กลางลำดับดังกล่าว ไม่ใช่ช่วงเริ่มต้น ผู้ดูแลระบบที่ติดตามแท็กของรีลีสแทนการติดตามฟีดคำแนะนำมีแพตช์ล่วงหน้าประมาณสี่สัปดาห์ก่อนคำเตือน

ขอบเขตของเวอร์ชันสมควรได้รับความสนใจมากกว่าที่ประกาศคำเตือนระบุไว้ เพราะแหล่งข้อมูลหลักสองแหล่งขัดแย้งกัน และคลังโค้ดเป็นตัวชี้ขาดคำถามนี้ ฟิลด์ในแบบฟอร์มของประกาศบันทึกเวอร์ชันที่ได้รับผลกระทบเป็น "<= 2.10.3-lts" พร้อมหมายเหตุว่าสิ่งนี้ได้รับการตรวจสอบบน 2.10.3-lts แล้ว และเส้นทางที่มีช่องโหว่ "อาจจะ" ส่งผลต่อทุกเวอร์ชันที่สร้างเอเจนต์ด้วยวิธีนี้ บทความของ Lasso เองระบุช่วงที่ได้รับผลกระทบเป็น "<= 2.10.4-lts" แท็กยืนยันช่วงที่กว้างกว่า: v2.10.4-lts ซึ่งเผยแพร่เมื่อ 16 กรกฎาคม 2026 มีไฟล์ sandbox_shell.py ขนาด 75 บรรทัดเดียวกันกับ v2.10.3-lts และไฟล์ที่เขียนใหม่ขนาด 311 บรรทัดปรากฏครั้งแรกใน v2.10.5-lts ผู้ดูแลระบบที่ใช้ 2.10.4-lts ซึ่งอ่านเพียงช่วงเวอร์ชันในประกาศคำเตือนเท่านั้นจะสรุปว่าตนอยู่นอกช่วงดังกล่าว แต่ไม่ใช่เช่นนั้น

สิ่งที่การแก้ไขนี้ไม่ได้ทำ

สิ่งที่ 2.10.5-lts แก้ไขคือ wrapper: มันไม่สร้างสตริงเชลล์เพียงสตริงเดียวภายใต้ root อีกต่อไป สิ่งที่มันไม่ได้ทำคือแก้ไขสิ่งใด ๆ เกี่ยวกับ tool นั้น การอ่าน repository โดยตรงที่แท็ก v2.10.8-lts ซึ่งเผยแพร่เมื่อวันที่ 22 ตุลาคม 2026 แสดงให้เห็นว่า agent ยังคงถูกสร้างด้วย backend=SandboxShellBackend และ interrupt_on ยังคงมีคีย์สามคีย์พอดี — write_file, read_file และ edit_file — โดยไม่มี execute ข้อเสนอแนะการแก้ไขสองข้อแรกของ advisory คือการสร้างบน backend ที่ไม่ทำการ execute โดยค่าเริ่มต้น และการเพิ่ม "execute": True ลงใน approval map ไม่ปรากฏอยู่ใน release นั้น

คำแนะนำแบบ fail-closed ถูกนำมาใช้ในภายหลัง ใน v2.10.7-lts และมีความสำคัญต่อโหมดการติดตั้งที่อยู่ในสถานะแย่ที่สุด เผยแพร่เมื่อวันที่ 15 ตุลาคม 2026 โดยเปลี่ยนบรรทัดใน sandbox_shell.py จาก CONFIG.get("SANDBOX", 0) เป็น CONFIG.get("SANDBOX", 1) การติดตั้งจากซอร์สหรือแบบ bare-metal ที่ไม่เคยตั้งค่าตัวแปรนี้ ตอนนี้มี wrapper เปิดใช้งานเป็นค่าเริ่มต้นแทนที่จะปิด ซึ่งในความหมายแคบ ๆ แล้วคือคำแนะนำ “fail closed on non-container deploys” ประกาศด้านความปลอดภัยเรียกร้องมากกว่านั้นภายใต้หัวข้อเดียวกัน — คือให้โฟลว์ที่สามารถ execute ได้ปฏิเสธที่จะเริ่มทำงานเมื่อ sandbox runtime ไม่พร้อมใช้งาน — และเรียกร้องแยกต่างหากว่า wrapper ต้องไม่สร้างสตริงคำสั่งสำหรับ root shell เลย ในฝั่งคอนเทนเนอร์ เป็นข้อเท็จจริงมากกว่าคำแนะนำ: ทั้ง installer/Dockerfile และ installer/Dockerfile-base ไม่มีไดเรกทีฟ USER ที่แท็ก v2.10.8-lts ดังนั้นอิมเมจแอปพลิเคชันยังคงเริ่มทำงานในฐานะ root

เมื่ออ่านประกอบกัน สถานะของบันทึก ณ วันที่ 28 ตุลาคม 2026 เป็นดังนี้ ครึ่งหลังของช่องโหว่ — แซนด์บ็อกซ์ที่อัฒภาคหลุดออกไป — ถูกปิดแล้ว และค่าเริ่มต้นแบบ fail-open บนการติดตั้งโฮสต์ก็ถูกปิดแล้ว ครึ่งแรก ซึ่งเป็นเครื่องมือ execute ที่มาพร้อมออบเจ็กต์แบ็กเอนด์และไม่ใช่คีย์ในแมปการอนุมัติ ยังคงเป็นวิธีที่ MaxKB สร้างผู้ช่วยที่เปิดใช้เครื่องมือ คำแนะนำการแก้ไขของผู้วิจัยเองเป็นแบบจำกัดขอบเขต: อัปเกรดเป็น 2.10.5-lts หรือใหม่กว่า และรันเวอร์ชัน Docker โดยเปิดแซนด์บ็อกซ์ GBHackers ถ่ายทอดคำแนะนำเดียวกันพร้อมรายการที่กว้างขึ้นสำหรับผู้ดูแลระบบ — ปิดแบ็กเอนด์ของเอเจนต์ที่รองรับเชลล์ เว้นแต่จำเป็นต้องเรียกใช้โค้ดอย่างชัดเจน กำหนดให้ต้องมีการอนุมัติจากมนุษย์ก่อนการดำเนินการ execute ใด ๆ รันคอนเทนเนอร์ในฐานะ non-root และถือว่าหน้าเว็บที่ถูกครอว์ล เอกสาร RAG และไฟล์อัปโหลดเป็นอินพุตที่ไม่น่าเชื่อถือ

บันทึก MaxKB อีกฉบับจากชุดเดียวกันในเดือนกันยายน

รายการ MaxKB รายการที่สองจากชุดนี้ในคลังเป็นบั๊กอีกตัวที่แตกต่างออกไปและมีจุดจบที่แย่กว่า CVE-2026-77516 ซึ่งเผยแพร่ไปยัง NVD เมื่อวันที่ 21 กันยายน 2026 เช่นกัน เป็นการข้ามการตรวจสอบสิทธิ์ (permission bypass) ไม่ใช่การฉีดคำสั่ง (command injection): ตั้งแต่เวอร์ชัน 2.0.0 ถึง 2.9.2 สมาชิก workspace ที่มีบทบาทต่ำสุด ซึ่งถูกปฏิเสธการเข้าถึงเครื่องมืออย่างชัดเจนผ่าน WorkspaceUserResourcePermission ยังคงสามารถผูกตัวระบุของเครื่องมือนั้นผ่าน tool_ids, skill_tool_ids หรือ mcp_tool_ids และเรียกใช้งานมันผ่านเส้นทางการส่งงานของ agent หรือ workflow ได้ เส้นทางการส่งงานไม่ได้นำการอนุญาตรายเครื่องมือที่เส้นทางเฉพาะของเครื่องมือบังคับใช้มาใช้ซ้ำ และการเรียกใช้เครื่องมือจะถอดรหัส init_params ฝั่งเซิร์ฟเวอร์ ดังนั้นผู้เรียกจึงได้รับข้อมูลรับรองที่มาพร้อมกับเครื่องมือที่ตนถูกปฏิเสธ คะแนนของมันคือ 5.4 และคำอธิบายของ NVD ปิดท้ายด้วยประโยคที่ CVE-2026-77521 ไม่จำเป็นต้องมี: "ณ เวลาที่ตรวจทานนี้ ยังไม่มีเวอร์ชันที่แก้ไขแล้วให้ใช้งาน"

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

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