เว็บไซต์ศูนย์ความมั่นคงปลอดภัยไซเบอร์เนเธอร์แลนด์ล่มชั่วคราว เว็บรัฐบาลหลายประเทศล่ม ช่องโหว่ PHP ทำให้องค์กรทั่วโลกออฟไลน์ได้อย่างไร?

เมื่อวันที่ 21 ตุลาคม 2026 เว็บไซต์ของศูนย์ความมั่นคงปลอดภัยไซเบอร์แห่งชาติเนเธอร์แลนด์ (NCSC) เองก็ไม่สามารถเปิดได้ชั่วคราว ในวันเดียวกัน เว็บไซต์สภาผู้แทนราษฎรเนเธอร์แลนด์และรัฐบาลฟินแลนด์ล่ม CNIL หน่วยงานคุ้มครองข้อมูลของฝรั่งเศสปิดเว็บไซต์ ส่วน pixiv และ Niconico ของญี่ปุ่นเข้าสู่โหมดบำรุงรักษาฉุกเฉิน

นี่ไม่ใช่การถูกโจมตี แต่เป็น "การปิดระบบเชิงป้องกัน" สิ่งที่ทำให้องค์กรเหล่านี้ยอมหยุดให้บริการมากกว่าเสี่ยงเปิดระบบ คือแพตช์ช่องโหว่สองรายการที่ PHP ออกอย่างเร่งด่วนในช่วงบ่ายของวันนั้น หมายเลข CVE-2026-109618 และ CVE-2026-109619 คะแนนความรุนแรงตามระบบ CVSS v4.0 อยู่ที่ 9.2 ทั้งคู่ วงการความปลอดภัยเรียกโดยรวมว่า "php2shell"

ช่องโหว่ทั้งสองจัดอยู่ในประเภท "การเรียกใช้โค้ดจากระยะไกลโดยไม่ได้รับอนุญาต" ผู้โจมตีไม่จำเป็นต้องล็อกอินและไม่ต้องให้เหยื่อทำอะไร ก็สามารถทำให้เซิร์ฟเวอร์รันโค้ดที่ตนกำหนดได้ ผลกระทบครั้งนี้ไม่ได้มาจากตัวช่องโหว่เพียงอย่างเดียว แต่มาจากจังหวะการจัดการ ตั้งแต่พบจนถึงแก้ไขใช้เวลาประมาณ 71 วัน และ 24 ชั่วโมงสุดท้ายถูกบีบให้เผยแพร่ก่อนกำหนดเพราะข้อมูลรั่วไหล ขณะที่เซิร์ฟเวอร์ประมาณ 1.03 ล้านเครื่องที่เปิดเผยเวอร์ชัน กว่าร้อยละ 70 รัน PHP เวอร์ชันที่หมดการสนับสนุนอย่างเป็นทางการแล้ว

บริษัทความปลอดภัย Wiz ระบุว่า อย่างน้อยหนึ่งช่องโหว่มีอยู่ในทุกเวอร์ชันตั้งแต่ PHP 5.4 เป็นต้นมา แต่สัญญาณแรกของช่องโหว่นี้ปรากฏขึ้นระหว่างการจัดการปัญหาจากรายงานการตรวจสอบปี 2024

การตรวจสอบครั้งนั้นได้รับทุนจาก Sovereign Tech Agency จัดโดย OSTIF และดำเนินการโดย Quarkslab ใช้เวลาประมาณสองเดือน พบปัญหาทั้งหมด 27 รายการ ในจำนวนนี้เป็นปัญหาด้านความปลอดภัย 17 รายการ (สูง 3 กลาง 5 ต่ำ 9) และนำไปสู่หมายเลข CVE 4 หมายเลข รายงานระบุชัดเจนว่า "เนื่องจากข้อจำกัดด้านงบประมาณ การตรวจสอบนี้มุ่งเน้นเฉพาะส่วนประกอบที่สำคัญที่สุด ไม่ใช่โค้ดเบสทั้งหมด"

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

