NGINX อุดช่องโหว่ร้ายแรง 3 จุด เจ้าของเว็บควรถามโฮสต์ก่อนเว็บล่ม

ช่องโหว่ NGINX ร้ายแรง 3 รายการได้คะแนนความรุนแรง CVSS รุ่น 4.0 ที่ 9.2 โดย NEXSIGHT รายงานว่า F5 ออกประกาศความปลอดภัยนอกรอบเมื่อวันที่ 14 ตุลาคม 2026 และมีรุ่นแก้ไขแล้ว จุดที่ต้องสนใจคือปัญหานี้ทำให้บริการหยุด และในบางเงื่อนไขอาจเปิดทางให้ผู้โจมตีสั่งให้ระบบรันโค้ดได้ (NEXSIGHT)

สำหรับคนเปิดร้านออนไลน์หรือทำงานผ่านเว็บ เรื่องนี้แปลเป็นคำง่าย ๆ ว่า ควรถามคนดูแลระบบว่าเว็บเราใช้ซอฟต์แวร์ตัวนี้หรือไม่ และอัปเดตถึงไหนแล้ว ผมไม่ได้กำลังบอกว่าเว็บของคุณโดนโจมตี แต่รายงานวันที่ 19 ตุลาคมระบุว่าผู้โจมตีจากระยะไกลที่ยังไม่ได้รับสิทธิ์เข้าระบบอาจใช้ช่องโหว่กับการตั้งค่าบางแบบที่ต่างจากค่าเริ่มต้นได้ จึงมีเหตุผลให้ตรวจสอบก่อนเกิดปัญหา (BleepingComputer)

สรุป 30 วินาที: เกิดอะไรขึ้น

NGINX คือซอฟต์แวร์เว็บเซิร์ฟเวอร์ หรือโปรแกรมที่รับและตอบคำขอใช้งานเว็บไซต์ รอบนี้ F5 ออกแพตช์ ซึ่งหมายถึงชุดอัปเดตแก้ข้อบกพร่อง นอกกำหนดปกติให้หลายผลิตภัณฑ์ในกลุ่ม NGINX โดยมีช่องโหว่ระดับวิกฤตเป็นประเด็นหลัก 3 รายการ (BleepingComputer)

• CVE-2026-15176 และ CVE-2026-93479 เป็นปัญหา heap buffer overflow หมายถึงการเขียนข้อมูลเกินพื้นที่หน่วยความจำที่เตรียมไว้ จนอาจทำให้ข้อมูลส่วนอื่นในหน่วยความจำเสียหาย (NEXSIGHT)
• CVE-2026-97205 เป็นปัญหา use-after-free หมายถึงโปรแกรมกลับไปใช้หน่วยความจำที่ปล่อยคืนไปแล้ว จนการทำงานผิดพลาดได้ (NEXSIGHT)
• ผลที่รายงานคือกระบวนการทำงานของ NGINX ล้มหรือเริ่มใหม่ ทำให้เกิด DoS หรือการทำให้บริการใช้งานไม่ได้ ส่วนการรันโค้ดมีเงื่อนไขเพิ่มเติมเกี่ยวกับระบบป้องกันหน่วยความจำ (BleepingComputer)
• ณ รายงานวันที่ 19 ตุลาคม F5 ยังไม่ได้ระบุว่าช่องโหว่เหล่านี้ถูกใช้โจมตีจริงแล้ว ข้อความนี้บอกสถานะของข้อมูลที่เปิดเผยในข่าว ไม่ได้รับรองว่าจะไม่มีการโจมตีเกิดขึ้นภายหลัง (BleepingComputer)

ประกาศหลักที่ NEXSIGHT อ้างถึงใช้รหัส K000163408 ลงวันที่ 14 ตุลาคม 2026 และเป็นดัชนีรวมประกาศที่เกี่ยวข้อง 11 รายการ ดังนั้นรายชื่อผลิตภัณฑ์ในประกาศรวมจึงกว้างกว่าช่องโหว่วิกฤต 3 รายการที่บทความนี้เน้นครับ (NEXSIGHT)

ทำไมเรื่องนี้เกี่ยวกับคุณ

