PHP พบช่องโหว่ใหม่ยังไร้แพตช์ เว็บแบบไหนต้องให้โฮสติ้งเช็กทันที

เพียง 2 วันหลังออกแพตช์ฉุกเฉิน PHP2Shell ทีม PHP ก็ประกาศช่องโหว่ใหม่ CVE-2026-115560 เมื่อวันที่ 23 ตุลาคม 2026 ซึ่งยังไม่มีแพตช์ และอาจเปิดทางให้คนภายนอกสั่งรันโค้ดบนเครื่องที่ให้บริการเว็บไซต์ได้ แต่ต้องเป็นเว็บที่มีการตั้งค่าผิดจากปกติในเงื่อนไขเฉพาะเท่านั้น (The Hacker News)

สำหรับคนขายของ เจ้าหน้าที่โรงเรียน หรือคนดูแลเว็บคลินิก ประเด็นที่ควรทำต่อคือส่งข่าวนี้ให้ผู้ดูแลเว็บตรวจการตั้งค่า ไม่ต้องเริ่มจากการท่องชื่อช่องโหว่ครับ เพราะคำว่า “อัปเดตแล้ว” รอบนี้ยังต้องถามต่อว่าอัปเดตเพื่อแก้ปัญหาตัวไหน แพตช์วันที่ 21 ตุลาคมแก้ PHP2Shell สองช่องโหว่ก่อนหน้า แต่ไม่ได้แก้ช่องโหว่ใหม่ตัวนี้ (The Hacker News)

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

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

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

ณ ข้อมูลที่เผยแพร่วันที่ 23 ตุลาคม ยังไม่มีรายงานการนำ CVE-2026-115560 ไปโจมตีจริง ข่าวการโจมตีที่ตามหลังการเปิดเผยวันที่ 21 ตุลาคมเป็นเรื่อง PHP2Shell สองตัวก่อนหน้า ต้องแยกชื่อให้ชัดก่อนส่งต่อในกลุ่มงานครับ (The Hacker News)

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

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

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

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

ทำงานยังไง

เซสชันคือข้อมูลที่โปรแกรมใช้ต่อเนื่องระหว่างการใช้งานเว็บ ส่วนตัวจัดรูปแบบข้อมูลเซสชัน หรือ serializer คือส่วนที่กำหนดว่าจะเก็บข้อมูลนั้นในรูปแบบใด ประกาศครั้งนี้พูดถึงโปรแกรมที่ตั้งรูปแบบหนึ่งไว้ก่อน แล้วเปลี่ยนเป็นอีกรูปแบบระหว่างทำงาน ร่วมกับการเปิด session upload progress ซึ่งเป็นความสามารถให้แอปติดตามความคืบหน้าของการส่งไฟล์ขึ้นเว็บ (The Hacker News)

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

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

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

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

จุดสังเกต: อัปเดตแล้ว ยังต้องถามว่าปิดความเสี่ยงตัวไหน

PHP 8.5.12, 8.4.27, 8.3.36 และ 8.2.35 เป็นเวอร์ชันแก้สองช่องโหว่ PHP2Shell ที่ออกวันที่ 21 ตุลาคม การติดตั้งเวอร์ชันเหล่านี้ยังจำเป็น แต่ไม่ได้แปลว่า CVE-2026-115560 ได้รับการแก้ตามไปด้วย เพราะช่องโหว่ใหม่ยังรอการแก้ในรอบปกติ (The Hacker News)

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

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

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

สำหรับเจ้าของกิจการ ผมมองว่าค่าใช้จ่ายที่ควรวางแผนก่อนคือเวลาของคนตรวจระบบ เวลานัดเปลี่ยนการตั้งค่า และเวลาทดสอบงานสำคัญหลังดำเนินการ นี่เป็นข้อเสนอในการบริหารงาน ไม่ใช่ตัวเลขความเสียหายจากเหตุโจมตี เพราะแหล่งข่าวยังไม่ได้ให้มูลค่าความเสียหายของช่องโหว่ใหม่นี้ และยังไม่มีรายงานการโจมตีที่ระบุว่าเป็น CVE-2026-115560 (The Hacker News)

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

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

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

วันที่ออกแพตช์จริงของ CVE-2026-115560 ยังไม่ทราบ ประกาศ PHP บอกว่าจะจัดการในรอบแก้บั๊กตามปกติและออกคำแนะนำฉบับเต็มพร้อมเวอร์ชันถัดไป แต่ยังไม่ได้ให้วันหรือหมายเลขเวอร์ชันที่จะแก้ รวมถึงยังไม่แจกแจงเวอร์ชันที่ได้รับผลกระทบและคะแนนความรุนแรงอย่างเป็นทางการ (PHP, The Hacker News)

