จัดทำโดย: Cloud Thunder Threat Intelligence
หัวข้อ: PHP2Shell และการตอบสนองของโลก พร้อมช่องโหว่ NGINX และ Oracle รอบเดือนตุลาคม 2569 (Critical Vulnerability & Global Response Assessment)
ประเภทเอกสาร: บทวิเคราะห์เชิงยุทธศาสตร์ด้านภัยคุกคามระดับชาติ (Strategic Threat Assessment)
มุมมอง: ความมั่นคงปลอดภัยไซเบอร์ของประเทศไทย
ฐานข้อมูล: ประกาศความปลอดภัยของ PHP (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp), nginx.org และ F5 (K000162416, K000163408), Oracle Critical Patch Update Advisory ตุลาคม 2569, รายงานจาก Tenable, Qualys TRU, watchTowr, Wiz, Google Cloud/Mandiant, SOCRadar, VulnCheck, Censys, Cloudflare, CERT-EU, NSA/CISA, NCSC (UK/NL), BSI, ASD, Bloomsbury Intelligence and Security Institute (BISI), รายงานข่าวจาก Reuters/dpa/Jiji ผ่านสื่อหลายประเทศ, SecurityWeek, The Hacker News, ThaiCERT/สกมช. และฐานข่าวของ Cloud Thunder (ข้อมูลถึงวันที่ 23 ตุลาคม 2569)

บทสรุปเชิงยุทธศาสตร์ (Strategic Summary)

สัปดาห์ที่ 14–21 ตุลาคม 2569 เป็นช่วงที่ซอฟต์แวร์สามชั้นซึ่งรองรับบริการดิจิทัลเกือบทั้งหมดของประเทศออกแพตช์ความปลอดภัยพร้อมกัน ชั้นแรกคือเว็บเซิร์ฟเวอร์และ reverse proxy (ตัวกลางรับคำขอก่อนส่งต่อเข้าระบบหลังบ้าน) อย่าง NGINX ชั้นที่สองคือภาษาและ runtime ที่ใช้รันเว็บแอปพลิเคชันอย่าง PHP และชั้นที่สามคือฐานข้อมูล มิดเดิลแวร์ และระบบบริหารทรัพยากรองค์กร (ERP) ของ Oracle ทั้งสามชั้นนี้คือ “กระดูกสันหลัง” ของเว็บไซต์หน่วยงานรัฐ ระบบทะเบียนนักศึกษา ระบบโรงพยาบาล ระบบธนาคาร และระบบงานหลังบ้านขององค์กรโครงสร้างพื้นฐานสำคัญทางสารสนเทศ (CII — Critical Information Infrastructure)

ในสามกลุ่มนี้ PHP2Shell คือภัยเร่งด่วนที่สุด แม้คะแนน CVSS (Common Vulnerability Scoring System — มาตรฐานให้คะแนนความรุนแรง) จะอยู่ที่ 9.2 ซึ่งต่ำกว่าช่องโหว่ 10.0 ของ Oracle เหตุผลมีสามข้อ ข้อแรก ช่องโหว่ทั้งสอง (CVE-2026-109618 และ CVE-2026-109619) อยู่ในแกนกลางของ PHP เอง ไม่ใช่ในแอปพลิเคชันตัวใดตัวหนึ่ง และโจมตีได้จากระยะไกลโดยไม่ต้องล็อกอิน นักวิจัยยืนยันการรันโค้ดจากระยะไกล (RCE — Remote Code Execution) บน WordPress, Drupal, Joomla และ Magento แล้ว ข้อที่สอง ข้อมูลช่องโหว่หลุดก่อนวันเปิดเผยตามกำหนด และ Amazon พบความพยายามโจมตีตั้งแต่วันที่ 17 ตุลาคม ซึ่งเป็นสี่วันก่อนแพตช์ออก ปัจจุบันมีการโจมตีจริงในวงกว้าง ข้อที่สาม PHP 8.1 ลงไปซึ่งหมดอายุแล้วไม่มีแพตช์จากผู้พัฒนา ข้อมูลของ Qualys ชี้ว่าราว 71% ของการติดตั้ง PHP ที่ระบุเวอร์ชันได้อยู่ในสายที่หมดอายุ

NGINX อยู่ในลำดับรอง ช่องโหว่หน่วยความจำ 3 ตัวที่ F5 ให้ CVSS v4.0 9.2 อาจทำให้ worker ล่มหรือถึงขั้นรันโค้ด แต่ทุกตัวต้องอาศัยการตั้งค่าเฉพาะ และยังไม่มีรายงานการโจมตีจริง อย่างไรก็ดี บทเรียนจาก NGINX Rift (CVE-2026-42945) เมื่อเดือนพฤษภาคม ซึ่งถูกโจมตีภายในสามวันหลังเปิดเผย บอกว่าช่วงเวลาปลอดภัยของช่องโหว่ NGINX สั้นมาก Oracle CPU อยู่ในลำดับที่ต้องจัดการเป็นระบบ ขนาด 1,295 แพตช์และช่องโหว่คะแนน 10.0 ในผลิตภัณฑ์ที่ทำหน้าที่ยืนยันตัวตนและเชื่อมระบบ (Oracle Access Manager, SOA Suite) ทำให้ระบบ ERP และระบบยืนยันตัวตนขององค์กรขนาดใหญ่ตกอยู่ในความเสี่ยงสูง แม้ Oracle ยังไม่ระบุว่ามีการโจมตีจริง

ในระดับโลก PHP2Shell กลายเป็นเหตุการณ์ที่หาได้ยาก เพราะ รัฐบาลหลายประเทศเลือกปิดเว็บไซต์ของตัวเองเป็นมาตรการป้องกัน เนเธอร์แลนด์ปิดระบบยืนยันตัวตนประชาชน DigiD และแม้แต่เว็บไซต์ของ NCSC เอง ฟินแลนด์ เยอรมนี ฝรั่งเศส เบลเยียม เดนมาร์ก เช็ก สหราชอาณาจักร แคนาดา และออสเตรเลียต่างมีเว็บไซต์ภาครัฐออฟไลน์ นายกรัฐมนตรีญี่ปุ่นโพสต์เตือนประชาชนเองจนมีผู้เข้าชมกว่า 30 ล้านครั้ง ส่วน NSA แนะนำให้ปิดระบบที่แพตช์ไม่ได้ ขณะเดียวกัน Wikipedia, Internet Archive และแพลตฟอร์มญี่ปุ่นอย่าง pixiv และ niconico ก็ปิดบางระบบ ความพยายามโจมตีที่ Cloudflare เห็นพุ่งจากหลักพันเป็นหลักล้านภายในวันเดียว แต่ ณ วันที่ 23 ตุลาคม ยังไม่มีการยืนยันต่อสาธารณะว่ามีระบบใดถูกเจาะสำเร็จ และ BSI ประเมินภายหลังว่าช่องโหว่ใช้งานยากกว่าที่คาด ข้อถกเถียงว่า “การปิดเว็บคุ้มหรือไม่” จึงกลายเป็นบทเรียนเชิงนโยบายที่สำคัญไม่แพ้ตัวช่องโหว่ (รายละเอียดในหัวข้อ 3)

สำหรับประเทศไทย ภาครัฐตอบสนองเร็วกว่าปกติ รองนายกรัฐมนตรีและรัฐมนตรีว่าการกระทรวง อว. สั่งให้มหาวิทยาลัย โรงพยาบาล และโรงเรียนแพทย์เร่งตรวจระบบ และ ThaiCERT ออกประกาศเตือนระดับประเทศตั้งแต่เช้าวันที่ 22 ตุลาคม แต่ข้อเท็จจริงเชิงโครงสร้างไม่เปลี่ยน ระบบเว็บภาครัฐและสถาบันการศึกษาของไทยจำนวนมากยังรัน PHP สายเก่าที่หมดอายุ ใช้ระบบจัดการเนื้อหา (CMS) ที่ไม่มีผู้ดูแลต่อเนื่อง และมีระบบ Oracle ที่ข้ามรอบแพตช์มาหลายไตรมาส ความเสี่ยงที่แท้จริงจึงไม่ได้อยู่ที่ตัวช่องโหว่เพียงอย่างเดียว แต่อยู่ที่ ช่องว่างระหว่างวันที่แพตช์ออกกับวันที่ระบบของไทยติดตั้งแพตช์จริง

ภาพที่ 1: เส้นเวลาช่องโหว่วิกฤตในสามแพลตฟอร์มตั้งแต่พฤษภาคมถึงตุลาคม 2569 จุดสีแดงคือเหตุการณ์ที่มีการโจมตีจริง จะเห็นว่าช่องโหว่ PHP ถูกโจมตีก่อนแพตช์ออก และช่องโหว่ NGINX เมื่อพฤษภาคมถูกโจมตีภายในสามวันหลังเปิดเผย

1. ภาพรวมช่องโหว่และลำดับความเร่งด่วน

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

เมื่อใช้เกณฑ์นี้ PHP2Shell อยู่ในระดับวิกฤตสูงสุด เพราะผ่านทั้งสี่ด้านในทางที่เลวร้าย คือถูกโจมตีจริงแล้ว กระทบระบบหลายร้อยล้านการติดตั้ง ไม่ต้องตั้งค่าพิเศษในกรณีของ Apache mod_php และระบบจำนวนมากไม่มีแพตช์ Oracle มีคะแนนสูงกว่าแต่ยังไม่มีรายงานการโจมตี และผลิตภัณฑ์ส่วนใหญ่ไม่ได้เปิดสู่อินเทอร์เน็ตโดยตรง ส่วน NGINX แม้จะเปิดสู่อินเทอร์เน็ตแทบทุกเครื่อง แต่ช่องโหว่รอบนี้ต้องอาศัย directive (คำสั่งตั้งค่า) เฉพาะ

