Plack 1.0056 แก้ CVE-2026-115825: Content-Length ทำให้ HTTP::Server::PSGI ล้ม

Plack 1.0056 แก้ HTTP::Server::PSGI ล้มจาก Content-Length ที่ประกาศเกินจริง

ทีมที่ใช้ HTTP::Server::PSGI ในชุด Plack ควรตรวจเวอร์ชันที่รันจริง หลังมีการเผยแพร่ CVE-2026-115825 ช่องโหว่เกิดในขั้นรับ request body ของเซิร์ฟเวอร์ ผู้ส่งคำขอจากเครือข่ายสามารถประกาศ Content-Length สูงมากแล้วส่งข้อมูลจริงเพียงเล็กน้อย ทำให้ Perl พยายามขยายบัฟเฟอร์ตามจำนวนที่ประกาศก่อนจะอ่านข้อมูลครบ หากหน่วยความจำไม่พอ process อาจจบลงพร้อมข้อผิดพลาด out of memory และบริการหยุดจนกว่าจะเริ่มใหม่ โครงการแก้ใน Plack 1.0056 ซึ่งมีโมดูล HTTP::Server::PSGI รุ่นเดียวกัน

ลำดับเวลาและขอบเขตเวอร์ชัน

commit แก้ไขในคลัง Plack ปรากฏเมื่อวันที่ 23 ตุลาคม 2026 เวลา 23:19 UTC พร้อมข้อความระบุ CVE-2026-115825 Plack 1.0056 บน MetaCPAN เผยแพร่เมื่อวันที่ 24 ตุลาคม 2026 เวลา 08:56 UTC และระบุการแก้ปัญหานี้ในบันทึกความปลอดภัย ระเบียน CVE-2026-115825 เผยแพร่ครั้งแรกวันที่ 25 ตุลาคม 2026 เวลา 16:51 UTC เวลาที่ระบุเป็น UTC ทั้งหมด ระเบียนระบุว่า HTTP::Server::PSGI ก่อน 1.0056 ได้รับผลกระทบ; ระบบที่ใช้รุ่น 1.0056 หรือใหม่กว่ามีแพตช์นี้

เหตุใด body สั้นจึงทำให้หน่วยความจำหมด

ส่วนรับคำขอเดิมใช้ sysread() โดยกำหนดความยาวที่จะอ่านจากจำนวน byte ที่ยังเหลือตาม Content-Length ค่านี้มาจาก header ของลูกค้าและอาจไม่ตรงกับข้อมูลที่ส่งจริง ใน Perl การขออ่านขนาดใหญ่อาจทำให้บัฟเฟอร์ถูกขยายตามจำนวนที่ขอ ก่อนที่จะได้รับ byte จากเครือข่ายเท่านั้น จึงไม่จำเป็นต้องมีการอัปโหลดไฟล์ใหญ่มาก ผู้โจมตีเพียงทำให้แอปเชื่อว่ามี body มหาศาลรออยู่ก็สร้างภาระการจัดสรรหน่วยความจำได้

ระเบียน CVE อธิบายว่า request เดียวก็อาจทำให้ process ออกจากระบบด้วยข้อผิดพลาดหน่วยความจำไม่พอ โดยเกิดก่อนแอป PSGI ถูกเรียก จุดนี้สำคัญต่อการวิเคราะห์ log เพราะแอปอาจไม่มีบันทึก route หรือ handler ที่ทำงานผิดพลาดเลย หากรัน HTTP::Server::PSGI เป็น process เดี่ยว บริการจะไม่ตอบคำขอจนกว่าตัวจัดการ process หรือผู้ดูแลจะเริ่มใหม่ แต่สภาพแวดล้อมที่มี supervisor อาจรีสตาร์ตอัตโนมัติและเห็นอาการเป็นการล้มซ้ำหรือช่วงว่างสั้น ๆ แทน

ปัญหานี้เป็นการปฏิเสธการให้บริการจากการจัดสรรหน่วยความจำ ไม่ใช่หลักฐานว่าผู้โจมตีอ่านไฟล์ ข้ามสิทธิ์ หรือรันโค้ดได้ การประเมินความเสี่ยงควรดูว่ามีการเปิดพอร์ตของเซิร์ฟเวอร์นี้ให้ภายนอกเข้าถึงโดยตรงหรือไม่ มี reverse proxy ที่จำกัดขนาด request อยู่หน้าบริการหรือไม่ และมี process manager ที่รีสตาร์ตพร้อมแจ้งเตือนเมื่อ process ล้มหรือไม่

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