ต้นตอของปัญหาอยู่ที่การจัดการหน่วยความจำ สาเหตุของ CVE-2026-109618 คือเมื่อคำขอใช้หน่วยความจำถึงขีดจำกัดที่ PHP กำหนดพอดี กระบวนการจะถูกขัดจังหวะ เหลือข้อมูลภายในที่เริ่มต้นไว้เพียงครึ่งเดียว จากนั้นข้อมูลส่วนนี้ถูกนำไปใช้เสมือนเป็นข้อมูลที่สมบูรณ์ ทำให้เกิดความเสียหายต่อหน่วยความจำ ส่วนสาเหตุของ CVE-2026-109619 คือ fatal error เกิดขึ้นผิดจังหวะ สถานะภายในของ PHP ยังคงชี้ไปยังหน่วยความจำที่ถูกปล่อยคืนจากคำขอก่อนหน้า เมื่อเวิร์กเกอร์โพรเซสเดียวกันประมวลผลคำขอถัดไป ก็จะนำหน่วยความจำส่วนนั้นกลับมาใช้ใหม่ เกิดเป็นข้อบกพร่องแบบ "การใช้งานหลังหน่วยความจำถูกปล่อยคืน" (use-after-free)

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

รายงานที่ช่วยด้วย AI กับการชะงักงันของระบบฉันทามติ

เมื่อวันที่ 11 สิงหาคม 2026 Ryan Austin นักวิจัยของบริษัทความปลอดภัย Calif รายงานช่องโหว่ที่สามารถเรียกใช้โค้ดจากระยะไกลได้โดยไม่มีเงื่อนไขเป็นรายแรก ซึ่งมีต้นเหตุเดียวกับปัญหา OOM ที่พบในปี 2024 ในวันเดียวกัน OpenAI รายงานต้นเหตุเดียวกันโดยอิสระ วันที่ 24 สิงหาคม Wiz ส่งรายงานเพิ่มเติม และวันที่ 18 กันยายน OpenAI รายงานวิธีการกระตุ้นเพิ่มเติม

นักวิจัยของ Calif ใช้โมเดล GPT-5.6 Sol ของ OpenAI ช่วยในการตรวจสอบความปลอดภัยระหว่างการค้นพบ Thai Duong ซีอีโอของ Calif โทรศัพท์เตือน Volker Dusch วิศวกรความปลอดภัยของ PHP Foundation เมื่อวันที่ 11 สิงหาคม OpenAI ระบุว่า เท่าที่ทราบ นี่เป็นครั้งแรกที่ AI ล้ำสมัยค้นพบช่องโหว่ประเภทนี้ก่อนผู้โจมตี เปิด "ช่วงเวลาที่ฝ่ายป้องกันได้เปรียบ" ให้ฝ่ายตั้งรับ Ami Luttwak ผู้ร่วมก่อตั้ง Wiz กล่าวว่านี่คือ "ช่องโหว่ที่ร้ายแรงที่สุดเท่าที่ AI เคยค้นพบมา" และซับซ้อนถึงขั้นที่ยากที่จะค้นพบหากไม่มี AI

แต่งานแก้ไขกลับหยุดชะงักและเริ่มใหม่หลายครั้งตลอดหลายเดือน

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

ทีมความปลอดภัยออกแบบวิธีแก้ไขที่แข่งขันกันหลายทาง แต่ละทางมีต้นทุน ทั้งทำลายความเข้ากันได้กับเวอร์ชันเก่า นำความเสี่ยง denial-of-service ใหม่มาให้ หรือต้องแก้ไขส่วนขยายภายนอกจำนวนมากจน "ดูเหมือนประสานงานไม่ได้" ทีม "กลัวผลที่ตามมาหากเลือกแนวทางที่ผิด" การแก้ไขครั้งนี้เกี่ยวข้องกับไฟล์เกือบ 200 ไฟล์ โค้ดมากกว่า 10,000 บรรทัด นำโดยผู้ดูแล PHP และทำอย่างเป็นความลับนานประมาณสองเดือน