ภาพที่ 2: เปรียบเทียบคะแนน CVSS ของช่องโหว่สำคัญ ณ วันที่ 23 ตุลาคม 2569 แถบสีแดงคือช่องโหว่ที่ถูกโจมตีจริงแล้ว ข้อสังเกตคือ PHP และ NGINX ใช้ CVSS v4.0 ส่วน Oracle ใช้ CVSS v3.1 ตัวเลขจึงเทียบกันตรง ๆ ไม่ได้ทั้งหมด

2. PHP2Shell (CVE-2026-109618 และ CVE-2026-109619)

2.1 ที่มาที่ไป: ช่องโหว่ที่ข้อมูลหลุดก่อนกำหนด

ช่องโหว่คู่นี้ถูกค้นพบโดยนักวิจัยหลายทีมที่ใช้โมเดล AI ช่วยในการค้นหา ตามลำดับเวลาที่ Wiz เปิดเผย บั๊กแรกถูกพบเมื่อ 19 สิงหาคม 2569 รายงานไปยังทีม PHP เมื่อ 24 สิงหาคม และ PHP รับทราบเมื่อ 21 กันยายน กำหนดเปิดเผยอย่างประสานงาน (coordinated disclosure) คือวันที่ 22 ตุลาคม ทีม PHP ให้เครดิตแก่ Calif, OpenAI และ Wiz รวมถึงรายอื่น ๆ ซึ่งสอดคล้องกับที่รัฐมนตรี อว. ระบุว่าได้รับการแจ้งเตือนจาก OpenAI

แผนการเปิดเผยพังลงเมื่อวันที่ 20 ตุลาคม เมื่อมีโพสต์บน Hacker News อ้างว่ามีช่องโหว่ RCE ใน PHP สองรายการ คะแนน 10.0 พร้อมหมายเลข CVE ต่อมา watchTowr ยืนยันว่าข้อมูลเป็นของจริง PHP จึงออกประกาศล่วงหน้าในเย็นวันเดียวกัน และ CERT-EU ออก Advisory 2026-018 ทีม PHP ตัดสินใจเลื่อนการออกแพตช์เร็วขึ้นหนึ่งวัน เป็นวันที่ 21 ตุลาคม เวลา 14:00 UTC (21:00 น. ตามเวลาไทย) ภายหลัง PHP Foundation ชี้แจงว่าคะแนน 10.0 ที่หลุดออกมาไม่ถูกต้อง คะแนนทางการคือ 9.2

จุดที่ควรบันทึกในเชิงข่าวกรองคือ Amazon Threat Intelligence ตรวจพบความพยายามโจมตีต่อระบบล่อ MadPot ของตนตั้งแต่วันที่ 17 ตุลาคม ก่อนข้อมูลหลุดสู่สาธารณะสามวัน และก่อนแพตช์ออกสี่วัน ยังไม่ทราบว่าผู้โจมตีได้ข้อมูลมาจากที่ใด แต่ข้อเท็จจริงนี้บ่งชี้ว่ามีผู้รู้รายละเอียดช่องโหว่ก่อนสาธารณะ และอาจใช้ช่องโหว่นี้เป็น zero-day (ช่องโหว่ที่ยังไม่มีแพตช์) อยู่ระยะหนึ่ง

2.2 รายละเอียดทางเทคนิค

CVE-2026-109618 — RCE ผ่านความเสียหายจากหน่วยความจำหมด (OOM corruption) เมื่อหน่วยความจำของ PHP หมด (out-of-memory) ในจังหวะที่ข้อมูลของคำขอเพิ่งถูกเตรียมไว้เพียงบางส่วน กลไกยกเลิกงาน (bailout) จะหยุดการทำงานกลางคัน แต่ขั้นตอนเก็บกวาดตอนจบคำขอ (request shutdown) กลับถือว่าข้อมูลที่เตรียมไม่เสร็จนั้นถูกต้อง แล้วนำไปใช้ต่อ ผลคือการใช้หน่วยความจำที่ไม่ได้กำหนดค่าหรือไม่ถูกต้อง ซึ่งผู้โจมตีจัดรูปให้กลายเป็นการรันโค้ดได้ การโจมตีใช้คำขอเดียวต่อหนึ่งครั้งที่พยายามบน mod_php และผู้โจมตีกระตุ้นให้หน่วยความจำหมดได้ด้วยคำขอขนาดใหญ่ เช่น multipart ที่มีหลายส่วน

CVE-2026-109619 — RCE ผ่านสถานะส่วนกลางที่ค้างอยู่ (stale global state) เป็นช่องโหว่ประเภท use-after-free (การใช้หน่วยความจำหลังถูกคืนไปแล้ว) สถานะบางส่วนที่ผูกกับคำขอหนึ่งยังคงชี้ไปยังหน่วยความจำที่ถูกปล่อยไปแล้ว เมื่อคำขอถัดไปถูกประมวลผลบน worker เดียวกัน ก็อ่านค่านั้นก่อนที่ระบบจะรีเซ็ต การโจมตีต้องใช้สองคำขอบน worker เดียวกัน และ PHP ยืนยันว่านอกจากรันโค้ดได้แล้วยัง อ่านหน่วยความจำของ worker ได้โดยไม่ต้องยืนยันตัวตน ซึ่งอาจมีรหัสผ่าน โทเค็นยืนยันตัวตน และ API key ของระบบหลังบ้านอยู่ เส้นทางที่ยืนยันแล้วคือกลไก session upload progress และบน PHP 8.5 คือฟีเจอร์ fatal error backtrace

ทั้งสองช่องโหว่ได้ CVSS v4.0 9.2 ด้วย vector AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H ค่า AC:H และ AT:P สะท้อนว่าความสำเร็จขึ้นกับการจัดวางหน่วยความจำ การ build และการกระจายคำขอไปยัง worker ไม่ได้แปลว่าโจมตียาก เพราะผู้โจมตีสามารถยิงซ้ำได้เรื่อย ๆ จนสำเร็จ

2.3 เวอร์ชันที่ได้รับผลกระทบและสภาพแวดล้อมที่เสี่ยงที่สุด

ทุกรูปแบบการรัน PHP ที่ให้บริการเว็บมีความเสี่ยง ได้แก่ PHP-FPM, Apache mod_php, php-cgi, FrankenPHP และ LiteSpeed แต่ระดับความเสี่ยงต่างกัน Apache mod_php ร่วมกับ prefork MPM เสี่ยงที่สุด เพราะการโจมตีที่สาธิตแล้วทำงานได้ด้วยค่าเริ่มต้น และเกิดขึ้นก่อนที่โค้ดของแอปพลิเคชันจะเริ่มทำงานด้วยซ้ำ PHP-FPM มีกลไกตอนเริ่มทำงานที่ปิดเส้นทาง OOM บางเส้นทางไว้ แต่การโจมตีผ่านวงจรชีวิตของ session ยังทำได้หากแอปพลิเคชันมีพฤติกรรมที่เหมาะสม

ภาพที่ 3: ข้อมูลจาก Qualys TRU (ลูกค้าราว 12,000 ราย) พบการติดตั้ง PHP ราว 166 ล้านรายการ ในจำนวนที่ระบุเวอร์ชันได้ราว 155 ล้าน มีถึง 71% อยู่ในสายที่หมดอายุ และภายใน 12 ชั่วโมงแรกหลังแพตช์ออกมีเพียงราว 199,000 รายการที่แพตช์แล้ว ตัวเลขเป็นค่าประมาณจากแหล่งเดียว

2.4 สถานะการโจมตี

นอกจากการตรวจพบของ Amazon เมื่อ 17 ตุลาคม วันที่ 21 ตุลาคม Amazon พบความพยายามเพิ่มเติมที่มี payload หลายรูปแบบ บ่งชี้ว่ามีผู้โจมตีหลายกลุ่ม Cloudflare รายงานว่าเริ่มเห็นการโจมตีและความพยายามหลบเลี่ยงกฎ WAF (Web Application Firewall — ไฟร์วอลล์กรองทราฟฟิกเว็บ) ขณะที่ watchTowr ทำซ้ำช่องโหว่ได้ทั้งสองตัวและเห็นความพยายามโจมตีต่อทั้งคู่ Patchstack ยืนยัน “เหตุโจมตีจริงหลายกรณี” แต่ยังไม่มีผู้เปิดเผยรายละเอียดทางเทคนิค ชื่อกลุ่มผู้โจมตี หรือ IoC (Indicators of Compromise — ตัวบ่งชี้การถูกบุกรุก) ที่ยืนยันได้

โค้ดที่อ้างว่าเป็น PoC (Proof of Concept — โค้ดพิสูจน์แนวคิด) แพร่กระจายบนอินเทอร์เน็ต แต่ทีม PHP ระบุว่า ณ วันเปิดเผยยังไม่พบตัวที่ใช้งานได้จริง และ Tenable เตือนว่าโค้ดลักษณะนี้มักถูกฝังมัลแวร์มาเพื่อโจมตีนักวิจัยและผู้ดูแลระบบที่ดาวน์โหลดไปทดสอบ บนตลาดใต้ดิน BreachForums และ Dread ปิดเว็บชั่วคราวเพื่อป้องกันตัวเอง และมีกระทู้ที่ผู้ใช้ขอโค้ดโจมตีที่ใช้ได้กับทุกเวอร์ชัน แสดงให้เห็นว่าความต้องการมีสูงแม้เครื่องมือยังไม่เสถียร

