MISP Guard แก้ CVE-2026-116372: feed ตอบ 2xx แล้วข้ามกฎกรอง

MISP Guard แก้ CVE-2026-116372: feed ตอบ 2xx บางรหัสแล้วข้ามกฎกรอง

โครงการ MISP แก้ช่องโหว่ CVE-2026-116372 ใน misp-guard ซึ่งเป็น proxy สำหรับตรวจและบังคับกฎกับข้อมูลที่แลกเปลี่ยนระหว่างระบบ MISP จุดผิดพลาดอยู่ที่การตอบกลับจาก feed: รุ่นที่ได้รับผลกระทบตรวจเนื้อหาตามกฎเมื่อ HTTP status เป็น 200 OK แต่ปล่อย status อื่นที่ไม่ใช่ 200 ผ่านไปโดยไม่ตรวจ แม้บางรหัสในกลุ่ม 2xx จะยังมีเนื้อหาที่ MISP นำเข้าได้ ผู้ควบคุม feed ที่ตั้งค่าอยู่ในระบบจึงอาจส่งข้อมูลที่กฎของ MISP Guard ควรปฏิเสธให้ผ่านถึง MISP

ระเบียน CVE ระบุว่ากระทบ misp-guard รุ่น 1.3 และก่อนหน้า โครงการแก้ใน commit b5f606a4e57a49cc4dbf9b3ef0c6ddd19f866735 แต่ ณ เวลาที่ตรวจยังไม่มี release หมายเลขใหม่หลัง v1.3 ในคลังทางการ ดังนั้นไม่ควรอ้างว่า v1.3 ได้รับการแก้แล้ว หรือระบุหมายเลขรุ่นที่แก้ไขซึ่งผู้พัฒนายังไม่เผยแพร่ ผู้ดูแลควรตรวจ source revision หรือ image ที่ใช้งานจริงว่ารวม commit นี้หรือไม่

วันเปิดเผยและหลักฐานต้นทาง

commit แพตช์ของ MISP Guard เผยแพร่วันที่ 26 ตุลาคม 2026 เวลา 07:53 UTC พร้อมข้อความระบุชัดว่าปิดช่องที่ status 2xx ซึ่งไม่ใช่ 200 ข้ามกฎกรอง นี่เป็นหลักฐานสาธารณะจากโครงการที่อธิบายช่องโหว่และการแก้ไข ระเบียน CVE-2026-116372 เผยแพร่ครั้งแรกวันที่ 26 ตุลาคม 2026 เวลา 08:36 UTC ส่วน release v1.3 ออกตั้งแต่วันที่ 1 กันยายน 2026 และยังเป็น release ล่าสุดที่คลังแสดง ณ เวลาตรวจ เวลาที่กล่าวในบทความเป็น UTC ทั้งหมด

การแยกวันของ commit, CVE และ release สำคัญต่อการรับมือ: commit วันที่ 26 ตุลาคมคือแพตช์ที่ยืนยันได้ ส่วนการเห็นเลข CVE ใหม่เพียงอย่างเดียวไม่ได้หมายความว่ามีแพ็กเกจที่อัปเดตผ่านช่องทาง release แล้ว ผู้ดูแลที่ใช้ container image หรือแพ็กเกจจากผู้แจกจ่ายควรตรวจว่า build ของตนรวม commit นี้จริง ก่อนสรุปว่าระบบได้รับการแก้ไข

กฎถูกข้ามได้อย่างไร

ตาม คำอธิบายโครงการ misp-guard ทำงานเป็น addon ของ mitmproxy เพื่อดูทราฟฟิกการซิงก์และ feed ของ MISP และบังคับกฎที่ผู้ดูแลกำหนด เช่นกฎเกี่ยวกับ tag, taxonomy หรือข้อมูลที่ไม่ควรไหลข้ามขอบเขต ในเส้นทาง process_feed_response ก่อนแก้ไข มีการส่ง response ที่ status ไม่ใช่ 200 ผ่านโดยไม่ตรวจเนื้อหา เพราะสมมติว่า response เหล่านั้นไม่มีข้อมูลเหตุการณ์ที่ MISP จะนำเข้า

สมมติฐานนี้ไม่ครอบคลุมรหัสความสำเร็จอื่น ตัวอย่างที่ระเบียน CVE และแพตช์ระบุคือ 201 Created, 203 Non-Authoritative Information และ 206 Partial Content หาก feed ส่งรหัสเหล่านี้พร้อมข้อมูลเหตุการณ์ MISP อาจยังนำข้อมูลเข้าได้ ขณะที่ MISP Guard ไม่เคยใช้กฎตรวจ body เลย ผลคือข้อมูลจาก feed ที่ควรถูกปฏิเสธอาจเข้าถึง MISP ผ่านเส้นทางที่ผู้ดูแลเชื่อว่ามี proxy คุมอยู่

