แจ้งเตือน PHP2Shell: ช่องโหว่ร้ายแรงใน PHP ผู้ดูแลเว็บไซต์ควรอัปเดตทันที

เมื่อวันที่ 21 ตุลาคม 2026 ทีมพัฒนา PHP ออกแพตช์ฉุกเฉินปิดช่องโหว่ระดับ Critical สองตัวที่วงการตั้งชื่อเล่นว่า PHP2Shell ช่องโหว่นี้ทำให้คนร้ายส่ง request ธรรมดาเข้ามาที่เว็บ แล้วรันโค้ดบนเซิร์ฟเวอร์ได้โดยไม่ต้องล็อกอิน

เรื่องนี้ไม่ได้กระทบแค่ WordPress ทุกระบบที่ทำงานบน PHP โดนเหมือนกันหมด ถ้าเว็บของคุณอยู่บนโฮสติ้งทั่วไป ให้ถือว่าเรื่องนี้เกี่ยวกับคุณ

ถ้าไม่แน่ใจว่าเว็บของคุณใช้ PHP หรือไม่ ให้ดูว่าโฮสติ้งมีเมนูเลือกเวอร์ชัน PHP ไหม ถ้ามี เว็บของคุณเกือบทั้งหมดใช้ PHP

สรุปสั้นสำหรับเจ้าของเว็บ

• อัปเดต WordPress อย่างเดียวไม่ช่วย ช่องโหว่อยู่ในตัว PHP ที่ติดตั้งบนเซิร์ฟเวอร์ ต้องอัปเดตผ่านหน้าจัดการโฮสติ้ง หรือให้ผู้ให้บริการโฮสติ้งอัปเดตให้
• เวอร์ชันที่แก้แล้ว: PHP 8.5.12, 8.4.27, 8.3.36 และ 8.2.35
• PHP 8.1 หรือต่ำกว่า ไม่ได้รับแพตช์ทางการแล้ว ต้องย้ายขึ้นไปใช้เวอร์ชันข้างบน
• ทีม PHP ระบุชัดว่า ไม่มีวิธีบรรเทาไหนที่ปิดได้ครบ การอัปเดตคือทางเดียวที่ปลอดภัย

PHP2Shell คืออะไร

PHP2Shell คือชื่อเรียกรวมของช่องโหว่สองตัว

ทั้งสองตัวจบที่ผลเดียวกันคือ คนร้ายสามารถรันโค้ดของตัวเองบนเซิร์ฟเวอร์ได้ (Remote Code Execution) และรายงานบางแหล่งระบุว่าตัวที่สองยังทำให้ข้อมูลในหน่วยความจำ รวมถึงรหัสผ่าน รั่วออกมาได้ด้วย

ทำไมถึงร้ายแรงกว่าช่องโหว่ทั่วไป

ช่องโหว่ส่วนใหญ่ที่เจอใน WordPress อยู่ในปลั๊กอินตัวใดตัวหนึ่ง ถ้าไม่ได้ใช้ปลั๊กอินนั้นก็ไม่โดน แต่ PHP2Shell อยู่ในขั้นตอนที่ PHP อ่าน request เข้ามา ซึ่งเกิดขึ้นก่อนที่โค้ดของเว็บจะเริ่มทำงาน

แปลว่าเว็บจะเป็น WordPress, Joomla, Moodle, เว็บร้านค้า หรือหน้า Hello World เปล่า ๆ ก็มีความเสี่ยงเหมือนกัน ธีมดีแค่ไหน ปลั๊กอินความปลอดภัยดีแค่ไหน ก็กันไม่ได้ เพราะมันพังก่อนปลั๊กอินจะได้ทำงาน

กลไกแบบเข้าใจง่าย

PHP ให้แต่ละ request ใช้หน่วยความจำได้ไม่เกินโควตาที่ตั้งไว้ (ค่า memory_limit ปกติคือ 128MB) เมื่อ request ไหนใช้เกิน โค้ดเดิมของ PHP จะ “กระโดดออก” จากงานทันที โดยไม่เก็บกวาดสิ่งที่ทำค้างไว้

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

ส่วนวิธีทำให้หน่วยความจำเต็มตรงจังหวะก็ไม่ยาก แค่ส่งฟอร์มแบบ multipart (แบบที่ใช้อัปโหลดไฟล์) ที่ยัด header มาจำนวนมาก

ใครเสี่ยงมากที่สุด