ถ้าคุณดูแลเว็บไซต์ สิ่งที่เกี่ยวโดยตรงคือความพร้อมใช้งาน เพราะช่องโหว่สามารถทำให้ส่วนที่ประมวลผลคำขอของ NGINX หยุดทำงานหรือเริ่มใหม่ได้ ส่วนคนที่ไม่ได้ดูแลเครื่องเองควรมองเป็นงานประสานกับผู้ให้บริการ มากกว่างานแก้ไขบนมือถือหรือคอมพิวเตอร์ส่วนตัวของตัวเอง ตัวปัญหาที่ข่าวกล่าวถึงอยู่ในระบบ NGINX ฝั่งให้บริการเว็บ (BleepingComputer)

ลองนึกถึงงานของตัวเอง หากเว็บรับคำสั่งซื้อเปิดไม่ได้ งานที่ควรถามต่อคือจะรับออเดอร์อย่างไรระหว่างรอ หากระบบงานที่ต้องใช้ทุกวันเข้าไม่ได้ ใครจะเป็นคนแจ้งผู้ใช้และติดตามการแก้ไข นี่เป็นตัวอย่างการวางแผนรับมือ ไม่ใช่รายงานว่ามีร้านค้า ธนาคาร หรือองค์กรไทยรายใดได้รับผลกระทบจากเหตุนี้แล้ว

คนที่ใช้บริการโฮสต์ภายนอกอาจไม่มีสิทธิ์อัปเดตซอฟต์แวร์ส่วนนี้เอง ผมแนะนำให้ส่งชื่อประกาศและถามสถานะให้ชัดว่า ใช้ผลิตภัณฑ์ใด รุ่นใด และตรวจการตั้งค่าแล้วหรือยัง เพราะ BleepingComputer ระบุว่าการใช้ประโยชน์เกี่ยวข้องกับการตั้งค่าที่ไม่ใช่ค่าเริ่มต้น การเห็นชื่อ NGINX อย่างเดียวจึงยังไม่พอจะสรุประดับความเสี่ยงของระบบหนึ่ง ๆ (BleepingComputer)

สำหรับทีมไอที ขอบเขตไม่ได้มีเพียง NGINX ที่ติดตั้งแยกบนเครื่อง รายการของศูนย์ความมั่นคงปลอดภัยไซเบอร์แคนาดายังรวม Ingress Controller, Gateway Fabric, Instance Manager และผลิตภัณฑ์ป้องกันเว็บในตระกูลเดียวกันด้วย การถามแค่ว่าเครื่องเว็บหลักอัปเดตหรือยังจึงอาจยังไม่ครอบคลุมรายการที่ต้องตรวจ (Canadian Cyber Centre)

ทำงานยังไง

คำอธิบายแบบไม่ต้องอ่านโค้ดคือ เมื่อ NGINX ประมวลผลคำขอในเงื่อนไขการตั้งค่าที่มีปัญหา ข้อบกพร่องจะทำให้การใช้หน่วยความจำผิดพลาด ตัวที่ทำงานรับคำขอจริงหรือ worker process จึงอาจล้มและเริ่มใหม่ได้ ทั้งปัญหาเขียนเกินพื้นที่และปัญหาใช้พื้นที่ที่คืนไปแล้วอยู่ในกลุ่มความเสียหายของหน่วยความจำนี้ (BleepingComputer)

เปรียบเหมือน พนักงานต้อนรับหน้าห้างที่บางกรณีโดนถามคำถามพิสดารแล้วล้มทั้งยืน คนที่เดินมาถามไม่จำเป็นต้องเป็นพนักงานของห้าง แต่ต้องเจอเงื่อนไขที่ทำให้เกิดอาการนั้น การเปรียบเทียบนี้ช่วยให้เห็นภาพว่าทำไมคำขอจากภายนอกจึงอาจกระทบการให้บริการได้ ส่วนในระบบจริง ข่าวระบุว่าผู้โจมตีไม่ต้องมีสิทธิ์เข้าระบบก่อน และต้องเกี่ยวข้องกับการตั้งค่าที่มีปัญหา ไม่ใช่ทุกการติดตั้งจะมีเงื่อนไขเหมือนกัน (BleepingComputer)

อีกคำที่ควรรู้คือ ASLR ย่อจาก Address Space Layout Randomization เป็นกลไกของระบบปฏิบัติการที่สุ่มตำแหน่งข้อมูลในหน่วยความจำ เพื่อทำให้ผู้โจมตีคาดเดาตำแหน่งที่ต้องใช้ได้ยากขึ้น NEXSIGHT อธิบายว่าการรันโค้ดอาจเกิดขึ้นเมื่อ ASLR ถูกปิด หรือเมื่อผู้โจมตีหลบผ่านการป้องกันนี้ได้ จึงไม่ควรย่อข่าวเหลือเพียงว่าใครก็สั่งรันโค้ดได้ทันที (NEXSIGHT)

