hackney 4.9.0 แก้ 5 CVE ใน HTTP client ของ Erlang

hackney 4.9.0 ปิด 5 CVE ใน HTTP client ของ Erlang

โครงการ hackney ออกเวอร์ชัน 4.9.0 เพื่อแก้ช่องโหว่ห้ารายการที่เกี่ยวข้องกับการส่งคำขอผ่านพร็อกซี การติดตาม redirect การตรวจใบรับรอง TLS การตีความที่อยู่ IP และการรับ response ขนาดใหญ่ ผู้พัฒนาที่ใช้ hackney โดยตรงหรือผ่านไลบรารีอื่นควรตรวจเวอร์ชันที่ติดตั้งและรูปแบบการใช้งาน เพราะผลกระทบของแต่ละรายการขึ้นกับคุณสมบัติที่แอปเปิดใช้และข้อมูลที่แอปยอมรับจากภายนอก

ลำดับเวลา: ระเบียน CVE ของผู้ประสานงานระบุวันที่เปิดเผยต่อสาธารณะเป็น 25 ตุลาคม 2026 (UTC) สำหรับทั้งห้ารายการ ขณะที่ บันทึกรีลีส 4.9.0 ของโครงการ ซึ่งแจกแจงการแก้ไขเหล่านี้เผยแพร่เวลา 21:39:32 UTC วันที่ 25 ตุลาคม 2026 นี่เป็นหลักฐานเวลาของการเปิดเผยจากผู้พัฒนาที่ตรวจสอบได้ ส่วนระเบียน CVE ทั้งห้าถูกเผยแพร่ครั้งแรกในวันที่ 26 ตุลาคม 2026 เวลา 13:48–13:49 UTC เวอร์ชันแก้ไข 4.9.0 ปรากฏในรีลีสของโครงการวันที่ 25 ตุลาคม และแพ็กเกจ 4.9.0 บน Hex ถูกเผยแพร่วันที่ 26 ตุลาคม 2026 เวลา 04:44:51 UTC ดังนั้นวันที่ของรีลีส GitHub กับวันที่แพ็กเกจพร้อมดาวน์โหลดบน Hex จึงไม่ใช่เวลาเดียวกัน

ช่องโหว่แต่ละรายการและขอบเขตที่กระทบ

CVE-2026-112880: แทรก HTTP header ในการยืนยันตัวตนกับ CONNECT proxy. กระทบ hackney ตั้งแต่ 2.0.0 จนก่อน 4.9.0 เมื่อพร็อกซีตอบสถานะ 407 แล้วแอปใช้ proxy_auth_fun เพื่อสร้างค่า Proxy-Authorization ค่าไบนารีที่ callback คืนมาถูกใส่ในคำขอ CONNECT รอบถัดไปโดยไม่ตรวจอักขระ CR, LF หรือ NUL หาก callback สร้างค่านั้นจากข้อมูลที่ผู้โจมตีมีอิทธิพลได้ เช่น challenge header ของพร็อกซี อาจเพิ่มบรรทัด header ที่ไม่ได้ตั้งใจในคำขอที่ส่งไปยังพร็อกซี เวอร์ชัน 4.9.0 ปฏิเสธค่าลักษณะนี้ด้วยข้อผิดพลาด invalid_header ประเด็นนี้ไม่ได้หมายความว่าผู้โจมตีทั่วไปสามารถแทรก header ได้โดยไม่ต้องมีเงื่อนไขเรื่อง callback และข้อมูลต้นทาง

CVE-2026-113440: credential รั่วผ่าน redirect บน hostname เดิม. กระทบตั้งแต่ 2.0.0 จนก่อน 4.9.0 เมื่อเปิด follow_redirect การตัดสินใจว่าจะส่ง Authorization และ Cookie ต่อไปเคยเปรียบเทียบเฉพาะ hostname จึงอาจส่งข้อมูลไปยังพอร์ตอื่นบนชื่อเครื่องเดียวกัน หรือจาก HTTPS ไป HTTP ที่ไม่มีการเข้ารหัส ผู้ดักฟังบนเส้นทางอาจอ่านข้อมูลในกรณีหลัง และบริการที่พอร์ตปลายทางอาจได้รับ credential ที่ไม่ได้ตั้งใจให้ใช้กับตน 4.9.0 คง credential ไว้เฉพาะ redirect ที่ scheme, host และ port ตรงกัน ตัวเลือก location_trusted ที่ผู้เรียกตั้งเพื่อให้ส่ง credential ไปยังปลายทางอื่นโดยตั้งใจยังคงพฤติกรรมเดิม จึงควรทบทวนการใช้งานตัวเลือกนี้ด้วย