3. PHP2Shell ในมุมมองโลก: เมื่อรัฐบาลหลายประเทศเลือก “ปิดเว็บ”

3.1 ทำไมทั้งโลกจึงตื่นตัวต่อช่องโหว่นี้เป็นพิเศษ

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

ประการแรกคือ ขนาดของพื้นที่โจมตี Wiz ประเมินว่า PHP ใช้ในเว็บไซต์ราว 70% ของโลก ส่วน BISI อ้างตัวเลขของ W3Techs ที่ 69.3% ของเว็บไซต์ที่ระบุภาษาฝั่งเซิร์ฟเวอร์ได้ ตัวเลขนี้ไม่ได้แปลว่าเว็บไซต์ 70% มีช่องโหว่ แต่บอกว่าแทบทุกองค์กรต้องตรวจสอบ Censys นับโฮสต์ PHP ที่เปิดสู่อินเทอร์เน็ตได้ราว 2.58 ล้านเครื่องในวันที่ 21 ตุลาคม และเกือบ 3 ล้านในวันถัดมา โดยในกลุ่มที่ระบุเวอร์ชันได้ราว 1.58 ล้านเครื่อง มีถึง 1.57 ล้านที่ยังไม่แพตช์ VulnCheck นับได้มากกว่าหนึ่งล้านโฮสต์ที่ใช้เวอร์ชันหมดอายุ ราว 920,000 โฮสต์อยู่ในสหรัฐฯ และกระจุกตัวบน AWS, DigitalOcean, Alibaba, OVHcloud และ Hetzner

ประการที่สองคือ ตำแหน่งของช่องโหว่ ช่องโหว่อยู่ในขั้นตอนที่ PHP แยกวิเคราะห์คำขอ (request parsing) ก่อนโค้ดของแอปพลิเคชันจะทำงาน NCSC ของเนเธอร์แลนด์ระบุว่าคำขอ POST เพียงครั้งเดียวอาจพอให้รันโค้ดได้ เฟรมเวิร์กอย่าง Laravel และ Symfony หรือ CMS อย่าง WordPress จึงไม่มีโอกาสตรวจสอบหรือป้องกันเลย การอัปเดตปลั๊กอินหรือ CMS ก็ไม่ช่วยอะไร Sansec ยืนยันว่ารันโค้ดได้โดยไม่ต้องยืนยันตัวตนบน WordPress, Drupal, Joomla, Magento, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony และ WHMCS

ประการที่สามคือ ไม่มีเวลาตั้งตัว ข้อมูลหลุดบน Hacker News เมื่อ 20 ตุลาคม ก่อนแพตช์ออกราว 24 ชั่วโมง ทำให้ทีมไอทีทั่วโลกต้องตัดสินใจตั้งแต่คืนก่อนหน้าว่าจะปิดระบบสำคัญหรือไม่ ทั้งที่ยังไม่รู้ด้วยซ้ำว่าช่องโหว่อยู่ตรงไหน

ประการที่สี่คือ คำแนะนำจากหน่วยงานรัฐที่ตรงไปตรงมาผิดปกติ NSA แนะนำว่าหากอัปเดตทันทีไม่ได้ ให้ “นำระบบออฟไลน์จนกว่าจะบรรเทาความเสี่ยงได้ครบ” BSI ของเยอรมนีประกาศระดับเตือนภัย 3 (สีส้ม) ประเมินความเสี่ยงว่า “สูงเป็นพิเศษ” และแนะนำให้นำเซิร์ฟเวอร์ออฟไลน์หากไม่แน่ใจ ส่วน NCSC ของสหราชอาณาจักรให้ “อัปเดตทันที” หากทำไม่ได้ให้ใช้มาตรการชั่วคราวของ PHP และหากยังทำไม่ได้อีกให้พิจารณานำระบบออฟไลน์ เมื่อหน่วยงานระดับนี้เปิดทางให้ “ปิดเว็บ” เป็นทางเลือกที่ยอมรับได้ ผู้บริหารไอทีจำนวนมากจึงเลือกทางนี้

3.2 ประเทศไหนทำอะไร

ภาพที่ 4: การตอบสนองระดับชาติต่อ PHP2Shell ระหว่าง 20–22 ตุลาคม 2569 สีแดงคือประเทศที่มีเว็บไซต์ภาครัฐถูกนำออฟไลน์ สีเหลืองคือผู้นำรัฐบาลออกมาเตือนเองและภาคเอกชนปิดบริการ สีเขียวคือออกคำแนะนำหรือคำสั่งโดยไม่มีรายงานการปิดเว็บภาครัฐ ข้อมูลรวบรวมจากรายงานข่าว จึงอาจไม่ครบทุกประเทศ

ยุโรปเป็นภูมิภาคที่ตอบสนองแรงที่สุด เนเธอร์แลนด์ปิดบริการสำคัญหลายตัวพร้อมกัน ได้แก่ DigiD (ระบบยืนยันตัวตนดิจิทัลของประชาชน) MijnOverheid (พอร์ทัลบริการรัฐ) Overheid.nl เว็บไซต์สภาผู้แทนราษฎร และแม้แต่เว็บไซต์ของ NCSC-NL เอง นอกจากนี้ยังมีท่าเรือรอตเทอร์ดัมและสมาคมฟุตบอลแห่งชาติ (KNVB) บางบริการกลับมาในวันที่ 21 หรือ 22 ตุลาคม ฟินแลนด์ปิดบริการเว็บภาครัฐผ่านหน่วยงานไอทีกลาง Valtori และหน่วยงานสำรวจที่ดินแห่งชาติ โดยระบุว่ายังไม่พบความพยายามโจมตีและไม่มีข้อมูลรั่ว เยอรมนีปิดเว็บไซต์ระดับสหพันธรัฐหลายแห่งที่ ITZBund ดูแลเป็นมาตรการป้องกัน เมืองไมนซ์ปิดพอร์ทัล mainz.de และบริการออนไลน์ของเมือง แต่สำนักงานยังให้บริการทางโทรศัพท์และอีเมลตามปกติ ฝรั่งเศสตัดการเชื่อมต่อเว็บไซต์ของจังหวัดและท้องถิ่นบางแห่งผ่านกระทรวงมหาดไทย เบลเยียมปิดเว็บไซต์กระทรวงการต่างประเทศ ทั้งที่ศูนย์ความมั่นคงไซเบอร์ของเบลเยียมระบุว่ายังไม่พบการโจมตีเว็บไซต์ในประเทศ เดนมาร์กได้รับผลกระทบรวมถึงแพลตฟอร์มสื่อสารของโรงเรียนระดับชาติ ส่วนสาธารณรัฐเช็กปิดเว็บไซต์หลักของรัฐบาลเมื่อ 19:00 น. ตามเวลาท้องถิ่นของวันที่ 21 ตุลาคม ตามคำแนะนำของหน่วยงานกำกับด้านไซเบอร์

ในสหราชอาณาจักร หลังการแจ้งเตือนของ NCSC เว็บไซต์ของสภาเมืองเอดินบะระและออกซ์ฟอร์ด รวมถึงตำรวจนครบาลลอนดอน (Met Police) ออฟไลน์ เว็บไซต์ของสภาเมืองบริสตอล แลมเบท และบาร์เน็ตแสดงข้อความผิดพลาด และมีรายงานว่ารัฐมนตรีแจ้งสภาขุนนางว่าบริการภาครัฐ 32 รายการใช้งานไม่ได้และอีก 4 รายการใช้งานได้บางส่วน ตัวเลขนี้มาจากแหล่งเดียว จึงควรใช้อย่างระมัดระวัง

อเมริกาเหนือและโอเชียเนีย ในแคนาดา นายอีแวน โซโลมอน รัฐมนตรีด้าน AI และนวัตกรรมดิจิทัล ประกาศผ่าน X ว่านำเว็บไซต์รัฐบาลบางส่วนออฟไลน์ชั่วคราว “เพื่อปกป้องระบบของรัฐและข้อมูลของชาวแคนาดา” และจะกลับมาเมื่อแพตช์แล้ว ระบบขนส่งมวลชนมอนทรีออล (STM) ปิด stm.info ตั้งแต่ก่อนเที่ยงและเปลี่ยนเส้นทางผู้ใช้ไปยังหน้าเบต้าที่แสดงสถานะการเดินรถ ส่วนองค์การสุราควิเบก (SAQ) ปิดเว็บไซต์โดยระบุว่าไม่พบการบุกรุก ในออสเตรเลีย ASD ยืนยันว่า cyber.gov.au ซึ่งเป็นเว็บไซต์ของหน่วยงานความมั่นคงไซเบอร์เองได้รับผลกระทบ แถลงการณ์ของ ASD จึงเข้าถึงไม่ได้หลายชั่วโมง กระทรวงมหาดไทยระบุว่าหลายหน่วยงานได้รับผลกระทบ และเว็บไซต์รัฐสภาล่มในเช้าวันพฤหัสบดี สหรัฐฯ เป็นกรณีที่ต่างออกไป NSA, CISA และ FBI ออกคำเตือนพร้อมกันในวันที่ 21 ตุลาคม แต่ไม่มีรายงานว่าเว็บไซต์ภาครัฐระดับสหพันธรัฐล่มหรือถูกบุกรุก OpenAI ระบุว่าได้ประสานกับทำเนียบขาวและ CISA ในการเปิดเผยช่องโหว่

