PHP2Shell คืออะไร? สรุปเหตุการณ์ช่องโหว่ PHP ครั้งใหญ่ ตุลาคม 2026

PHP2Shell คืออะไร? สรุปเหตุการณ์ช่องโหว่ PHP ครั้งใหญ่ ตุลาคม 2026

PHP2Shell คืออะไร

PHP2Shell คือชื่อเรียกช่องโหว่ร้ายแรง 2 ตัวในแกนหลักของภาษา PHP ได้แก่ CVE-2026-109618 และ CVE-2026-109619 ซึ่งเปิดให้ผู้โจมตีสั่งรันโค้ดบนเซิร์ฟเวอร์ได้จากระยะไกล (Remote Code Execution) โดยไม่ต้องล็อกอิน ทั้งสองตัวได้คะแนนความรุนแรง CVSS 9.2 จาก 10 (The Hacker News) และ PHP ออกแพตช์แก้ไขแล้วเมื่อ 21 ตุลาคม 2026

เหตุที่เรื่องนี้ใหญ่ เพราะปัญหาอยู่ที่ตัว PHP เอง ไม่ใช่ปลั๊กอินหรือธีม เว็บไซต์ WordPress, Joomla, Drupal, Magento รวมถึงแผงควบคุมอย่าง cPanel และ Plesk ล้วนทำงานบน PHP จึงอยู่ในข่ายเสี่ยงทั้งหมดหากเซิร์ฟเวอร์ยังใช้เวอร์ชันเก่า (ITdaily)

ช่องโหว่นี้ถูกค้นพบโดยทีมวิจัยจาก Calif, OpenAI และ Wiz (The Hacker News) แต่ละตัวมีลักษณะต่างกันเล็กน้อย

ช่องโหว่นี้ถูกค้นพบโดยทีมวิจัยจาก Calif, OpenAI และ Wiz (The Hacker News) แต่ละตัวมีลักษณะต่างกันเล็กน้อย

ที่มา: watchTowr

สรุปเหตุการณ์ PHP2Shell ปลายเดือนตุลาคม 2026

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

เว็บไซต์แบบไหนได้รับผลกระทบ

ตัวเลขที่สะท้อนขนาดของเหตุการณ์ได้ดีคือ ห้องแล็บ Threat Intelligence ของมหาวิทยาลัย Delft ติดตามคำขอโจมตีได้มากกว่า 50,000 ครั้ง จากกว่า 600 IP ใน 70 ประเทศ (The Register)

ข้อควรระวังในการอ่านข่าว: รายงานบางชิ้นในช่วงแรกเร็วเกินไป เช่น Unit 42 ถอนรายงานวันที่ 23 ต.ค. ที่โยงการเจาะหน่วยงานรัฐในยุโรปกับ PHP2Shell ไปเมื่อ 26 ต.ค. (SOCRadar) จึงควรยึดข้อมูลจากแหล่งต้นทางอย่าง php.net, CISA และบริษัทความปลอดภัยที่เผยแพร่หลักฐาน

เว็บไซต์แบบไหนได้รับผลกระทบ

เว็บไซต์ใดก็ตามที่เซิร์ฟเวอร์ยังรัน PHP เวอร์ชันก่อนแพตช์ถือว่าเสี่ยง ไม่ว่าจะสร้างด้วย WordPress หรือเขียนเองทั้งหมด การอัปเดต WordPress หรือปลั๊กอินไม่ได้แก้ PHP2Shell สิ่งที่ต้องอัปเดตคือตัว PHP บนเซิร์ฟเวอร์ (Pentest-Tools.com)

สรุปเหตุการณ์ PHP2Shell ปลายเดือนตุลาคม 2026

ข้อมูลเวอร์ชัน: SOCRadar, The Hacker News, martincid.com