อย่างไรก็ตาม การเปิด ASLR ไม่ได้ทำให้ข้ามงานแพตช์ได้ เพราะผลกระทบอีกส่วนคือบริการหยุด ซึ่งรายงานแยกไว้จากเงื่อนไขการรันโค้ด วิธีอ่านข่าวที่เหมาะสมจึงต้องแยกสองเรื่องนี้ออกจากกัน: ระบบอาจมีความเสี่ยงต่อการหยุดให้บริการ และในบางสภาพแวดล้อมอาจมีความเสี่ยงต่อการรันโค้ดเพิ่มขึ้นด้วย (BleepingComputer)

จุดหักมุม: คะแนนวิกฤต แต่ยังต้องดูการตั้งค่าจริง

ตัวเลข 9.2 ฟังแล้วชวนให้รีบจัดการ ซึ่งเหมาะกับการหยิบเรื่องนี้ขึ้นมาตรวจ แต่ตัวเลขไม่ได้บอกว่าเครื่องทุกเครื่องมีเงื่อนไขครบเหมือนกัน BleepingComputer ระบุชัดถึงการตั้งค่าที่ต่างจากค่าเริ่มต้น ขณะที่ NEXSIGHT อธิบายการใช้ความสามารถบางอย่างร่วมกันเป็นเงื่อนไขของแต่ละช่องโหว่ ทีมดูแลจึงควรตรวจทั้งรุ่นและการตั้งค่าไปพร้อมกัน (BleepingComputer, NEXSIGHT)

อีกจุดคือคะแนนที่ดูต่างกันอาจมาจากคนละรุ่นของเกณฑ์ CVSS ซึ่งเป็นระบบให้คะแนนความรุนแรงของช่องโหว่ NEXSIGHT ระบุว่าทั้งสามรายการได้ 8.1 ระดับสูงตาม CVSS 3.1 และ 9.2 ระดับวิกฤตตาม CVSS 4.0 จึงควรเขียนเลขพร้อมชื่อรุ่นของเกณฑ์เสมอ ไม่อย่างนั้นคนรับงานต่ออาจนึกว่ามีใครคัดลอกตัวเลขผิด (NEXSIGHT)

เรื่องเงิน / ผลกระทบ

แหล่งข่าวชุดนี้ไม่มีตัวเลขความเสียหาย ค่าใช้จ่ายในการแก้ไข หรือจำนวนองค์กรไทยที่ได้รับผลกระทบ จึงยังประเมินเป็นเงินบาทไม่ได้ สิ่งที่ระบุได้คือผลทางเทคนิค ได้แก่ บริการหยุด การเริ่มกระบวนการทำงานใหม่ และโอกาสรันโค้ดภายใต้เงื่อนไขที่กล่าวไปแล้ว (BleepingComputer)

ในมุมวางแผนธุรกิจ ผมแนะนำให้เริ่มจากงานที่หยุดแล้วกระทบรายรับหรือทำให้คนทำงานต่อไม่ได้ เช่น ช่องทางรับคำสั่งซื้อและระบบที่พนักงานต้องใช้ประจำ จากนั้นให้คนดูแลระบบตรวจว่าแต่ละบริการอยู่ในขอบเขตประกาศหรือไม่ วิธีนี้ช่วยให้การจัดลำดับงานผูกกับผลที่เกิดกับธุรกิจจริง โดยไม่ต้องแต่งตัวเลขความเสียหายขึ้นมา

ส่วนต้นทุนการแก้ไขควรถามให้ครบทั้งเวลาทดสอบ ช่วงเวลาที่จะเปลี่ยนระบบ และคนที่รับผิดชอบตรวจหลังเปลี่ยน สำหรับทีมที่ยังแพตช์ทันทีไม่ได้ NEXSIGHT รายงานว่ามีแนวทางลดความเสี่ยงด้วยการปรับการตั้งค่า แต่ยังคงแนะนำให้ย้ายไปใช้รุ่นที่มีการแก้ไข และหากสายรุ่นเดิมไม่มีรุ่นแก้ก็ควรอัปเกรดไปสายที่รวมการแก้แล้ว (NEXSIGHT)

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

