ช่องโหว่ถูกโจมตีเฉลี่ยใน 3 วัน: รอบแพตช์ขององค์กรไทยต้องเร็วแค่ไหนในปี 2026
รอบแพตช์รายเดือนไม่ทันผู้โจมตีแล้ว Rapid7 พบช่องโหว่ร้ายแรงถูกโจมตีเฉลี่ย 3 วันหลังเปิดเผย และตั้งแต่ มิ.ย. CISA ให้แก้ช่องโหว่ใน KEV ส่วนใหญ่ใน 3 วัน
โดย กองบรรณาธิการ THAI DATA อ่าน 10 นาที ผู้เข้าชม 1
สรุปประเด็นสำคัญ
- Rapid7 รายงานเมื่อ 21 ตุลาคม 2026 ว่าช่องโหว่ระดับ High และ Critical ถูกโจมตีเฉลี่ย 3 วันหลังเปิดเผย การโจมตีที่ติดตามได้ในไตรมาส 3 เกิดภายใน 7 วัน 71% ภายใน 14 วัน 80% และภายใน 30 วัน 90%
- จากการนับของเราในแค็ตตาล็อก KEV ฉบับ 2026.10.21 CISA เพิ่มช่องโหว่ 270 รายการระหว่าง 1 ม.ค.–20 ต.ค. 2026 มากกว่าช่วงเดียวกันของปี 2025 30.4% และเกินทั้งปี 2025 ที่มี 245 รายการแล้ว
- ช่องโหว่เลข CVE-2026 คิดเป็น 67.8% ของรายการที่เพิ่มในปีนี้ เดือนกันยายนสูงถึง 40 จาก 43 รายการ แปลว่าช่องโหว่ที่เพิ่งออกเลขในปีเดียวกันถูกใช้โจมตีเร็วขึ้น
- หลัง CISA ออก BOD 26-04 เมื่อ 10 มิ.ย. 2026 ช่องโหว่ที่เพิ่มเข้า KEV 111 จาก 137 รายการได้เวลาแก้เพียง 3 วัน จากเดิมที่ส่วนใหญ่ได้ 14 หรือ 21 วัน
- Talos ของ Cisco ระบุว่า CVE ทั้งหมดเพิ่ม 105% แต่ KEV เพิ่มเพียง 37% รอบแพตช์ที่ได้ผลจึงต้องจัดลำดับตามหลักฐานการโจมตีและการเปิดออกอินเทอร์เน็ต ไม่ใช่ไล่ตามจำนวน
รอบแพตช์รายเดือนที่หลายองค์กรใช้อยู่ช้ากว่าผู้โจมตีแล้ว รายงานไตรมาส 3 ปี 2026 ของ Rapid7 ซึ่งเผยแพร่เมื่อ 21 ตุลาคม 2026 พบว่าช่องโหว่ระดับ High และ Critical ถูกโจมตีเฉลี่ย 3 วันหลังเปิดเผย และ CISA ก็ให้เวลาแก้ช่องโหว่ใน KEV ส่วนใหญ่เพียง 3 วันตั้งแต่เดือนมิถุนายน
บทวิเคราะห์นี้รวมตัวเลขจาก Rapid7, Cisco Talos, Amazon และ Second Security กับข้อมูลที่เรานับเองจากแค็ตตาล็อก KEV ของ CISA เพื่อตอบคำถามเดียว คือรอบแพตช์ขององค์กรไทยควรแบ่งเป็นกี่ระดับ และแต่ละระดับต้องเร็วแค่ไหน
ผู้โจมตีใช้เวลากี่วันหลังช่องโหว่ถูกเปิดเผย
Rapid7 ติดตามช่องโหว่ระดับ High และ Critical ที่เริ่มถูกโจมตีใหม่ในไตรมาส 3 ได้ 43 รายการ ลดลง 7% จากไตรมาส 2 แต่สูงกว่าช่วงเดียวกันของปีก่อน 19% ตัวเลขที่สำคัญกว่าคือความเร็ว การโจมตีเกิดขึ้นเฉลี่ย 3 วันหลังเปิดเผยต่อสาธารณะ
| ระยะเวลาหลังเปิดเผย | สัดส่วนการโจมตีที่ Rapid7 ติดตามได้ในไตรมาส 3 ปี 2026 |
|---|---|
| ภายใน 7 วัน | 71% |
| ภายใน 14 วัน | 80% |
| ภายใน 30 วัน | 90% |
Rapid7 ยังพบว่า 34 จาก 43 รายการ (79%) ไม่ต้องยืนยันตัวตนหรือให้ผู้ใช้กดอะไร ระบบที่เปิดออกอินเทอร์เน็ตจึงถูกเจาะได้ทันทีที่ผู้โจมตีเข้าถึงได้ ส่วนรายงานภัยคุกคามที่ Rapid7 ติดตาม 8% ระบุว่ามี AI เป็นส่วนหนึ่งของการปฏิบัติการโจมตี และตลาดใต้ดินมีโพสต์ขายสิทธิ์เข้าถึง RDP หรือเครือข่าย 41 โพสต์
คำถามที่ Rapid7 ตั้งไว้ตรงกับปัญหาของทีมไอทีไทยหลายแห่ง คือจะลดความเสี่ยงอย่างไรเมื่อผู้โจมตีลงมือได้ก่อนรอบแพตช์ครั้งถัดไปจะมาถึง ถ้ารอบแพตช์ขององค์กรคือเดือนละครั้ง ช่องโหว่เกือบทั้งหมดในตารางข้างบนถูกโจมตีไปแล้วก่อนถึงวันแพตช์
ข้อมูล KEV ปี 2026 บอกอะไรเกี่ยวกับรอบแพตช์
เรานับจากไฟล์ JSON ของแค็ตตาล็อก KEV ที่ CISA เผยแพร่ ฉบับ catalogVersion 2026.10.21 (ออก 21 ตุลาคม 2026 เวลา 14:04 UTC มีทั้งหมด 1,754 รายการ) โดยนับตามวันที่ CISA เพิ่มแต่ละรายการ (dateAdded) รายการล่าสุดในฉบับนี้เพิ่มเมื่อ 20 ตุลาคม ตัวเลขปี 2026 จึงครอบคลุม 1 มกราคม ถึง 20 ตุลาคม ส่วน "ช่องโหว่ใหม่ของปีนี้" นับจากปีในเลข CVE ซึ่งบอกปีที่ออกหรือจองเลข ไม่ใช่วันเปิดเผยที่แน่นอน
| เดือน (ปี 2026) | เพิ่มเข้า KEV | เป็นเลข CVE-2026 | สัดส่วน |
|---|---|---|---|
| มกราคม | 17 | 7 | 41.2% |
| กุมภาพันธ์ | 28 | 13 | 46.4% |
| มีนาคม | 26 | 10 | 38.5% |
| เมษายน | 31 | 15 | 48.4% |
| พฤษภาคม | 21 | 15 | 71.4% |
| มิถุนายน | 23 | 19 | 82.6% |
| กรกฎาคม | 26 | 22 | 84.6% |
| สิงหาคม | 31 | 24 | 77.4% |
| กันยายน | 43 | 40 | 93.0% |
| ตุลาคม (1–20) | 24 | 18 | 75.0% |
| รวม | 270 | 183 | 67.8% |
สิ่งที่ข้อมูลบอกมี 3 ข้อ ข้อแรก ปีนี้ CISA เพิ่มช่องโหว่เข้า KEV แล้ว 270 รายการ มากกว่าช่วงเดียวกันของปี 2025 ที่มี 207 รายการ 30.4% และเกินทั้งปี 2025 ซึ่งมี 245 รายการไปแล้ว ข้อสอง สัดส่วนช่องโหว่เลข CVE-2026 เพิ่มจากราว 4 ใน 10 รายการช่วงต้นปีเป็น 40 จาก 43 รายการในเดือนกันยายน แปลว่าช่องโหว่ที่ CISA ยืนยันว่าถูกโจมตีในช่วงหลังส่วนใหญ่เป็นช่องโหว่ที่เพิ่งออกเลขในปีเดียวกัน ไม่ใช่ของเก่าที่ค้างมานาน รอบแพตช์ที่ช้าจึงพลาดช่องโหว่กลุ่มนี้ได้ง่ายที่สุด
ช่องโหว่เก่าก็ยังต้องอยู่ในรอบแพตช์
ข้อสาม ของเก่าก็ยังไม่หายไป ปีนี้มีช่องโหว่ที่เลข CVE เก่ากว่าปี 2025 ถูกเพิ่มเข้า KEV 49 รายการ เฉพาะวันที่ 8 ตุลาคมมี CVE-2015-5477 ของ ISC BIND และ CVE-2015-3306 ของ ProFTPD ซึ่งเป็นเลข CVE ปี 2015 ผู้ผลิตที่มีช่องโหว่เข้า KEV มากที่สุดในปีนี้คือ Microsoft 40 รายการ Cisco 19 รายการ และ Fortinet กับ Apple อย่างละ 9 รายการ และมี 27 รายการที่ CISA ระบุว่าเคยถูกใช้ในแคมเปญแรนซัมแวร์ ระบบเก่าที่หลุดจากรอบแพตช์มานานจึงยังเป็นเป้าหมายได้เสมอ
CISA ลดเวลาแก้ช่องโหว่ใน KEV เหลือ 3 วัน
CISA สร้างแค็ตตาล็อก KEV ในปี 2021 ภายใต้ BOD 22-01 ซึ่งบังคับหน่วยงานรัฐบาลกลางสหรัฐฯ ให้แก้ช่องโหว่ในรายการตามกำหนด วันที่ 10 มิถุนายน 2026 CISA ออก BOD 26-04 ยกเลิก BOD 22-01 และ BOD 19-02 แล้วให้เหตุผลว่าผู้โจมตีที่ใช้ AI อาจทำให้ช่วงเวลาระหว่างแพตช์ออกจนถึงการโจมตีสั้นลงอีก
คำสั่งใหม่ไม่ได้ให้เวลาเท่ากันทุกช่องโหว่ แต่ตัดสินจาก 4 คำถาม คือระบบเปิดออกอินเทอร์เน็ตหรือไม่ ช่องโหว่อยู่ใน KEV หรือไม่ ผู้โจมตีทำทุกขั้นตอนแบบอัตโนมัติได้หรือไม่ และหลังเจาะแล้วยึดระบบได้ทั้งหมดหรือบางส่วน กรณีที่เสี่ยงที่สุดต้องแก้ภายใน 3 วันพร้อมตรวจหาร่องรอยว่าระบบถูกเจาะไปก่อนแพตช์หรือไม่ (forensic triage) ส่วนกรณีที่เสี่ยงน้อยที่สุดแก้ตามรอบอัปเกรดระบบได้
ผลของคำสั่งนี้เห็นชัดในข้อมูล KEV ที่เรานับ ช่องโหว่ 133 รายการที่เพิ่มระหว่าง 1 มกราคมถึง 9 มิถุนายน ได้เวลาแก้ 14 วัน 55 รายการ 21 วัน 44 รายการ 3 วัน 31 รายการ และอีก 3 รายการได้ 2 หรือ 5 วัน แต่ 137 รายการที่เพิ่มตั้งแต่ 10 มิถุนายนถึง 20 ตุลาคม ได้ 3 วันถึง 111 รายการ (81%) ที่เหลือ 26 รายการได้ 14 วัน และ 89 รายการในช่วงหลังนี้มีเงื่อนไขให้ตรวจร่องรอยการถูกเจาะด้วย
BOD 26-04 บังคับเฉพาะหน่วยงานรัฐบาลกลางสหรัฐฯ แต่ในประกาศเพิ่มรายการ KEV วันที่ 20 ตุลาคม CISA แนะนำให้ทุกองค์กรใช้การจัดการช่องโหว่ตามความเสี่ยงและแก้รายการใน KEV ก่อน ตัวอย่างล่าสุดคือชุดวันที่ 20 ตุลาคม ที่ SiteGuard ได้ 3 วันและ Siemens Software Center ได้ 14 วัน
จำนวนช่องโหว่พุ่ง แต่ที่ถูกโจมตีจริงยังเป็นส่วนน้อย
Cisco Talos เขียนเมื่อ 20 ตุลาคมว่า AI รุ่นใหม่ที่เก่งด้านหาช่องโหว่ เช่น Mythos กำลังไล่ขุดหนี้ทางเทคนิคในไลบรารีเก่าที่ใช้กันทั่วโลก ทำให้ประกาศช่องโหว่ใน Patch Tuesday ของ Microsoft เพิ่มจากเฉลี่ยราว 100 รายการต่อเดือนก่อนเดือนมิถุนายน เป็น 975 รายการในเดือนกันยายน และ 1,415 รายการในเดือนตุลาคมตามการนับของ Talos (ดูข่าว Patch Tuesday ตุลาคม 2026)
แต่ Talos ชี้ว่าจำนวนที่ถูกโจมตีจริงไม่ได้โตตาม จากช่องโหว่ 975 รายการของ Microsoft ในเดือนกันยายน มีเพียง 3 รายการที่พบการโจมตีจริง และเมื่อเทียบกับช่วงเดียวกันของปีก่อน CVE ที่เผยแพร่เพิ่มขึ้น 105% ขณะที่รายการใน KEV เพิ่มขึ้น 37% ตัวเลขของเราจาก KEV ช่วง 1 มกราคมถึง 20 ตุลาคมให้ภาพเดียวกันที่ 30.4%
ข้อสรุปของ Talos คือเวลาก่อนช่องโหว่ถูกโจมตีสั้นลงอย่างรวดเร็ว ขณะที่จำนวนช่องโหว่ที่อาจกลายเป็นการโจมตียังเพิ่มขึ้น งานที่ยากที่สุดของฝ่ายป้องกันจึงเป็นการแยกว่าช่องโหว่ใดเป็นทางเข้าจริงของสภาพแวดล้อมตัวเอง รอบแพตช์ที่พยายามไล่แก้ทุกรายการพร้อมกันจะจมอยู่กับปริมาณ ส่วนรอบแพตช์ที่แยกช่องโหว่ซึ่งถูกโจมตีจริงออกมาก่อนจะทันกว่า
PHP2Shell: เมื่อการโจมตีมาก่อนวันเปิดเผย
ช่องโหว่ PHP2Shell (CVE-2026-109618 และ CVE-2026-109619) เป็นตัวอย่างที่ชัดที่สุดของสัปดาห์นี้ Amazon Threat Intelligence รายงานว่า honeypot MadPot พบความพยายามโจมตีครั้งแรกตั้งแต่ 17 ตุลาคม หรือ 4 วันก่อนการเปิดเผย ในวันออกแพตช์ 21 ตุลาคม Amazon พบโค้ดโจมตีตัวอย่าง (proof of concept) หลายชุดตั้งแต่ราว 02:00 UTC ก่อนกำหนดยกเลิกการปิดข้อมูลเวลา 14:00 UTC และหลังแพตช์ออกไม่กี่ชั่วโมงก็มีโค้ดโจมตีเพิ่มและถูกใช้โจมตีในวงกว้าง (รายละเอียดในข่าว PHP2Shell ถูกโจมตีจริง)
Amazon สรุปบทเรียนไว้ตรงกับเรื่องรอบแพตช์ว่า สำหรับช่องโหว่วิกฤตบนระบบที่เปิดออกอินเทอร์เน็ต ควรวัดเวลาแพตช์และมาตรการลดความเสี่ยงเป็นชั่วโมง เพราะ SLA 7 วันหรือ 30 วันตั้งอยู่บนช่วงเวลาที่ไม่มีอยู่แล้ว และควรเริ่มสืบสวนจากวันที่พบการโจมตีครั้งแรก ไม่ใช่วันเปิดเผย
ช่องว่างก่อนมีเลข CVE ทำให้รอบแพตช์เริ่มช้า
กรณีอื่นในสัปดาห์เดียวกันให้ภาพคล้ายกัน ผู้ค้นพบช่องโหว่ชุด Plex2Shell ใน Plex Media Server เผยแพร่รายละเอียดและโค้ดสาธิตเมื่อ 16 ตุลาคม และผู้วิจัยที่ตั้ง honeypot ไว้พบการโจมตีจริงในเช้าวันที่ 17 ตุลาคม ส่วนช่องโหว่ในแอป Collabora บน Nextcloud ถูกใช้ฝัง webshell ก่อนมีเลข CVE 33 วัน
กรณี Collabora สะท้อนปัญหาที่ Second Security เรียกว่า Patchless Window คือช่วงระหว่างที่โค้ดแก้ช่องโหว่ของโครงการโอเพนซอร์สขึ้นสาธารณะจนถึงวันที่มีเลข CVE ผู้วิจัยวัด CVE โอเพนซอร์ส 18,594 รายการที่เผยแพร่ระหว่างมกราคมถึงสิงหาคม 2026 พบว่าค่ามัธยฐานของช่วงนี้เพิ่มจาก 5.1 วันในเดือนมกราคมเป็น 39.2 วันในเดือนสิงหาคม และโค้ดโจมตีสาธารณะกลุ่มที่เร็วที่สุด 10% ออกมาภายใน 1.8 วันหลังโค้ดแก้ขึ้นสาธารณะ รอบแพตช์ที่รอเลข CVE อย่างเดียวจึงเริ่มช้ากว่าผู้โจมตีตั้งแต่ต้น
รอบแพตช์แบบไหนที่องค์กรไทยควรใช้
ตารางด้านล่างจัดรอบแพตช์เป็น 4 ระดับเวลา (ระดับฉุกเฉินแยกเป็น 2 กรณี) โดยเราจัดกลุ่มจาก 16 กรณีในตาราง Remediation Timelines ของ BOD 26-04 และเพิ่มคำแนะนำของ Amazon ในระดับฉุกเฉิน องค์กรปรับตัวเลขได้ตามความพร้อม แต่ลำดับความสำคัญควรคงไว้
| ระดับรอบแพตช์ | ช่องโหว่แบบไหน (ตามเกณฑ์ BOD 26-04) | เป้าหมายเวลา |
|---|---|---|
| ฉุกเฉิน | อยู่ใน KEV และยึดระบบได้ทั้งหมด บนระบบที่เปิดออกอินเทอร์เน็ต หรือบนระบบภายในที่ผู้โจมตีทำทุกขั้นตอนอัตโนมัติได้ | ไม่เกิน 3 วัน พร้อมตรวจหาร่องรอย (Amazon แนะนำให้วัดเป็นชั่วโมงสำหรับระบบที่เปิดออกอินเทอร์เน็ต) |
| ฉุกเฉิน แม้ยังไม่ต้องตรวจร่องรอย | เปิดออกอินเทอร์เน็ต อยู่ใน KEV ทำอัตโนมัติได้แต่ยึดได้บางส่วน หรือเปิดออกอินเทอร์เน็ต ยังไม่อยู่ใน KEV แต่ทำอัตโนมัติได้และยึดได้ทั้งหมด เช่น PHP2Shell ในวันแรก | ไม่เกิน 3 วัน |
| เร่งด่วน | กรณีอื่นที่อยู่ใน KEV และกรณีเปิดออกอินเทอร์เน็ตที่ยังไม่อยู่ใน KEV แต่ยึดได้ทั้งหมดหรือทำอัตโนมัติได้อย่างใดอย่างหนึ่ง | ไม่เกิน 14 วัน |
| รอบปกติ | เปิดออกอินเทอร์เน็ตแต่ยังไม่อยู่ใน KEV ทำอัตโนมัติไม่ได้และยึดได้บางส่วน หรือระบบภายในที่ยังไม่อยู่ใน KEV แต่ทำอัตโนมัติได้ | ไม่เกิน 60 วัน หรือรอบแพตช์รายเดือน |
| ตามรอบอัปเกรด | ระบบภายใน ยังไม่อยู่ใน KEV และทำอัตโนมัติไม่ได้ | รอบอัปเกรดหรือติดตั้งใหม่ครั้งถัดไป |
เตรียมอะไรให้รอบแพตช์ฉุกเฉินทำได้จริง
สิ่งที่ทำให้รอบแพตช์แบบนี้ใช้ได้จริงแบ่งเป็นการเตรียมล่วงหน้า 3 ข้อ และสิ่งที่ต้องทำเมื่อแพตช์ไม่ทันอีก 3 ข้อ
- รู้ก่อนว่าระบบใดเปิดออกอินเทอร์เน็ต BOD 26-04 ให้หน่วยงานติดป้ายทุกระบบที่เข้าถึงได้จากนอกเครือข่ายว่าเป็นระบบจริงหรือทดสอบ เปิดสู่สาธารณะหรือใช้ภายใน และเป็นเซิร์ฟเวอร์ แอปพลิเคชัน หรืออุปกรณ์เครือข่าย Rapid7 ก็แนะนำให้เริ่มจากรายการระบบที่เข้าถึงได้จากภายนอก เพราะช่องโหว่ 79% ในรายงานไม่ต้องล็อกอิน
- ใช้ KEV เป็นรายการแรกของรอบแพตช์ฉุกเฉิน ดึงไฟล์ JSON ของ KEV มาเทียบกับรายการซอฟต์แวร์ขององค์กรทุกวัน เพราะ CISA เพิ่มรายการได้หลายครั้งต่อสัปดาห์ และช่องโหว่ส่วนใหญ่ที่เพิ่มตั้งแต่เดือนมิถุนายนได้เวลาแก้เพียง 3 วัน
- แยกรอบแพตช์ฉุกเฉินออกจากรอบแพตช์รายเดือน อนุมัติขั้นตอนการเปลี่ยนแปลงล่วงหน้าสำหรับระดับฉุกเฉิน กำหนดผู้มีอำนาจตัดสินใจนอกเวลาทำการ และเตรียมแผนย้อนกลับ เพื่อไม่ต้องรอคณะกรรมการประชุมรอบถัดไป
เมื่อรอบแพตช์ตามไม่ทันต้องทำอะไร
- ถ้าแพตช์ไม่ทัน ให้ลดการเปิดออกอินเทอร์เน็ตก่อน BOD 26-04 ระบุว่าการถอดระบบออกจากอินเทอร์เน็ตเป็นมาตรการที่เปลี่ยนระดับความเร่งด่วนได้ ส่วน Rapid7 แนะนำให้ประเมินมาตรการทดแทนและการตรวจจับเมื่อแก้ทันทีไม่ได้ สำหรับ PHP2Shell หน่วยงานไทยก็ออกมาตรการรับมือและมีคู่มือแพตช์ให้ทำตาม
- ตรวจร่องรอยตั้งแต่วันที่ถูกโจมตีครั้งแรก แพตช์ปิดประตูได้แต่ไม่ได้ไล่ผู้บุกรุกที่เข้ามาก่อน Amazon แนะนำให้เริ่มสืบสวนจากวันที่พบการโจมตีครั้งแรก และผู้ผลิตบางรายเตือนว่าการอัปเดตอาจลบหลักฐาน จึงควรเก็บ log และข้อมูลวินิจฉัยก่อนลงแพตช์
- ติดตามประกาศของโครงการโอเพนซอร์สโดยตรง Second Security พบว่าช่วงก่อนมีเลข CVE ยาวขึ้นเป็นหลายสัปดาห์ องค์กรที่ใช้ซอฟต์แวร์โอเพนซอร์สบนระบบสำคัญจึงควรติดตาม GitHub Security Advisories และ release notes ของโครงการ ไม่รอเพียงเครื่องสแกนช่องโหว่ และควรมีการตรวจจับตามพฤติกรรมที่ไม่ผูกกับลายเซ็นของ CVE ใดตัวหนึ่ง ซึ่งทั้ง Amazon และ Talos แนะนำตรงกัน
สรุป: วัดรอบแพตช์ด้วยระบบที่เสี่ยงที่สุด
ตัวเลข 3 วันของ Rapid7 กับกำหนด 3 วันของ CISA มาบรรจบกันโดยบังเอิญ แต่ให้ข้อสรุปเดียวกัน คือรอบแพตช์ขององค์กรต้องมีอย่างน้อยสองความเร็ว ความเร็วแรกสำหรับระบบที่เปิดออกอินเทอร์เน็ตและมีหลักฐานการโจมตี ซึ่งต้องวัดเป็นชั่วโมงหรือวัน ความเร็วที่สองสำหรับช่องโหว่ที่เหลือซึ่งยังจัดตามรอบเดือนหรือรอบอัปเกรดได้ ตัวชี้วัดที่ผู้บริหารควรถามทีมไอทีจึงไม่ใช่ "แพตช์ครบกี่เปอร์เซ็นต์" แต่เป็น "ช่องโหว่ใน KEV บนระบบที่เปิดออกอินเทอร์เน็ตใช้เวลาแก้กี่ชั่วโมง" ติดตามข่าวช่องโหว่ล่าสุดได้ที่หมวด Security
คำถามที่พบบ่อย
รอบแพตช์ขององค์กรควรเร็วแค่ไหนในปี 2026?
สำหรับระบบที่เปิดออกอินเทอร์เน็ตและมีช่องโหว่ที่ถูกโจมตีจริง รอบแพตช์ควรวัดเป็นชั่วโมงถึงไม่เกิน 3 วัน ตามที่ CISA กำหนดใน BOD 26-04 และ Amazon แนะนำให้วัดเป็นชั่วโมง ส่วนช่องโหว่บนระบบภายในหรือที่ยังไม่มีหลักฐานการโจมตีใช้รอบ 14 วัน 60 วัน หรือรอบอัปเกรดตามระดับความเสี่ยง
ช่องโหว่ถูกโจมตีเร็วแค่ไหนหลังเปิดเผย?
รายงานไตรมาส 3 ปี 2026 ของ Rapid7 พบว่าช่องโหว่ระดับ High และ Critical ถูกโจมตีเฉลี่ย 3 วันหลังเปิดเผยต่อสาธารณะ 71% ของการโจมตีที่ติดตามได้เกิดภายใน 7 วัน และ 90% เกิดภายใน 30 วัน บางกรณีอย่าง PHP2Shell มีความพยายามโจมตีก่อนวันเปิดเผยด้วย
CISA KEV คืออะไร และช่วยจัดรอบแพตช์ได้อย่างไร?
KEV หรือ Known Exploited Vulnerabilities Catalog คือรายการช่องโหว่ที่ CISA มีหลักฐานว่าถูกใช้โจมตีจริง พร้อมกำหนดเวลาแก้สำหรับหน่วยงานรัฐบาลกลางสหรัฐฯ CISA แนะนำให้ทุกองค์กรใช้รายการนี้จัดลำดับการแก้ไข องค์กรไทยใช้เป็นรายการแรกที่ต้องเข้ารอบแพตช์ฉุกเฉินได้ เพราะมีหลักฐานการโจมตีแล้ว
BOD 26-04 ต่างจาก BOD 22-01 อย่างไร?
BOD 26-04 ที่ CISA ออกเมื่อ 10 มิถุนายน 2026 ยกเลิก BOD 22-01 และ BOD 19-02 แล้วกำหนดเวลาแก้ตาม 4 ปัจจัย คือระบบเปิดออกอินเทอร์เน็ตหรือไม่ อยู่ใน KEV หรือไม่ ผู้โจมตีทำอัตโนมัติได้หรือไม่ และยึดระบบได้ทั้งหมดหรือบางส่วน กรณีเสี่ยงที่สุดต้องแก้ใน 3 วันพร้อมตรวจหาร่องรอยการถูกเจาะ
แหล่งอ้างอิง
- Q3 2026 Threat Update: Attackers Are Exploiting Vulnerabilities Within 3 Days — Rapid7
- There's only so much code: the rise in vulnerability numbers — Cisco Talos
- Known Exploited Vulnerabilities Catalog (JSON feed) — CISA
- BOD 26-04: Prioritizing Security Updates Based on Risk — CISA
- Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot — Amazon Web Services
- The Patchless Window — Second Security
บุคคล องค์กร และสถานที่ในข่าวนี้
เลือกชื่อเพื่ออ่านข่าวทั้งหมดที่กล่าวถึง ตัวเลขคือจำนวนข่าว
- ประเทศและสถานที่
- สหรัฐอเมริกา410
- ผลิตภัณฑ์และเทคโนโลยี
- CISA KEV14MadPot3
- เหตุการณ์และงาน
- PHP2Shell9
- กฎหมายและมาตรฐาน
- BOD 26-048
พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