กลุ่มที่ต้องระวังเป็นพิเศษ

  • เว็บบน Shared Hosting เจ้าของเว็บอัปเดต PHP เองไม่ได้ ต้องรอผู้ให้บริการโฮสติ้ง ในวันที่แพตช์ออก มีเว็บที่ mySites.guru ติดตามอยู่เพียง 0.08% ที่แสดงเวอร์ชันที่แก้ไขแล้ว ณ 13:52 UTC (martincid.com)
  • เว็บที่ยังใช้ PHP 7.4 หรือ 8.1 เพราะสาขาเหล่านี้ไม่ได้รับแพตช์จาก PHP อีกแล้ว
  • เซิร์ฟเวอร์ VPS ที่ไม่มีคนดูแลประจำ เพราะการโจมตีเริ่มภายในไม่กี่ชั่วโมงหลังข้อมูลเผยแพร่

วิธีตรวจสอบและป้องกัน PHP2Shell

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

  1. ตรวจเวอร์ชัน PHP ที่เว็บใช้งานจริง ไม่ใช่เวอร์ชันจากคำสั่ง php -v ในเทอร์มินัล เพราะเซิร์ฟเวอร์หนึ่งเครื่องอาจมี PHP หลายชุด ให้ตรวจจาก PHP-FPM หรือ mod_php ที่ให้บริการหน้าเว็บ หรือดูที่ Tools > Site Health ใน WordPress
  2. อัปเดต PHP ให้ตรงสาขา ใช้เวอร์ชันตามตารางด้านบน บน cPanel มี PHP อยู่ 3 ชุดที่ต้องดูแยกกัน คือ ea-php ของ EasyApache, alt-php ของ CloudLinux และ PHP ภายในของ cPanel เอง (ComputingForGeeks)
  3. อย่าดูแค่เลขเวอร์ชัน Debian, Ubuntu และระบบลักษณะเดียวกันจะ backport แพตช์เข้าเวอร์ชันเดิม เลขเวอร์ชันจึงอาจดูเก่าทั้งที่แก้แล้ว ให้ตรวจ changelog ของแพ็กเกจว่ามี CVE นี้หรือไม่ (The Hacker News)
  4. รีสตาร์ต Apache, PHP-FPM และ worker ทุกตัว หลังอัปเดต ไม่เช่นนั้นโปรเซสเดิมยังทำงานด้วยโค้ดเก่า (martincid.com)
  5. ตรวจร่องรอยการถูกเจาะ เพราะการโจมตีเริ่มก่อนแพตช์ ให้ไล่ดูไฟล์ .php แปลกปลอมในโฟลเดอร์ uploads, cron job ที่ไม่รู้จัก, บัญชีผู้ดูแลที่ไม่ได้สร้าง และ log ที่มี Segmentation fault หรือ zend_mm_heap corrupted ซึ่งเป็นสัญญาณต้องสงสัย ไม่ใช่หลักฐานยืนยัน (GitHub: php2shell)

มาตรการชั่วคราวระหว่างรออัปเดต

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

  • ปิด session.upload_progress.enabled = 0 ซึ่ง PHP เองแนะนำไว้ในประกาศของ CVE-2026-109619 (Computing) ผลข้างเคียงมีเพียงแถบแสดงความคืบหน้าการอัปโหลดไม่ทำงาน
  • เปิด WAF เช่น Cloudflare ที่ออกกฎฉุกเฉินแล้ว แต่ Cloudflare เองระบุว่าเป็นเพียงทางเลี่ยงชั่วคราว (The Hacker News)
  • ถ้าใช้ Shared Hosting ให้เปิดทิกเก็ตสอบถามผู้ให้บริการว่าอัปเดต PHP แล้วหรือยัง และขอเวอร์ชันที่ยืนยันได้

