สารบัญ
คำตอบสั้น: PHP2Shell คือชื่อเรียกช่องโหว่ 2 รายการในแกนหลักของภาษา PHP ได้แก่ CVE-2026-109618 และ CVE-2026-109619 ทั้งคู่ได้คะแนนความรุนแรง CVSS v4.0 ที่ 9.2 (ระดับวิกฤต) ผู้โจมตีสามารถส่งคำขอ (Request) เข้ามาที่เว็บไซต์แล้วสั่งรันโค้ดบนเซิร์ฟเวอร์ได้โดยไม่ต้องล็อกอิน วิธีแก้ที่ได้ผลจริงมีทางเดียวคืออัปเดต PHP เป็นเวอร์ชัน 8.5.12, 8.4.27, 8.3.36 หรือ 8.2.35 ตามสาขาที่ใช้อยู่ แล้วรีสตาร์ตบริการ PHP ทุกตัว
ช่องโหว่นี้ไม่ได้อยู่ในปลั๊กอินหรือธีมตัวใดตัวหนึ่ง แต่อยู่ใน PHP ซึ่งเป็นภาษาที่ขับเคลื่อน WordPress, Drupal, Joomla และเว็บไซต์ธุรกิจจำนวนมากในไทย หากคุณมีเว็บไซต์ที่พัฒนาด้วย PHP หรือเคยใช้บริการรับทำเว็บไซต์ด้วย WordPress บทความนี้จะช่วยให้คุณรู้ว่าต้องเช็กอะไร และต้องทำอะไรต่อ
PHP2Shell คืออะไร และทำไมถึงร้ายแรงกว่าช่องโหว่ทั่วไป
ชื่อ “PHP2Shell” ไม่ได้มาจากทีม PHP แต่เป็นชื่อที่นักวิจัยความปลอดภัยตั้งขึ้น เพื่อสื่อถึงผลลัพธ์ที่เกิดขึ้น คือผู้โจมตีส่งคำขอไปที่เว็บไซต์ แล้วได้สิทธิ์สั่งงาน (Shell) บนเซิร์ฟเวอร์กลับมา
ช่องโหว่ทั้งสองรายการมีลักษณะดังนี้

สิ่งที่ทำให้ PHP2Shell อันตรายเป็นพิเศษมี 3 ข้อ
- ไม่ต้องล็อกอิน ผู้โจมตีไม่จำเป็นต้องมีบัญชีใด ๆ ในระบบ
- กระทบทุกแอปที่รันบน PHP เวอร์ชันที่มีช่องโหว่ ไม่ว่าโค้ดเว็บไซต์จะเขียนมาดีแค่ไหน เพราะปัญหาอยู่ที่ตัวภาษาเอง
- กระทบทุกรูปแบบการติดตั้ง ทั้ง Apache แบบ mod_php, PHP-FPM, php-cgi, FrankenPHP และ LiteSpeed โดยทีม PHP ระบุว่า Apache ที่ใช้ mod_php เป็นรูปแบบที่มีความเสี่ยงสูงที่สุด
ทีมวิจัยของ Wiz ยังยืนยันว่าสามารถรันโค้ดได้จริงบนระบบทดสอบของ WordPress, Drupal และ Joomla รวมถึงอ่านข้อมูลสำคัญที่ค้างอยู่ในหน่วยความจำ เช่น รหัสผ่าน โทเคนยืนยันตัวตน และ API Key ได้
ไทม์ไลน์เหตุการณ์ PHP2Shell (ตุลาคม 2569)

ข้อสังเกตสำคัญคือ การโจมตีเริ่มก่อนที่แพตช์จะออก และหลังจากนั้นไม่ถึงสัปดาห์ก็มีหลักฐานว่าโจมตีสำเร็จจริงแล้ว ดังนั้น PHP2Shell ไม่ใช่ความเสี่ยงในทางทฤษฎีอีกต่อไป
เว็บไซต์ของคุณเสี่ยงไหม? เช็กจากเวอร์ชัน PHP
ทุกเวอร์ชันที่ต่ำกว่าเวอร์ชันในตารางด้านล่างถือว่ามีช่องโหว่

