# ช่องโหว่ถูกโจมตีเฉลี่ยใน 3 วัน: รอบแพตช์ขององค์กรไทยต้องเร็วแค่ไหนในปี 2026

> รอบแพตช์รายเดือนไม่ทันผู้โจมตีแล้ว Rapid7 พบช่องโหว่ร้ายแรงถูกโจมตีเฉลี่ย 3 วันหลังเปิดเผย และตั้งแต่ มิ.ย. CISA ให้แก้ช่องโหว่ใน KEV ส่วนใหญ่ใน 3 วัน

- ประเภท: บทวิเคราะห์ · หมวด: Cybersecurity
- เผยแพร่: 2026-10-22T12:45:00.000Z · อัปเดต: 2026-10-22T12:45:00.000Z
- โดย: กองบรรณาธิการ THAI DATA, THAI DATA IT BUSINESS ENTERPRISE
- ที่มา: https://thaidata.co.th/security/vulnerability-exploited-within-3-days-patch-cycle/

## สรุปประเด็นสำคัญ

- 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 ยืนยันว่าถูกโจมตีในช่วงหลังส่วนใหญ่เป็นช่องโหว่ที่เพิ่งออกเลขในปีเดียวกัน ไม่ใช่ของเก่าที่ค้างมานาน รอบแพตช์ที่ช้าจึงพลาดช่องโหว่กลุ่มนี้ได้ง่ายที่สุด

![กราฟแท่งช่องโหว่ที่ CISA เพิ่มเข้า KEV ต่อเดือนในปี 2026 เทียบกับจำนวนที่เป็นเลข CVE-2026 สัดส่วนเพิ่มจาก 7 ใน 17 รายการเดือนมกราคมเป็น 40 ใน 43 รายการเดือนกันยายน](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/vulnerability-exploited-within-3-days-patch-cycle/kev-2026-additions-new-cve-share.webp?v=0578e4d4) _(ภาพ: THAI DATA (ข้อมูล: CISA KEV))_

## ช่องโหว่เก่าก็ยังต้องอยู่ในรอบแพตช์

ข้อสาม ของเก่าก็ยังไม่หายไป ปีนี้มีช่องโหว่ที่เลข 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) ส่วนกรณีที่เสี่ยงน้อยที่สุดแก้ตามรอบอัปเกรดระบบได้

![ตาราง Remediation Timelines ใน BOD 26-04 ของ CISA กำหนดเวลาแก้ 3 วัน 14 วัน 60 วัน หรือตามรอบอัปเกรด ตามการเปิดออกอินเทอร์เน็ต สถานะใน KEV การโจมตีอัตโนมัติ และระดับการยึดระบบ](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/vulnerability-exploited-within-3-days-patch-cycle/cisa-bod-26-04-table-1-timelines.webp?v=4eb34f83) _(ภาพ: CISA)_

ผลของคำสั่งนี้เห็นชัดในข้อมูล KEV ที่เรานับ ช่องโหว่ 133 รายการที่เพิ่มระหว่าง 1 มกราคมถึง 9 มิถุนายน ได้เวลาแก้ 14 วัน 55 รายการ 21 วัน 44 รายการ 3 วัน 31 รายการ และอีก 3 รายการได้ 2 หรือ 5 วัน แต่ 137 รายการที่เพิ่มตั้งแต่ 10 มิถุนายนถึง 20 ตุลาคม ได้ 3 วันถึง 111 รายการ (81%) ที่เหลือ 26 รายการได้ 14 วัน และ 89 รายการในช่วงหลังนี้มีเงื่อนไขให้ตรวจร่องรอยการถูกเจาะด้วย

![กราฟแท่งเวลาแก้ที่ CISA ให้กับช่องโหว่ใน KEV ปี 2026 ก่อนและหลัง BOD 26-04: หลัง 10 มิถุนายน 111 จาก 137 รายการได้ 3 วัน](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/vulnerability-exploited-within-3-days-patch-cycle/kev-remediation-window-bod-26-04.webp?v=001610dd) _(ภาพ: THAI DATA (ข้อมูล: CISA KEV))_