ตำแหน่งส่วนประกอบที่มีปัญหาไม่ตรงกันในข่าวสองแห่ง BleepingComputer จัด CVE-2026-15176 และ CVE-2026-97205 ไว้ในส่วนประกอบ HTTP/3 ขณะที่ NEXSIGHT จัดสองรายการนี้ไว้ในส่วนประกอบแกนหลักของ NGINX ส่วน CVE-2026-93479 ทั้งสองแหล่งเชื่อมโยงกับส่วนตั้งค่าจับคู่ข้อมูล ผมจึงไม่ใช้ชื่อส่วนประกอบจากข่าวใดข่าวหนึ่งตัดสินว่าเครื่องของใครปลอดภัย ควรให้ผู้ดูแลเทียบประกาศรายช่องโหว่และการตั้งค่าจริงก่อน (BleepingComputer, NEXSIGHT)

ขอบเขตเวอร์ชันต้องอ่านตามขอบเขตประกาศ Canadian Cyber Centre ระบุ NGINX Plus R33 ถึง R36 ในกลุ่มได้รับผลกระทบด้วย ขณะที่รายละเอียดของช่องโหว่หลักใน NEXSIGHT เน้นสาย 37.0 และรุ่นแก้ในสาย 37.0 กับ 37.1 จึงยังไม่ควรสรุปจากข้อมูลชุดนี้ว่ารุ่นเก่าทุกรุ่นได้รับผลจากทั้งสามช่องโหว่เหมือนกัน หรือมีทางอัปเดตแบบเดียวกันทั้งหมด (Canadian Cyber Centre, NEXSIGHT)

วันที่เป็นคนละขั้นของการเผยแพร่ NEXSIGHT รายงานประกาศ F5 วันที่ 14 ตุลาคม ส่วนคำเตือน AV26-1049 ของแคนาดาลงวันที่ 15 ตุลาคม และข่าว BleepingComputer ลงวันที่ 19 ตุลาคม 2026 จึงไม่ควรนำวันที่ข่าวมาบอกว่าเป็นวันที่ F5 เพิ่งออกแพตช์ (NEXSIGHT, Canadian Cyber Centre, BleepingComputer)

ยังไม่ทราบผลกระทบในไทยและสถานะหลังรายงานล่าสุด แหล่งข้อมูลที่ให้มาไม่ได้ระบุองค์กรไทยที่ได้รับผลกระทบ และข้อความว่ายังไม่ถูกระบุว่ามีการโจมตีจริงเป็นสถานะตามข่าววันที่ 19 ตุลาคม ไม่ใช่ผลตรวจระบบของผู้อ่านหรือการยืนยันสถานการณ์ทุกช่วงเวลาครับ (BleepingComputer)

แล้วเราควรทำอะไร

เจ้าของร้านออนไลน์และธุรกิจขนาดเล็กที่จ้างโฮสต์หรือทีมดูแลเว็บ

1. ส่งข่าวนี้ให้ผู้ดูแล แล้วถามว่าใช้ NGINX หรือผลิตภัณฑ์ในประกาศหรือไม่ ขอชื่อผลิตภัณฑ์และรุ่นที่ใช้อยู่เพื่อให้เทียบกับรายการได้ ผมแนะนำให้ขอคำตอบเป็นข้อความที่ย้อนกลับมาอ่านได้
2. ถ้าอยู่ในขอบเขต ให้ขอแผนอัปเดตและเวลาที่จะยืนยันผล อย่าจบเพียงคำว่า “รับทราบแล้ว” เพราะเป้าหมายของงานคือให้ทราบว่าส่วนที่เกี่ยวข้องแก้แล้วหรือยัง แนวทางหลักของคำเตือนแคนาดาคือทบทวนประกาศและติดตั้งอัปเดตที่จำเป็นเมื่อมีให้ใช้ (Canadian Cyber Centre)
3. ตกลงว่าจะตรวจงานสำคัญอะไรหลังเปลี่ยน เช่น เปิดหน้าเว็บ ส่งข้อมูลที่จำเป็น และใช้งานขั้นตอนหลักของร้านได้หรือไม่ ข้อนี้เป็นคำแนะนำให้ตรวจผลกับงานจริงของคุณ ไม่ใช่หลักฐานว่าเว็บผ่านหรือไม่ผ่านช่องโหว่

ผู้ดูแลเซิร์ฟเวอร์และทีมไอที

