โปรแกรมที่ส่งไฟล์จาก ERP ไปยังคู่ค้าอาจใช้ libcurl อยู่ภายใน แม้ผู้ใช้งานจะไม่เคยเปิดคำสั่ง curl เลย เมื่อมีประกาศช่องโหว่ การตรวจเฉพาะโปรแกรม curl บนเครื่องจึงอาจยังตอบไม่ได้ว่างานส่งข้อมูลของบริษัทได้รับผลกระทบหรือไม่
เมื่อวันที่ 14 ตุลาคม 2569 โครงการ curl เผยแพร่เวอร์ชัน 8.23.0 พร้อมประกาศ CVE-2026-92392 ระดับ High ซึ่งเกิดระหว่างอัปโหลดผ่าน HTTP/2 หากเซิร์ฟเวอร์ส่งคำสั่งยกเลิกสตรีมบางชนิด curl อาจกลับไปใช้หน่วยความจำที่คืนไปแล้ว หรือ use-after-free ปัญหานี้กระทบได้ทั้งเครื่องมือ curl และแอปที่ใช้ libcurl ตาม ประกาศความปลอดภัย และ บันทึกการออกรุ่น
ประเด็นสำหรับธุรกิจคือหาส่วนประกอบที่ใช้งานจริงให้เจอ แล้วกำหนดว่าจะอัปเดตอะไรและทดสอบงานใด บทความนี้เสนอแนวทางตรวจสอบ ไม่ได้ระบุว่า ERP หรือระบบ API ทุกระบบมีช่องโหว่นี้
ความเสี่ยงสูง มีเงื่อนไขที่ต้องตรวจ
ประกาศระบุว่ามีการพิสูจน์ความเป็นไปได้ที่จะเปลี่ยนข้อผิดพลาดนี้เป็นการรันคำสั่งจากระยะไกล แต่ต้องเป็นเซิร์ฟเวอร์ที่ประสงค์ร้ายและเข้าเงื่อนไขเฉพาะหลายด้าน เช่น รู้รุ่นและโครงสร้างภายในของ curl สถาปัตยกรรมเครื่อง สภาพหน่วยความจำ และจังหวะการส่งข้อมูลพร้อมกัน ข้อมูลนี้ไม่ควรถูกตีความว่าเพียงใช้ curl ก็จะถูกสั่งรันโค้ดได้ทันที รายละเอียดเงื่อนไขอยู่ใน ประกาศ CVE-2026-92392
ช่วงรุ่นที่ประกาศระบุว่าได้รับผลกระทบคือ 8.12.0 ถึง 8.22.0 โดยมีข้อยกเว้นสำหรับสาขาที่แก้แล้ว ได้แก่ 8.14.X ตั้งแต่ 8.14.3, 8.16.X ตั้งแต่ 8.16.2 และ 8.20.X ตั้งแต่ 8.20.2 ส่วนรุ่นก่อน 8.12.0 และตั้งแต่ 8.23.0 ไม่ได้รับผลกระทบจาก CVE นี้ การอยู่นอกขอบเขต CVE นี้ไม่ได้ยืนยันว่าปลอดจากช่องโหว่อื่น ตรวจเทียบได้กับ ตารางความปลอดภัยของ curl
เริ่มจากแอปที่ส่งข้อมูลออก
ทีมไอทีควรเริ่มตรวจงานอัปโหลดที่สำคัญ เช่น ส่งเอกสารให้คู่ค้า ส่งไฟล์สำรอง หรือส่งข้อมูลผ่านตัวเชื่อมต่อระบบ รายการเหล่านี้เป็นตัวอย่างสำหรับตั้งคำถามกับผู้ดูแล ไม่ใช่หลักฐานว่าแอปเหล่านั้นใช้ libcurl
สำหรับแต่ละงาน ให้หาคำตอบจากรายการส่วนประกอบซอฟต์แวร์ เอกสารการสร้างแอป รายการแพ็กเกจในคอนเทนเนอร์ หรือผู้ขาย โดยเก็บข้อมูลที่ใช้ตัดสินใจได้จริง
- แอปหรือบริการใดโหลด libcurl จากที่ใด เป็นสำเนาของระบบปฏิบัติการหรือสำเนาที่แอปบรรจุมาด้วย
- รุ่นและ build ที่รันอยู่คืออะไร ผู้ขายนำแพตช์กลับมาใส่ในรุ่นเดิมแล้วหรือยัง และมีเอกสารยืนยันใด
- เส้นทางอัปโหลดนั้นใช้ HTTP/2 หรือไม่ เชื่อมต่อปลายทางใด และใครเป็นผู้รับผิดชอบงาน
- จะรับแพตช์จากช่องทางใด ใครทดสอบ และเปลี่ยนระบบได้ช่วงไหน
ผลจาก curl --version ใช้ตรวจเครื่องมือที่เรียกคำสั่งนั้นได้ แต่ไม่ควรใช้ยืนยัน libcurl ทุกสำเนาในแอปหรือคอนเทนเนอร์ การอัปเดตแพ็กเกจบนเครื่องแม่จึงต้องตามด้วยการตรวจว่าส่วนประกอบที่บริการใช้อยู่เปลี่ยนจริงแล้ว
เลือกวิธีแก้ แล้วทดสอบให้ถึงผลลัพธ์ของงาน
โครงการ curl แนะนำให้อัปเกรดเป็น 8.23.0 ใช้แพตช์กับรุ่นที่ใช้อยู่ หรือหลีกเลี่ยง HTTP/2 ตาม แนวทางในประกาศ สำหรับซอฟต์แวร์ที่ผู้ขายดูแล ควรขอรุ่นแก้ไขและวิธีติดตั้งที่รองรับ แทนการเปลี่ยนไฟล์ไลบรารีในแพ็กเกจโดยไม่มีข้อมูลความเข้ากันได้
หากจำเป็นต้องหลีกเลี่ยง HTTP/2 ชั่วคราว ให้ผู้ดูแลยืนยันว่าตั้งค่าได้ตรงเส้นทางที่เกี่ยวข้อง ทดสอบกับปลายทางจริง และกำหนดวันกลับมาตรวจเมื่อแพตช์พร้อม วิธีชั่วคราวควรมีเจ้าของงานและเงื่อนไขยุติที่ชัดเจน
การทดสอบควรจบที่ข้อมูลถึงปลายทางและระบบงานบันทึกผลถูกต้อง ตัวอย่างเช่น ใช้ไฟล์ทดสอบที่ไม่มีข้อมูลอ่อนไหว ส่งผ่านตัวเชื่อมต่อเดิม แล้วตรวจว่าปลายทางรับไฟล์ครบ สถานะใน ERP ตรงกัน และเมื่อการส่งล้มเหลว ระบบแจ้งข้อผิดพลาดหรือส่งซ้ำตามที่ออกแบบไว้ การทดสอบนี้ช่วยตรวจความต่อเนื่องของงานหลังเปลี่ยนรุ่น ไม่ใช่การพิสูจน์ว่าไม่มีช่องโหว่อื่น
ก่อนปิดงาน ให้แนบหลักฐานรุ่นหรือแพตช์ที่รันจริง ผลทดสอบ และชื่อผู้รับผิดชอบไว้กับรายการเปลี่ยนแปลง ระบบที่ยังรอผู้ขายควรมีวันติดตามครั้งถัดไป ทีมธุรกิจจึงตรวจได้ว่างานส่งข้อมูลสำคัญรายการใดแก้แล้ว และรายการใดยังต้องจัดการต่อ
ภาพประกอบสร้างด้วย AI สำหรับบทความนี้ ไม่ใช่ภาพเหตุการณ์โจมตีจริง
