PHP เตรียมแพตช์ฉุกเฉินคืนนี้ 3 ทุ่ม เจ้าของเว็บควรทักโฮสต์วันนี้

อัปเดต 21 ต.ค. 2026 21:50 น. (เวลาไทย): PHP ปล่อยแพตช์แล้ว รุ่นที่ต้องอัปคือ 8.5.12, 8.4.27, 8.3.36 และ 8.2.35 อ่านรายละเอียดที่ PHP ออกแพตช์ฉุกเฉินแล้ว

PHP แจ้งช่องโหว่ร้ายแรงสองจุด คะแนนความรุนแรงจุดละ 9.2 และกำหนดปล่อยรุ่นแก้ไขวันที่ 21 ตุลาคม 2026 เวลา 21:00 น. ตามเวลาไทย คืนนี้ โดยประกาศทางการระบุเวลา 14:00 UTC ซึ่งช้ากว่าไทยเจ็ดชั่วโมง (PHP) ถ้าคุณมีเว็บไซต์ขายของหรือเว็บรับข้อมูลลูกค้า เรื่องนี้ควรอยู่ในรายการงานวันนี้ เพราะสิ่งที่ต้องเตรียมคือคนดูแลระบบและแผนอัปเดต ไม่ต้องรอให้เว็บมีอาการก่อน

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

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

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

• ทีม PHP ประกาศเมื่อวันที่ 20 ตุลาคมว่าเตรียมแก้ช่องโหว่ระดับวิกฤตสองจุด แต่ละจุดมีคะแนน CVSS v4.0 เท่ากับ 9.2 ระบบคะแนนนี้ใช้สื่อสารความรุนแรงของช่องโหว่ ไม่ใช่จำนวนเว็บไซต์ที่ถูกโจมตี (PHP)
• กำหนดการทางการคือวันที่ 21 ตุลาคม เวลา 21:00 น. ไทย พร้อมขอให้ผู้ใช้เตรียมอัปเกรดทันทีที่รุ่นแก้ไขพร้อมใช้งาน (PHP)
• watchTowr บอก BleepingComputer ว่าเป็นช่องโหว่ RCE หรือการที่คนนอกสั่งเครื่องเราทำงานได้จากระยะไกล และเชื่อว่าส่งผลต่อ PHP หลายรุ่น แต่ขอบเขตรุ่นยังต้องรอทีม PHP ยืนยัน (BleepingComputer)
• CERT-EU แนะนำให้ค้นหาระบบที่ใช้ PHP และเตรียมติดตั้งแพตช์ ซึ่งหมายถึงชุดแก้ไขซอฟต์แวร์ หากแก้ทันทีไม่ได้ ให้พิจารณาแยกแอปที่เปิดสู่อินเทอร์เน็ตออกจากเครือข่ายสาธารณะชั่วคราว (CERT-EU)
• watchTowr ระบุว่ายังไม่พบการนำช่องโหว่ไปโจมตีจริงในสิ่งที่ทีมสังเกต ณ เวลารายงาน ข้อนี้เป็นสถานะการตรวจพบของทีม ไม่ใช่คำรับรองว่าไม่มีใครโจมตีที่ไหนเลย (BleepingComputer)

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

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

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

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

ทำงานยังไง

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

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

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

Sansec ประเมินว่าต้องอัปเดต PHP ในระดับโครงสร้างพื้นฐาน หรือส่วนเครื่องและซอฟต์แวร์พื้นฐานที่ทำให้เว็บทำงาน การแก้เฉพาะโค้ดร้านค้าไม่ใช่วิธีแก้ปัญหานี้ตามรายงานของบริษัท (Sansec) ในทางปฏิบัติ เจ้าของเว็บจึงควรขอคำยืนยันเรื่อง PHP โดยตรง แทนการได้รับคำตอบกว้าง ๆ ว่าอัปเดตเว็บแล้วโดยไม่รู้ว่าอัปเดตส่วนใด

