Express ออกแพตช์ 2 CVE ใน body-parser และ multer: คำขอเดียวอาจทำให้โปรเซสล่ม

ผู้พัฒนาในองค์กร Express เผยแพร่ประกาศความปลอดภัยใหม่สองรายการเมื่อ 22 ตุลาคม 2026 สำหรับแพ็กเกจที่เว็บแอป Node.js ใช้บ่อย: CVE-2026-111181 ใน body-parser และ CVE-2026-113872 ใน multer ทั้งสองกรณีอาจทำให้โปรเซส Node.js ล่มจากคำขอเดียวโดยไม่ต้องลงชื่อเข้าใช้ แต่จุดกระตุ้นต่างกันอย่างสำคัญ จึงต้องตรวจ dependency และการตั้งค่าของแต่ละแอปแยกกัน ไม่ควรสรุปว่าเพียงใช้ Express ก็มีช่องโหว่ทั้งสองโดยอัตโนมัติ

วันที่ของข่าวเข้าเกณฑ์ 48 ชั่วโมงอย่างชัดเจน: คำเตือนของผู้ดูแลแพ็กเกจและรุ่นแก้ออกวันที่ 22 ตุลาคม 2026 เช่นเดียวกับวันที่เผยแพร่ระเบียน CVE ทั้งสอง เรื่องนี้ไม่ใช่การนำแพตช์เก่ามาเล่าใหม่ รุ่นแก้ของ body-parser คือ 1.20.9 สำหรับสาย 1.x และ 2.4.0 สำหรับสาย 2.x ส่วน multer แก้ใน 2.5.0

body-parser: สตรีมถอดรหัสยังส่ง error หลังอ่าน body เสร็จ

ประกาศของ body-parser ระบุว่าแอปที่ใช้ค่าเริ่มต้นอาจถูกทำให้ล่มด้วยคำขอที่มี Content-Encoding และข้อมูลท้ายสตรีมที่ทำให้ตัวถอดรหัสส่ง error ภายหลัง middleware อ่าน body จบไปแล้ว ขณะนั้น stream ยังเชื่อมอยู่แต่ไม่มีตัวรับ error ที่เหมาะสม ข้อยกเว้นที่ไม่ถูกจับจึงทำให้โปรเซส Node.js ยุติการทำงาน ผู้พัฒนาระบุว่าไม่ต้องยืนยันตัวตนหรือจับคู่กับ route ที่เปิดเผยโดยเฉพาะ เพราะ middleware ทำงานก่อนการเลือก route

ช่วงเวอร์ชันที่ได้รับผลกระทบคือ ต่ำกว่า 1.20.9 ในสาย 1.x และ ตั้งแต่ 2.0.0 แต่ต่ำกว่า 2.4.0 ในสาย 2.x รุ่นแก้คือ 1.20.9 และ 2.4.0 ตามลำดับ คะแนนใน advisory คือ CVSS 3.1 7.5 ระดับ High โดยเน้นผลกระทบต่อความพร้อมใช้งาน ไม่ใช่การอ้างว่าช่องโหว่นี้อ่านข้อมูลลับหรือรันโค้ดได้ ข้อเท็จจริงที่ควรสื่อให้ทีมปฏิบัติการเข้าใจคือการรีสตาร์ตอัตโนมัติอาจทำให้บริการกลับมา แต่ไม่ได้ลบสาเหตุที่คำขอเดิมทำให้โปรเซสล่มได้

หากแอปไม่จำเป็นต้องรับ request body ที่บีบอัด ผู้ดูแลแพ็กเกจเสนอวิธีบรรเทาชั่วคราวคือกำหนด inflate: false ใน middleware เพื่อปฏิเสธคำขอที่เข้ารหัสก่อนสร้างสตรีมถอดรหัส อย่างไรก็ตาม การเปลี่ยนค่านี้อาจกระทบ client ที่ส่ง body แบบบีบอัดอยู่จริง จึงควรตรวจ log และทดสอบก่อนใช้กับ production การอัปเดตแพ็กเกจยังเป็นทางแก้หลัก

multer: เงื่อนไขเฉพาะ fileFilter แบบ asynchronous