เอเชีย ญี่ปุ่นเป็นประเทศที่ผู้นำรัฐบาลลงมาเตือนเองอย่างชัดเจนที่สุด นายกรัฐมนตรีซานาเอะ ทากาอิจิ โพสต์บน X เวลา 21:55 น. ของวันที่ 21 ตุลาคม ขอให้ทุกคนที่มีเว็บไซต์สาธารณะตรวจว่าใช้ PHP หรือไม่ และเตรียมติดตั้งแพตช์ที่จะออกเวลา 23:00 น. และระบุว่า “การปิดเว็บไซต์ชั่วคราว” เป็นวิธีที่ได้ผลหากแพตช์ทันทีไม่ได้ โพสต์นี้มีผู้เข้าชมเกิน 30 ล้านครั้งภายในไม่กี่ชั่วโมง แพลตฟอร์มใหญ่อย่าง pixiv, DMM, niconico และผู้ให้บริการร้านค้าออนไลน์ BASE เข้าสู่การปิดปรับปรุงฉุกเฉิน Sakura Internet ระงับบางฟังก์ชันของบริการคลาวด์ และ BISI รายงานว่าธนาคารบางแห่ง รวมถึง Mizuho ระงับบริการออนไลน์บางส่วน ส่วนไทยอยู่ในกลุ่มที่ออกคำสั่งและประกาศเตือนระดับชาติ (รายละเอียดในหัวข้อ 6.4) แต่ไม่มีรายงานการปิดเว็บไซต์ภาครัฐเป็นวงกว้าง

ประเทศกำลังพัฒนา ภาพในหลายประเทศต่างออกไปมาก กรณีเคนยาเป็นตัวอย่างที่ชัด W3Techs พบว่าเว็บไซต์โดเมน .ke ที่ระบุภาษาได้ใช้ PHP ถึง 82.4% ซึ่งสูงกว่าค่าเฉลี่ยโลก แต่จนถึงเวลา 20:00 น. ของวันที่ 21 ตุลาคม ทั้งหน่วยงานกำกับการสื่อสารและ KE-CIRT/CC ยังไม่ได้ออกคำแนะนำใด ๆ ช่องว่างนี้สะท้อนว่าประเทศที่พึ่งพา PHP และโฮสติ้งราคาถูกมากที่สุด มักเป็นประเทศที่มีกลไกแจ้งเตือนช้าที่สุด

3.3 ภาคเอกชนและแพลตฟอร์มระดับโลก

ผลกระทบไม่ได้จำกัดอยู่ที่ภาครัฐ มูลนิธิ Wikimedia ซึ่งดูแล Wikipedia บนซอฟต์แวร์ MediaWiki ที่เขียนด้วย PHP ระบุว่า “ได้ปิดระบบอื่นจำนวนหนึ่งเป็นมาตรการป้องกันจนกว่าจะแพตช์ได้อย่างปลอดภัย” Internet Archive และ 4chan ปิดบางหน้าเช่นกัน ส่วนแพลตฟอร์ม SaaS ที่สร้างบน PHP เช่น ระบบสรรหาบุคลากรและระบบบริหารงานบุคคลบางราย ก็ต้องประเมินและแจ้งลูกค้า ในภาคการผลิต Engineering.com ชี้ว่าความเสี่ยงลึกกว่าเว็บไซต์ เพราะ PHP มักฝังอยู่ในหน้าจัดการของระบบ MES พอร์ทัลซัพพลายเออร์ และอุปกรณ์ที่ผู้ผลิตไม่ได้ระบุว่าใช้ PHP ขณะที่ Broadcom/VMware ต้องออกแถลงสถานะผลกระทบต่อผลิตภัณฑ์ของตน เช่นเดียวกับ Cisco ที่ออก advisory สำหรับผลิตภัณฑ์ที่ฝัง PHP

Automattic ระบุว่า WordPress.com, WordPress VIP, WP Cloud และ Pressable ได้รับการป้องกันแล้วก่อนแพตช์ออก ลูกค้าไม่ต้องทำอะไร ส่วน WordPress.org ย้ำว่าไม่ต้องอัปเดต WordPress เอง แต่ต้องอัปเดต PHP ข้อมูลของ The Repository ระบุว่า ก่อนแพตช์ออก 35.1% ของเว็บไซต์ WordPress ใช้ PHP เวอร์ชันที่ไม่ได้รับการสนับสนุนแล้ว ซึ่งหมายความว่ามีเว็บไซต์ WordPress ขนาดใหญ่มากที่ไม่มีแพตช์จาก PHP โดยตรง

3.4 ทั่วโลกแก้ปัญหาอย่างไร

การตอบสนองทั่วโลกแบ่งได้เป็นสี่ชั้น ซึ่งองค์กรส่วนใหญ่ใช้ผสมกัน

ชั้นที่ 1: Virtual patching ที่ขอบเครือข่าย ผู้ให้บริการ CDN และ WAF รายใหญ่เป็นแนวป้องกันแรกที่ทำงานได้ภายในไม่กี่ชั่วโมง Cloudflare ปล่อยกฎไฟร์วอลล์ให้ลูกค้าทุกราย รวมถึงแผนฟรี ก่อนแพตช์ออก ขณะที่ AWS, Akamai, Fastly และ Google Cloud Armor ออกกฎในลักษณะเดียวกัน แต่ CTO ของ Cloudflare ย้ำว่ากฎนี้เป็นเพียง “STOPGAP” และป้องกันได้เฉพาะทราฟฟิกที่วิ่งผ่าน Cloudflare เท่านั้น มีรายงานว่าผู้โจมตีพยายามหลบเลี่ยงกฎ WAF แล้ว ตลาดหุ้นตอบรับด้วย โดยหุ้น Cloudflare ขึ้นราว 6% ในวันที่ 21 ตุลาคม แม้ BISI จะเตือนว่าตัวเลขนี้พิสูจน์อะไรได้ไม่มาก

ชั้นที่ 2: การแพตช์โดยผู้ให้บริการโฮสติ้ง สำหรับเว็บไซต์ขนาดเล็กและกลางส่วนใหญ่ของโลก ผู้ที่แพตช์จริงไม่ใช่เจ้าของเว็บแต่เป็นผู้ให้บริการโฮสติ้ง ความเร็วจึงต่างกันมาก 20i แพตช์เสร็จภายในราว 6 ชั่วโมงหลังแพตช์ออก (20:01 UTC) Kinsta เสร็จเวลา 23:25 UTC WP Engine เสร็จ 01:19 UTC ของวันถัดไป และ Hostinger เสร็จ 06:44 UTC ขณะที่ Liquid Web, Rocket.net, Bluehost และ HostGator ยังทยอยแพตช์ต่อเนื่อง และ OVHcloud ขยายเวลาบำรุงรักษาสำหรับเวอร์ชันเก่าไปถึง 26 ตุลาคม ผู้ให้บริการหลายรายใช้มาตรการเสริมก่อนแพตช์เสร็จ เช่น SiteGround แก้ไขระดับเซิร์ฟเวอร์ล่วงหน้าหลายชั่วโมง ส่วน Bluehost จำกัดขนาดไฟล์อัปโหลดชั่วคราว ข้อวิจารณ์ที่ตามมาคือการสื่อสาร นักพัฒนาหลายรายบ่นว่าไม่ได้รับแจ้งจากโฮสต์โดยตรง ต้องไปดูเองจากหน้าสถานะ

ชั้นที่ 3: การจัดการ PHP เวอร์ชันหมดอายุ นี่คือโจทย์ที่ยากที่สุด และแต่ละรายเลือกต่างกัน ทีม PHP ออก source backport สำหรับ 7.4, 8.0 และ 8.1 แต่ไม่มีสำหรับเวอร์ชันที่เก่ากว่า cPanel ใส่แพตช์ให้ 7.4, 8.0 และ 8.1 โดยไม่เปลี่ยนเลขเวอร์ชัน ผู้ดูแลจึงต้องตรวจจากวันที่ build แทน CloudLinux ซึ่งอยู่เบื้องหลังโฮสติ้งแบบแชร์จำนวนมากออกแพ็กเกจย้อนไปถึง PHP 5.2 Hetzner แพตช์ 5.6 และ 7.3 ในวันที่ 22 ตุลาคม อีกด้านหนึ่ง AWS, Google Cloud, GoDaddy, A2 Hosting และ Liquid Web ใช้โอกาสนี้ผลักลูกค้าให้ย้ายไปเวอร์ชันใหม่ Azure App Service ไม่แพตช์เวอร์ชันหมดอายุเลย และ Google Cloud ยอมรับว่า Cloud Run และ Cloud Functions ที่ใช้ PHP 5.5, 7.2, 7.3, 7.4 และ 8.1 ยังมีช่องโหว่ บนแพลตฟอร์มที่ลูกค้าดูแลเอง เช่น DigitalOcean Droplet และ AWS Lightsail ความรับผิดชอบตกอยู่กับลูกค้าทั้งหมด

