รายงานช่องโหว่ curl ระดับ LOW และ MEDIUM ย้ายขึ้น GitHub แบบเปิดเผย เริ่ม 26 ต.ค. 2026
เริ่ม 26 ต.ค. 2026 รายงานช่องโหว่ curl ระดับ LOW และ MEDIUM ต้องแจ้งเป็น issue สาธารณะบน GitHub เหลือเฉพาะ HIGH และ CRITICAL ที่รับแบบลับบน HackerOne
โดย กองบรรณาธิการ THAI DATA อ่าน 5 นาที
สรุปประเด็นสำคัญ
- Daniel Stenberg ผู้นำโครงการ curl ประกาศเมื่อ 20 ตุลาคม 2026 ว่าตั้งแต่ 26 ตุลาคม 2026 รายงานช่องโหว่ curl ที่ประเมินว่าอยู่ระดับ LOW หรือ MEDIUM ต้องแจ้งเป็น issue สาธารณะใน GitHub ของโครงการ
- เฉพาะช่องโหว่ curl ระดับ HIGH และ CRITICAL ที่ยังรับแบบเป็นความลับบน HackerOne รายงานระดับต่ำที่ส่งเข้า HackerOne จะถูกขอให้ส่งใหม่บน GitHub แล้วปิดและเปิดเผยต่อสาธารณะ
- Stenberg ระบุว่าในหลายปีที่ผ่านมา รายงานที่ส่งเข้ามา มากกว่า 90% ประเมินได้อย่างรวดเร็วว่าต่ำกว่าระดับ HIGH และผู้ดูแลหลักทุกคนรับภาระจนเกือบถึงขีดจำกัด
- เมื่อ 19 ตุลาคม 2026 โครงการแก้นโยบายให้รายงานช่องโหว่ curl ระดับ LOW หรือ MEDIUM ที่เกิดเฉพาะกับรุ่นที่เก่ากว่า 3 ปี อยู่นอกขอบเขต ส่วนร่างขั้นตอนใหม่ใน pull request #23483 ยังรอ merge
Daniel Stenberg ผู้นำโครงการ curl ประกาศเมื่อ 20 ตุลาคม 2026 ว่าตั้งแต่ 26 ตุลาคม 2026 รายงานช่องโหว่ curl ระดับ LOW และ MEDIUM ต้องแจ้งเป็น issue สาธารณะบน GitHub แทนการแจ้งแบบลับ เหลือเฉพาะระดับ HIGH และ CRITICAL ที่รับผ่าน HackerOne เพราะรายงานหลั่งไหลเข้ามาจนผู้ดูแลรับไม่ไหว
รายงานช่องโหว่ curl แจ้งที่ไหน ตั้งแต่ 26 ต.ค. 2026
curl เป็นทั้งโปรแกรมบรรทัดคำสั่งและไลบรารี libcurl สำหรับรับส่งข้อมูลผ่าน URL เว็บไซต์โครงการระบุว่ามีการติดตั้งมากกว่า 2 หมื่นล้านชุด ทั้งในสคริปต์ รถยนต์ ทีวี เราเตอร์ อุปกรณ์การแพทย์ และโทรศัพท์มือถือ นโยบายเดิมให้แจ้งช่องโหว่ curl ทุกระดับผ่าน HackerOne และห้ามเปิดในระบบติดตามบั๊กสาธารณะจนกว่าจะประกาศพร้อมรุ่นที่แก้ไข
| ระดับที่ curl ประเมิน | ช่องทางตั้งแต่ 26 ต.ค. 2026 | การเปิดเผย |
|---|---|---|
| LOW | issue บน GitHub ของ curl | สาธารณะตั้งแต่แจ้ง |
| MEDIUM | issue บน GitHub ของ curl | สาธารณะตั้งแต่แจ้ง |
| HIGH | HackerOne | ลับจนประกาศพร้อมรุ่นที่แก้ไข |
| CRITICAL | HackerOne | ลับจนประกาศพร้อมรุ่นที่แก้ไข |
นักวิจัยที่ไม่แน่ใจระดับยังแจ้งผ่าน HackerOne ได้ และทีม curl จะบอกว่าประเมินไว้ระดับใด รายงานบน HackerOne ที่ทีมเห็นว่าเป็น LOW หรือ MEDIUM จะถูกขอให้ส่งใหม่บน GitHub แล้วปิดในสถานะ informative พร้อมเปิดเผยต่อสาธารณะ Stenberg ระบุว่าในหลายปีที่ผ่านมา รายงานช่องโหว่ curl มากกว่า 90% ประเมินได้อย่างรวดเร็วว่าต่ำกว่าระดับ HIGH
curl ใช้ระดับความรุนแรงของตัวเอง 4 ระดับและไม่ใช้คะแนน CVSS นโยบายนิยาม HIGH ว่าเป็นปัญหาที่มีผลจริงและโจมตีได้ไม่ยาก ส่วน CRITICAL คือผู้โจมตีจากระยะไกลที่ไม่ต้องยืนยันตัวตนรันโค้ดได้บนการตั้งค่าทั่วไป โครงการไม่มี bug bounty และเป็น CNA ที่ขอหมายเลข CVE ให้ช่องโหว่ curl เองได้
ร่างนโยบายบน GitHub และเส้นแบ่งรุ่นเก่า 3 ปี
Stenberg เปิด pull request #23483 เมื่อ 19 ตุลาคม 2026 เพื่อแก้เอกสาร VULN-DISCLOSURE-POLICY.md และแบบฟอร์มแจ้งบั๊กบน GitHub ให้บอกผู้แจ้งว่า ถ้าไม่รู้หรือเชื่อว่าระดับตั้งแต่ HIGH ขึ้นไปให้ไปที่ HackerOne ถ้าคิดว่าเป็น LOW หรือ MEDIUM ให้แจ้งบน GitHub เขาเรียกว่าเป็นร่างแรกของขั้นตอนใหม่เพื่อลดภาระทีมความปลอดภัย ณ 22 ตุลาคม 2026 pull request นี้ได้รับอนุมัติจากผู้รีวิวหลายคนแต่ยังไม่ merge และหน้านโยบายบน curl.se ยังเป็นฉบับเดิม
วันเดียวกันนั้น โครงการรวมการแก้นโยบายอีกข้อเข้า branch master ข้อความ commit ของ Stenberg ระบุว่า "ต้องมีเส้นแบ่งที่ไหนสักแห่ง" สาระคือรายงานช่องโหว่ curl ระดับ LOW หรือ MEDIUM ที่เกิดเฉพาะกับรุ่นที่เก่ากว่า 3 ปีอยู่นอกขอบเขตและถูกปิดโดยไม่ดำเนินการ โครงการให้ความสำคัญกับปัญหาที่ทำซ้ำได้บนรุ่นล่าสุดและ branch master
ทำไม curl ต้องเปลี่ยน: รายงานคุณภาพดีที่มาไม่หยุด
Stenberg เขียนว่านโยบายนี้เกิดจาก "หิมะถล่ม" ของรายงานช่องโหว่ curl ที่ยังไม่เห็นจุดจบ และคาดว่าจะไม่ลดลงในอีกหลายเดือน ผู้ดูแลหลักทุกคนตึงเครียดและรับภาระจนเกือบถึงขีดจำกัด "เราต้องลงมือเพื่อให้อยู่รอด" เขาเขียน และบอกว่านี่อาจไม่ใช่มาตรการสุดท้าย
ในโพสต์ "ignore the slop" วันที่ 22 ตุลาคม 2026 เขาตอบผู้ที่แนะนำให้เมินรายงานที่ใช้ AI ว่าทำไม่ได้ เพราะรายงานเหล่านี้ชี้ปัญหาจริงและบางครั้งเป็นช่องโหว่จริง รายงานมั่วที่ AI แต่งขึ้นแทบหายไปตั้งแต่ฤดูใบไม้ผลิปี 2026 ความท้าทายตอนนี้คือ "ปริมาณสูงและคุณภาพสูง" ในไม่กี่เดือนที่ผ่านมามีรายงานช่องโหว่ curl หลายร้อยฉบับ และทุกฉบับมี AI มีส่วนช่วย เรื่องนี้ต่อเนื่องจากผลสำรวจ AI slop ของ Linux Foundation ที่พบว่าภาวะหมดไฟของผู้ดูแลเป็นข้อกังวลอันดับต้นของโครงการใหญ่
เขายกตัวอย่างว่า AI มักหา "คอมโบประหลาด" ของตัวเลือก libcurl ที่ทำงานผิดคาด แต่แทบไม่มีโอกาสเกิดในการใช้งานจริง การออก CVE ให้ปัญหาแบบนี้สร้างงานทั้งให้โครงการและทุกคนที่ต้องอัปเดตตาม เขาจะปฏิเสธรายงานลักษณะนี้หนักขึ้น แต่ทิ้งระดับ LOW ทั้งหมดไม่ได้ เพราะโครงการ CVE มีกระบวนการอุทธรณ์ ถ้า curl ไม่ออก CVE ให้ช่องโหว่จริง ผู้อื่นก็จะออกแทน
ทำไมเรื่องนี้สำคัญ
curl เป็นชิ้นส่วนโอเพนซอร์สที่ฝังอยู่ในซอฟต์แวร์และอุปกรณ์จำนวนมากที่สุดชิ้นหนึ่ง เมื่อโครงการระดับนี้ยอมรับว่าวิธีรับรายงานแบบเดิมรับมือไม่ไหว ก็สะท้อนปัญหาที่โครงการอื่นจะเจอเช่นกัน เมื่อ AI ทำให้การหาและเขียนรายงานเร็วกว่าการตรวจและแก้ Stenberg เชื่อว่ามีโครงการไม่มากที่ทนรายงานปริมาณสูงแบบนี้ได้นาน
สิ่งที่ curl คาดหวังคือให้คนนอกทีมช่วยประเมินรายงาน ร่วมเขียน advisory และตรวจว่าแพตช์แก้ครบก่อนออกรุ่นจริง แทนที่จะพบปัญหาหลังประกาศ CVE เมื่อนักวิจัยจำนวนมากใช้ AI ไล่ตรวจแพตช์ที่เพิ่งออก ส่วนข้อเสียที่เขายอมรับเองคือผู้ไม่หวังดีจะเห็นช่องโหว่ curl ระดับต่ำได้ก่อนมีรุ่นที่แก้ไข
ผลต่อองค์กรไทยและทีมพัฒนา
- นักวิจัยความปลอดภัยและ bug hunter ชาวไทย ที่จะส่งรายงานช่องโหว่ curl หลัง 26 ตุลาคม 2026 ควรอ่านเกณฑ์ระดับความรุนแรงในนโยบายของ curl ก่อน ระดับ HIGH ขึ้นไปหรือไม่แน่ใจให้ไปที่ HackerOne ระดับต่ำกว่านั้นให้เปิด issue บน GitHub และเขียนสรุปปัญหาสั้น ๆ ด้วยภาษาของตัวเองก่อนแนบรายละเอียด
- ทีมไอทีและทีมดูแลเซิร์ฟเวอร์ ควรรู้ว่ารายงานช่องโหว่ curl ระดับ LOW และ MEDIUM จะเปิดเผยตั้งแต่ตอนแจ้ง ไม่ใช่ตอนออกแพตช์ จึงควรติดตาม issue ใน GitHub ของ curl กับหน้า security ของ curl.se และอัปเดตแพ็กเกจ curl และ libcurl ตามรุ่นที่ distro ออกให้
- บริษัทที่ฝัง libcurl ในผลิตภัณฑ์หรืออุปกรณ์ ควรทำบัญชีว่า libcurl รุ่นใดอยู่ในผลิตภัณฑ์ใด เพราะรายงานช่องโหว่ curl ระดับต่ำบนรุ่นที่เก่ากว่า 3 ปีจะถูกปิดโดยไม่แก้ การค้างรุ่นเก่าไว้นานจึงเสี่ยงขึ้น
- ผู้ดูแลโครงการโอเพนซอร์สในไทย นำแนวทางนี้ไปปรับใช้ได้ ทั้งการเขียนเกณฑ์ระดับความรุนแรงให้ชัด การกำหนดรุ่นที่รับรายงาน และการแยกช่องทางลับกับช่องทางสาธารณะตามความรุนแรง
ติดตามข่าวโครงการโอเพนซอร์ส ไลเซนส์ และผู้ดูแลเพิ่มเติมได้ที่หมวดซอฟต์แวร์
คำถามที่พบบ่อย
รายงานช่องโหว่ curl แบบใหม่เริ่มเมื่อไรและเปลี่ยนอะไร?
เริ่ม 26 ตุลาคม 2026 ตามประกาศของ Daniel Stenberg เมื่อ 20 ตุลาคม 2026 รายงานช่องโหว่ curl ที่ประเมินว่าอยู่ระดับ LOW หรือ MEDIUM ต้องแจ้งเป็น issue สาธารณะใน GitHub ของโครงการ ส่วนระดับ HIGH และ CRITICAL ยังแจ้งแบบเป็นความลับผ่าน HackerOne เหมือนเดิม
ถ้าไม่แน่ใจว่าช่องโหว่ curl ที่พบอยู่ระดับไหน ควรแจ้งที่ใด?
นักวิจัยที่ไม่แน่ใจยังส่งรายงานช่องโหว่ curl ผ่าน HackerOne ได้ แล้วทีม curl จะบอกว่าประเมินไว้ระดับใด ถ้าเป็น LOW หรือ MEDIUM ทีมจะขอให้ส่งใหม่เป็น issue บน GitHub และปิดรายงานบน HackerOne พร้อมเปิดเผยต่อสาธารณะ
ทำไมโครงการ curl ถึงเปลี่ยนวิธีรับรายงานช่องโหว่?
Daniel Stenberg เขียนว่ารายงานช่องโหว่ curl หลั่งไหลเข้ามาไม่หยุดจนผู้ดูแลหลักรับภาระเกือบถึงขีดจำกัด ในไม่กี่เดือนที่ผ่านมามีรายงานหลายร้อยฉบับ ทุกฉบับมี AI มีส่วนช่วย และส่วนใหญ่เป็นรายงานคุณภาพดีที่มาในปริมาณสูง ไม่ใช่รายงานมั่วแบบเดิม
การเปิดเผยช่องโหว่ curl ระดับต่ำบน GitHub มีความเสี่ยงอะไร?
Stenberg ยอมรับว่าผู้ไม่หวังดีจะเห็นปัญหาได้นานขึ้นเล็กน้อยก่อนมีรุ่นที่แก้ไข โครงการจึงจำกัดการเปิดเผยไว้เฉพาะระดับที่ต่ำกว่า HIGH และหวังว่าการเปิดให้คนทั่วไปร่วมตรวจจะช่วยให้แพตช์ถูกต้องขึ้นและให้ distro ตามการแก้ไขได้เร็วขึ้น
แหล่งอ้างอิง
- Do minor curl vulnerabilities in the open — Daniel Stenberg (curl)
- "ignore the slop" — Daniel Stenberg (curl)
- VULN-DISCLOSURE-POLICY.md: take severity < HIGH to GitHub #23483 — GitHub (curl)
- VULN-DISCLOSURE-POLICY.md: officially don't care for old issues — GitHub (curl)
- curl vulnerability disclosure policy — curl
- curl - command line tool and library for transferring data with URLs — curl
บุคคล องค์กร และสถานที่ในข่าวนี้
เลือกชื่อเพื่ออ่านข่าวทั้งหมดที่กล่าวถึง ตัวเลขคือจำนวนข่าว
- บุคคล
- Daniel Stenberg2
- องค์กรและบริษัท
- GitHub50HackerOne5
- ผลิตภัณฑ์และเทคโนโลยี
- curl3
พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