CVE-2026-115693: การ pin CA ส่วนตัวไม่จำกัด trust store ตามที่คาด. กระทบตั้งแต่ 1.24.0 จนก่อน 4.9.0 เมื่อแอปกำหนด cacerts หรือ cacertfile ใน ssl_options เพื่อเชื่อถือ CA ส่วนตัวเท่านั้น callback partial_chain ของ hackney ยังอาจยอมรับ chain ที่เชื่อมถึง root สาธารณะในชุด certifi ได้ ผู้โจมตีบนเส้นทางที่มีใบรับรองจาก CA สาธารณะ สำหรับ hostname ที่ถูก pin จึงอาจปลอมเป็นเซิร์ฟเวอร์นั้นได้ การตรวจ hostname ยังคงทำงาน; ช่องโหว่นี้ไม่ใช่การยอมรับใบรับรองที่ออกให้ชื่ออื่น รุ่นใหม่ปรับการรวม SSL options ให้ CA ที่ผู้เรียกกำหนดมีผลตามเจตนา ผู้ที่เคยอาศัย cross-signed root ควรใส่ root ที่จำเป็นในรายการของตนหรือกำหนด partial_chain เองตามคำอธิบายในรีลีส

CVE-2026-115700: หลบการคัดกรอง IP เพื่อทำ SSRF. กระทบตั้งแต่ 4.0.1 จนก่อน 4.9.0 ที่อยู่ IPv6 ในวงเล็บเหลี่ยมซึ่งเข้ารหัสแบบ percent หรือ IP literal ที่มีจุดท้ายชื่อ อาจดูไม่ใช่ IP สำหรับตัวกรองของแอป แต่ hackney เชื่อมต่อไปยัง IP ที่ตีความได้จริง ผลคือแอปที่รับ URL จากผู้ใช้และพึ่ง allowlist ซึ่งตรวจข้อความ URL ต่างจากการตีความของ hackney อาจส่งคำขอไปยัง loopback หรือเครือข่ายภายใน รวมทั้งปลายทางของ Location เมื่อเปิด redirect โครงการระบุว่านี่คือรูปแบบที่การแก้ CVE-2026-47076 ก่อนหน้านี้ยังครอบคลุมไม่ครบ ไม่ใช่ CVE เดิมที่เพิ่งมีการเผยแพร่ซ้ำ

CVE-2026-97200: response ทำให้หน่วยความจำหมด. กระทบตั้งแต่ 2.0.0-beta.1 จนก่อน 4.9.0 เมื่อแอปให้ hackney เก็บ response ทั้งก้อนผ่านผลของ hackney:request/5 หรือ hackney:body/1 เซิร์ฟเวอร์ปลายทางที่เป็นอันตรายอาจส่งข้อมูลยาวมากหรือข้อมูลบีบอัดซึ่งขยายตัวมากหลังคลายการบีบอัดจนหน่วยความจำของไคลเอนต์หมด เส้นทางนี้รวม HTTP/1.1, HTTP/2 และ HTTP/3 ตามบันทึกรีลีส 4.9.0 เพิ่มตัวเลือก max_body_size พร้อมค่าเริ่มต้น 512 MiB และคืน {error, body_too_large} เมื่อเกินขีดจำกัด ทั้งนี้ 512 MiB ยังสูงสำหรับบางบริการ และแอปที่ดาวน์โหลดไฟล์ใหญ่ต้องกำหนดค่าให้เหมาะสม การตั้ง infinity เป็นการปิดเพดานดังกล่าว

การรับมือสำหรับผู้ดูแลระบบและผู้พัฒนา

เริ่มจากตรวจ dependency lockfile และเวอร์ชัน hackney ที่รันจริง รวมถึง dependency ทางอ้อม อัปเดตเป็น hackney 4.9.0 หรือใหม่กว่า และทดสอบการเชื่อมต่อผ่าน proxy, redirect, private CA และการอ่าน response กับสภาพแวดล้อมของตนเอง โดยเฉพาะแอปที่รับ URL จากผู้ใช้ ควรตรวจปลายทางหลัง normalize/resolve และหลัง redirect ทุกครั้ง ไม่ให้การกรองทำงานบนรูปแบบ URL ที่ต่างจากปลายทางซึ่งไคลเอนต์จะเชื่อมต่อจริง สำหรับ credential ให้จำกัดการติดตาม redirect และหลีกเลี่ยง location_trusted หากไม่มีความจำเป็นที่ชัดเจน

แอปที่ pin CA ควรตรวจว่า trust store หลังอัปเดตตรงตามนโยบาย และทดสอบกรณีใบรับรองที่ถูกต้องจาก CA ที่ระบุไว้กับกรณีที่ควรถูกปฏิเสธ แอปที่ดึง response จากเซิร์ฟเวอร์ที่ไม่เชื่อถือควรกำหนด max_body_size ให้สัมพันธ์กับปริมาณข้อมูลที่รับได้ และรองรับ {error, body_too_large} แทนการสมมติว่าจะได้ body เสมอ การอัปเดตเวอร์ชันช่วยแก้พฤติกรรมในไลบรารี แต่การกำหนดขอบเขตการใช้งานของแอปยังจำเป็นต่อความเสี่ยง SSRF และการใช้ทรัพยากร

แหล่งต้นทาง: รีลีส 4.9.0 ของ hackney, แพ็กเกจ 4.9.0 บน Hex, และระเบียน CVE ที่เชื่อมไว้ในแต่ละหัวข้อข้างต้น