ชั้นที่ 4: การปิดระบบหรือลดฟังก์ชัน สำหรับระบบที่แพตช์ไม่ทันและไม่มี WAF ทางเลือกสุดท้ายคือนำออฟไลน์ หรือเปลี่ยนเป็นโหมดอ่านอย่างเดียว (static read-only) ปิดการอัปโหลดไฟล์ และลดขนาด POST สูงสุด ตามที่ Techzine และ NCSC-NL แนะนำ ตัวอย่างของ STM ในมอนทรีออลที่เปลี่ยนเส้นทางผู้ใช้ไปยังหน้าแสดงสถานะแบบเรียบง่ายแทนการปิดเงียบ เป็นแนวปฏิบัติที่ควรนำมาใช้ เพราะรักษาบริการที่จำเป็นไว้ได้ระหว่างที่ระบบหลักออฟไลน์

3.5 การโจมตีจริงเกิดขึ้นแค่ไหน

ภาพที่ 5: ความพยายามโจมตี PHP2Shell ที่ Cloudflare ตรวจพบ เพิ่มจากหลักพันก่อนแพตช์ออกราว 10 ชั่วโมง เป็นหลักหมื่นภายใน 45 นาทีหลังประกาศ หลักแสนภายใน 2 ชั่วโมง และหลักล้านในวันถัดมา ตัวเลขเป็นลำดับขนาดตามคำบอกเล่าของ CEO Cloudflare ไม่ใช่ค่าที่วัดได้แม่นยำ

ปริมาณความพยายามโจมตีสูงมาก แต่หลักฐานความสำเร็จยังน้อย watchTowr ระบุว่า PoC ที่แพร่กระจาย “หยาบ” ส่วนใหญ่ใช้ไม่ได้ ทำได้แค่วัดเวลาตอบสนอง หรือทำให้เซิร์ฟเวอร์ล่ม Wordfence รันโค้ดได้จากช่องโหว่หนึ่งตัวเฉพาะในห้องทดลองที่ตั้งค่าพิเศษ ส่วนอีกตัวส่วนใหญ่ทำให้ PHP ล่มหรือรีสตาร์ต VulnCheck พบไอพีจากจีนอย่างน้อยหนึ่งรายพยายามฝัง web shell แต่ไม่สำเร็จ JFrog พบ PoC ปลอมและมัลแวร์บน GitHub ที่หลอกนักวิจัย ขณะที่ Patchstack ยืนยันเหตุโจมตีจริงหลายกรณีแต่ยังไม่เผยรายละเอียด และ BISI สรุปว่า ณ วันที่ 23 ตุลาคม ยังไม่มีการยืนยันต่อสาธารณะว่ามีระบบใดถูกเจาะสำเร็จ เจ้าหน้าที่ของเยอรมนี เนเธอร์แลนด์ สหราชอาณาจักร และญี่ปุ่นต่างรายงานว่ายังไม่พบการโจมตีที่สำเร็จ และ BSI ประเมินภายหลังว่าช่องโหว่ใช้งานยากกว่าที่คาดไว้

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

3.6 ต้นทุนของการปิดเว็บ: ถกเถียงที่ยังไม่จบ

การปิดเว็บไซต์ภาครัฐเป็นวงกว้างกลายเป็นประเด็นถกเถียงเชิงนโยบายทันที BISI วิเคราะห์ว่าการปิดระบบเป็นทางเลือกที่สมเหตุสมผลสำหรับเป้าหมายมูลค่าสูง แต่มีต้นทุนสูงเมื่อใช้เป็นมาตรการทั่วไป เพราะ การสูญเสียความพร้อมใช้งานเป็นเรื่องแน่นอน ขณะที่ความเสี่ยงที่หลีกเลี่ยงได้ยังไม่แน่นอน เมื่อ BSI ออกมาประเมินภายหลังว่าช่องโหว่ใช้งานยากกว่าที่คิด คำถามว่าการปิด DigiD หรือบริการประชาชนทั้งวันคุ้มค่าหรือไม่จึงชัดขึ้น BISI ยังเตือนว่ากรณีนี้สร้างบรรทัดฐานที่ทำให้การ “ปิดไฟ” (going dark) กลายเป็นทางเลือกกระแสหลัก และเปิดทางให้แค่ข่าวลือที่น่าเชื่อถือก็ก่อความปั่นป่วนได้โดยไม่ต้องมีโค้ดโจมตีจริง

ในมุมเศรษฐกิจ ผู้ให้บริการโฮสติ้งต้องแบกต้นทุนการบังคับย้ายเวอร์ชันและการแก้ปลั๊กอินหรือโค้ดเก่าที่ใช้กับ PHP ใหม่ไม่ได้ ธุรกิจขนาดเล็กบนโฮสติ้งแบบแชร์แบกความเสี่ยงที่ตัวเองควบคุมไม่ได้ ภาคประกันภัยเริ่มจับตา “เหตุการณ์สะสม” (aggregation event) ที่ช่องโหว่เดียวกระทบผู้เอาประกันจำนวนมากพร้อมกัน และคำถามว่าการปิดเว็บเองโดยไม่มีการบุกรุกจะเคลมความคุ้มครองธุรกิจหยุดชะงักได้หรือไม่ขึ้นกับถ้อยคำในกรมธรรม์ ขณะที่ GlobalData ประเมินว่า SME ในสหราชอาณาจักรมีประกันไซเบอร์เพียงราว 40%

ในมุมความเป็นอิสระทางดิจิทัล BISI ชี้ว่าการที่ยุโรปต้องพึ่งผู้ให้บริการ edge ของสหรัฐฯ เพียงไม่กี่รายในการป้องกันฉุกเฉิน ทำให้ตอบสนองได้เร็ว แต่ก็ตอกย้ำความกังวลเรื่องอธิปไตยทางดิจิทัล และในมุมของระบบนิเวศโอเพนซอร์ส PHP Foundation ยอมรับว่ารากของปัญหาเคยถูกพบตั้งแต่ปี 2567 แต่การแก้ไขค้างไปหลายเดือน และเรียกสิ่งนี้ว่า “ความล้มเหลวเชิงโครงสร้าง” จากกระบวนการตัดสินใจและการขาดทรัพยากร ทีมพัฒนา PHP มีขนาดเล็ก และต้องคัดกรองรายงานที่ไม่ถูกต้องกว่า 100 รายการตั้งแต่ 1 กรกฎาคม BISI เสนอว่าบริษัท AI ที่ให้ทุนโครงการค้นหาช่องโหว่ควรให้ทุนฝั่งแก้ไขด้วย ไม่เช่นนั้นจะเพิ่มภาระให้ผู้ดูแลโครงการ

3.7 บทเรียนสำหรับไทยจากการตอบสนองของโลก

เมื่อเทียบกับประเทศอื่น การตอบสนองของไทยอยู่ในกลุ่ม “ออกคำสั่งและประกาศเตือน” ซึ่งเร็วกว่าหลายประเทศกำลังพัฒนา แต่ไม่ได้ใช้มาตรการปิดระบบเชิงรุกแบบยุโรป บทเรียนที่นำมาใช้ได้มีสามข้อ ข้อแรก ประเทศที่ตัดสินใจได้เร็วล้วนมี หน่วยงานไอทีกลางที่รู้ว่าระบบใดใช้ PHP เช่น Valtori ของฟินแลนด์ หรือ ITZBund ของเยอรมนี จึงสั่งปิดเฉพาะจุดได้ภายในไม่กี่ชั่วโมง ไทยยังไม่มีทะเบียนลักษณะนี้ในระดับประเทศ ข้อที่สอง การปิดเว็บควรมีเกณฑ์ ไม่ใช่ปฏิกิริยาตกใจ ระบบที่มีข้อมูลอ่อนไหวหรือบริการยืนยันตัวตนควรปิดก่อน ส่วนเว็บประชาสัมพันธ์ที่ไม่มีข้อมูลสำคัญอาจใช้ WAF หรือโหมดอ่านอย่างเดียวแทน ข้อที่สาม เว็บไซต์หน่วยงานไทยจำนวนมากอยู่บนโฮสติ้งเอกชนในประเทศที่แทบไม่มีผู้ใดออกแถลงสถานะการแพตช์ ต่างจากผู้ให้บริการต่างชาติที่มีหน้าสถานะสาธารณะ หน่วยงานกำกับดูแลควรกำหนดให้ผู้ให้บริการโฮสติ้งและคลาวด์ที่รับงานภาครัฐต้องรายงานสถานะการแพตช์ภายในเวลาที่กำหนดเมื่อเกิดเหตุระดับนี้

4. NGINX: ห้าช่องโหว่รอบตุลาคม และบทเรียนจาก NGINX Rift

4.1 ที่มาที่ไป

วันที่ 14 ตุลาคม 2569 NGINX ออกเวอร์ชัน 1.30.6 (สาย stable) และ 1.31.7 (สาย mainline) แก้ช่องโหว่ 5 รายการ นับเป็นการออกแพตช์ความปลอดภัยครั้งที่ 8 ของ NGINX ในปีนี้ ขณะที่ NGINX จัดทั้ง 5 รายการเป็นระดับกลาง (medium) บริษัท F5 เจ้าของ NGINX ให้คะแนน CVSS v4.0 บั๊กหน่วยความจำทั้งสามที่ 9.2 บั๊ก TLS ที่ 8.3 และบั๊ก HTTP/3 ที่ 6.9 ในรอบเดียวกัน F5 ประกาศแก้ข้อบกพร่องใน NGINX รวม 11 รายการผ่าน advisory K000163408 ผู้ค้นพบมีหลายราย ได้แก่ Matt Suiche (Tolmo) กับ Mateusz Gierblinski, Hansol Lee (GOTROOT), ทีม PhiNode Labs และนักวิจัยชื่อ Cyberlanc3r ส่วนช่องโหว่ alias นั้น F5 พบเอง

