MaxKB: เส้นทางการกระจายงานของเอเจนต์เปิดช่องให้ผู้ใช้ที่ถูกปฏิเสธสิทธิ์การใช้เครื่องมือยังสามารถเรียกใช้เครื่องมือนั้นและอ่านข้อมูลรับรองของเครื่องมือได้

MaxKB ผู้ช่วย AI องค์กรแบบโอเพนซอร์สที่ดูแลโดย 1Panel-dev มีรายการสิทธิ์แบบรายผู้ใช้และรายเครื่องมือ เพื่อให้ผู้ดูแลระบบสามารถให้สิทธิ์สมาชิกเวิร์กสเปซเข้าถึงเครื่องมือหนึ่งและปฏิเสธอีกเครื่องมือหนึ่งได้ ตามประกาศด้านความปลอดภัยที่เผยแพร่เมื่อวันที่ 2 กันยายน 2026 การปฏิเสธดังกล่าวมีผลกับเส้นทางของเครื่องมือเอง แต่ไม่มีผลกับเส้นทางที่เอเจนต์หรือเวิร์กโฟลว์ใช้เรียกเครื่องมือเดียวกัน สมาชิกเวิร์กสเปซที่มีบทบาทต่ำสุดสามารถระบุตัวระบุของเครื่องมือที่ถูกปฏิเสธขณะสร้างเวิร์กโฟลว์ รันเวิร์กโฟลว์ และได้รับไม่เพียงผลลัพธ์ของเครื่องมือเท่านั้น แต่ยังได้รับข้อมูลรับรองที่ MaxKB ถอดรหัสฝั่งเซิร์ฟเวอร์เพื่อรันเครื่องมือนั้นด้วย เวอร์ชัน 2.0.0 ถึง 2.9.2 ได้รับผลกระทบ และประกาศดังกล่าวไม่ได้ระบุเวอร์ชันที่แก้ไขแล้ว บันทึกนี้ — การข้ามการตรวจสอบสิทธิ์การส่งต่อเครื่องมือของ MaxKB — เป็นหนึ่งในรายการที่ปรากฏใน OrcaRouter AI Incident Archive ซึ่งเก็บชุดบันทึกทั้งหมดและรายการข้างเคียงของเหตุการณ์นี้

สิ่งที่ทำให้กรณีนี้คุ้มค่าที่จะอ่านอย่างละเอียดไม่ใช่คะแนน但它就是ข้อเท็จจริงที่ว่าผลิตภัณฑ์มีมาตรการตรวจสอบที่ถูกต้องอยู่แล้ว นำไปใช้กับประตูที่ชัดเจน และปล่อยให้ประตูที่สองซึ่งนำไปสู่ความสามารถเดียวกันนั้นไม่ถูกเฝ้าระวัง คำแนะนำด้านความปลอดภัย GHSA-383v-fx78-pphm เขียนโดยนักวิจัยที่ค้นพบและเผยแพร่ผ่านระบบคำแนะนำด้านความปลอดภัยของ GitHub เมื่อเวลา 07:43 UTC ของวันที่ 2 กันยายน 2026 โดยให้เครดิต Matteo Panzeri (@matte1782) บันทึก CVE-2026-77516 ตามมาในวันที่ 21 กันยายน 2026

สิ่งที่ประกาศนี้กำหนดไว้

โมเดลแบบต่อเครื่องมือของ MaxKB คือ WorkspaceUserResourcePermission ซึ่งในเอกสารคำแนะนำอธิบายว่าเป็น allow-list แบบ default-deny ที่ถูก resolve ณ เวลาที่มีคำขอ เส้นทางของเครื่องมือโดยเฉพาะจะบังคับใช้มาตรการนี้ เอกสารคำแนะนำระบุการบังคับใช้ไว้ใน apps/tools/views/tool.py โดยที่ Operate.put, Operate.get, Debug.post, Export.get และ Delete ต่างมีการตรวจสอบสิทธิ์การดู (view-permission) เทียบกับสิทธิ์เครื่องมือในเวิร์กสเปซของผู้เรียก Debug.post เป็นเส้นทางที่ใกล้เคียงกับการเรียกใช้เครื่องมือโดยตรงที่สุด และถูกควบคุมด้วยเงื่อนไขการอนุญาต