มาตรการแก้ไขที่ PHP Foundation เสนอรวมถึง เปลี่ยนการตัดสินใจของทีมความปลอดภัยเป็นเสียงข้างมาก และสนับสนุนให้สมาชิกประนีประนอม

ภาพ: Oracle October 2026 Critical Patch Update Addresses 1209 CVE (ที่มา: jp.tenable.com)

คืนวันที่ 20 ตุลาคม: ข้อมูลรั่วไหลและการเผยแพร่ก่อนกำหนด

กำหนดการเผยแพร่เดิมคือวันที่ 22 ตุลาคม วันที่ 20 ตุลาคม เวลาประมาณ 15:00 UTC หมายเลข CVE สองรายการเริ่มแพร่สะพัดในฟอรัมและโซเชียลมีเดีย พร้อมเวลาเผยแพร่ที่ผิดและคะแนน CVSS 10.0 ที่ผิด (ค่าจริงคือ 9.2) แต่ไม่มีรายละเอียดทางเทคนิครั่วไหล

เวลาประมาณ 20:00 น. Calif เผยแพร่วิดีโอสาธิตโค้ดโจมตีที่รันกับหลายเป้าหมายโดยไม่ตั้งใจ สำเนาวิดีโอแพร่กระจายในโซเชียลมีเดีย PHP Foundation ระบุว่าวิดีโอดังกล่าวช่วยให้ผู้อื่นเร่งพัฒนาเครื่องมือโจมตีของตัวเอง

เวลา 19:30 น. ทีม PHP ออกประกาศล่วงหน้า และเลื่อนเวลาเผยแพร่เป็นวันที่ 21 ตุลาคม เวลา 14:00 UTC ประกาศระบุว่า "ทีมความปลอดภัย PHP แจ้งล่วงหน้า: กำลังจะเผยแพร่อัปเดตความปลอดภัยในวันพุธที่ 21 ตุลาคม 2026 เวลา 14:00 UTC ช่องโหว่ร้ายแรงสองรายการ คะแนน CVSSv4 9.2 ทั้งคู่ แนะนำให้ผู้ใช้ PHP เตรียมอัปเดต หากรายละเอียดถูกเปิดเผยหรือมีหลักฐานการโจมตีจริง จะเผยแพร่ก่อนกำหนด"

คืนนั้น บริษัทความปลอดภัย watchTowr ยืนยันว่าช่องโหว่เป็นของจริง Benjamin Harris ซีอีโอกล่าวว่า "เนื่องจากความอ่อนไหว เรายังไม่สามารถแบ่งปันข้อมูลทางเทคนิคได้ แต่ยืนยันได้ว่าช่องโหว่เหล่านี้มีอยู่จริง"

วันเดียวกัน มีโพสต์ประกาศล่วงหน้าบน Hacker News (ถูกลบภายหลัง) ผู้โพสต์ยอมรับว่าตน "ไม่มีหลักฐานใดนอกจาก 'ที่มา: เชื่อใจฉันเถอะเพื่อน'" แต่กลับระบุช่องโหว่สองรายการ หมายเลข CVE สองรายการ และวันที่เปิดเผยได้อย่างแม่นยำ แม้จะบอกคะแนนเป็น 10.0 ก็ตาม

ช่วงกันชนสองวันที่เหลืออยู่ ถูกบีบอัดเหลือเพียงคืนเดียว

วันที่ 21: การปิดระบบและกฎเกณฑ์