จุดสังเกต: ข่าวรั่วทำให้ทุกฝ่ายต้องเตรียมพร้อมก่อนรายละเอียดครบ

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

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

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

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

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

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

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

หากต้องเลือกระหว่างเปิดบริการต่อกับพักบริการบางส่วน คำแนะนำของ CERT-EU คือพิจารณาแยกแอปที่เปิดสู่อินเทอร์เน็ตออกจากเครือข่ายสาธารณะเมื่อยังแก้ไขทันทีไม่ได้ (CERT-EU) ผมแนะนำให้เจ้าของงานกับไอทีตกลงร่วมกันว่าบริการใดจำเป็นต้องเปิด และจะสื่อสารอย่างไร แทนการให้คนเฝ้าเครื่องตัดสินใจเรื่องรายได้ลำพังตอนกลางคืน

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

คะแนนความรุนแรงต่างกัน: ทีม PHP ระบุ CVSS v4.0 จุดละ 9.2 ขณะที่ watchTowr และโพสต์ที่ถูกลบซึ่ง BleepingComputer รายงานถึงระบุ 10.0 บทความนี้ยึด 9.2 ตามประกาศทางการ และเก็บตัวเลขจากรายงานอื่นไว้ในฐานะข้อมูลที่ยังไม่ตรงกัน (PHP, BleepingComputer)

เวลานัดหมายมีหลายชุด: ประกาศ PHP ระบุวันที่ 21 ตุลาคม เวลา 14:00 UTC หรือ 21:00 น. ไทย ส่วน watchTowr กล่าวถึงกำหนดเดิมวันพฤหัสบดีเวลา 11:00 ET ซึ่งในบริบทข่าวคือวันที่ 22 ตุลาคม เวลา 22:00 น. ไทย ขณะเดียวกัน Mallory เขียนว่ากำหนดที่เลื่อนมาคือวันที่ 21 ตุลาคม เวลา 09:00 EDT หรือ 20:00 น. ไทย จึงต่างจากประกาศ PHP หนึ่งชั่วโมง สำหรับการเตรียมคืนนี้ให้ยึดประกาศ PHP และเผื่อการปล่อยก่อนเวลาไว้ด้วย (PHP, BleepingComputer, Mallory)

รุ่นที่ได้รับผลกระทบยังไม่ยืนยันจากทีม PHP: watchTowr บอกว่าเชื่อว่าครอบคลุม PHP 5, 6, 7 และ 8 ขณะที่ Sansec ระบุ PHP 5.4 ขึ้นไป ส่วน CERT-EU ใช้ถ้อยคำว่าอาจกระทบตั้งแต่ PHP 5 เป็นต้นไป ขอบเขตเหล่านี้ยังต้องตรวจเทียบรายการทางการที่จะออกพร้อมแพตช์ ไม่ควรสรุปจากข่าวว่าทุกรุ่นได้รับผลเหมือนกันแน่นอน (BleepingComputer, Sansec, CERT-EU, PHP)

เลขรุ่นแก้ไขที่มีผู้รายงานยังไม่ใช่รายการยืนยัน: Mallory อ้างข้อมูลจาก Kevin Beaumont ว่ารุ่นที่คาดว่าจะมีตัวแก้คือ 8.5.12, 8.4.27, 8.3.36 และ 8.2.35 รายการนี้ยังไม่ยืนยันจากประกาศ PHP ที่ให้มา อย่าใช้เลขเหล่านี้เพียงอย่างเดียวรับรองว่าเครื่องปลอดภัยแล้ว ต้องอ่านประกาศรุ่นแก้ไขจริงอีกครั้ง (Mallory, PHP)

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

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

เจ้าของธุรกิจและเจ้าของเว็บที่ใช้โฮสติ้งร่วมกับผู้อื่น