1. ทำรายการผลิตภัณฑ์ รุ่น และรูปแบบติดตั้ง รวมถึงคอนเทนเนอร์หรือชุดซอฟต์แวร์ที่บรรจุระบบไว้ให้รันแยกกัน ผมแนะนำให้ตรวจสิ่งที่ใช้งานจริงครบทุกชุด เพราะประกาศรวมครอบคลุมผลิตภัณฑ์หลายชนิด (Canadian Cyber Centre)
2. เทียบสายรุ่นกับตารางด้านล่าง สำหรับแพ็กเกจที่มากับระบบปฏิบัติการ ให้ตรวจประกาศของผู้จัดทำระบบนั้นเพิ่มเติม ข้อมูลชุดนี้ไม่ได้ให้สถานะแพ็กเกจของแต่ละค่าย จึงไม่ควรเดาว่ารุ่นที่เห็นได้รับการแก้ไขแล้วหรือยัง
3. หากยังอัปเดตไม่ได้ ให้ประเมินแนวทางชั่วคราวที่แหล่งข่าวถ่ายทอดจาก F5 ได้แก่ หลีกเลี่ยงการตั้งค่าบางแบบที่เกี่ยวกับการชี้ตำแหน่งไฟล์ ปิด AIO ซึ่งเป็นการอ่านเขียนไฟล์แบบไม่รอให้งานก่อนหน้าจบ หรือปิด SSI ซึ่งเป็นการให้เซิร์ฟเวอร์ประกอบเนื้อหาบางส่วนในหน้าเว็บ อีกแนวทางคือเปลี่ยนการจับข้อความตามรูปแบบให้มีชื่อกำกับและจำกัดการใช้งานอยู่ในขอบเขตที่ตรงกัน ทั้งหมดต้องเลือกให้ตรงกับช่องโหว่และการตั้งค่าของระบบ (NEXSIGHT)
4. ทดสอบการเปลี่ยนในสภาพแวดล้อมทดสอบก่อน และตรวจไวยากรณ์การตั้งค่าด้วย nginx -t ก่อนสั่งให้ระบบอ่านค่าที่แก้ใหม่ แนวทางตรวจการตั้งค่าและทดสอบก่อนใช้จริงเป็นสิ่งที่ NEXSIGHT รายงานจากคำแนะนำ F5 แต่ผลผ่านการตรวจไวยากรณ์อย่างเดียวไม่ควรถูกใช้แทนการตรวจรุ่นและผลการให้บริการ (NEXSIGHT)

ทีม Kubernetes

1. ตรวจทั้ง Ingress Controller ซึ่งเป็นส่วนจัดการทางเข้าของคำขอไปยังบริการ และ Gateway Fabric ที่ใช้ในระบบของทีม ชื่อทั้งสองอยู่ในรายการคำเตือนแคนาดา จึงควรรวมไว้ในขอบเขตตรวจ ไม่ตรวจเพียง NGINX ที่ติดตั้งนอกระบบจัดการแอป (Canadian Cyber Centre)
2. เทียบรุ่น Ingress Controller กับ 5.7.0 และ Gateway Fabric กับ 2.8.0 ตามรายการของแคนาดา พร้อมตรวจว่าชุดที่ทำงานจริงได้รับการเปลี่ยนแล้ว ผมแนะนำให้บันทึกผลเป็นรายระบบเพื่อให้เจ้าของบริการตามสถานะได้ (Canadian Cyber Centre)
3. หลังเปลี่ยน ให้ตรวจเส้นทางการใช้งานหลักของบริการและติดตามอาการผิดปกติ การตรวจว่าบริการยังทำงานได้เป็นงานคนละส่วนกับการยืนยันว่ารุ่นที่ใช้อยู่รวมการแก้ไขแล้ว ทีมควรมีคำตอบให้ครบทั้งสองส่วน

รุ่นที่ควรนำไปเทียบกับระบบจริง

ตารางนี้สรุปรุ่นอ้างอิงจาก AV26-1049 ของ Canadian Cyber Centre ซึ่งระบุรุ่นก่อนหน้าตัวเลขเหล่านี้ในรายการได้รับผลกระทบ นี่เป็นรายการของประกาศรวม จึงต้องเลือกสายผลิตภัณฑ์และอ่านรายละเอียดประกอบ ไม่ควรตีความว่าทุกผลิตภัณฑ์มีทั้งสามช่องโหว่เหมือนกัน (Canadian Cyber Centre)

