สรุปสั้น

โครงการ curl ออกเวอร์ชัน 8.23.0 เมื่อวันที่ 14 ตุลาคม 2569 เพื่อแก้ช่องโหว่ CVE-2026-92392 ซึ่งเป็นบั๊ก use-after-free ในการจัดการการอัปโหลดผ่าน HTTP/2 กระทบทั้งเครื่องมือบรรทัดคำสั่ง curl และไลบรารี libcurl ตั้งแต่เวอร์ชัน 8.12.0 ถึง 8.22.0 ซึ่งซอฟต์แวร์อื่นจำนวนมากใช้รับส่งข้อมูล ช่องโหว่นี้เปิดให้เซิร์ฟเวอร์ที่ผู้โจมตีควบคุมและรับไฟล์อัปโหลดทำให้หน่วยความจำของไคลเอนต์เสียหายได้ และผู้รายงานสาธิตต่อจนรันโค้ดบนเครื่องที่อัปโหลดได้สำเร็จ curl จัดระดับไว้ที่ High ตามสเกล 4 ระดับของโครงการ นับเป็นช่องโหว่ระดับ High ครั้งแรกนับตั้งแต่ heap overflow ใน SOCKS5 เมื่อตุลาคม 2566 และร่นรอบออกรุ่นลง 2 สัปดาห์เพื่อส่งแพตช์

อย่างไรก็ตาม การยึดเครื่องไคลเอนต์จริงต้องรู้เวอร์ชัน curl สถาปัตยกรรม ตัวจัดสรรหน่วยความจำของ libc และเลย์เอาต์ heap ของเป้าหมายแบบเจาะจง นาย Daniel Stenberg หัวหน้านักพัฒนา curl ระบุว่าผลที่น่าจะเกิดมากที่สุดจากการพยายามโจมตีคือโปรแกรมแครช จึงไม่ได้จัดเป็น Critical ช่องโหว่นี้อยู่ในทุกรุ่นตั้งแต่ 8.12.0 ที่ออกเมื่อกุมภาพันธ์ 2568 และยังไม่มีแหล่งใดรายงานการโจมตีจริง แต่รายงานบน HackerOne พร้อมสคริปต์เซิร์ฟเวอร์และ Docker container ที่ทำซ้ำการรันโค้ดได้ถูกเปิดเผยต่อสาธารณะแล้วพร้อมประกาศ

รายละเอียดข่าว

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 14 ตุลาคม 2569 ว่า curl 8.23.0 แก้ CVE ทั้งหมด 24 รายการ โดย CVE-2026-92392 เป็นรายการเดียวที่อยู่ระดับ High ส่วนอีก 23 รายการเป็นระดับ Low curl ใช้สเกลความรุนแรงของตัวเองและไม่เผยแพร่คะแนน CVSS ขณะที่ National Vulnerability Database ยังไม่ได้วิเคราะห์ระเบียนนี้ ณ วันที่ 14 ตุลาคม

curl patches HTTP/2 upload use-after-free flaw CVE-2026-92392

เงื่อนไขของการโจมตีคือไคลเอนต์ต้องอัปโหลดไฟล์ขนาดราว 135KB ผ่าน HTTP/2 ไปยังเซิร์ฟเวอร์ที่ผู้โจมตีควบคุม และใบรับรองของเซิร์ฟเวอร์ต้องผ่านการตรวจของไคลเอนต์ ทั้งนี้ libcurl จะเจรจาใช้ HTTP/2 โดยค่าเริ่มต้นกับ URL แบบ https:// เมื่อเซิร์ฟเวอร์รองรับ และไลบรารีถูกคอมไพล์มาพร้อม HTTP/2