ปีนี้ NGINX มีประวัติที่ต้องนำมาประกอบการตัดสินใจ เมื่อกลางเดือนพฤษภาคม ช่องโหว่ NGINX Rift (CVE-2026-42945) ใน ngx_http_rewrite_module ซึ่งซ่อนอยู่ในโค้ดตั้งแต่เวอร์ชัน 0.6.27 ราว 18 ปี ถูกเปิดเผยพร้อม PoC โดยทีม Depthfirst ที่ใช้แพลตฟอร์มค้นหาช่องโหว่ด้วย AI และ VulnCheck ตรวจพบความพยายามโจมตีตั้งแต่วันที่ 16 พฤษภาคม เพียงสามวันหลังเปิดเผย การโจมตีทำให้ worker ล่มซ้ำได้แน่นอน และอาจรันโค้ดได้หากข้าม ASLR (Address Space Layout Randomization — กลไกสุ่มตำแหน่งหน่วยความจำ) ได้ ต่อมาในเดือนกรกฎาคม F5 แก้ CVE-2026-42533 ซึ่งเป็น heap overflow อีกตัว และ ช่องโหว่ regex map ตัวใหม่ในรอบตุลาคม (CVE-2026-93479) เกิดจากโค้ดที่แพตช์เดือนกรกฎาคมนั้นเอง เซิร์ฟเวอร์ที่อัปเดตเมื่อกรกฎาคมจึงยังได้รับผลกระทบ

4.2 รายละเอียดทางเทคนิค

กลไกของบั๊กแต่ละตัวมีความน่าสนใจในเชิงวิศวกรรม ช่องโหว่ alias เกิดในช่วงสั้น ๆ หลังจาก rewrite เปลี่ยน URI แต่ก่อนที่ NGINX จะเลือก location ใหม่ หากมีสิ่งใดอ่าน $request_filename ในช่วงนั้น และ prefix ของ location ยาวกว่า URI ใหม่ การแปลง URI เป็น path ไฟล์จะเขียนเกินบัฟเฟอร์ ช่องโหว่ AIO เกิดจากตัวนับขนาด 8 บิตที่บวกค่าโดยไม่ตรวจขอบเขต เมื่อครบ 256 ค่าจะวนกลับเป็นศูนย์ ทำให้คำขอถูกปล่อยหน่วยความจำทั้งที่ยังมีงาน asynchronous ค้างชี้อยู่

ช่องโหว่ที่กระทบระบบจำนวนมากที่สุดในเชิงปริมาณคือ CVE-2026-97629 เพราะการตั้ง ssl_session_cache shared:SSL:10m เป็นตัวอย่างในเอกสารทางการของ NGINX ตั้งแต่เวอร์ชัน 1.23.2 NGINX สร้างและหมุนคีย์ session ticket เองเมื่อเปิด shared cache แต่ละ worker เก็บคีย์ 3 ช่อง ขณะที่การหมุนคัดลอกเพียง 2 ช่อง ช่องที่สามจึงเป็นข้อมูลค้างในหน่วยความจำ ticket ที่อ้างช่องนั้นอาจถูกยืนยันด้วยคีย์ที่ไม่ได้กำหนดค่า F5 ระบุว่าการปลอมนี้เกิดแบบสุ่มและผู้โจมตีควบคุมไม่ได้ แต่สำหรับระบบที่พึ่ง mutual TLS (การยืนยันตัวตนสองทางด้วยใบรับรอง) เป็นชั้นป้องกันเดียว นี่คือจุดอ่อนที่ยอมรับไม่ได้

5. Oracle Critical Patch Update ตุลาคม 2569

5.1 ภาพรวม

Oracle ออก Critical Patch Update (CPU — ชุดแพตช์รายไตรมาส) รอบสุดท้ายของปี 2569 เมื่อวันที่ 20 ตุลาคม รวม 1,295 แพตช์ ครอบคลุม CVE ที่ไม่ซ้ำกัน 1,209 รายการใน 33 กลุ่มผลิตภัณฑ์ ตามการวิเคราะห์ของ Tenable แบ่งเป็นระดับวิกฤต 95 รายการ ระดับสูง 439 รายการ และระดับกลาง 582 รายการ จำนวนแพตช์ที่โจมตีจากระยะไกลได้โดยไม่ต้องยืนยันตัวตนอยู่ที่ 690 รายการตามการนับจาก risk matrix ของ Oracle (แหล่งข่าวบางแห่งนับได้ 562 รายการ เนื่องจากวิธีนับ CVE ที่ซ้ำข้ามผลิตภัณฑ์ต่างกัน) Oracle ยังไม่ระบุว่ามีช่องโหว่ใดถูกโจมตีจริง แต่ย้ำว่ายังได้รับรายงานความพยายามโจมตีช่องโหว่ที่มีแพตช์แล้วแต่ลูกค้าไม่ได้ติดตั้งอย่างต่อเนื่อง

ภาพที่ 6: จำนวนแพตช์ใน Oracle CPU ตุลาคม 2569 แยกตามกลุ่มผลิตภัณฑ์ แถบสีเหลืองคือส่วนที่โจมตีจากระยะไกลได้โดยไม่ต้องยืนยันตัวตน Fusion Middleware (รวม WebLogic) มีสัดส่วนนี้สูงที่สุด ส่วน Java SE แทบทุกรายการอยู่ในกลุ่มนี้

5.2 ช่องโหว่ที่ต้องปิดก่อน

ช่องโหว่คะแนน 10.0 ทั้งหมดมีลักษณะ “scope change” หมายความว่าผลกระทบลามออกนอกคอมโพเนนต์ที่มีช่องโหว่ได้ ที่น่ากังวลเป็นพิเศษคือ CVE-2026-87337 ใน Oracle Access Manager ซึ่งเป็นระบบ Single Sign-On และควบคุมการเข้าถึงขององค์กร หากระบบยืนยันตัวตนถูกยึด ผู้โจมตีอาจเข้าถึงทุกระบบที่อยู่หลังมันได้ ส่วน CVE-2026-75803 ในคอมโพเนนต์ OpenSSL ของ Database Server กระทบรุ่น 19.3–19.32 และ 23.4.0–23.26.3 โจมตีผ่าน TLS ได้โดยไม่ต้องมีข้อมูลรับรอง

5.3 บริบทของภัยต่อ Oracle

แม้รอบนี้ยังไม่มีการโจมตีจริง ประวัติที่ผ่านมาแสดงว่าผู้โจมตีให้ความสำคัญกับผลิตภัณฑ์ Oracle สูงมาก กลุ่มแรนซัมแวร์ Clop เคยใช้ zero-day ใน Oracle E-Business Suite กวาดข้อมูลจากองค์กรจำนวนมาก โดยเหยื่อยังทยอยประกาศจนถึงเดือนกันยายน 2569 และ ShinyHunters เคยใช้ zero-day ใน PeopleSoft เมื่อกลางปี ในวันที่ 21 ตุลาคม Oracle ยังออก Security Alert แยกสำหรับ CVE-2026-91403 (CVSS 9.1) ใน Java เพื่อเลิกเชื่อถือ CA ตัวกลางของ eMudhra ที่กุญแจเดาได้ง่าย ซึ่งอาจถูกใช้ปลอมใบรับรอง HTTPS รอบถัดไปของ Oracle คือ Critical Security Patch Update วันที่ 17 พฤศจิกายนและ 15 ธันวาคม และ CPU รอบถัดไปวันที่ 19 มกราคม 2570

6. ผลกระทบต่อประเทศไทยโดยตรง

6.1 PHP: ภาคการศึกษา สาธารณสุข และเว็บไซต์ภาครัฐ

PHP เป็นภาษาที่อยู่เบื้องหลังเว็บไซต์ของหน่วยงานรัฐไทยจำนวนมาก ทั้งที่สร้างบน WordPress, Joomla และ Drupal และระบบที่พัฒนาขึ้นเองโดยผู้รับจ้าง ระบบลักษณะหลังนี้มักถูกส่งมอบพร้อม PHP เวอร์ชันที่ใช้ในวันส่งงาน และไม่มีสัญญาบำรุงรักษาที่ครอบคลุมการอัปเกรด runtime ผลคือมีระบบจำนวนไม่น้อยที่ยังรัน PHP 5.x หรือ 7.x อยู่ ระบบเหล่านี้ไม่มีแพตช์จาก PHP และต้องพึ่ง backport จากดิสทริบิวชัน Linux ซึ่งหลายเครื่องก็หมดอายุไปแล้วเช่นกัน

การที่รัฐมนตรี อว. ระบุมหาวิทยาลัย โรงพยาบาล และโรงเรียนแพทย์เป็นกลุ่มเร่งด่วนนั้นสอดคล้องกับข้อเท็จจริงเชิงเทคนิค สถาบันการศึกษามีเว็บไซต์ย่อยของคณะ ภาควิชา และโครงการจำนวนมากที่ดูแลกระจัดกระจาย ส่วนโรงพยาบาลมีระบบเชื่อมต่อข้อมูลผู้ป่วยและระบบนัดหมายที่เปิดสู่อินเทอร์เน็ต ความสามารถของ CVE-2026-109619 ในการอ่านหน่วยความจำของ worker โดยไม่ต้องยืนยันตัวตนทำให้ ข้อมูลรับรองการเชื่อมต่อฐานข้อมูลและ API key ที่ฝังอยู่ในแอปพลิเคชันอาจรั่วได้แม้ผู้โจมตีจะยังไม่สามารถรันโค้ด ซึ่งเป็นความเสี่ยงต่อข้อมูลส่วนบุคคลตาม พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล โดยตรง