จากการวิเคราะห์ที่เผยแพร่หลังออกแพตช์

• Apache + mod_php เสี่ยงที่สุด มีการยืนยันว่ายิงสำเร็จผ่าน HTTP ได้ด้วยค่าตั้งค่าเริ่มต้น
• PHP-FPM และ LiteSpeed (ที่โฮสติ้งส่วนใหญ่ใช้) โจมตียากกว่า แต่ “ยังไม่มีคนสาธิตให้ดู” ไม่ได้แปลว่าปลอดภัย ควรอัปเดตเหมือนกัน
• FrankenPHP ผลวิเคราะห์ซอร์สโค้ดบอกว่ามีแนวโน้มโดนแบบเดียวกับ mod_php

ไทม์ไลน์ที่วุ่นวายกว่าปกติ

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

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

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

สิ่งที่เจ้าของเว็บไซต์ควรทำทันที

1. เช็กเวอร์ชัน PHP ของเว็บ

สำหรับเว็บ WordPress ทำได้จากหลังบ้านเลย

1. เข้าเมนู เครื่องมือ (Tools) › สุขภาพเว็บไซต์ (Site Health)
2. คลิกแท็บ ข้อมูล (Info)
3. เปิดหัวข้อ เซิร์ฟเวอร์ (Server) แล้วดูบรรทัด PHP version

ระบบอื่นเช็กได้จากหลังบ้านเช่นกัน

• Joomla: ระบบ (System) › ข้อมูลระบบ (System Information) ดูบรรทัด PHP Version
• Moodle: การดูแลระบบเว็บไซต์ (Site administration) › เซิร์ฟเวอร์ (Server) › ข้อมูล PHP (PHP info)
• Drupal: รายงาน (Reports) › รายงานสถานะ (Status report)
• ระบบอื่นหรือไม่แน่ใจ: ดูที่หน้าเลือกเวอร์ชัน PHP ในแผงควบคุมโฮสติ้ง หรือถามผู้ให้บริการโฮสติ้ง

ถ้าเลขที่เห็นต่ำกว่า 8.5.12, 8.4.27, 8.3.36 หรือ 8.2.35 ในสายเดียวกัน แปลว่ายังไม่ได้แพตช์

สำหรับคนที่เข้าเซิร์ฟเวอร์เองได้ ระวังเรื่องหนึ่ง คำสั่ง php -v บอกเวอร์ชันของ PHP ฝั่งคอมมานด์ไลน์ ซึ่งอาจไม่ใช่ตัวเดียวกับที่เว็บใช้จริง ให้ดูจาก Site Health หรือหน้าตั้งค่า PHP ในแผงควบคุมโฮสติ้งแทน

2. สำรองเว็บไซต์และฐานข้อมูลก่อนอัปเดต

โดยเฉพาะคนที่ต้องขยับจาก PHP 8.1 ขึ้นไป 8.2 หรือสูงกว่า ปลั๊กอินหรือธีมเก่าบางตัวอาจทำงานไม่ได้ ถ้ามีแบ็กอัปไว้ จะย้อนกลับได้ทันที อ่านวิธีวางระบบแบ็กอัปได้ที่ คู่มือสำรองข้อมูลและความปลอดภัย WordPress

3. อัปเดต PHP เป็นเวอร์ชันที่แก้แล้ว

• โฮสติ้งทั่วไป (shared hosting): เข้าแผงควบคุม เช่น hPanel, cPanel, Plesk หาเมนู PHP Configuration หรือ Select PHP Version ถ้ายังไม่มีเวอร์ชันที่แก้แล้วให้เลือก ให้ส่งข้อความถามผู้ให้บริการว่าจะอัปเดตเมื่อไร
• ดูแลเซิร์ฟเวอร์เอง (VPS): อัปเดตแพ็กเกจจากดิสโทรหรือ repository ที่ใช้ แล้วรีสตาร์ต PHP-FPM / Apache ทุกตัว เพราะ worker ที่รันค้างอยู่ยังใช้โค้ดเก่าในหน่วยความจำ
• ใช้ PHP 8.1 หรือต่ำกว่า: ต้องย้ายเวอร์ชัน ส่วน PHP 8.2 เองจะหมดระยะแพตช์ความปลอดภัยวันที่ 31 ธันวาคม 2026 ถ้าต้องย้ายอยู่แล้ว แนะนำให้ไป 8.3 หรือ 8.4 เลย