รายงานส่งถึง curl ผ่าน HackerOne เมื่อวันที่ 15 กันยายน 2569 และทีมความปลอดภัยยืนยันได้ภายในไม่กี่ชั่วโมง ต่อมาเมื่อ 7 ตุลาคม โครงการประกาศล่วงหน้าว่าจะมีแพตช์ระดับ High ในรุ่นถัดไป และร่นรอบออกรุ่นจาก 8 สัปดาห์เหลือ 6 สัปดาห์ curl ให้เครดิตการค้นพบแก่ “Luna with Claude, Anthropic” โดยนาย Stenberg ระบุว่าผู้รายงานคือนางสาว Luna Tong จาก Anthropic และพบผ่านบริการ OSS Scanner ของบริษัท ซึ่งเปิดตัวเมื่อ 8 ตุลาคมในรูปแบบสมัครใจ สแกนโครงการโอเพนซอร์สที่ลงทะเบียนด้วยโมเดล AI แล้วส่งผลพร้อมตัวทำซ้ำและแพตช์ที่เสนอ รายงานของ curl มาถึงก่อนการเปิดตัวสาธารณะราว 3 สัปดาห์

ประเด็นนี้น่าสนใจเพราะนาย Stenberg เคยเขียนเมื่อกรกฎาคม 2568 ว่าราวหนึ่งในห้าของรายงานความปลอดภัยที่ curl ได้รับในปีนั้นเป็นสิ่งที่เขาเรียกว่า “AI slop” และมีเพียงราวหนึ่งในยี่สิบที่เป็นช่องโหว่จริง

รายละเอียดช่องโหว่

HTTP/2 ส่งหลายการรับส่ง (transfer) ผ่านการเชื่อมต่อเดียว และ libcurl ติดตามแต่ละการรับส่งด้วยออบเจกต์ที่เรียกว่า easy handle ลำดับการโจมตีตามที่ curl และรายงานสาธารณะอธิบายมีดังนี้

  1. ระหว่างการอัปโหลด เซิร์ฟเวอร์หยุดการรับส่งด้วยการตั้งหน้าต่าง HTTP/2 เป็นศูนย์ ส่งคำตอบกลับบางส่วน แล้วรีเซ็ตสตรีมโดยยังเปิดการเชื่อมต่อค้างไว้ curl ถือว่าการรีเซ็ตเป็นเหตุให้ลองใหม่
  2. ในขั้นเก็บกวาด curl แจ้งเลเยอร์ HTTP/2 ว่าการรับส่งจบแล้วก่อน จากนั้นจึงส่งข้อมูลอัปโหลดที่ค้างอยู่ลงการเชื่อมต่อเดิม เมื่อไม่มีการรับส่งลงทะเบียนอยู่ ไบต์ที่เหลือจึงถูกอ่านเป็นคำขอใหม่
  3. รูปแบบบรรทัดที่ผู้รายงานใส่ไว้ในไฟล์อัปโหลดทำให้ไบต์เหล่านั้นดูเหมือนบรรทัดคำขอ ทำให้มีการเปิดสตรีมใหม่ที่เก็บพอยน์เตอร์ไปยัง easy handle
  4. การลองใหม่สำเร็จบนการเชื่อมต่อ HTTP/1.1 ใหม่ และแอปพลิเคชันคืนหน่วยความจำของ handle ไป แต่การเชื่อมต่อเก่ายังถือพอยน์เตอร์และใช้มันเมื่อเซิร์ฟเวอร์ส่งเฟรมบนสตรีมนั้น ซึ่งเกิดได้แม้ตอนโปรแกรมกำลังปิด

ในเอ็กซ์พลอยต์ของผู้รายงาน ข้อมูลจากเซิร์ฟเวอร์ไปลงในหน่วยความจำที่ handle เคยใช้ คำขอที่ส่งออกไปรั่วที่อยู่หน่วยความจำภายในซึ่งเซิร์ฟเวอร์ใช้ข้าม ASLR จากนั้นพอยน์เตอร์ฟังก์ชันในหน่วยความจำนั้นถูกเขียนทับด้วยไบต์จากเซิร์ฟเวอร์และ curl เรียกใช้ฟังก์ชันนั้น ตามคำแนะนำของ curl การรันโค้ดต้องให้ผู้โจมตีรักษาจังหวะการรับส่งคู่ขนาน 2 รายการให้ตรง และใส่ payload ให้พอดีในพื้นที่ราว 23 ไบต์