เส้นทางการ Dispatch ของ agent และ workflow ไม่ได้นำการตรวจสอบนั้นมาใช้ซ้ำ คำแนะนำ (advisory) ชี้ถึงสามจุดแยกกันที่การตรวจสอบนี้หายไป ใน apps/application/serializers/application.py serializer ของ application ผูก tool_ids, skill_tool_ids และ mcp_tool_ids ตรงจากข้อมูลที่ส่งเข้ามาในคำขอ โดยไม่มีการอนุญาตเป็นรายเครื่องมือ — และ advisory ระบุว่าความไม่สมมาตรนี้มองเห็นได้ในไฟล์เดียวกัน เพราะ knowledge_id_list ถูกตรวจสอบเทียบกับฐานความรู้ที่ผู้ใช้เข้าถึงได้ในอีกไม่กี่บรรทัดถัดลงไป ในขณะที่เครื่องมือต่าง ๆ กลับไม่ได้รับการตรวจสอบ ใน apps/common/utils/shared_resource_auth.py filter_authorized_ids ปล่อยผ่านเครื่องมือทุกตัวในเวิร์กสเปซของผู้เรียกเองโดยไม่มีเงื่อนไข ด่านตรวจข้ามเวิร์กสเปซที่มันพึ่งพาอยู่นั้นเป็น hook ที่มีเฉพาะรุ่น enterprise ซึ่งไม่มีอยู่ใน community edition และมันไม่เคยตรวจสอบกับ WorkspaceUserResourcePermission เลย และที่จุดปลายทาง apps/application/flow/step_node/tool_lib_node/impl/base_tool_lib_node.py ได้รันโค้ดที่จัดเก็บไว้ของเครื่องมือด้วย init_params ที่ถูกถอดรหัสโดย rsa_long_decrypt ภายใต้ตัวตนของ application โดยไม่มีการตรวจสอบสิทธิ์เป็นรายเครื่องมือ

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

การสาธิตด้วยตัวเลขของผู้วิจัยเอง

เอกสารแนะนำรายงานการยืนยันแบบไดนามิกบน v2.9.2 ซึ่งรันจากอิมเมจ all-in-one อย่างเป็นทางการ 1panel/maxkb:v2.9.2 การตั้งค่าประกอบด้วยเวิร์กสเปซหนึ่งแห่ง ผู้ดูแลระบบหนึ่งคน และสมาชิกคนที่สองที่มีบทบาท USER ผู้ดูแลระบบสร้าง Tool A และ Tool B ใส่ซีเคร็ตแบบสุ่มใหม่ลงใน init_paramsของ Tool B และเขียน body ของ Tool B ให้คืนค่าซีเคร็ตนั้นเมื่อถูกเรียกใช้งาน จากนั้นสมาชิกได้รับสิทธิ์ระดับรายเครื่องมือสำหรับ Tool A เท่านั้น และเอกสารแนะนำระบุว่าสถานะการไม่ให้สิทธิ์ใด ๆ สำหรับ Tool B ถูกตรวจสอบซ้ำในฐานข้อมูลหลังการรัน

ครึ่งหนึ่งที่ถูกปฏิเสธของการทดสอบส่งคืนสิ่งที่ผลิตภัณฑ์สัญญาไว้ ในฐานะสมาชิก เส้นทางดีบักสำหรับ Tool B ตอบกลับ 403 เส้นทางอัปเดตตอบกลับ 403 เส้นทางส่งออกตอบกลับ 403 และ Tool A ที่ได้รับสิทธิ์ส่งคืน 200 เพื่อตรวจสอบความถูกต้องเบื้องต้น ครึ่งหนึ่งของการข้ามได้ผูก Tool B เข้ากับแอปพลิเคชันเวิร์กโฟลว์ผ่านโหนดไลบรารีเครื่องมือ — การผูกได้รับการยอมรับด้วย HTTP 200 และไม่มีการตรวจสอบรายเครื่องมือ — และการรันเวิร์กโฟลว์ส่งคืน HTTP 200 พร้อมเนื้อหาที่มีชื่อของเครื่องมือ ความลับเซนติเนล และรายการคีย์ ["api_key"]

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

คะแนนหนึ่งถูกเผยแพร่ ส่วนคะแนนที่สูงกว่านั้นถูกโต้แย้ง