วันที่ 21 ตุลาคม เวลา 07:41 UTC Chainguard บริษัทซอฟต์แวร์ซัพพลายเชน เผยแพร่คอนเทนเนอร์อิมเมจที่รวมแพตช์แล้วก่อนกำหนด เร็วกว่าเวลาการเปิดเผยแบบประสานงานกว่า 6 ชั่วโมง PHP Foundation กล่าวว่าการกระทำนี้ "เพิกเฉยต่องานหลายสัปดาห์ของหลายฝ่าย"

แพตช์อย่างเป็นทางการของ PHP ขึ้นระบบจริงเมื่อเวลาประมาณ 13:35 UTC เร็วกว่าแผน 14:00 น. ไม่กี่นาที กฎไฟร์วอลล์เว็บแอปพลิเคชัน (WAF) ของ Cloudflare เปิดใช้งานเป็นดีฟอลต์สำหรับผู้ใช้ฟรีและเสียเงินเมื่อเวลา 03:02 UTC เร็วกว่าการเปิดเผยอย่างเป็นทางการประมาณ 9 ชั่วโมง กฎใช้สัญญาณทั้งจากคำขอและการตอบสนอง เพื่อบล็อกความพยายามโจมตีและป้องกันข้อมูลรั่วไหลออกภายนอก Dane Knecht ประธานเจ้าหน้าที่ฝ่ายเทคโนโลยีของ Cloudflare กล่าวว่า "เราเห็นการโจมตีระยะแรกเริ่มแล้ว และจะอัปเดตมาตรการบรรเทาเมื่อมีวิธีการโจมตีใหม่ ๆ เกิดขึ้น นี่เป็นเพียงมาตรการชั่วคราว"

เว็บไซต์ของศูนย์ความมั่นคงปลอดภัยไซเบอร์แห่งชาติเนเธอร์แลนด์ปิดระบบเชิงป้องกัน เว็บไซต์รัฐบาลบางส่วนของเนเธอร์แลนด์และฟินแลนด์ล่ม เว็บไซต์ของ CNIL หน่วยงานคุ้มครองข้อมูลฝรั่งเศสปิดตัว BASE, pixiv และ Niconico ของญี่ปุ่นเข้าสู่โหมดบำรุงรักษาฉุกเฉิน กระทรวงมหาดไทยฝรั่งเศสระบุว่าเว็บไซต์รัฐบาลท้องถิ่นถูกปิดชั่วคราวเป็นมาตรการป้องกัน โรงพยาบาลก็ได้รับผลกระทบเช่นกัน สมาคมอุตสาหกรรมอีคอมเมิร์ซเนเธอร์แลนด์ Thuiswinkel.org ปิดเว็บไซต์บางส่วนของตัวเองชั่วคราว และแนะนำให้สมาชิกติดต่อผู้ให้บริการเทคนิคในวันนั้น พร้อมระบุว่า "ไม่ใช่แค่ WordPress/WooCommerce แต่ต้องเปลี่ยนเวอร์ชันของทุกระบบ"

ทาคาอิจิ ซานาเอะ นายกรัฐมนตรีญี่ปุ่น โพสต์บน X ในคืนนั้น เรียกร้องให้ตรวจสอบระบบและเตรียมติดตั้งแพตช์