6.2 NGINX: ชั้นหน้าด่านของบริการดิจิทัลภาครัฐและการเงิน

NGINX ทำหน้าที่เป็น reverse proxy และ load balancer หน้าบริการดิจิทัลจำนวนมากในไทย รวมถึงเป็นส่วนประกอบของ Ingress Controller บน Kubernetes ที่ธนาคารและผู้ให้บริการคลาวด์ใช้ ความเสี่ยงหลักในรอบนี้คือการทำให้บริการล่ม (Denial of Service) ซึ่งสำหรับ CII ด้านการเงินและบริการภาครัฐถือเป็นผลกระทบโดยตรงต่อความพร้อมใช้งาน และบั๊ก TLS session ticket กระทบระบบ API ระหว่างหน่วยงานที่ใช้ mutual TLS ในการยืนยันตัวตนระหว่างระบบ ข้อควรระวังคือผลิตภัณฑ์ของ F5 บางตัว เช่น Ingress Controller และ Gateway Fabric ยังไม่มี build ที่แก้ไข ณ กลางเดือนตุลาคม

6.3 Oracle: ระบบหลังบ้านของ CII

Oracle Database, E-Business Suite, PeopleSoft และ WebLogic เป็นระบบหลักของธนาคาร รัฐวิสาหกิจด้านพลังงานและสาธารณูปโภค ผู้ให้บริการโทรคมนาคม และหน่วยงานรัฐขนาดใหญ่ในไทย ระบบเหล่านี้มักไม่ได้เปิดสู่อินเทอร์เน็ตโดยตรง แต่ช่องโหว่ที่โจมตีผ่าน T3/IIOP และ HTTP โดยไม่ต้องยืนยันตัวตนกลายเป็นเครื่องมือเคลื่อนที่ในเครือข่าย (lateral movement) ชั้นดีหลังผู้โจมตีเข้ามาได้จากจุดอื่น เช่นจากเว็บเซิร์ฟเวอร์ PHP ที่ถูกยึด ความเชื่อมโยงนี้คือเหตุผลที่ต้องมองช่องโหว่ทั้งสามกลุ่มเป็นภาพเดียวกัน ไม่ใช่สามเหตุการณ์แยกกัน

6.4 การตอบสนองของภาครัฐไทย

วันที่ 22 ตุลาคม 2569 ศ.ดร.ยศชนัน วงศ์สวัสดิ์ รองนายกรัฐมนตรีและรัฐมนตรีว่าการกระทรวง อว. สั่งให้หน่วยงานในสังกัดตรวจสอบและอัปเกรดระบบ พร้อมประสานกระทรวงอื่น ในวันเดียวกัน นายภราดร ปริศนานันทกุล รัฐมนตรีประจำสำนักนายกรัฐมนตรี ผู้กำกับดูแล สกมช. สั่งการให้รับมือด่วน ThaiCERT ออกประกาศเตือนระดับประเทศและส่งคำแนะนำไปยังหน่วยงานรัฐ หน่วยงาน CII และเครือข่าย Sectoral CERT โดยวางการดำเนินการ 4 ด้าน คือ แจ้งเตือนและประสานงาน สำรวจและประเมินความเสี่ยง เฝ้าระวังและตรวจจับ และติดตามผลการแพตช์ ณ วันที่จัดทำรายงาน ยังไม่มีการเปิดเผยจำนวนระบบของไทยที่ได้รับผลกระทบ ยังไม่มีรายงานระบบที่ถูกโจมตี และยังไม่มีการกำหนดเส้นตายการอัปเกรด

7. ประเมินเชิงยุทธศาสตร์ต่อความมั่นคงของชาติ

ประเด็นเชิงยุทธศาสตร์ข้อแรกคือ AI กำลังเร่งความเร็วทั้งฝั่งค้นหาและฝั่งใช้ช่องโหว่ ทั้ง NGINX Rift และ PHP2Shell ถูกค้นพบโดยทีมที่ใช้ AI ช่วยวิเคราะห์โค้ด และทั้งสองเป็นบั๊กที่ซ่อนอยู่ในซอฟต์แวร์โอเพนซอร์สที่ผ่านการตรวจมานับสิบปี (NGINX Rift ราว 18 ปี, PHP2Shell ย้อนถึง PHP 5.4 ในปี 2555) แนวโน้มนี้หมายความว่าซอฟต์แวร์พื้นฐานที่เคยถือว่า “ผ่านการพิสูจน์แล้ว” จะมีช่องโหว่วิกฤตถูกขุดขึ้นมาถี่ขึ้น และช่วงเวลาระหว่างเปิดเผยกับการโจมตีจริงจะสั้นลงเรื่อย ๆ จากหลายสัปดาห์เหลือเพียงไม่กี่วัน หรือในกรณีของ PHP2Shell คือเกิดก่อนการเปิดเผยด้วยซ้ำ

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

ข้อที่สามคือ หนี้ทางเทคนิค (technical debt) คือช่องโหว่ระดับชาติ การที่ PHP สายหมดอายุครองสัดส่วนราว 71% ในข้อมูลของ Qualys ไม่ใช่ปัญหาเฉพาะของประเทศใดประเทศหนึ่ง แต่สำหรับไทยซึ่งระบบภาครัฐจำนวนมากพัฒนาผ่านการจัดซื้อจัดจ้างแบบโครงการ และไม่มีงบบำรุงรักษาต่อเนื่อง สัดส่วนนี้อาจสูงกว่าค่าเฉลี่ย ระบบที่ไม่มีเจ้าของชัดเจนจะไม่ถูกแพตช์ ไม่ว่าคำสั่งจากส่วนกลางจะเร่งด่วนเพียงใด

ข้อที่สี่คือ ห่วงโซ่การโจมตีข้ามแพลตฟอร์ม สถานการณ์ที่สมเหตุสมผลที่สุดสำหรับผู้โจมตีระดับรัฐหรือกลุ่มแรนซัมแวร์คือ ยึดเว็บเซิร์ฟเวอร์ PHP ที่เปิดสู่อินเทอร์เน็ต อ่านข้อมูลรับรองจากหน่วยความจำหรือไฟล์ config แล้วใช้ช่องโหว่ Oracle หรือข้อมูลรับรองที่ได้เคลื่อนเข้าระบบหลังบ้าน กลุ่มจารกรรมไซเบอร์ที่มุ่งเป้าไทยมีประวัติใช้ช่องโหว่บนอุปกรณ์และบริการที่เปิดสู่อินเทอร์เน็ตเป็นทางเข้าหลัก ขณะที่กลุ่มแรนซัมแวร์อย่าง Clop เคยแสดงให้เห็นแล้วว่าช่องโหว่ในระบบ ERP เพียงตัวเดียวสามารถใช้กวาดข้อมูลจากองค์กรนับร้อยได้

8. ข้อเสนอเชิงยุทธศาสตร์

8.1 ระยะเร่งด่วน (0–30 วัน)

ภายใน 72 ชั่วโมงแรก องค์กรโครงสร้างพื้นฐานสำคัญและหน่วยงานรัฐควร สำรวจ PHP ทุกจุด รวมถึง PHP ที่ฝังมากับอุปกรณ์ แผงควบคุมโฮสติ้ง (cPanel, Plesk) และ container image โดยตรวจจากโปรเซสที่รันจริง เพราะ php -v อาจรายงานคนละตัวกับที่ให้บริการเว็บ จากนั้นอัปเกรดเป็น 8.5.12, 8.4.27, 8.3.36 หรือ 8.2.35 ตามสาย หรือใช้แพ็กเกจ backport ของดิสทริบิวชัน แล้ว รีสตาร์ต worker ทุกตัว ระบบที่อัปเกรดไม่ได้ทันทีให้ใช้มาตรการชั่วคราวของ PHP ได้แก่ session.upload_progress.enabled=0, fatal_error_backtraces=0 (PHP 8.5) และพิจารณา memory_limit=-1 ร่วมกับ cgroup memory limit โดยตั้งที่ php.ini หรือ FPM pool เท่านั้น (ตั้งผ่าน ini_set() หรือ .user.ini ไม่ได้ผล) พร้อมวางระบบไว้หลัง WAF ที่มีกฎสำหรับ PHP2Shell และระบบที่เป็น PHP 5.x หรือ 7.x ที่ไม่มี backport ควรถอดออกจากอินเทอร์เน็ตจนกว่าจะย้ายได้

ควบคู่กันนั้น ให้ ล่าหาร่องรอยการถูกบุกรุกย้อนหลังถึงวันที่ 17 ตุลาคม เพราะการโจมตีเริ่มก่อนแพตช์ สัญญาณที่ควรค้นหา ได้แก่ คำขอ multipart ผิดปกติตามด้วยข้อผิดพลาด memory limit, HTTP 500 ซ้ำ ๆ, cookie PHPSESSID ขนาดใหญ่ผิดปกติ, โปรเซส php-fpm, php-cgi, httpd หรือ apache2 ที่เรียก shell หรือ curl/wget, ไฟล์ใหม่ใน web root, cron job ใหม่ และบัญชีที่เพิ่มขึ้น หากพบสิ่งผิดปกติให้ถือว่าข้อมูลรับรองทุกตัวบนเครื่องนั้นรั่วแล้วและเปลี่ยนทั้งหมด

