AI หาช่องโหว่ได้ 1,061 รายการในครึ่งปี แต่ถูกโจมตีจริงแค่ 14 — VulnCheck ชี้ Project Glasswing แจ้ง 23,019 เคส กลายเป็น CVE 126 และถูกใช้โจมตีจริง 1
ตลอดปีที่ผ่านมาเราเขียนถึงข่าว “AI หาช่องโหว่ได้เป็นพัน” ซ้ำแล้วซ้ำอีก — Project Glasswing ของ Anthropic, MDASH ของ Microsoft, Daybreak/Patch the Planet ของ OpenAI, Project Lightwell ของ IBM+Red Hat ทุกครั้งตัวเลขที่ประกาศคือ จำนวนช่องโหว่ที่ค้นพบ ซึ่งเป็นตัวเลขที่ดูน่าตื่นเต้นแต่ไม่ได้บอกอะไรเลยว่าความเสี่ยงลดลงจริงไหม
รายงาน State of Exploitation ครึ่งปีแรก 2026 ของ VulnCheck (เผยแพร่ 28 กรกฎาคม 2026 โดย Patrick Garrity — เราเขียนถึงช้าไปหนึ่งสัปดาห์) เป็นชิ้นแรกที่ไปวัดอีกฝั่งของสมการ นั่นคือ ช่องโหว่ที่ AI หาเจอ สุดท้ายถูกใช้โจมตีจริงกี่รายการ และคำตอบตรงไปตรงมามาก
ตัวเลขหลัก
- VulnCheck ติดตาม 1,061 ช่องโหว่ ที่มาจากโปรแกรมค้นหาด้วย AI ในครึ่งปีแรก 2026
- ในจำนวนนี้ยืนยันว่าถูกโจมตีจริง (exploited in the wild) เพียง 14 รายการ คิดเป็น 1.3%
- อัตรานี้ ไม่ต่างจากช่องโหว่ที่มนุษย์หาเจอ — พูดอีกอย่างคือ AI ไม่ได้ผลิตช่องโหว่ที่ “อันตรายกว่า” มันแค่ผลิตช่องโหว่ที่ “เยอะกว่า”
เคสที่ชัดที่สุดคือ Project Glasswing ของ Anthropic ที่เราเคยเขียนถึงหลายรอบ VulnCheck ไล่เส้นทางให้ดูทั้งกรวย:
| ขั้น | จำนวน |
|---|---|
| finding ที่รายงานเข้าไป | 23,019 |
| กลายเป็น CVE ที่เผยแพร่จริง | 126 |
| ยืนยันว่าถูกใช้โจมตีจริง | 1 (CVE-2026-26980) |
จาก 23,019 เหลือ 1 — อัตราส่วนราว 1 ใน 23,000
ภาพรวมการโจมตีที่เหลือของครึ่งปี
รายงานให้บริบทที่สำคัญกว่าตัวเลข AI เสียอีก:
- ครึ่งปีแรก 2026 มีช่องโหว่ที่พบการโจมตีจริง (KEV) 495 รายการ
- 23.43% พบการโจมตีตั้งแต่วันที่ประกาศ CVE หรือก่อนหน้านั้น — คือเป็น zero-day หรือใกล้เคียง
- ค่ามัธยฐานของเวลาจากประกาศ CVE ถึงพบการโจมตี ลดจาก 120 วันในปี 2025 เหลือ 80 วัน และราว 200 CVE ถูกโจมตีภายใน 31 วัน
- อัตราส่วน KEV ต่อ CVE ทั้งหมดลดเหลือ 1.4% จาก 2.7% ในปลายปี 2023 — เพราะตัวหารโตเร็วกว่าตัวเศษมาก
กลุ่มเทคโนโลยีที่ถูกโจมตีมากที่สุด เรียงลำดับ:
- Content Management System — คิดเป็นราวหนึ่งในสามของ KEV ทั้งหมด
- อุปกรณ์ network edge (Cisco, Palo Alto, Fortinet ฯลฯ)
- เครื่องมือด้านความปลอดภัยและเครื่องมือนักพัฒนา
- แพลตฟอร์มบริหารจัดการอุปกรณ์
- แอปพลิเคชันเดสก์ท็อป
ข้อสังเกตที่ VulnCheck เน้นคือ เครื่องมือ AI เองกำลังกลายเป็นเป้าที่น่าสนใจ ซึ่งสอดคล้องกับสิ่งที่เราเขียนถึงเมื่อวานเรื่องเวิร์มฝัง prompt injection ใน Word ที่ใช้ Copilot เป็นพาหะ
สิ่งที่รายงานนี้ “ไม่ได้” บอก
ต้องอ่านอย่างเป็นธรรมด้วย รายงานวัด การโจมตีที่ถูกสังเกตเห็นและยืนยันได้ ไม่ใช่ความเสี่ยงทั้งหมด ช่องโหว่ที่ถูกแพตช์ก่อนมีใครหาเจอย่อมไม่มีวันปรากฏในสถิติการโจมตี — ซึ่งก็คือ จุดประสงค์ของโปรแกรมพวกนี้ตั้งแต่แรก ตัวเลข 1.3% จึงตีความได้สองทางที่ตรงข้ามกัน: “AI หาแต่ของไร้สาระ” หรือ “AI ทำงานสำเร็จจนไม่มีอะไรให้โจมตี” ข้อมูลชุดนี้อย่างเดียวแยกสองข้อนี้ออกจากกันไม่ได้
สิ่งที่มันบอกได้แน่ ๆ คือ จำนวน finding ไม่ใช่ตัวชี้วัดที่ใช้ตัดสินใจอะไรได้ และแล็บที่ประกาศตัวเลขหลักหมื่นควรถูกถามต่อว่าในนั้นกลายเป็น CVE กี่รายการ และมีกี่รายการที่มีคนสนใจพอจะโจมตี
มุมมอง AI Curator
ตัวเลขที่ผมคิดว่าสำคัญที่สุดในรายงานนี้ ไม่ใช่ 1.3% แต่คือ 80 วัน
เพราะ 1.3% เป็นเรื่องของฝั่งผู้ผลิตช่องโหว่ ส่วน 80 วันเป็นเรื่องของทุกคนที่ต้องแพตช์ ค่ามัธยฐานที่ลดจาก 120 เหลือ 80 วันภายในปีเดียว แปลว่า หน้าต่างเวลาที่องค์กรมีก่อนจะเจอการโจมตีจริง หดลงหนึ่งในสาม และเมื่อบวกกับข้อเท็จจริงที่ว่าเกือบหนึ่งในสี่ถูกโจมตีตั้งแต่วันประกาศ กระบวนการแบบ “รอรอบแพตช์รายเดือน” กลายเป็นความเสี่ยงที่คำนวณได้ ไม่ใช่แค่ best practice ที่ควรทำ
สำหรับไทยและ SEA ผมอยากชี้ตัวเลขเดียวให้จ้อง: หนึ่งในสามของช่องโหว่ที่ถูกโจมตีจริงคือ CMS ไม่ใช่โมเดล AI ไม่ใช่ agent framework ไม่ใช่ของล้ำ ๆ — คือ WordPress, Joomla, Drupal และปลั๊กอินของมัน ซึ่งเป็นสิ่งที่รันเว็บไซต์หน่วยงานราชการ โรงเรียน โรงพยาบาล และ SME ไทยจำนวนมหาศาล ในขณะที่งบและความสนใจด้านความปลอดภัยขององค์กรกำลังไหลไปทาง “จะป้องกัน AI agent อย่างไร” ช่องทางที่โดนจริงยังเป็นปลั๊กอิน CMS ที่ไม่ได้อัปเดตมาสองปี
นี่คือรูปแบบที่ซ้ำมาตลอดในวงการความปลอดภัย: ความสนใจไปทางความเสี่ยงใหม่ที่น่าตื่นเต้น ขณะที่การโจมตีจริงยังเกิดที่ความเสี่ยงเก่าที่น่าเบื่อ รายงานของ VulnCheck เป็นตัวเลขที่เอาไปใช้เถียงในที่ประชุมงบประมาณได้จริง — ถ้าองค์กรของคุณกำลังจะซื้อเครื่องมือ AI ล่าช่องโหว่ คำถามที่ควรถามผู้ขายไม่ใช่ “หาได้กี่รายการ” แต่คือ “ทีมผมมีกำลังไล่ปิดได้กี่รายการต่อสัปดาห์” เพราะ finding ที่ไม่มีคนแก้ คือหนี้ทางเทคนิคที่มีเอกสารประกอบเรียบร้อย ไม่ใช่ความปลอดภัยที่เพิ่มขึ้น
ข้อสุดท้ายที่ควรจับตา: เครื่องมือนักพัฒนาติดอันดับ 3 ของกลุ่มที่ถูกโจมตี สำหรับทีมที่กำลังต่อ MCP server, ติดตั้ง agent skill จาก marketplace หรือรัน coding agent ที่มีสิทธิ์เขียนไฟล์ในเครื่อง — นั่นคือพื้นผิวการโจมตีที่โตเร็วที่สุดในกองที่คุณดูแลอยู่ และแทบไม่มีใครใส่ไว้ใน asset inventory
แหล่งข่าว
อ่านเพิ่มในหมวด งานวิจัย
Anthropic ให้ Claude สร้างชุดข้อมูลที่ดูไร้พิษภัยแต่ทำโมเดลเบี้ยว ซ่อนในเรื่องเลี้ยงผึ้งและมวยปล้ำ จนผ่านระบบตรวจที่คล้ายของจริง
ทีม Alignment ของ Anthropic ให้ Claude ปีนหาชุดข้อมูล fine-tune ที่หลบ monitor ได้ ผลคือซ่อนพฤติกรรมในงานเขียนแนวบทบาทสมมติ และโมเดลที่เทรนแล้วนำไปใช้ในบุคลิกตัวเอง ผลซ้ำได้บน Qwen 3.6 27B แต่การทดลองเอื้อฝ่ายโจมตีมากและไม่ได้สะท้อนโมเดลที่ใช้งานจริง
Memdoor ทำซ้ำ GVS5H ได้: ทีม Qwen3.8-27B ห้าตัวตามทัน Fable 5 บนโจทย์ LiveCodeBench Hard แต่ผู้ทำบอกเองว่า 'เท่า' ไม่ใช่ 'ชนะ'
Memdoor ปล่อย workflow team-solve ที่เขียนวิธี GVS5H เป็น YAML ล้วนและทำคะแนน 9.8/10 บน LiveCodeBench Hard 10 ข้อ เทียบกับ 8.0 ของ Fable 5 แบบเรียกครั้งเดียว แต่ตัวอย่างเล็กและมีข้อจำกัด ส่วนงานวิจัยต้นฉบับชี้ว่าวิธีนี้ไม่ได้ช่วยทุกโมเดล
QwenPU รัน LLM ซ้อนใน LLM ด้วยหน่วยเวกเตอร์ที่คอมไพล์ลงในน้ำหนัก Qwen3.5-4B ส่วน bootgpt ทำให้เครื่อง 386 บูตเข้าโมเดลภาษาโดยไม่มี OS
ผู้สร้าง Qwenputer ปล่อย QwenPU เมื่อ 31 ต.ค. รัน stories260K ของ Karpathy บนหน่วยเวกเตอร์ที่คอมไพล์ลงในน้ำหนัก Qwen3.5-4B ลดเหลือ 53,000 trace token ต่อหนึ่ง token เรื่องเล่า วันเดียวกัน bootgpt ใส่โมเดล int8 ขนาด 11.5KB ให้บูตบนเครื่อง 386 โดยไม่มี OS