ผลิตภัณฑ์	รุ่นอ้างอิงสำหรับตรวจการอัปเดต
NGINX Open Source	1.30.6 / 1.31.7
NGINX Plus	37.0.5.1 / 37.1.0.1
NGINX Ingress Controller	5.7.0
NGINX Gateway Fabric	2.8.0
NGINX Instance Manager	2.24.0
F5 WAF for NGINX	5.16.0 / 5.14.2
F5 DoS for NGINX	4.11.0
NGINX JavaScript	1.0.2

ตัวเลขในตารางทั้งหมดมาจากคำเตือนแคนาดา โดยเครื่องหมายคั่นแสดงตัวเลขของต่างสายรุ่น ไม่ได้หมายความว่าต้องติดตั้งสองรุ่นพร้อมกัน รายการเดียวกันยังระบุ NGINX Plus R33 ถึง R36 ว่าได้รับผลกระทบด้วย จึงควรให้ผู้ดูแลตรวจทางอัปเกรดของสายเดิมก่อนตัดสินใจ (Canadian Cyber Centre)

ผมมองว่า…

ผมมองว่า สิ่งที่ควรเร่งไม่ใช่การส่งต่อคะแนน 9.2 แต่คือการทำให้รู้ว่าใครดูแลระบบไหนและแก้ถึงขั้นใดแล้ว นี่เป็นความเห็นของผมจากข้อมูลในข่าว เพราะคำว่า “วิกฤต” จะช่วยงานได้น้อยถ้าส่งต่อกันหลายรอบแล้วยังไม่มีคนเทียบรุ่นจริง

ผมให้น้ำหนักกับการมีหลักฐานการตรวจที่อ่านรู้เรื่อง: ใช้อะไร อยู่รุ่นใด เข้าข่ายหรือไม่ ถ้าเข้าข่ายจะอัปเดตเมื่อไร และใครตรวจผลหลังเปลี่ยน เจ้าของธุรกิจไม่จำเป็นต้องเข้าใจรายละเอียดการจัดการหน่วยความจำทั้งหมดเพื่อถามคำถามเหล่านี้ได้ ส่วนทีมเทคนิคก็จะได้ขอบเขตงานชัดขึ้น แทนการตอบสถานะกว้าง ๆ ว่า “กำลังดูอยู่” จนวันทำงานเปลี่ยนเป็นวันตามงาน

ปิดท้าย: สิ่งที่ต้องจับตา

สิ่งที่ควรติดตามต่อคือสถานะการโจมตีจริง คำอธิบายส่วนประกอบที่ข่าวระบุต่างกัน และแนวทางแก้สำหรับสายรุ่นที่องค์กรใช้อยู่ โดยฐานข้อมูลของบทความนี้จบที่รายงาน BleepingComputer วันที่ 19 ตุลาคม ซึ่งยังไม่ระบุว่าถูกใช้โจมตีจริง ส่วนคำเตือนแคนาดาแนะนำให้ติดตั้งอัปเดตที่จำเป็นเมื่อมีให้ใช้งาน (BleepingComputer, Canadian Cyber Centre)

สำหรับวันนี้ ผมแนะนำให้เจ้าของเว็บเริ่มจากขอสถานะที่ตรวจสอบได้จากคนดูแล และให้ทีมไอทีนำรายการผลิตภัณฑ์ไปเทียบกับสิ่งที่กำลังทำงานจริง เมื่อได้คำตอบแล้วจึงจัดคิวแก้ไขตามความสำคัญของบริการ ไม่จำเป็นต้องรอให้ผู้ใช้แจ้งว่าเข้าเว็บไม่ได้ก่อนครับ

Recap

• ถามผู้ดูแลว่าเว็บหรือระบบงานใช้ผลิตภัณฑ์ในประกาศหรือไม่
• เก็บชื่อผลิตภัณฑ์ รุ่น และผู้รับผิดชอบของแต่ละระบบ
• เทียบรุ่นจริงกับรายการอัปเดตและสายรุ่นที่ใช้อยู่
• ตรวจคอนเทนเนอร์ Ingress Controller และ Gateway Fabric ในขอบเขตงานด้วย
• หากยังแพตช์ไม่ได้ ให้ผู้ดูแลเลือกมาตรการชั่วคราวให้ตรงกับการตั้งค่า
• ทดสอบการเปลี่ยน ตรวจการตั้งค่า และตรวจงานหลักหลังอัปเดต
• แยกสถานะการแก้ช่องโหว่ออกจากสถานะที่เว็บยังเปิดได้
• ติดตามข้อมูลการโจมตีต่อ และยังไม่สรุปว่าองค์กรไทยได้รับผลกระทบ