คะแนน CVSS ซึ่งเป็นระบบให้คะแนนความรุนแรงของช่องโหว่ ที่ PHP ระบุไว้ว่า 9.2 เป็นของสองช่องโหว่ในประกาศเตรียมออกแพตช์ PHP2Shell ก่อนหน้า ไม่ควรนำคะแนนนั้นมาใส่ให้ช่องโหว่ใหม่ แหล่งข่าวที่ให้มายังไม่ได้ระบุคะแนนของ CVE-2026-115560 จึงไม่มีคะแนนสองค่าที่ขัดกันให้เลือกใช้ (PHP, The Hacker News)

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

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

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

เจ้าของเว็บที่ไม่มีทีมไอที

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

1. เว็บของเราเข้าเงื่อนไขเปลี่ยนวิธีจัดเก็บเซสชันระหว่างทำงาน พร้อมเปิดการติดตามอัปโหลดตาม CVE-2026-115560 หรือไม่ และใครเป็นคนตรวจ?
2. ถ้ายังยืนยันไม่ได้หรือเข้าเงื่อนไข ได้ปิดความสามารถนี้จากการตั้งค่าระดับเซิร์ฟเวอร์ และเริ่มกระบวนการ PHP ใหม่ทุกตัวแล้วหรือยัง?
3. ระบบได้แพตช์ PHP2Shell วันที่ 21 ตุลาคมแล้วหรือยัง และใครจะติดตามแพตช์สำหรับช่องโหว่ใหม่?

หลังได้รับคำตอบ ผมเสนอให้เก็บวันที่ดำเนินการ ชื่อผู้รับผิดชอบ และสิ่งที่ต้องทดสอบไว้ในใบงานเดียวกัน ถ้าคำตอบยังมีเพียง “อัปเดตแล้ว” ให้ขอแยกสถานะสองเรื่องตามคำถามข้างต้น เพราะแพตช์ฉุกเฉินเดิมยังไม่แก้ช่องโหว่ใหม่ (The Hacker News)

ผู้ดูแลโฮสติ้งและทีมไอที

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

1. ทำรายการระบบ PHP ที่รับงานเว็บ พร้อมผู้รับผิดชอบและสถานะอัปเดต เพื่อแยกระบบที่ต้องตรวจเงื่อนไขใหม่ออกจากงานแพตช์เดิมให้ติดตามได้ครบ
2. ตรวจรูปแบบการตั้งค่าและโค้ดร่วมกับนักพัฒนา หากต้องใช้มาตรการชั่วคราว ให้ปิดการติดตามความคืบหน้าอัปโหลดจากการตั้งค่าหลักของ PHP กลุ่มกระบวนการ FPM หรือการตั้งค่าเซิร์ฟเวอร์ ตามประกาศ ไม่พึ่งคำสั่งเปลี่ยนค่าในแต่ละสคริปต์หรือการตั้งค่ารายเว็บไซต์ของ FPM
3. เริ่มกระบวนการทำงาน PHP ใหม่ทุกตัว แล้วตรวจยืนยันว่าค่าที่ต้องการมีผลจริง ผมแนะนำให้ทดสอบงานที่เกี่ยวกับการส่งไฟล์ตามขอบเขตใช้งานของเว็บด้วย
4. คงแพตช์ PHP2Shell ไว้ และคงการปิดความสามารถนี้จนมีรุ่นปกติที่แก้ปัญหาใหม่ หากทำมาตรการนี้ครบตั้งแต่วันที่ 21 ตุลาคมและยังคงไว้ PHP ระบุว่าไม่ต้องทำเพิ่มสำหรับช่องโหว่ใหม่นี้

นักพัฒนาเว็บ

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

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

ผมมองว่า…

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

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

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

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

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

Recap

• ส่งคำถามเรื่อง CVE-2026-115560 ให้โฮสติ้งหรือผู้พัฒนาเว็บ
• ขอผลตรวจว่าแอปเปลี่ยนรูปแบบข้อมูลเซสชันระหว่างทำงานหรือไม่
• ตรวจการเปิดความสามารถติดตามความคืบหน้าอัปโหลดร่วมกับเงื่อนไขอื่น
• หากใช้มาตรการชั่วคราว ให้ผู้ดูแลตั้งค่าระดับเซิร์ฟเวอร์ตามประกาศ PHP
• ยืนยันว่าเริ่มกระบวนการ PHP ใหม่ทุกตัวหลังเปลี่ยนการตั้งค่าแล้ว
• แยกสถานะแพตช์ PHP2Shell ออกจากสถานะการลดความเสี่ยงช่องโหว่ใหม่
• เก็บผู้รับผิดชอบ ผลตรวจ และรายการทดสอบงานอัปโหลดไว้ติดตาม
• รอประกาศรุ่นแก้ไขและคำแนะนำฉบับเต็มก่อนทบทวนการเปิดความสามารถกลับ