BOD 26-04 บังคับเฉพาะหน่วยงานรัฐบาลกลางสหรัฐฯ แต่ใน[ประกาศเพิ่มรายการ KEV วันที่ 20 ตุลาคม](https://www.cisa.gov/news-events/alerts/2026/10/20/cisa-adds-six-known-exploited-vulnerabilities-catalog) CISA แนะนำให้ทุกองค์กรใช้การจัดการช่องโหว่ตามความเสี่ยงและแก้รายการใน KEV ก่อน ตัวอย่างล่าสุดคือ[ชุดวันที่ 20 ตุลาคม ที่ SiteGuard ได้ 3 วันและ Siemens Software Center ได้ 14 วัน](/security/siemens-software-center-cve-2026-110936-siteguard-kev/)

## จำนวนช่องโหว่พุ่ง แต่ที่ถูกโจมตีจริงยังเป็นส่วนน้อย

Cisco Talos เขียนเมื่อ 20 ตุลาคมว่า AI รุ่นใหม่ที่เก่งด้านหาช่องโหว่ เช่น Mythos กำลังไล่ขุดหนี้ทางเทคนิคในไลบรารีเก่าที่ใช้กันทั่วโลก ทำให้ประกาศช่องโหว่ใน Patch Tuesday ของ Microsoft เพิ่มจากเฉลี่ยราว 100 รายการต่อเดือนก่อนเดือนมิถุนายน เป็น 975 รายการในเดือนกันยายน และ 1,415 รายการในเดือนตุลาคมตามการนับของ Talos (ดู[ข่าว Patch Tuesday ตุลาคม 2026](/security/microsoft-patch-tuesday-october-2026-1413-cves/))

แต่ Talos ชี้ว่าจำนวนที่ถูกโจมตีจริงไม่ได้โตตาม จากช่องโหว่ 975 รายการของ Microsoft ในเดือนกันยายน มีเพียง 3 รายการที่พบการโจมตีจริง และเมื่อเทียบกับช่วงเดียวกันของปีก่อน CVE ที่เผยแพร่เพิ่มขึ้น 105% ขณะที่รายการใน KEV เพิ่มขึ้น 37% ตัวเลขของเราจาก KEV ช่วง 1 มกราคมถึง 20 ตุลาคมให้ภาพเดียวกันที่ 30.4%

![บทความ There's only so much code ของ Cisco Talos วันที่ 20 ตุลาคม 2026 ระบุว่า CVE เพิ่ม 105% ขณะที่ KEV เพิ่ม 37% และมีเพียง 3 จาก 975 ช่องโหว่ของ Microsoft ในเดือนกันยายนที่ถูกโจมตีจริง](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/vulnerability-exploited-within-3-days-patch-cycle/talos-only-so-much-code-vulnerability-numbers.webp?v=333af486) _(ภาพ: Cisco Talos (ภาพหน้าจอ))_

ข้อสรุปของ 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 ถูกโจมตีจริง](/security/php2shell-exploited-before-disclosure-amazon-madpot/))

Amazon สรุปบทเรียนไว้ตรงกับเรื่องรอบแพตช์ว่า สำหรับช่องโหว่วิกฤตบนระบบที่เปิดออกอินเทอร์เน็ต ควรวัดเวลาแพตช์และมาตรการลดความเสี่ยงเป็นชั่วโมง เพราะ SLA 7 วันหรือ 30 วันตั้งอยู่บนช่วงเวลาที่ไม่มีอยู่แล้ว และควรเริ่มสืบสวนจากวันที่พบการโจมตีครั้งแรก ไม่ใช่วันเปิดเผย

## ช่องว่างก่อนมีเลข CVE ทำให้รอบแพตช์เริ่มช้า