บทเรียนจาก PHP2Shell สำหรับเจ้าของเว็บไซต์

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

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

  • ทำบัญชีรายการเว็บไซต์ ระบุโฮสติ้ง เวอร์ชัน PHP และผู้รับผิดชอบของแต่ละเว็บ เมื่อมีช่องโหว่ใหม่จะตอบได้ทันทีว่าเว็บไหนเสี่ยง
  • ใช้ PHP สาขาที่ยังได้รับซัพพอร์ต ปัจจุบันคือ 8.3 ขึ้นไป และวางแผนย้ายเว็บที่ยังอยู่บน 8.2 ก่อนสิ้นปี 2026
  • เลือกโฮสติ้งที่อัปเดตเร็วและแจ้งสถานะชัดเจน เพราะเจ้าของเว็บบน Shared Hosting แก้ปัญหาระดับ PHP เองไม่ได้
  • มีแบ็กอัปที่กู้คืนได้จริงและแยกจากเซิร์ฟเวอร์หลัก เพื่อรับมือกรณีเว็บถูกเจาะก่อนแพตช์

เมื่อเลือกผู้ให้บริการรับทำเว็บไซต์ ควรถามด้วยว่ามีแผนดูแลความปลอดภัยหลังส่งมอบหรือไม่ เพราะเว็บที่ออกแบบดีแต่ไม่มีใครอัปเดตเซิร์ฟเวอร์ ก็เป็นเป้าหมายได้ง่ายในเหตุการณ์แบบ PHP2Shell

คำถามที่พบบ่อยเกี่ยวกับ PHP2Shell

PHP2Shell อันตรายแค่ไหน

อันตรายระดับวิกฤต ผู้โจมตีสามารถรันคำสั่งบนเซิร์ฟเวอร์ได้โดยไม่ต้องล็อกอิน และมีการยืนยันแล้วว่าถูกใช้โจมตีจริง CISA บรรจุทั้งสอง CVE ในรายการ KEV เมื่อ 26 ตุลาคม 2026

เว็บ WordPress ได้รับผลกระทบจาก PHP2Shell ไหม

ได้รับผลกระทบ หากเซิร์ฟเวอร์ใช้ PHP เวอร์ชันก่อนแพตช์ การอัปเดต WordPress หรือปลั๊กอินไม่ช่วย ต้องอัปเดต PHP บนเซิร์ฟเวอร์

PHP เวอร์ชันไหนปลอดภัยจาก PHP2Shell

PHP 8.5.12, 8.4.27, 8.3.36 และ 8.2.35 ขึ้นไป หรือแพ็กเกจของ Linux distribution ที่ระบุใน changelog ว่าแก้ CVE-2026-109618 และ CVE-2026-109619 แล้ว

ปิด session.upload_progress อย่างเดียวพอไหม

ไม่พอ เป็นเพียงมาตรการชั่วคราวเพื่อลดความเสี่ยงระหว่างรออัปเดต ทีมพัฒนา PHP ยืนยันว่าการอัปเดต PHP คือทางแก้เดียวที่สมบูรณ์

ใช้ Shared Hosting ต้องทำอย่างไร

ติดต่อผู้ให้บริการโฮสติ้งเพื่อยืนยันว่าอัปเดต PHP แล้ว ตรวจเวอร์ชันจากหน้า Site Health ของ WordPress หรือแผงควบคุม และเปลี่ยนไปใช้สาขา PHP ที่ยังได้รับซัพพอร์ตผ่านเมนู MultiPHP หรือ PHP Selector

อัปเดตแล้วต้องทำอะไรต่อ

รีสตาร์ตบริการ PHP และเว็บเซิร์ฟเวอร์ จากนั้นตรวจหาไฟล์และบัญชีแปลกปลอม เปลี่ยนรหัสผ่านสำคัญ เพราะเว็บอาจถูกเจาะไปแล้วก่อนอัปเดต

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

ข้อมูลในบทความอัปเดต ณ วันที่ 3 พฤศจิกายน 2026 สถานการณ์ด้านความปลอดภัยอาจเปลี่ยนแปลง ควรตรวจสอบประกาศล่าสุดจาก php.net ก่อนดำเนินการ

เราใช้คุกกี้เพื่อเพิ่มประสิทธิภาพ และประสบการณ์ที่ดีในการใช้งานเว็บไซต์ กด "MORE INFO" เพื่ออ่านเพิ่มเติม หรือกด "ACCEPT" เพื่อยอมรับข้อตกลงในการเก็บข้อมูล