สำหรับ NGINX ให้อัปเกรดเป็น 1.30.6 หรือ 1.31.7 และใช้ nginx -T ตรวจ config ที่รันจริงหา alias คู่ rewrite, regex map, aio คู่ SSI, listen ... quic และ ssl_session_cache shared ที่ไม่มี ssl_session_ticket_key สำหรับ Oracle ให้จัดลำดับ Access Manager, SOA Suite, WebLogic, E-Business Suite, Database Server และ APEX ก่อน โดยเฉพาะระบบที่เข้าถึงได้จากเครือข่ายที่ไม่น่าเชื่อถือ และจำกัดการเข้าถึงพอร์ต T3/IIOP ให้เหลือเฉพาะเครือข่ายที่จำเป็น

8.2 ระยะกลาง (1–3 เดือน)

สกมช. และหน่วยงานกำกับดูแลรายภาคส่วนควรจัดทำ ทะเบียนซอฟต์แวร์พื้นฐาน (runtime inventory) สำหรับหน่วยงาน CII ที่ระบุเวอร์ชัน PHP, เว็บเซิร์ฟเวอร์ และผลิตภัณฑ์ Oracle ของระบบที่เปิดสู่อินเทอร์เน็ต เพื่อให้ครั้งหน้าการตอบสนองเริ่มจากข้อมูลจริง ไม่ใช่การสำรวจใหม่ทุกครั้ง หน่วยงานควรกำหนดกรอบเวลาแพตช์ตามระดับความเสี่ยงที่ชัดเจน เช่น ช่องโหว่ที่ถูกโจมตีจริงต้องแพตช์ภายใน 72 ชั่วโมง และช่องโหว่วิกฤตที่ยังไม่ถูกโจมตีภายใน 14 วัน และควรทบทวนสถาปัตยกรรมเพื่อแยกเว็บเซิร์ฟเวอร์ที่เปิดสู่ภายนอกออกจากระบบฐานข้อมูลและ ERP ด้วย network segmentation และไม่เก็บข้อมูลรับรองแบบข้อความธรรมดาในไฟล์ config ของเว็บแอปพลิเคชัน

8.3 ระยะยาว (3–12 เดือน)

ในเชิงนโยบาย การจัดซื้อจัดจ้างระบบสารสนเทศภาครัฐควร บังคับให้มีเงื่อนไขการบำรุงรักษาความปลอดภัยตลอดอายุการใช้งาน รวมถึงการอัปเกรด runtime เมื่อเวอร์ชันหมดอายุ ไม่ใช่เพียงการแก้บั๊กของแอปพลิเคชัน หน่วยงานที่มีระบบ PHP สายหมดอายุควรมีแผนย้ายพร้อมงบประมาณภายในปีงบประมาณถัดไป นอกจากนี้ ไทยควรพิจารณาเข้าร่วมหรือสร้างช่องทางรับแจ้งเตือนล่วงหน้า (pre-notification) จากโครงการโอเพนซอร์สและผู้ผลิตรายใหญ่ผ่าน ThaiCERT เพื่อลดช่องว่างที่หน่วยงานไทยรู้เรื่องช่องโหว่หลังผู้โจมตี และควรลงทุนในความสามารถตรวจจับบนเซิร์ฟเวอร์ Linux ซึ่งหลายองค์กรยังไม่ได้ติดตั้ง EDR (Endpoint Detection and Response) เทียบเท่ากับเครื่อง Windows

8.4 มุมมองไปข้างหน้า (Outlook)

ในระยะ 30 วันข้างหน้า คาดว่า PoC ที่ใช้งานได้จริงของ PHP2Shell จะเสถียรขึ้นและถูกรวมเข้าเครื่องมือสแกนอัตโนมัติ ทำให้การโจมตีแบบหว่านแหต่อเว็บไซต์ PHP เพิ่มขึ้นอย่างมาก โดยเป้าหมายแรก ๆ คือการฝัง web shell การติดตั้งโปรแกรมขุดเงินดิจิทัล และการขโมยข้อมูลรับรองเพื่อขายต่อให้กลุ่มแรนซัมแวร์ CISA อาจเพิ่มช่องโหว่ทั้งสองเข้าแคตตาล็อก KEV (Known Exploited Vulnerabilities) เมื่อมีหลักฐานยืนยันชัดเจน สำหรับ NGINX ประวัติปีนี้บ่งชี้ว่าจะมีรอบแพตช์ต่อไปอีกและอาจมีการโจมตีหากมีผู้เผยแพร่ PoC ส่วน Oracle ช่องโหว่ระดับ 10.0 ในระบบยืนยันตัวตนและมิดเดิลแวร์มีโอกาสถูกนักวิจัยทำ patch diffing และเผยแพร่รายละเอียดภายในไม่กี่สัปดาห์ ซึ่งจะเปลี่ยนสถานะความเสี่ยงอย่างรวดเร็ว หน่วยงานไทยที่ใช้ช่วงเวลานี้ปิดช่องโหว่ให้ครบจะผ่านคลื่นนี้ไปได้ ส่วนหน่วยงานที่รอจนมีข่าวการโจมตีในประเทศก่อนจึงลงมือ มีแนวโน้มสูงที่จะกลายเป็นข่าวนั้นเอง

ภาคผนวก

ก. MITRE ATT&CK Mapping (พฤติกรรมที่คาดการณ์จากความสามารถของช่องโหว่)

ข. ตัวบ่งชี้และสัญญาณสำหรับการล่าภัย

ณ วันที่ 23 ตุลาคม 2569 ยังไม่มีแหล่งที่น่าเชื่อถือเผยแพร่ IoC ที่ยืนยันแล้ว (hash, IP, domain) สำหรับการโจมตี PHP2Shell หรือช่องโหว่ NGINX/Oracle รอบนี้ ตารางด้านล่างจึงเป็นสัญญาณพฤติกรรมสำหรับการล่าภัย (hunting signals) ไม่ใช่ IoC

ค. ตารางเวอร์ชันที่แก้ไข

ง. แหล่งอ้างอิง

• php2shell (CVE-2026-109618, CVE-2026-109619): Frequently Asked Questions — Tenable
• PHP Announces Critical Security Release for Two Vulnerabilities — Qualys
• PHP CVE-2026-109618 FAQ — watchTowr
• Responding to core PHP vulnerabilities — Google Cloud
• PHP2Shell — SOCRadar
• Websites shut down globally after AI finds cybersecurity flaw — CNN
• PHP2Shell: Critical PHP Vulnerabilities and the Fragility of the Web’s Foundations — BISI
• PHP2Shell Exploitation Started Days Before Patches — SecurityWeek
• NSA, CISA Urge Immediate Patching of PHP2Shell Flaws — ExecutiveGov
• PHP2Shell: Governments Pull Websites Offline — Shattered
• PHP2Shell Crisis: Which Major Websites Went Offline — WorthvieW
• PHP shuts the internet: Why PHP2Shell affects every company — Techzine
• PHP Vulnerability: List of Websites Powered by PHP — Newsweek
• UK councils and Met Police among sites pulled offline after NCSC alert — Insurance Business
• Canadian government shuts down some websites — BetaKit
• Canadian apps and government websites go offline — CP24
• Government cybersecurity website hit in global flaw — Newcastle Herald (AAP)
• Japan PM Warns of Vulnerabilities in PHP — Nippon.com (Jiji)
• Japan’s PM, the NSA and the FBI tell websites to update PHP or go offline — Tech-ish
• Sicherheitslücke bei PHP: Millionen Webseiten bedroht — ZDFheute
• PHP Patches PHP2Shell as Hosts Across the WordPress Ecosystem Race — The Repository
• PHP2Shell Host Patch Status Tracker — ActiveSet
• PHP2Shell—for manufacturers, the danger goes deeper than a website — Engineering.com
• PHP Security Release Announcement — PHP
• Security Advisory 2026-018 — CERT-EU
• nginx security advisories — NGINX
• K000162416 — F5
• NGINX Fixes 5 Flaws, Including Possible RCE and a TLS Bug — The Hacker News
• NGINX critical fixes 2026 — Aviatrix
• Attackers are exploiting critical NGINX vulnerability (CVE-2026-42945) — Help Net Security
• Oracle Critical Patch Update Advisory — October 2026 — Oracle
• Oracle Patches Over 1,200 Vulnerabilities With October 2026 CPU — SecurityWeek
• Oracle Critical Patch Update October 2026 Fixes 1,209 CVEs — SecurityOnline
• Oracle October 2026 CPU Addresses 1,209 CVEs — Tenable
• “ภราดร” สั่งรับมือด่วน ช่องโหว่ไซเบอร์ระดับวิกฤต “PHP2Shell” — สยามรัฐ
• ยศชนันสั่งยกระดับความปลอดภัย หลัง OpenAI พบช่องโหว่ PHP — กรุงเทพธุรกิจ
• ข่าวที่เกี่ยวข้องใน Cloud Thunder: PHP2Shell , NGINX แพตช์ 5 ช่องโหว่ , Oracle CPU ตุลาคม 2569 , Java CVE-2026-91403 , NGINX Rift , NGINX CVE-2026-42533