กรณีอื่นในสัปดาห์เดียวกันให้ภาพคล้ายกัน ผู้ค้นพบช่องโหว่ชุด Plex2Shell ใน Plex Media Server [เผยแพร่รายละเอียดและโค้ดสาธิตเมื่อ 16 ตุลาคม](https://zmain.info/blog/plex2shell) และ[ผู้วิจัยที่ตั้ง honeypot ไว้พบการโจมตีจริงในเช้าวันที่ 17 ตุลาคม](https://www.boredhackerblog.info/2026/10/plex-vulnerabilities-being-exploited-in.html) ส่วนช่องโหว่ใน[แอป Collabora บน Nextcloud ถูกใช้ฝัง webshell ก่อนมีเลข CVE 33 วัน](/security/collabora-online-cve-2026-110447-nextcloud-backdoor/)

กรณี 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 ข้อ

1. **รู้ก่อนว่าระบบใดเปิดออกอินเทอร์เน็ต** BOD 26-04 ให้หน่วยงานติดป้ายทุกระบบที่เข้าถึงได้จากนอกเครือข่ายว่าเป็นระบบจริงหรือทดสอบ เปิดสู่สาธารณะหรือใช้ภายใน และเป็นเซิร์ฟเวอร์ แอปพลิเคชัน หรืออุปกรณ์เครือข่าย Rapid7 ก็แนะนำให้เริ่มจากรายการระบบที่เข้าถึงได้จากภายนอก เพราะช่องโหว่ 79% ในรายงานไม่ต้องล็อกอิน
2. **ใช้ KEV เป็นรายการแรกของรอบแพตช์ฉุกเฉิน** ดึงไฟล์ JSON ของ KEV มาเทียบกับรายการซอฟต์แวร์ขององค์กรทุกวัน เพราะ CISA เพิ่มรายการได้หลายครั้งต่อสัปดาห์ และช่องโหว่ส่วนใหญ่ที่เพิ่มตั้งแต่เดือนมิถุนายนได้เวลาแก้เพียง 3 วัน
3. **แยกรอบแพตช์ฉุกเฉินออกจากรอบแพตช์รายเดือน** อนุมัติขั้นตอนการเปลี่ยนแปลงล่วงหน้าสำหรับระดับฉุกเฉิน กำหนดผู้มีอำนาจตัดสินใจนอกเวลาทำการ และเตรียมแผนย้อนกลับ เพื่อไม่ต้องรอคณะกรรมการประชุมรอบถัดไป

## เมื่อรอบแพตช์ตามไม่ทันต้องทำอะไร

1. **ถ้าแพตช์ไม่ทัน ให้ลดการเปิดออกอินเทอร์เน็ตก่อน** BOD 26-04 ระบุว่าการถอดระบบออกจากอินเทอร์เน็ตเป็นมาตรการที่เปลี่ยนระดับความเร่งด่วนได้ ส่วน Rapid7 แนะนำให้ประเมินมาตรการทดแทนและการตรวจจับเมื่อแก้ทันทีไม่ได้ สำหรับ PHP2Shell หน่วยงานไทยก็ออก[มาตรการรับมือ](/security/php2shell-measures-thailand-ncsa-mhesi/)และมี[คู่มือแพตช์](/security/php2shell-patch-guide-check-php-version/)ให้ทำตาม
2. **ตรวจร่องรอยตั้งแต่วันที่ถูกโจมตีครั้งแรก** แพตช์ปิดประตูได้แต่ไม่ได้ไล่ผู้บุกรุกที่เข้ามาก่อน Amazon แนะนำให้เริ่มสืบสวนจากวันที่พบการโจมตีครั้งแรก และผู้ผลิตบางรายเตือนว่าการอัปเดตอาจลบหลักฐาน จึงควรเก็บ log และข้อมูลวินิจฉัยก่อนลงแพตช์
3. **ติดตามประกาศของโครงการโอเพนซอร์สโดยตรง** Second Security พบว่าช่วงก่อนมีเลข CVE ยาวขึ้นเป็นหลายสัปดาห์ องค์กรที่ใช้ซอฟต์แวร์โอเพนซอร์สบนระบบสำคัญจึงควรติดตาม GitHub Security Advisories และ release notes ของโครงการ ไม่รอเพียงเครื่องสแกนช่องโหว่ และควรมีการตรวจจับตามพฤติกรรมที่ไม่ผูกกับลายเซ็นของ CVE ใดตัวหนึ่ง ซึ่งทั้ง Amazon และ Talos แนะนำตรงกัน

## สรุป: วัดรอบแพตช์ด้วยระบบที่เสี่ยงที่สุด

ตัวเลข 3 วันของ Rapid7 กับกำหนด 3 วันของ CISA มาบรรจบกันโดยบังเอิญ แต่ให้ข้อสรุปเดียวกัน คือรอบแพตช์ขององค์กรต้องมีอย่างน้อยสองความเร็ว ความเร็วแรกสำหรับระบบที่เปิดออกอินเทอร์เน็ตและมีหลักฐานการโจมตี ซึ่งต้องวัดเป็นชั่วโมงหรือวัน ความเร็วที่สองสำหรับช่องโหว่ที่เหลือซึ่งยังจัดตามรอบเดือนหรือรอบอัปเกรดได้ ตัวชี้วัดที่ผู้บริหารควรถามทีมไอทีจึงไม่ใช่ "แพตช์ครบกี่เปอร์เซ็นต์" แต่เป็น "ช่องโหว่ใน KEV บนระบบที่เปิดออกอินเทอร์เน็ตใช้เวลาแก้กี่ชั่วโมง" ติดตามข่าวช่องโหว่ล่าสุดได้ที่[หมวด Security](/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](https://www.rapid7.com/blog/post/tr-q3-2026-threat-update-attackers-exploiting-vulnerabilities-within-3-days/) — Rapid7
- [There's only so much code: the rise in vulnerability numbers](https://blog.talosintelligence.com/theres-only-so-much-code-the-rise-in-vulnerability-numbers/) — Cisco Talos
- [Known Exploited Vulnerabilities Catalog (JSON feed)](https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json) — CISA
- [BOD 26-04: Prioritizing Security Updates Based on Risk](https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk) — CISA
- [Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/) — Amazon Web Services
- [The Patchless Window](https://thepatchlesswindow.com/) — Second Security