บันทึกการเปลี่ยนแปลงของ Plack 1.0056 ระบุว่าปรับไม่ให้ HTTP::Server::PSGI จัดสรรบัฟเฟอร์ใหญ่เท่าค่า Content-Length ที่ประกาศ แพตช์ใน source จำกัดขนาดการอ่านแต่ละครั้งเป็นช่วง โดยไม่ใช้ตัวเลขจาก header ไปขยายบัฟเฟอร์ทั้งก้อนโดยตรง วิธีนี้ทำให้การรับ body จริงยังเดินหน้าตามจำนวน byte ที่มีอยู่ แต่ค่า header ที่สูงเกินจริงไม่ทำให้การอ่านครั้งแรกขอหน่วยความจำเท่ากัน

รุ่นเดียวกันยังแก้การจัดการ HTTP ที่เกี่ยวข้อง เช่น ปฏิเสธ Content-Length ที่ผิดรูปแบบ ติดลบ ซ้ำ หรือยาวเกินเกณฑ์ด้วย 400 และตอบ 501 สำหรับ Transfer-Encoding ที่เซิร์ฟเวอร์ไม่ได้รองรับ แทนการส่ง raw chunked body ให้แอป รวมถึงแก้กรณี byte เกินหลัง body ถูกส่งต่อเข้า psgi.input ผู้ดูแลจึงควรทดสอบ client และ proxy ที่ใช้อยู่ด้วย เพราะระบบที่เคยอาศัยพฤติกรรมยอมรับคำขอผิดรูปแบบอาจเห็นรหัสตอบกลับเปลี่ยนไปหลังอัปเดต นี่เป็นผลจากการตรวจ HTTP ที่เข้มขึ้น ไม่ได้แปลว่าคำขอปกติควรถูกปฏิเสธ

ขั้นตอนตรวจและรับมือ

ตรวจ dependency ของ Plack ใน environment ที่ process ใช้จริง โดยเฉพาะ container image หรือเครื่องที่มี Perl module หลายชุด แล้วอัปเดตเป็น 1.0056 หรือใหม่กว่า รีสตาร์ตบริการให้โหลดโมดูลที่แก้แล้ว ตรวจทั้ง health check และคำขอ POST ที่มี body ตามปกติ หากมี proxy ด้านหน้า ให้ทดสอบเส้นทางผ่าน proxy และการเชื่อมต่อเข้าบริการโดยตรงในเครือข่ายภายในที่ผู้ดูแลควบคุม เพื่อไม่ให้ endpoint ที่หลุดจาก proxy ยังคงเสี่ยง

ระหว่างรออัปเดต การตั้งขนาด request สูงสุดที่ proxy และการจำกัดหน่วยความจำ process ช่วยลดผลกระทบ แต่ไม่ได้แก้ปัญหาการอ่านของโมดูล ถ้าต้องเปิดบริการให้รับ body ขนาดใหญ่ ควรประเมินขีดจำกัดที่เหมาะกับงานจริงแทนการตั้งค่าแบบไม่จำกัด หลังอัปเดตให้ดู log ของ process manager สำหรับ out-of-memory, จำนวนครั้งที่รีสตาร์ต, และ response 400 หรือ 501 ใหม่ที่เกี่ยวกับ request ผิดรูปแบบ เพื่อตรวจว่าการเปลี่ยนแปลงไม่รบกวน client ที่ถูกต้อง

หากต้องตรวจย้อนหลังว่าเกิดการใช้ช่องโหว่หรือไม่ ให้เทียบเวลา process ล้มกับ access log ที่มี Content-Length สูงผิดปกติ และกับ metric หน่วยความจำของ container หรือเครื่องจริง ควรจำกัดการเข้าถึง log เพราะอาจมีรายละเอียดคำขอของผู้ใช้ การพบค่าขนาดสูงเพียงอย่างเดียวไม่ยืนยันเหตุการณ์โจมตี ต้องดูหลักฐานประกอบก่อนสรุป

แหล่งข้อมูลต้นทาง: commit แก้ไขใน Plack, Plack 1.0056 และ Changes และระเบียน CVE-2026-115825