ประกาศของ multer ระบุว่าเวอร์ชัน ตั้งแต่ 2.0.0 แต่ต่ำกว่า 2.5.0 อาจทำให้โปรเซสล่มเมื่อแอปกำหนด fileFilter แบบ asynchronous ระหว่างจัดการคำขออัปโหลด หากคำขอถูกยกเลิกในขณะที่ callback ของไฟล์อีกตัวหนึ่งยังรออยู่ callback ที่กลับมาภายหลังอาจพยายามใช้งาน parsing stream ที่ถูกปิดไปแล้ว จนเกิด error ที่ไม่มีตัวรับและจบด้วยการหยุดโปรเซส

เงื่อนไขนี้ต่างจาก body-parser: ผู้พัฒนาระบุชัดว่า การอัปโหลดที่ใช้ fileFilter แบบ synchronous ไม่ได้รับผลกระทบจากรายการนี้ และชนิด storage engine ไม่ใช่ตัวแยกความเสี่ยง หากแอปใช้ multer แต่ไม่ได้มี filter แบบ asynchronous ก็ไม่ควรนำคำเตือนนี้ไปเหมารวมกับทุก endpoint อัปโหลด รุ่นแก้คือ multer 2.5.0 และ advisory ให้คะแนน CVSS 3.1 7.5 ระดับ High เช่นกัน

หากยังอัปเกรดไม่ได้ ผู้พัฒนาแนะนำให้เปลี่ยนเป็น fileFilter แบบ synchronous ชั่วคราวเมื่อการตรวจไฟล์สามารถทำได้อย่างถูกต้องด้วยวิธีนั้น แต่ระบบที่ต้องตรวจข้อมูลภายนอกหรือทำงานแบบ asynchronous จริง ๆ ไม่ควรตัดขั้นตอนตรวจทิ้งเพียงเพื่อหลีกเลี่ยงบั๊ก ควรวางแผนอัปเกรดและทดสอบพฤติกรรมอัปโหลดแทน

ตรวจ dependency ในบริการจริงอย่างไร

เริ่มจากค้นหา body-parser และ multer ใน lockfile และแผนผัง dependency ของทุกบริการ Node.js ไม่ว่าจะอ้างแพ็กเกจโดยตรงหรือดึงเข้ามาผ่าน dependency อื่น คำสั่งอย่าง npm ls body-parser multer ช่วยให้เห็นรุ่นที่ติดตั้งในโปรเจกต์ปัจจุบัน แต่ควรตรวจผลใน image หรือ artifact ที่ deploy จริงด้วย เพราะ lockfile ของ branch พัฒนาอาจไม่ตรงกับ production และหนึ่งระบบอาจมีสำเนาแพ็กเกจหลายรุ่นพร้อมกัน

สำหรับ body-parser ให้เลือกอัปเดตตามสายที่ใช้อยู่เป็น 1.20.9 หรือ 2.4.0 ขึ้นไป สำหรับ multer ให้ตรวจว่ามี fileFilter แบบ asynchronous หรือไม่ แล้วอัปเดตเป็น 2.5.0 ขึ้นไปตามคำแนะนำผู้พัฒนา ก่อน deploy ให้ทดสอบทั้งคำขอปกติ คำขอที่แอปปฏิเสธ และการยกเลิกอัปโหลดระหว่างทางในสภาพแวดล้อมทดสอบ เพื่อดูว่าการจัดการ error และทรัพยากรยังทำงานถูกต้อง

หลังปล่อยรุ่นแก้ ควรติดตามจำนวนโปรเซสรีสตาร์ต, HTTP 5xx, เวลาให้บริการ และ log ของ middleware เปรียบเทียบก่อนและหลังเปลี่ยนแพ็กเกจ หากพบการล่มก่อนอัปเดต ให้เก็บหลักฐานและตรวจความเชื่อมโยงกับคำขอที่เกี่ยวข้องโดยไม่สรุปทันทีว่าเป็นการโจมตี เพราะโปรเซสอาจล่มจากสาเหตุอื่นได้เช่นกัน การจำกัดขนาดคำขอและตั้ง timeout ยังคงเป็นแนวป้องกันทั่วไปที่ดี แต่ไม่ใช่ตัวแทนแพตช์ของสอง CVE นี้

แหล่งต้นทางและวันที่: body-parser advisory เผยแพร่ 22 ตุลาคม 2026; multer advisory เผยแพร่ 22 ตุลาคม 2026; ระเบียน CVE-2026-111181 และ CVE-2026-113872 เผยแพร่ 22 ตุลาคม 2026