เงื่อนไขการโจมตีไม่ใช่ใครก็ส่งคำขอจากอินเทอร์เน็ตแล้วข้ามกฎได้ ผู้โจมตีต้อง ควบคุมหรือยึด feed endpoint ที่ MISP ตั้งค่าไว้ และรอให้ระบบดึง feed ตามการทำงานปกติ เมื่อสถานะและเนื้อหาตรงเงื่อนไขนี้จึงเกิดการข้ามกฎ ไม่ต้องมีการโต้ตอบของผู้ใช้เพิ่มเติมนอกเหนือจากวงจร polling ของ feed ที่มีอยู่แล้ว ผลกระทบหลักเป็นความน่าเชื่อถือของการกรองและการนำเข้าข้อมูล ไม่ใช่หลักฐานว่าช่องโหว่นี้ทำให้รันโค้ดบน MISP ได้โดยตรง

แพตช์เปลี่ยนพฤติกรรมอะไร

โค้ดที่แก้เพิ่มเงื่อนไข 200 < status_code < 300 ก่อนเส้นทางส่ง response ที่ไม่ใช่ 200 ผ่าน เมื่อพบรหัสความสำเร็จอื่น MISP Guard จะปฏิเสธ response แทนที่จะยอมให้ผ่านโดยไม่ตรวจ การทดสอบที่เพิ่มใน commit ครอบคลุม 201, 203 และ 206 โดยยืนยันว่าคำขอถูกบล็อกและตอบ 403 ขณะที่การตอบ 304 Not Modified ยังอยู่ในพฤติกรรมเดิมที่ไม่ใช่ข้อมูลเหตุการณ์แบบ 2xx

การแก้แบบนี้เลือกปิดเส้นทางที่ประเมินเนื้อหาได้ไม่มั่นใจ แทนการพยายามใช้กฎกับ response ทุกชนิด ผู้ดูแลควรเตรียมทดสอบ feed ที่ใช้งานจริง เพราะ feed ที่เคยตอบ 201, 203 หรือ 206 แล้วผ่าน proxy อาจถูกบล็อกหลังอัปเดต นี่เป็นการเปลี่ยนพฤติกรรมที่ตั้งใจเพื่อรักษาขอบเขตการกรอง หาก feed ที่เชื่อถือได้ต้องใช้รหัสเหล่านี้ ควรแก้รูปแบบการตอบของ feed หรือประเมินการผสานงานกับ MISP Guard โดยไม่เปิดทางให้เนื้อหาที่ไม่ผ่านกฎถูกนำเข้า

วิธีตรวจระบบและลดความเสี่ยง

เริ่มจากสำรวจ MISP instance ที่ใช้ MISP Guard และรายชื่อ feed ที่ route ผ่าน proxy จากนั้นตรวจเวอร์ชันและ commit ของโค้ดใน process หรือ container จริง รุ่น v1.3 หรือต่ำกว่า ยังอยู่ในช่วงได้รับผลกระทบตามระเบียน CVE ถ้าดึง source จาก branch ให้ยืนยันว่ามี commit b5f606a4e57a49cc4dbf9b3ef0c6ddd19f866735 หรือการแก้เทียบเท่าจากผู้ดูแลโครงการ หากนโยบายองค์กรอนุญาตใช้เฉพาะ release ที่ติด tag ให้ติดตาม release ถัดไปและตรวจว่า release นั้นรวมแพตช์ก่อน rollout

ระหว่างที่ยังอัปเดตไม่ได้ จำกัด feed ให้เหลือเฉพาะ endpoint ที่เชื่อถือได้และเฝ้าดู HTTP status ของ feed response โดยเฉพาะรหัส 2xx ที่ไม่ใช่ 200 อาจบังคับปฏิเสธรหัสดังกล่าวที่ reverse proxy ชั้นหน้า MISP Guard หากสถาปัตยกรรมรองรับและทดสอบแล้ว ตรวจ log การนำเข้าข้อมูลจาก feed ที่เคยตอบ status เหล่านั้น และทบทวนข้อมูลที่ไม่ควรผ่านกฎเข้ามา มาตรการชั่วคราวขึ้นกับรูปแบบการเชื่อมต่อจริงและไม่แทนการแก้ที่ต้นโครงการ

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

แหล่งข้อมูลต้นทาง: โครงการ MISP Guard, commit แพตช์และการทดสอบ, release v1.3 และ ระเบียน CVE-2026-116372