คะแนนที่แนบมากับ CVE-2026-77516 คือ CVSS 3.1 5.4 ระดับ Medium โดยมีเวกเตอร์ AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N บันทึกของ NVD ระบุว่าคะแนนดังกล่าวมาจากฟีด advisory ของ GitHub ไม่ใช่จากการวิเคราะห์ของ NVD เอง และรายการนี้มีสถานะ Deferred หมายความว่า NVD ยังไม่ได้เพิ่มข้อมูลเชิงลึกให้ การจัดประเภทของคลังข้อมูลเองเป็นไปตามคะแนนที่เผยแพร่นั้น คือความรุนแรงระดับปานกลาง และไม่มีการบันทึกความเสียหายที่เกิดขึ้นจริง

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

มีการประเมินเพิ่มเติมอีกสองรายการที่อยู่ในบันทึกอย่างเป็นทางการ จุดตัดสินใจ SSVC ของ CISA ซึ่งถูกเพิ่มไว้ในรายการ NVD เมื่อวันที่ 28 กันยายน 2026 บันทึกการถูกใช้ประโยชน์ว่า "poc" ความสามารถในการทำอัตโนมัติว่า "no" และผลกระทบทางเทคนิคว่า "partial" — ค่า "poc" สะท้อนว่ามี proof of concept อยู่ ซึ่งมีอยู่จริงในคำแนะนำดังกล่าวเอง ไม่ใช่ข้อค้นพบว่ามีการถูกใช้ประโยชน์ในสภาพจริง แบบจำลอง EPSS ของ FIRST ระบุความน่าจะเป็นของการถูกใช้ประโยชน์ใน 30 วันข้างหน้าอยู่ที่ 0.242% อยู่ในเปอร์เซ็นไทล์ที่ 15.2 ในการประเมินเมื่อวันที่ 27 ตุลาคม 2026

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

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

ในรีโพซิทอรี MaxKB ฟังก์ชันที่ปิดเส้นทางการ dispatch — validate_bound_tool_permissions และ get_authorized_tool_ids ใน apps/application/serializers/application.py — ไม่ปรากฏในแท็ก v2.9.2 และใน v2.10.2-lts, v2.10.3-lts และ v2.10.4-lts แต่ปรากฏตั้งแต่ v2.10.5-lts เป็นต้นไป รีลีสนั้นเผยแพร่เมื่อวันที่ 6 สิงหาคม 2026 ก่อนคำแนะนำด้านความปลอดภัยสี่สัปดาห์ แท็กเดียวกันยังเพิ่มการตรวจสอบเครื่องมือรายผู้ใช้ใน base_tool_lib_node.py โดยอ้างอิง WorkspaceUserResourcePermission และเพิ่มตัวกรองที่คำนึงถึงผู้ใช้ใน shared_resource_auth.py — กล่าวคือมัน implements โครงร่างของขั้นตอนการแก้ไขสามขั้นที่คำแนะนำด้านความปลอดภัยแนะนำในภายหลัง

ไม่มีใครระบุความเชื่อมโยงดังกล่าวต่อสาธารณะ บันทึกการออกรุ่น v2.10.5-lts ไม่ได้กล่าวถึงการแก้ไขสิทธิ์ของเครื่องมือ แต่ระบุรายการด้านความปลอดภัยที่ไม่เกี่ยวข้องกันสี่รายการ และงานฟีเจอร์กับการแก้บั๊กอีกจำนวนหนึ่ง คำแนะนำด้านความปลอดภัยไม่ได้ระบุชื่อ 2.10.5 และช่วงที่ได้รับผลกระทบสิ้นสุดเพียงที่ 2.9.2 ซึ่งเป็นรุ่นสุดท้ายในสาย 2.9 ประวัติการออกรุ่นไม่พบแพตช์ 2.9.x ใดๆ หลังคำแนะนำด้านความปลอดภัย ดังนั้นการติดตั้งใช้งานบน 2.9.2 จึงไม่มีบิลด์ที่ได้รับการแก้ไขภายในสายของตนเอง รุ่นปัจจุบันคือ v2.10.8-lts ซึ่งเผยแพร่เมื่อวันที่ 22 ตุลาคม 2026 โดยบันทึกของรุ่นดังกล่าวอธิบายถึงการแก้ไขใน X-Pack เกี่ยวกับการอนุญาตใช้เครื่องมือที่ใช้ร่วมกัน มากกว่าสิ่งใดในเส้นทางดิสแพตช์ของ Community Edition

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