4. ตรวจเว็บหลังอัปเดต

การอัปเดตกันการโจมตีครั้งใหม่ได้ แต่ไม่ได้ไล่คนที่เข้ามาแล้วออกไป ให้เช็กอย่างน้อย

• มีผู้ใช้ระดับ ผู้ดูแลระบบ (Administrator) ที่ไม่รู้จักหรือไม่
• มีไฟล์ PHP แปลก ๆ หรือไฟล์ที่ถูกแก้ไขช่วงไม่กี่วันนี้หรือไม่
• มี Cron Job หรืองานตั้งเวลาที่ไม่ได้สร้างเองหรือไม่

ถ้าเจอสัญญาณผิดปกติ อย่าแค่ลบทิ้งทีละไฟล์ ให้กู้จากแบ็กอัปก่อนเกิดเหตุ แล้วเปลี่ยนรหัสผ่านทุกอย่าง ทั้ง WordPress, ฐานข้อมูล และบัญชีโฮสติ้ง

ถ้ายังอัปเดตไม่ได้ทันที

สำหรับผู้ดูแลเซิร์ฟเวอร์เองที่ต้องรอหน้าต่างอัปเดต มีมาตรการชั่วคราวที่ลดความเสี่ยงได้บางส่วน แต่ไม่ได้ปิดช่องโหว่ครบ

• ตั้ง session.upload_progress.enabled = 0 ใน php.ini หรือ pool ของ FPM (ตั้งผ่าน ini_set() หรือ .user.ini ไม่ได้ผล)
• ตั้ง memory_limit = -1 ในจุดที่แอปแก้ทับไม่ได้ แล้วคุม post_max_size ให้ต่ำ (8M ถ้าไม่มีอัปโหลด หรือ 32M ถ้ามี) พร้อมจำกัดหน่วยความจำระดับ container หรือ cgroup เพราะค่านี้ทำให้ request เดียวกิน RAM ได้ไม่จำกัด
• จำกัดขนาด request จำนวน header และจำนวนชิ้นของ multipart ที่ web server หรือ proxy
• รีสตาร์ต worker ทุกตัวหลังเปลี่ยนค่า

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

ส่วนคนที่ใช้ shared hosting ตั้งค่าพวกนี้เองไม่ได้ ทางที่ใช่คือติดต่อโฮสติ้งให้อัปเดตเร็วที่สุด

เว็บเก่าที่ไม่มีใครดูแล คือความเสี่ยงที่แท้จริง

เหตุการณ์แบบนี้ทำให้เห็นปัญหาที่เราเจอบ่อยมากในเว็บธุรกิจ คือเว็บที่ทำไว้หลายปี ไม่มีใครอัปเดต PHP ค้างอยู่ 7.x หรือ 8.0 ธีมเก่าที่ไม่รองรับ PHP ใหม่ จนพอถึงเวลาต้องอัปเดตจริง กดแล้วเว็บพัง เลยต้องปล่อยค้างไว้ในเวอร์ชันที่ไม่มีแพตช์

นี่คือจังหวะที่ดีที่จะตัดสินใจว่าเว็บเก่าควร “ซ่อมต่อ” หรือ “ย้ายบ้านใหม่”

• ถ้าเว็บยังใช้งานได้ดี ทีม Southern Whale ช่วยอัปเดต PHP ทดสอบปลั๊กอิน และแก้จุดที่ไม่รองรับให้ได้
• ถ้าเว็บเก่าเกินจะซ่อม เราช่วยย้ายเว็บไซต์มาสู่ระบบใหม่ที่ดูแลง่าย อัปเดตสม่ำเสมอ โดยเก็บ URL และอันดับ SEO เดิมไว้ให้ครบ
• เว็บที่เราดูแล เราเช็กเวอร์ชันและแพตช์ให้ตามรอบ เจ้าของธุรกิจไม่ต้องคอยตามข่าวช่องโหว่เอง

ไม่แน่ใจว่าเว็บของคุณใช้ PHP เวอร์ชันไหน หรือเสี่ยงแค่ไหน ขอตรวจเว็บฟรีได้เลย เราจะบอกให้ว่าต้องทำอะไรบ้าง

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

• PHP Security Release ประกาศทางการ: php.net
• Help Net Security: PHP2Shell critical PHP vulnerabilities patched
• Patchstack: PHP vulnerable to critical RCE
• DEV Community: Risk by SAPI and stopgaps