1. ส่งข้อความถึงโฮสต์หรือคนทำเว็บวันนี้ว่า “เว็บเราใช้ PHP รุ่นอะไร ใครดูแลส่วนนี้ และคืนนี้จะติดตามกับลงแพตช์ PHP ให้เมื่อพร้อมหรือไม่” คำถามนี้ทำให้คำแนะนำของ Sansec เรื่องติดต่อผู้ให้บริการกลายเป็นงานที่มีผู้รับผิดชอบ (Sansec)
2. ผมแนะนำให้สำรองข้อมูลเว็บและข้อมูลธุรกิจที่จำเป็นตอนนี้ พร้อมถามวิธีกู้คืนให้เข้าใจ การสำรองข้อมูลเป็นการเตรียมรับการเปลี่ยนระบบ ไม่ได้ทำให้ช่องโหว่หายไป จึงยังต้องติดตามการอัปเดต PHP ตามคำแนะนำทางการ (PHP)
3. ขอแผนว่าจะทำเมื่อไร ตรวจการใช้งานอะไรหลังอัปเดต และแจ้งผลผ่านช่องทางไหน หากอัปเดตไม่ได้ ให้ถามทางเลือกในการจำกัดการเข้าถึงชั่วคราวตามแนวทาง CERT-EU พร้อมคุยผลต่อการรับงานของร้าน (CERT-EU)
4. หลังผู้ให้บริการแจ้งเสร็จ ผมแนะนำให้ขอข้อมูลรุ่นที่ใช้งานและลองงานหลักของเว็บ เช่น การสั่งซื้อหรือการส่งแบบฟอร์ม อย่าจบที่คำว่า “จัดการแล้ว” โดยไม่มีรายละเอียดพอให้เจ้าของงานเข้าใจ

ทีมไอทีและนักพัฒนา

1. สำรวจจุดที่ใช้ PHP ทั้งระบบหลักและระบบที่อาจหลงรายการ Mallory แนะนำให้ทำบัญชีการติดตั้ง PHP และเตรียมทดสอบกับนำแพตช์ขึ้นใช้งานอย่างเร่งด่วน (Mallory) ผมแนะนำให้รวมคอนเทนเนอร์ ซึ่งเป็นชุดสภาพแวดล้อมสำหรับรันแอป และ Docker image ซึ่งเป็นต้นแบบชุดนั้นไว้ในรายการตรวจด้วย เพื่อให้แผนครอบคลุมวิธีส่งมอบระบบของทีม
2. วางช่วงบำรุงรักษาคืนวันที่ 21 ตุลาคมรอบเวลา 21:00 น. ไทย พร้อมคนทดสอบและช่องทางแจ้งเหตุ แต่ติดตามระหว่างวันด้วยเพราะ PHP อาจปล่อยก่อนกำหนด (PHP)
3. เมื่อประกาศออก ให้อ่านรุ่นที่ได้รับผลกระทบและรุ่นแก้ไขจาก PHP ก่อนตัดสินใจ จากนั้นดำเนินการตามวิธีของผู้ให้บริการหรือระบบที่ใช้อยู่ ข้อมูลชุดนี้ยังไม่มีข้อกำหนดเรื่องการเริ่มบริการใหม่ที่ยืนยันได้ จึงควรตรวจคำแนะนำของแพ็กเกจจริง ไม่เดาขั้นตอนจากชื่อภาษา (PHP)
4. แยกระบบรุ่นเก่าเป็นงานที่ต้องมีทางออกชัดเจน Sansec แนะนำให้ขอตัวแก้ที่ปรับสำหรับรุ่นเก่าหรือย้ายไปสายรุ่นที่รองรับ ส่วน CERT-EU แนะนำให้พิจารณาแยกบริการออกจากเครือข่ายสาธารณะหากยังแก้ไม่ได้ (Sansec, CERT-EU)
5. อย่าเลือก PHP 8.6 รุ่น RC มาใช้เป็นทางแก้บนเว็บจริง RC คือรุ่นทดสอบก่อนออกจริง และหน้า PHP ระบุว่า PHP 8.6.0 RC3 ยังเป็นรุ่นทดสอบ พร้อมเตือนชัดว่าไม่ให้ใช้ในระบบใช้งานจริง (PHP) เลขรุ่นมากกว่าไม่ได้ตอบคำถามว่ารุ่นใดแก้ช่องโหว่นี้แล้ว