แพตช์เป็นการสลับลำดับโค้ด 6 บรรทัดใน lib/multi.c โดยนาย Stefan Eissing ให้เลเยอร์ HTTP/2 ปล่อยการอ้างอิงถึง handle หลังจากส่งข้อมูลอัปโหลดที่ค้างเสร็จแล้ว ไม่ใช่ก่อน curl ยอมรับว่าเป็นความผิดพลาดที่ภาษาแบบ memory-safe น่าจะป้องกันได้ แต่ไม่มีแผนเขียน curl ใหม่ด้วยภาษาดังกล่าว

ผลกระทบ

curl และ libcurl ฝังอยู่ในซอฟต์แวร์จำนวนมหาศาล ตั้งแต่สคริปต์อัตโนมัติ เครื่องมือ CI/CD แอปพลิเคชันเดสก์ท็อปและมือถือ ไปจนถึงอุปกรณ์ฝังตัว ระบบที่อัปโหลดไฟล์ไปยังปลายทางภายนอกผ่าน HTTPS เช่น การส่งล็อก แบ็กอัป หรือรายงานขึ้นบริการคลาวด์ อาจตกเป็นเป้าหากปลายทางถูกยึดหรือถูกหลอกให้เชื่อมต่อไปยังเซิร์ฟเวอร์ของผู้โจมตีที่มีใบรับรองถูกต้อง

ความเสี่ยงที่ใกล้ตัวกว่าการรันโค้ดคือการทำให้โปรแกรมแครช (DoS) เพราะเงื่อนไขการรันโค้ดสำเร็จค่อนข้างแคบ แต่เมื่อเอ็กซ์พลอยต์และสภาพแวดล้อมทำซ้ำเผยแพร่แล้ว ผู้ที่ต้องการโจมตีเป้าหมายที่รู้บิลด์แน่ชัด เช่น อิมเมจคอนเทนเนอร์สาธารณะหรือเฟิร์มแวร์รุ่นเดียวกันจำนวนมาก จะมีจุดเริ่มต้นที่ดี ปัญหาที่ยากกว่าคือ libcurl มักถูกคอมไพล์ฝังแบบ static ในผลิตภัณฑ์ต่าง ๆ ทำให้ต้องรอผู้ผลิตแต่ละรายออกอัปเดต

คำแนะนำ

  • อัปเกรด curl และ libcurl เป็น 8.23.0 หรือนำ commit แพตช์ไปใช้กับบิลด์ของตนเอง
  • สาขาเก่ามีรุ่นที่แก้แล้วคือ 8.14.3, 8.16.2 และ 8.20.2 · Debian 13 (trixie) แก้ใน 8.14.1-2+deb13u7 ผ่าน DSA-6558-1 ส่วน Debian 12 (bookworm) ไม่มีโค้ดที่มีช่องโหว่
  • หากยังอัปเดตไม่ได้ ให้เลี่ยง HTTP/2 โดยใช้ตัวเลือก --http1.1 ในเครื่องมือ curl หรือตั้ง CURLOPT_HTTP_VERSION เป็น CURL_HTTP_VERSION_1_1 ในแอปพลิเคชัน (curl ระบุว่าค่านี้เป็นเพียง “คำขอ” เพราะอาจนำการเชื่อมต่อเดิมที่ใช้เวอร์ชันอื่นกลับมาใช้)
  • บิลด์ libcurl ที่ไม่ได้เปิด HTTP/2 จะไม่เข้าถึงเส้นทางโค้ดที่มีช่องโหว่
  • สำรวจซอฟต์แวร์และอิมเมจคอนเทนเนอร์ที่ฝัง libcurl แบบ static ด้วย SBOM หรือเครื่องมือสแกน แล้วติดตามอัปเดตจากผู้ผลิต
  • เฝ้าระวังการแครชผิดปกติของงานอัปโหลดอัตโนมัติที่ส่งข้อมูลไปยังปลายทางภายนอก

แหล่งอ้างอิง