คำตอบตรงประเด็น: หลักฐานรองรับว่า AISLE มีผลงาน 18 ใน 24 CVE ที่เปิดเผยวันที่ 14 ตุลาคม 2026 พร้อม curl 8.23.0 หรือ 75% ของชุดเปิดเผยนั้น แต่ 3 รายการแก้ตั้งแต่ 8.22.0 แล้ว ตัวเลขนี้ไม่ใช่อัตราความแม่นยำของ AI และไม่ได้หมายความว่า AI ทำงานโดยไม่มีมนุษย์ตรวจ
ผลตรวจ: ยืนยันสัดส่วน 18/24 ได้ในขอบเขตวันเปิดเผย แต่คำว่า “พบ 75% ในรุ่นล่าสุด” ต้องมีบริบท เรื่องวันแก้บั๊ก การจัดระดับความรุนแรง และผู้ตรวจรับรายงาน เราตรวจเอกสารต้นทาง ไม่ได้ทดลอง AISLE หรือรันช่องโหว่
คำกล่าวมาจากไหน
AISLE ประกาศวันที่ 14 ตุลาคม 2026 ว่าช่องโหว่จากแพลตฟอร์ม AI ของบริษัทคิดเป็น 18 จาก 24 CVE ในรอบ curl ล่าสุด ส่วน บทความของ Stanislav Fort ใช้ถ้อยคำว่า 18 รายการเพิ่งแก้ใน 8.23.0 นี่คือต้นทางคำกล่าวของผู้พัฒนา ไม่ใช่ผลทดสอบเทียบโมเดลโดยเรา
ฝั่งโครงการ Daniel Stenberg ประกาศ curl 8.23.0 วันเดียวกัน พร้อมช่องโหว่ที่แก้แล้ว 24 รายการ และ ยืนยันความร่วมมือกับ AISLE ว่าเครื่องมือ AI ที่มีทีมมนุษย์ผู้เชี่ยวชาญสนับสนุนช่วยให้พบและแก้ปัญหาจริงได้ การยืนยันจากผู้ดูแลโครงการมีน้ำหนักต่อผลรับรายงาน แต่ยังไม่ใช่ benchmark แบบควบคุมของแพลตฟอร์ม
75% ใช้ตัวหารอะไร
ทะเบียน CVE ของ curl มี 24 รายการลงวันเปิดเผย 14 ตุลาคม 2026 ส่วนดัชนีท้าย รายงาน audit ที่โครงการเผยแพร่ ระบุ 18 ผลงาน AISLE ที่เปิดเผยในวันดังกล่าว จึงคำนวณได้ 18 ÷ 24 × 100 = 75%
| จำนวน | สิ่งที่นับ | สิ่งที่ยังสรุปไม่ได้ |
|---|---|---|
| 24 CVE | รายการ curl/libcurl ที่เปิดเผยวันที่ 14 ต.ค. 2026 | ไม่ใช่จำนวนช่องโหว่ทั้งหมดที่ยังซ่อนอยู่ |
| 18 CVE | ผลงาน AISLE ในชุดเปิดเผย 24 รายการนี้ | ไม่ใช่รายงานดิบทั้งหมดที่ระบบเคยเสนอ |
| 75% | สัดส่วนผลงานในชุดเปิดเผยที่กำหนด | ไม่ใช่ precision, recall หรือโอกาสตรวจพบทุกบั๊ก |
การวัด precision ต้องรู้จำนวนรายงานที่ตรวจแล้วเป็นจริงเทียบกับรายงานที่เสนอทั้งหมด ส่วน recall ต้องมีฐานช่องโหว่ที่ควรพบครบชุด ข้อมูล 18/24 เพียงอย่างเดียวตอบสองคำถามนั้นไม่ได้ และยังใช้จัดอันดับความสามารถทั่วไปของโมเดลไม่ได้
3 รายการแก้ก่อนวันเปิดเผย
ความต่างสำคัญอยู่ระหว่าง Fixed in กับ Disclosed ในรายงาน PDF หน้า 7–9 และ 54 เอกสารระบุชัดว่า AISLE-CURL-18, -20 และ -27 แก้ใน 8.22.0 แต่ประกาศรายละเอียดพร้อม 8.23.0
| CVE | รุ่นที่แก้แล้ว | วันเปิดเผย advisory |
|---|---|---|
| CVE-2026-86409 | 8.22.0 ออก 2 ก.ย. 2026 | 14 ต.ค. 2026 |
| CVE-2026-86411 | 8.22.0 ออก 2 ก.ย. 2026 | 14 ต.ค. 2026 |
| CVE-2026-87864 | 8.22.0 ออก 2 ก.ย. 2026 | 14 ต.ค. 2026 |
ดังนั้นถ้อยคำว่า AISLE ทั้ง 18 รายการ “เพิ่งแก้ใน 8.23.0” ไม่ตรงกับรายละเอียดต้นทางครบทุกข้อ ตารางสรุปจัด 15 รายการไว้ที่การแก้ใน 8.23.0 อีก 3 รายการอยู่ใน 8.22.0 แต่สัดส่วนการเปิดเผย 18/24 ยังถูกต้อง ไม่ควรนำสองวิธีนับมาปนกัน
ลองสลับฐานนับ: เปอร์เซ็นต์เปลี่ยนเพราะอะไร?
เลือกหัวข้อด้านล่างเพื่อเปลี่ยนชุดที่นำมานับ ผลคำนวณใช้ข้อมูลจริงของ CVE ชุดเปิดเผย 14 ต.ค. 2026 ไม่ใช่คะแนนทดลอง AI
① ฐานการเปิดเผยทั้งหมด / กลับค่าเริ่มต้น
18 ÷ 24 = 75%
AISLE 18 รายการ + ผู้รายงานอื่น 6 รายการ = ทั้งหมด 24 รายการที่เปิดเผยวันที่ 14 ต.ค.
คำถามที่ตอบ: ในชุดเปิดเผยวันนี้ ใครมีผลงานกี่ส่วน?
② เฉพาะที่แก้ครั้งแรกใน curl 8.23.0
15 ÷ 21 ≈ 71.4%
ตัด 3 รายการของ AISLE ที่แก้แล้วใน 8.22.0 ออกจากทั้งเศษและส่วน: (18 − 3) ÷ (24 − 3) จำนวนของผู้รายงานอื่นยังเป็น 6
คำถามที่ตอบ: เฉพาะรายการในชุดเปิดเผยนี้ที่แก้ครั้งแรกใน 8.23.0 สัดส่วนเป็นเท่าไร?
สามรายการที่ตัดออก: CVE-2026-86409, CVE-2026-86411 และ CVE-2026-87864
ข้อจำกัด: ทั้งสองฐานไม่ใช่ precision/recall และกลุ่ม “ผู้รายงานอื่น” มีผลงานที่ใช้ Claude ด้วย จึงไม่ใช่การเทียบ AI กับมนุษย์
ใช้ Tab แล้ว Enter/Space เลือกหัวข้อ หรือแตะบนมือถือ เลือกข้อ ① เพื่อกลับฐานเริ่มต้น ไม่มีการเคลื่อนไหวหรือการส่งข้อมูล และไม่สั่ง Agent จริง
ข้อมูลสำรองอ่านได้: ฐานเปิดเผย AISLE 18/24 =75%; ฐานแก้ครั้งแรกใน8.23.0 AISLE15/21≈71.4%. ที่มา ทะเบียน curl และ audit หน้า7–9,54
ฐาน21ในตัวเปรียบเทียบตัดสามรายการที่แก้ใน8.22.0ออกจากทั้งเศษและส่วน ส่วนผลงานผู้รายงานอื่น6รายการยังอยู่ครบ กลุ่มนี้มีเครดิต Luna ร่วมกับ Claude อย่างน้อยสองรายการ จึงใช้เป็นกลุ่ม “ไม่ใช้ AI” ไม่ได้
35 CVE สะสม และรายการ High เป็นคนละขอบเขต
รายงาน audit จัดทำโดย Joshua Rogers และทีม AISLE ระบุช่วงงานกันยายน 2025–กันยายน 2026 ครอบคลุม curl, libcurl และ wcurl รวม 35 CVE ที่โครงการรับรอง แบ่งเป็น Medium 4 และ Low 31 ตามเกณฑ์ความรุนแรงของ curl ไม่มี High หรือ Critical ในชุด 35 ของ AISLE ตัวเลขสะสมนี้จึงเป็นอีกชุดหนึ่งจาก 18 และ 24
ในรอบเปิดเผย 14 ต.ค. มี CVE-2026-92392 ระดับ High ซึ่ง advisory ให้เครดิตผู้รายงานเป็น Luna ร่วมกับ Claude ของ Anthropic และผู้แก้เป็น Stefan Eissing จึงไม่ควรนำรายการนี้ไปเพิ่มเครดิตให้ AISLE ปัญหาเกี่ยวกับการใช้หน่วยความจำหลังปล่อยระหว่างอัปโหลด HTTP/2 และอาจนำไปสู่การรันโค้ดภายใต้เงื่อนไขเฉพาะ ไม่ใช่หลักฐานว่า curl ทุกเครื่องถูกโจมตีสำเร็จ
AI Agent ทำส่วนไหน มนุษย์อนุมัติตรงไหน
ตามคำอธิบายของ AISLE ระบบประกอบบริบทโค้ดและติดตามสถานะข้ามส่วน เสนอกรณีผิดพลาด แล้วคัดค้านหรือตรวจยืนยันข้อสงสัยด้วยโค้ด เอกสาร และกรณีทดสอบ ก่อนนักวิจัยมนุษย์ตรวจรายงานที่จะส่ง
- ระบบและนักวิจัย AISLE สร้างหลักฐานและตรวจกรณีที่สงสัย
- นักวิจัย AISLE ทบทวนก่อนส่งให้โครงการ
- ทีม curl ตรวจความถูกต้อง ขอบเขต และระดับความรุนแรง พร้อมตัดสินการให้ CVE และการเปิดเผย
- ผู้ดูแลเขียนหรือทบทวนแพตช์และเผยแพร่รุ่นแก้ไข
ผู้ดูแล curl ยืนยันคุณภาพความร่วมมือและบทบาททีมมนุษย์ แต่เราไม่มีข้อมูลครบเรื่องรุ่นโมเดล prompt สิทธิ์เครื่องมือ compute ต้นทุน รายงานที่ถูกปฏิเสธ หรือเวลาทำงานต่อข้อ จึงยังแยกผลงานของโมเดล ระบบรอบโมเดล และมนุษย์ออกมาเป็นคะแนนไม่ได้
ข้อจำกัดและหลักฐานที่ตรวจขัดกัน
รายงาน PDF เขียนโดย AISLE แม้อยู่บนเว็บไซต์ curl ส่วนประกาศของผู้ดูแลและ advisory เป็นหลักฐานอีกฝั่งของการรับรองปัญหา ข่าวที่คัดลอกข่าวประชาสัมพันธ์เดียวกันไม่ได้นับเป็นการทดลองอิสระเพิ่ม การตรวจนี้พบความต่างเรื่องวันแก้กับวันเปิดเผยข้างต้น จึงควรยึดวัน Fixed in ใน advisory แต่ละรายการและตารางใน PDF เป็นหลักเมื่ออธิบายวันที่แก้
คำกล่าวเปรียบเทียบกับระบบ AI อื่นก็ยังไม่ใช่การแข่งขันภายใต้โค้ด เวลา เครื่องมือ และทรัพยากรเท่ากัน จึงไม่ใช้กรณีนี้สรุปว่าโมเดลหนึ่งเหนือกว่าอีกโมเดลในทุกงาน
บทวิเคราะห์ HYBRID MIND และข้อคิด
กรณีนี้แสดงคุณค่าของผลลัพธ์ที่ผู้ดูแลนำไปแก้ได้จริง มากกว่าจำนวนข้อความแจ้งเตือนเพียงอย่างเดียว การประเมิน AI สำหรับงานความปลอดภัยควรดูหลักฐานที่ทำซ้ำได้ ภาระตรวจรายงาน และการนำแพตช์ไปใช้ ควบคู่กับวันเปิดเผยและความรุนแรง ไม่ใช้เปอร์เซ็นต์เดียวแทนทุกมิติ
สำหรับทีมที่ใช้ curl หรือ libcurl ให้ตรวจ advisory ของส่วนประกอบและแพ็กเกจที่ใช้งาน แล้ววางแผนอัปเดตหรือใช้แพตช์ที่เกี่ยวข้อง เอกสารของ CVE-2026-92392 แนะนำ 8.23.0 และระบุรุ่นที่แก้ในสาขา 8.20.X, 8.16.X และ 8.14.X ด้วย จึงต้องอ่านข้อยกเว้นของแต่ละสาขา ไม่ตัดสินจากเลขรุ่นหลักอย่างเดียว
คำถามที่พบบ่อย
75% เป็นตัวเลขแต่งขึ้นหรือไม่?
ไม่ใช่ในขอบเขตนี้ 18 จาก 24 รายการคิดเป็น 75% แต่ต้องระบุว่าเป็นชุดเปิดเผย 14 ต.ค. 2026 ไม่ใช่ความแม่นยำของระบบ
35, 24 และ 18 ขัดกันหรือไม่?
เป็นคนละขอบเขต: 35 คือผลงานสะสมในรายงาน, 24 คือทุก CVE ที่เปิดเผยในรอบวันนั้น, 18 คือผลงาน AISLE ในชุด 24
บทความนี้พิสูจน์ว่า AISLE ทำงานเองทั้งหมดหรือไม่?
ไม่ หลักฐานบอกถึงเครื่องมือ AI ร่วมกับนักวิจัยและผู้ดูแล curl ที่ตรวจรายงานและแพตช์ เราไม่ได้ทดลองแพลตฟอร์มหรือวัดอัตราผิดพลาดเอง
อ่านต่อ: เงื่อนไขและแพตช์ช่องโหว่ GitLab Duo และ ขอบเขตการตรวจคีย์ Anthropic ของ GitHub
แหล่งอ้างอิง
- AISLE: คำกล่าว 18/24 — 14 ต.ค. 2026
- Stanislav Fort: audit และกระบวนการตรวจรายงาน
- Daniel Stenberg: ความร่วมมือและรายงาน audit
- ประกาศ curl 8.23.0 และ ทะเบียน CVE
- curl Security Audit PDF: หน้า 7–9, 53–54
- 86409, 86411, 87864: แยกวันแก้กับวันเปิดเผย
- CVE-2026-92392: ความรุนแรง เงื่อนไข และเครดิต
ตรวจจากต้นฉบับสาธารณะ ณ รอบผลิต 15 ต.ค. 2026 ไม่ได้ติดตั้งหรือรันซอฟต์แวร์ข่าว ไม่ได้ทดสอบช่องโหว่ ภาพที่ใช้เป็นภาพประกอบแนวคิดด้วย AI
ใส่ความเห็น