มีสามสิ่งที่ควรแยกออกจากการสาธิตนี้ ประการแรก ไม่มีรายงานสาธารณะว่าการบายพาสนี้ถูกนำไปใช้กับใคร บันทึกที่มีอยู่เป็นช่องโหว่ที่ถูกค้นพบ ไม่ใช่การบุกรุกที่ถูกสอบสวน จึงไม่มีผู้เสียหาย ไม่มีผู้กระทำที่ระบุตัวได้ และไม่มีความเสียหาย อีกทั้ง proof of concept ในคำแนะนำด้านความปลอดภัยนั้นถูกเรียกใช้โดยนักวิจัยในพื้นที่ทำงานที่ควบคุมได้ ประการที่สอง ดูเหมือนจะไม่มีองค์กรข่าว หน่วยงานกำกับดูแล หรือทีมวิจัยชุดที่สองใดวิเคราะห์ข้อบกพร่องนี้ การรายงานที่มีอยู่จำกัดอยู่เฉพาะในฐานข้อมูลช่องโหว่และตัวรวบรวมข้อมูล ซึ่งรวมถึง VulDB ฐานข้อมูลของ Rapid7, Armis, SOCRadar และ openCVE โดยรายการเหล่านี้ระบุ CVE และนำคำอธิบายจากคำแนะนำด้านความปลอดภัยมาแสดง และไม่มีรายการใดเสนอการประเมินโค้ดอย่างเป็นอิสระ กลไกตามที่อธิบายไว้ในที่นี้จึงอาศัยคำแนะนำด้านความปลอดภัยเพียงฉบับเดียวและซอร์สโค้ดของผู้จำหน่ายเอง ประการที่สาม ไม่มีตัวเลขว่ามีการติดตั้ง MaxKB จำนวนเท่าใดที่อยู่ในช่วงที่ได้รับผลกระทบ และทั้งผู้จำหน่ายและนักวิจัยต่างไม่ได้เผยแพร่ตัวเลขดังกล่าว

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

สิ่งที่ผู้ควบคุมสามารถทำได้

แนวทางแก้ไขของคำแนะนำด้านความปลอดภัยฉบับนี้มุ่งไปที่ผู้ดูแลโค้ดมากกว่าผู้ปฏิบัติงาน และสามขั้นตอนของคำแนะนำนี้สอดคล้องกับโค้ดที่ปรากฏใน v2.10.5-lts: ใช้สิทธิ์ระดับเครื่องมือ (per-tool grant) ก่อนเรียกใช้เครื่องมือใน implementation ของ tool-library และ tool node ตรวจสอบทุกค่าที่ผูกไว้ในtool_ids, skill_tool_ids และ mcp_tool_ids ณ เวลาที่ผูก ในลักษณะเดียวกับที่ knowledge_id_list ถูกตรวจสอบอยู่แล้ว และทำให้ filter_authorized_ids ตรวจสอบสิทธิ์ระดับเครื่องมือแทนที่จะพิจารณาเฉพาะการเป็นสมาชิก workspace เท่านั้น

สำหรับทีมที่กำลังใช้งานบิลด์ที่ได้รับผลกระทบ ขั้นตอนปฏิบัติที่ได้จากคำอธิบายของประกาศคำแนะนำนั้นเองมีดังนี้

• ให้ถือว่าความลับทุกตัวที่จัดเก็บไว้ในinit_paramsของเครื่องมือบน deployment ที่ได้รับผลกระทบนั้นสามารถเข้าถึงได้โดยสมาชิกทุกคนใน workspace รวมถึงบทบาทต่ำสุด และให้หมุนเวียนข้อมูลรับรองเหล่านั้น แทนที่จะสันนิษฐานว่าการห้ามในระดับเครื่องมือได้ปกป้องข้อมูลเหล่านั้นไว้

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

• ตรวจสอบว่าเวิร์กโฟลว์และเอเจนต์ใดผูกเครื่องมือที่มีข้อมูลรับรอง (credentials) ไว้ เนื่องจากการผูกนั้นเป็นขั้นตอนที่คำแนะนำด้านความปลอดภัยระบุว่าถูกยอมรับโดยไม่มีการตรวจสอบเป็นรายเครื่องมือ

• หากกำลังอัปเกรด โปรดทราบว่าการตรวจสอบต่อผู้ใช้ปรากฏในรีโพซิทอรีตั้งแต่ v2.10.5-lts เป็นต้นไป และไม่มีรีลีสใดถูกระบุว่าเป็นตัวแก้ไขโดย advisory — ผู้ดูแลระบบที่พึ่งพาการอัปเกรดกำลังพึ่งพาซอร์สโค้ดที่ติดแท็ก ไม่ใช่แถลงการณ์แพตช์จากผู้จำหน่าย

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

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