กลุ่มที่น่ากังวลที่สุดคือเว็บที่ยังใช้ PHP 8.1 หรือต่ำกว่า ทีม PHP เผยแพร่เพียงชุดแก้ไขระดับซอร์สโค้ด (Backport) สำหรับ 7.4, 8.0 และ 8.1 เท่านั้น ไม่มีเวอร์ชันสำเร็จรูปให้อัปเดต จากการสำรวจของบริษัท Mallory ในวันที่ 21 ต.ค. พบบริการบนอินเทอร์เน็ตที่แสดงเวอร์ชัน PHP ราว 2.6 ล้านรายการ และประมาณ 73.5% ยังใช้ PHP 8.1 หรือเก่ากว่า
วิธีเช็กเวอร์ชัน PHP สำหรับเจ้าของเว็บที่ไม่ใช่สายเทคนิค
- ผ่านแผงควบคุมโฮสติ้ง เช่น cPanel, Plesk หรือ DirectAdmin มักแสดงเวอร์ชัน PHP ในเมนู “Select PHP Version” หรือ “PHP Settings”
- ผ่านหลังบ้าน WordPress ไปที่ Tools > Site Health > Info > Server จะเห็นเวอร์ชัน PHP ที่เว็บใช้งานจริง
- สอบถามผู้ให้บริการโฮสติ้งหรือทีมดูแลเว็บไซต์ ให้ยืนยันว่าอัปเดตแล้วหรือยัง และเวอร์ชันที่ให้บริการหน้าเว็บจริงคือเวอร์ชันใด
ข้อควรระวัง: คำสั่ง php -v บนเซิร์ฟเวอร์อาจแสดงเวอร์ชันของ PHP แบบ Command Line ซึ่งไม่จำเป็นต้องตรงกับเวอร์ชันที่ให้บริการหน้าเว็บจริง โดยเฉพาะเซิร์ฟเวอร์ที่ติดตั้ง PHP หลายเวอร์ชันพร้อมกัน
วิธีแก้ PHP2Shell ที่ถูกต้อง
1. อัปเดต PHP เป็นเวอร์ชันที่แก้ไขแล้ว
อัปเดตเป็นเวอร์ชันตามสาขาที่ใช้อยู่ (8.5.12, 8.4.27, 8.3.36 หรือ 8.2.35) หากใช้แพ็กเกจจาก Linux Distribution เช่น Ubuntu, Debian หรือ RHEL ให้ติดตั้งอัปเดตความปลอดภัยของ Distribution นั้น ๆ เพราะบางรายนำชุดแก้ไขมาใส่โดยที่เลขเวอร์ชันไม่เปลี่ยน จึงควรตรวจจากประกาศความปลอดภัยของ Distribution แทนการดูเลขเวอร์ชันเพียงอย่างเดียว
2. รีสตาร์ต PHP-FPM หรือเว็บเซิร์ฟเวอร์
ขั้นตอนนี้ถูกลืมบ่อยที่สุด หากไม่รีสตาร์ต PHP-FPM, Apache หรือ LiteSpeed ระบบจะยังรันโค้ดเวอร์ชันเก่าที่ค้างอยู่ในหน่วยความจำ หลังรีสตาร์ตแล้วให้เช็กเวอร์ชันซ้ำอีกครั้งเพื่อยืนยันว่าเวอร์ชันใหม่เป็นตัวที่ให้บริการจริง
3. ถ้ายังใช้ PHP 8.1 หรือต่ำกว่า ให้วางแผนย้ายสาขา
ทางเลือกคือใช้แพ็กเกจที่ Distribution หรือผู้ให้บริการ LTS ทำแพตช์ย้อนหลังไว้ แล้วเร่งย้ายไปสาขาที่ยังได้รับการสนับสนุน ซึ่งมักต้องทดสอบความเข้ากันได้ของธีม ปลั๊กอิน และโค้ดที่เขียนเอง สำหรับระบบที่ยังย้ายไม่ได้ ควรนำออกจากอินเทอร์เน็ตชั่วคราวจนกว่าจะแก้ไขเสร็จ
การอัปเดต WordPress หรือปลั๊กอินไม่ได้ช่วยแก้ PHP2Shell เพราะช่องโหว่อยู่ที่ PHP ไม่ใช่ที่ WordPress ต้องอัปเดต PHP เท่านั้น
ถ้ายังอัปเดตไม่ได้ทันที ควรทำอะไรระหว่างนี้
มาตรการต่อไปนี้ช่วยลดความเสี่ยงได้บางส่วน แต่ทีม PHP ระบุชัดว่า ไม่มีมาตรการใดทำให้ระบบปลอดภัยได้เท่ากับการอัปเดต
- ปิด Session Upload Progress ตั้งค่า
session.upload_progress.enabled = Offใน php.ini ที่เว็บเซิร์ฟเวอร์ใช้งานจริง แล้วรีสตาร์ต Worker ทุกตัว วิธีนี้ปิดเส้นทางโจมตีที่ยืนยันแล้วของ CVE-2026-109619 เท่านั้น ไม่ได้ช่วยป้องกัน CVE-2026-109618 - เปิดใช้ WAF (Web Application Firewall) Cloudflare รายงานว่าพบทราฟฟิกโจมตีก่อนการเปิดเผยช่องโหว่ และได้เพิ่มกฎป้องกัน PHP2Shell ให้ทั้งผู้ใช้ WAF แบบฟรีและแบบเสียเงิน
- จำกัดการเข้าถึงระบบที่ไม่จำเป็นต้องเปิดสาธารณะ เช่น หน้าทดสอบ (Staging) หรือระบบภายในที่วางอยู่บนเซิร์ฟเวอร์เดียวกัน
สัญญาณที่ควรตรวจสอบว่าอาจถูกโจมตีแล้ว
แพตช์ช่วยป้องกันการโจมตีครั้งใหม่ แต่ไม่ได้ลบสิ่งที่ผู้โจมตีอาจทิ้งไว้ก่อนหน้า หากเว็บไซต์ใช้เวอร์ชันที่มีช่องโหว่ตั้งแต่กลางเดือนตุลาคม 2569 ควรตรวจสอบสิ่งเหล่านี้
- กระบวนการ php-fpm, php-cgi หรือ apache2 เรียกใช้ Shell หรือเครื่องมือดาวน์โหลดไฟล์อย่าง curl และ wget
- ไฟล์ PHP แปลกปลอมที่ไม่ได้สร้างเอง โดยเฉพาะในโฟลเดอร์อัปโหลดไฟล์
- บัญชีผู้ดูแลระบบใหม่ที่ไม่รู้ที่มา หรือ Cron Job ที่ไม่ได้ตั้งไว้
- Error Log ที่พบข้อความ
zend_mm_heap corruptedหรือ Apache Worker ล่ม (Segmentation fault, Abort) ผิดปกติ ร่วมกับคำขอแบบ POST ที่ตอบกลับด้วยรหัส 5xx จำนวนมาก
สัญญาณข้อสุดท้ายเป็นเพียงข้อบ่งชี้ที่ต้องตรวจสอบต่อ ไม่ใช่หลักฐานยืนยันว่าถูกเจาะ หากพบความผิดปกติ ควรเปลี่ยนรหัสผ่านฐานข้อมูล, API Key และรหัสผ่านผู้ดูแลระบบทั้งหมด เพราะข้อมูลเหล่านี้อาจถูกอ่านออกไปจากหน่วยความจำแล้ว
คำแนะนำจาก ThaiCERT สำหรับองค์กรไทย
สำนักงานคณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติ (สกมช.) โดย ThaiCERT ออกประกาศแจ้งเตือนเมื่อวันที่ 22 ตุลาคม 2569 และขอให้หน่วยงานและผู้ดูแลระบบที่ใช้ PHP ดำเนินการ 3 ข้อ ได้แก่
- ตรวจสอบความเสี่ยง สำรวจระบบและเวอร์ชัน PHP ที่ใช้งาน โดยเฉพาะระบบที่เปิดให้บริการผ่านอินเทอร์เน็ต
- เร่งแก้ไขช่องโหว่ ติดตั้งแพตช์ความปลอดภัยตามคำแนะนำของผู้พัฒนาโดยเร็ว
- เฝ้าระวังการโจมตี ตรวจความผิดปกติของ Web Server และเตรียมพร้อมรับมือเหตุภัยคุกคาม
แนวทางนี้ใช้ได้กับธุรกิจเอกชนทุกขนาด ไม่ใช่เฉพาะหน่วยงานภาครัฐ
Web Evolve แนะนำ: แพตช์อย่างเดียวไม่พอ ต้องมีระบบดูแลต่อเนื่อง
PHP2Shell สะท้อนปัญหาที่พบบ่อยในเว็บไซต์ธุรกิจไทย คือเว็บถูกสร้างเสร็จแล้วถูกปล่อยไว้หลายปีโดยไม่มีใครดูแลเวอร์ชัน PHP และเซิร์ฟเวอร์ เมื่อเกิดช่องโหว่ระดับนี้ เจ้าของเว็บจึงไม่รู้ด้วยซ้ำว่าเว็บของตัวเองใช้เวอร์ชันอะไร
แนวทางที่ทีม Web Evolve ใช้ดูแลเว็บไซต์ลูกค้าเมื่อเกิดช่องโหว่ระดับวิกฤตมีดังนี้
- ตรวจเวอร์ชันที่ให้บริการจริง ไม่ใช่ดูจากเวอร์ชัน CLI อย่างเดียว เพื่อให้แน่ใจว่าแพตช์มีผลกับหน้าเว็บจริง
- อัปเดตบน Staging ก่อน ทดสอบธีม ปลั๊กอิน และฟังก์ชันสำคัญ เช่น ฟอร์มติดต่อและระบบชำระเงิน แล้วจึงอัปเดตบนเว็บจริง
- วาง Cloudflare เป็นด่านหน้า สำหรับงานด้าน Cyber Security เราแนะนำ Cloudflare เป็นตัวเลือกหลัก เพราะได้ทั้ง WAF, การป้องกัน DDoS และ CDN ในที่เดียว และมักออกกฎป้องกันช่องโหว่ใหม่ได้เร็ว อย่างกรณี PHP2Shell ที่มีกฎป้องกันให้ใช้ตั้งแต่แพ็กเกจฟรี ทางเลือกอื่นที่ใช้ได้ เช่น Sucuri, Wordfence (สำหรับ WordPress) หรือ ModSecurity บนเซิร์ฟเวอร์
- ตรวจหาร่องรอยหลังแพตช์ ไล่ตรวจไฟล์แปลกปลอม บัญชีผู้ดูแลระบบ และ Log ย้อนหลังช่วงที่เว็บยังมีช่องโหว่
สำหรับธุรกิจที่กำลังมองหาบริการรับทำเว็บไซต์ ควรถามผู้ให้บริการตั้งแต่แรกว่ามีบริการดูแลหลังส่งมอบหรือไม่ ใครรับผิดชอบการอัปเดต PHP และเซิร์ฟเวอร์ และจะแจ้งเตือนลูกค้าอย่างไรเมื่อเกิดช่องโหว่ใหม่ เพราะความปลอดภัยของเว็บไซต์ไม่ได้จบในวันที่เว็บเปิดใช้งาน
คำถามที่พบบ่อยเกี่ยวกับ PHP2Shell (FAQ)
PHP2Shell คืออะไร?
PHP2Shell คือชื่อเรียกช่องโหว่ CVE-2026-109618 และ CVE-2026-109619 ในแกนหลักของภาษา PHP ที่ทำให้ผู้โจมตีรันโค้ดบนเซิร์ฟเวอร์ได้โดยไม่ต้องยืนยันตัวตน มีคะแนนความรุนแรง CVSS v4.0 ที่ 9.2
PHP2Shell กระทบ PHP เวอร์ชันไหนบ้าง?
กระทบทุกเวอร์ชันที่ต่ำกว่า 8.5.12, 8.4.27, 8.3.36 และ 8.2.35 รวมถึงสาขาที่หมดอายุแล้ว เช่น 8.1, 8.0 และ 7.x ซึ่งไม่มีเวอร์ชันแก้ไขอย่างเป็นทางการ
เว็บ WordPress ได้รับผลกระทบจาก PHP2Shell ไหม?
ได้รับผลกระทบหากเซิร์ฟเวอร์ใช้ PHP เวอร์ชันที่มีช่องโหว่ เพราะปัญหาอยู่ที่ PHP ไม่ใช่ WordPress การอัปเดต WordPress หรือปลั๊กอินจึงไม่ช่วยแก้ ต้องอัปเดต PHP
อัปเดต PHP แล้วต้องทำอะไรต่อ?
ต้องรีสตาร์ต PHP-FPM หรือเว็บเซิร์ฟเวอร์ แล้วเช็กเวอร์ชันซ้ำว่าเวอร์ชันใหม่เป็นตัวที่ให้บริการจริง จากนั้นตรวจหาร่องรอยการบุกรุกย้อนหลัง และเปลี่ยนรหัสผ่านสำคัญหากพบความผิดปกติ
ปิด session.upload_progress อย่างเดียวพอไหม?
ไม่พอ การปิดค่านี้ช่วยปิดเส้นทางโจมตีของ CVE-2026-109619 เท่านั้น และไม่ได้ป้องกัน CVE-2026-109618 การอัปเดต PHP คือวิธีแก้ที่ได้ผลจริงเพียงวิธีเดียว
PHP2Shell กับ CVE-2024-4577 เป็นช่องโหว่เดียวกันไหม?
ไม่ใช่ CVE-2024-4577 เป็นช่องโหว่ปี 2024 ที่เกิดกับ PHP แบบ CGI บน Windows ส่วน PHP2Shell เป็นช่องโหว่คู่ใหม่ที่เปิดเผยในเดือนตุลาคม 2569 และกระทบ PHP ทุกแพลตฟอร์ม
สรุป
PHP2Shell เป็นช่องโหว่ระดับวิกฤตที่ถูกใช้โจมตีจริงแล้ว และกระทบเว็บไซต์ทุกเว็บที่รันบน PHP เวอร์ชันเก่า สิ่งที่ต้องทำมี 4 ขั้นตอน คือ เช็กเวอร์ชัน PHP ที่ให้บริการจริง, อัปเดตเป็นเวอร์ชันที่แก้ไขแล้ว, รีสตาร์ตบริการ และตรวจหาร่องรอยการบุกรุก ส่วนเว็บที่ยังใช้ PHP 8.1 หรือต่ำกว่า ควรวางแผนย้ายสาขาโดยเร็ว
หากไม่แน่ใจว่าเว็บไซต์ของคุณปลอดภัยแล้วหรือยัง ทีม Web Evolve พร้อมช่วยตรวจเวอร์ชัน PHP วางระบบ Cloudflare และดูแลเว็บไซต์อย่างต่อเนื่อง ทั้งสำหรับลูกค้าเดิมและเว็บไซต์ที่พัฒนาโดยผู้ให้บริการรายอื่น ติดต่อทีมงานได้ทาง LINE Official หรือหน้าติดต่อบนเว็บไซต์ webevolve.co.th
แหล่งอ้างอิง
- PHP Security Advisory: Critical remote code execution vulnerabilities, update now (php.net, 21 ต.ค. 2569)
- GitHub Security Advisories: GHSA-w8hw-w9fx-j79w (CVE-2026-109618) และ GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
- ThaiCERT: แจ้งเตือน พบช่องโหว่ PHP2Shell (22 ต.ค. 2569)
- ฐานเศรษฐกิจ: “ภราดร” สั่ง สกมช. รับมือด่วน ช่องโหว่ไซเบอร์วิกฤต “PHP2Shell” (22 ต.ค. 2569) และ ThaiCERT ระดมสมองรับมือช่องโหว่ PHP2Shell (30 ต.ค. 2569)
- Pentest-Tools.com: PHP2Shell – what it is, how to detect, how to patch
- CERT-EU Security Advisory 2026-018
- BleepingComputer: CISA confirms PHP2Shell vulnerabilities now exploited in attacks (27 ต.ค. 2569)
- Cloudflare Blog: PHP vulnerabilities WAF protection
- iThome: รายงานผลการทดสอบของ Wiz บน WordPress, Drupal และ Joomla