CERT-EU หน่วยงานความมั่นคงปลอดภัยไซเบอร์ของสหภาพยุโรป ออกประกาศความปลอดภัยหมายเลข 2026-018 เมื่อวันที่ 20 ตุลาคม แนะนำให้องค์กรที่ไม่สามารถแพตช์ได้ "พิจารณาแยกแอปพลิเคชันที่เชื่อมต่ออินเทอร์เน็ตออกจากเครือข่ายสาธารณะ" ศูนย์ความมั่นคงปลอดภัยไซเบอร์แห่งชาติสหราชอาณาจักรระบุว่า "เมื่อไม่สามารถแก้ไขได้ทันที องค์กรควรพิจารณาปิดระบบจนกว่าจะบรรเทาได้อย่างสมบูรณ์" สำนักงานความมั่นคงปลอดภัยไซเบอร์และโครงสร้างพื้นฐาน (CISA) ของสหรัฐฯ ออกประกาศเตือนเมื่อวันที่ 21 แนะนำให้อัปเกรด PHP ส่วนระบบ 8.1 และเก่ากว่าที่อัปเกรดไม่ได้ควร "ปิดระบบ" ACSC ในสังกัดสำนักงานสัญญาณออสเตรเลีย, IPA ของญี่ปุ่น และ CERT-FR ของฝรั่งเศสก็ออกคำแนะนำในลักษณะเดียวกัน สำนักงานความมั่นคงแห่งชาติสหรัฐฯ (NSA) โพสต์บนโซเชียลมีเดียว่า "ช่องโหว่เหล่านี้มักเปิดเส้นทางตรงไปยังระบบไฟล์หรือฐานข้อมูลของเซิร์ฟเวอร์"

กว่าร้อยละ 70 ของระบบไม่มีแพตช์อย่างเป็นทางการ

PHP ออกแพตช์ซอร์สโค้ดแบบขั้นต่ำเป็นกรณีพิเศษสำหรับ PHP 7.4, 8.0 และ 8.1 ที่หมดการสนับสนุนแล้ว ดิสทริบิวชันลินุกซ์และผู้ให้บริการ long-term support (LTS) ได้รับแพตช์ล่วงหน้า เวอร์ชันที่แก้ไขคือ PHP 8.5.12, 8.4.27, 8.3.36 และ 8.2.35

แต่เวอร์ชันที่เก่ากว่านั้นต้องพึ่งพาดิสทริบิวชันหรือปิดระบบเท่านั้น ตามข้อมูลจาก VirusTotal ในบรรดาเซิร์ฟเวอร์ที่เปิดเผยหมายเลขเวอร์ชัน ประมาณ 758,000 เครื่องรัน PHP 5.4–8.1 (ไม่ได้รับแพตช์อย่างเป็นทางการแล้ว) และประมาณ 272,000 เครื่องอยู่ในสาขาที่ยังสนับสนุน CyberScoop อ้างนักวิจัยว่าอาจมีโฮสต์ที่เปิดเผยต่ออินเทอร์เน็ตมากกว่า 1.3 ล้านเครื่องได้รับผลกระทบ Shodan นับได้ประมาณ 1.9 ล้านเครื่อง ในบรรดาเซิร์ฟเวอร์ PHP ที่เปิดเผยเวอร์ชัน 1.03 ล้านเครื่อง 73.6% รันบนสาขา PHP 5.4–8.1

Cisco Talos ประเมินจากข่าวกรองโอเพนซอร์สว่า ระบบ PHP ประมาณร้อยละ 50 จะไม่ได้รับแพตช์

การสนับสนุนด้านความปลอดภัยของสาขา PHP 8.2 จะสิ้นสุดในวันที่ 31 ธันวาคม 2026 เมื่อช่องโหว่ระดับเดียวกันระบาดครั้งหน้า องค์กรที่ยังคงอยู่บน 8.2 จะเหลือช่วงกันชนเพียงประมาณสองเดือน

ตามข้อมูลของ W3Techs บริษัทวิจัยตลาด PHP ขับเคลื่อนเว็บไซต์ประมาณร้อยละ 70 ของเว็บไซต์ที่รู้จักภาษาเซิร์ฟเวอร์ WordPress คิดเป็นประมาณร้อยละ 43 ของเว็บไซต์ทั่วโลก Wordfence เตือนว่า เว็บไซต์ WordPress ทุกแห่งรันบนเซิร์ฟเวอร์ PHP แต่การอัปเดตอัตโนมัติของ WordPress ไม่ได้แก้ไขชั้น PHP