ผู้ใช้เว็บไซต์ทั่วไป พนักงาน ผู้ปกครอง และนักเรียน

1. ข่าวนี้ไม่ได้มีคำสั่งให้ผู้เข้าชมเว็บติดตั้งโปรแกรมใดลงโทรศัพท์หรือคอมพิวเตอร์ คำแนะนำหลักมุ่งไปที่ผู้ดูแลระบบ PHP และการอัปเดตฝั่งเครื่องที่ให้บริการเว็บ (PHP, CERT-EU)
2. ผมแนะนำให้ระวังเมื่อเว็บที่คุ้นเคยมีพฤติกรรมแปลก เช่น เนื้อหาหรือคำขอข้อมูลเปลี่ยนไปมาก ให้หยุดกรอกข้อมูลและติดต่อผู้ให้บริการผ่านช่องทางเดิมก่อน อาการแปลกเพียงอย่างเดียวไม่ได้พิสูจน์ว่าเกี่ยวกับช่องโหว่นี้
3. ถ้าคุณรับผิดชอบเว็บในที่ทำงาน ให้ส่งข่าวต่อภายในถึงคนดูแลพร้อมคำถามเรื่องแผนคืนนี้ สิ่งที่ช่วยได้มากคือให้ข่าวไปถึงผู้ลงมืออัปเดต ไม่จำเป็นต้องอธิบายเทคนิคการโจมตีให้ทุกคนฟัง

ผมมองว่า…

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

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

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

คืนนี้ให้จับตาประกาศ PHP วันที่ 21 ตุลาคม 2026 เวลา 21:00 น. ไทย หรือก่อนหน้านั้นหากทีมตัดสินใจปล่อยเร็ว สิ่งที่ต้องรอคือรายละเอียดช่องโหว่ รายชื่อรุ่นที่ได้รับผลกระทบ และรุ่นที่แก้แล้วตามที่ทีม PHP ระบุว่าจะเผยแพร่พร้อมกัน (PHP) หลังจากนั้นจึงตรวจว่าแผนของผู้ให้บริการตรงกับประกาศหรือไม่

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

Recap

• จำกำหนดทางการ: 21 ตุลาคม 2026 เวลา 21:00 น. ไทย และติดตามเผื่อปล่อยก่อนเวลา (PHP)
• แยกคะแนนทางการ 9.2 ออกจากตัวเลขในรายงานที่ยังไม่ตรงกัน (PHP)
• รอรายการรุ่นที่ได้รับผลกระทบและรุ่นแก้ไขจากประกาศจริง (PHP)
• ถามโฮสต์หรือคนดูแลเว็บวันนี้ว่าใครจะอัปเดต PHP เมื่อแพตช์ออก (Sansec)
• สำรองข้อมูลและตกลงแผนทดสอบหลังอัปเดตตามความจำเป็นของเว็บ
• สำรวจระบบ PHP ให้ครบ และเตรียมทางออกสำหรับระบบที่ยังอัปเดตไม่ได้ (CERT-EU)
• ไม่ใช้ PHP 8.6 รุ่น RC บนระบบจริงเพื่อหวังแก้ปัญหานี้ (PHP)
• ผู้ใช้ทั่วไปไม่ต้องติดตั้งตัวแก้ฝั่งเซิร์ฟเวอร์เอง และควรหยุดตรวจสอบก่อนกรอกข้อมูลเมื่อเว็บผิดสังเกต