ฟีเจอร์ session upload progress ของ PHP (session.upload_progress เปิดเป็นดีฟอลต์มานานกว่าสิบปี แต่มีเว็บไซต์ใช้น้อยมาก) เป็นหนึ่งในช่องทางโจมตีที่ยืนยันแล้ว คำแนะนำในการบรรเทารวมถึงการปิดฟีเจอร์นี้และลดค่า post_max_size แต่ PHP ระบุว่า "ไม่มีมาตรการบรรเทาที่สมบูรณ์ การอัปเกรดเป็นทางเลือกเดียวที่ปลอดภัย" Gina Peter Banyard นักพัฒนาหลักของ PHP กล่าวว่า "วิธีบรรเทาเดียวคือแพตช์หรืออัปเกรด PHP" Joe Ferguson ผู้จัดการรีลีส PHP 8.6 ตอบคำแนะนำที่ว่า "แค่ปิดฟีเจอร์ session upload progress ก็พอ" ว่า "การตั้งค่า ini ช่วยคุณไม่ได้"

จนถึงวันที่ 21 ตุลาคม ยังไม่มีเหยื่อที่ถูกเจาะระบบยืนยัน ปริมาณข้อมูลรั่วไหล หรือมูลค่าความเสียหาย ข้อมูลสาธารณะมีเพียง "การปิดระบบเชิงป้องกัน" และ "Cloudflare สังเกตเห็นทราฟฟิกการโจมตี"

บริษัทความปลอดภัย Sansec คาดการณ์ว่า "เราคาดว่าการโจมตีขนาดใหญ่จะเริ่มขึ้นภายใน 15 นาทีหลังการเผยแพร่" Jake Knott หัวหน้าฝ่ายข่าวกรองภัยคุกคามของ watchTowr กล่าวว่า "แม้จนถึงตอนนี้ยังไม่มีใครสำเร็จ แต่เราไม่คิดว่ามันจะอยู่อย่างนี้ได้นาน" Thai Duong ซีอีโอของ Calif กล่าวว่า "ใครก็ตามบนทวิตเตอร์สามารถนำแพตช์ไปรันกับ AI แล้วโพสต์สคริปต์โจมตีได้ เมื่อถึงตอนนั้นจะวุ่นวายไปหมด"

Volker Dusch วิศวกรความปลอดภัยของ PHP Foundation เปรียบเทียบเหตุการณ์นี้กับ Heartbleed ในปี 2014 โดยกล่าวว่านี่คือปัญหาความปลอดภัยที่ร้ายแรงที่สุดของ PHP ในรอบกว่าสิบปี สำหรับการตัดสินใจเผยแพร่ก่อนกำหนด เขากล่าวว่าเป็นการ "สมดุลที่ดี" ระหว่าง "การเตือนฝ่ายตั้งรับ" กับ "การไม่ให้เวลาผู้โจมตีพัฒนามากเกินไป"

Lukasz Olejnik ที่ปรึกษาความปลอดภัยอิสระและนักวิจัยอาวุโสรับเชิญของ King's College London กล่าวว่า "ทุกคนควรแพตช์ทันที การโจมตีอาจมาเร็วมากและมีขนาดใหญ่มาก AI ทำให้การใช้ประโยชน์จากช่องโหว่แบบนี้กลายเป็นเรื่องเร่งด่วน จริง ๆ แล้วมันเป็นเรื่องของหนึ่งหรือสองนาที" Wouter van Dongen แฮกเกอร์สายจริยธรรมชาวเนเธอร์แลนด์กล่าวว่า "แพตช์หนึ่งอุดช่องโหว่ได้ แต่ย้อนการบุกรุกที่เกิดขึ้นก่อนหน้าไม่ได้... หลายระบบจะเปราะบางไปอีกนาน เพราะไม่ใช่ทุกคนจะอัปเดตทันที และ PHP เวอร์ชันเก่าก็ไม่มีการอัปเดตความปลอดภัยอย่างเป็นทางการอีกต่อไป"