ช่องโหว่ PHP2Shell คืออะไร? เว็บ WordPress ต้องอัปเดต PHP ยังไง

ช่องโหว่ PHP ที่ชื่อ PHP2Shell (CVE-2026-109618 และ CVE-2026-109619) เป็นบั๊กในตัว PHP Engine เอง เปิดทางให้ผู้โจมตีรันโค้ดบนเซิร์ฟเวอร์ได้โดยไม่ต้องล็อกอิน กระทบเว็บ WordPress, Drupal, Joomla และเว็บ PHP แทบทุกเว็บ วิธีแก้มีทางเดียวที่ครบคืออัปเดตเป็น PHP 8.2.35, 8.3.36, 8.4.27 หรือ 8.5.12 ขึ้นไป

ข่าวนี้ออกมาเมื่อ 21 ตุลาคม 2026 และกระจายในกลุ่มนักพัฒนาไทยเร็วมาก (เพจ devhub.in.th สรุปไว้เป็นภาษาไทยตั้งแต่วันแรก) บทความนี้รวบรวมจากแหล่งต้นทางโดยตรง ทั้งประกาศของทีม PHP, รายงานของ Wiz ที่ค้นพบช่องโหว่ และประกาศของ Cloudflare แล้วเรียบเรียงใหม่สำหรับเจ้าของเว็บ WordPress ที่อยากรู้ว่า “แล้วเว็บเราต้องทำอะไร” มากกว่ารายละเอียดเชิงลึกของ exploit

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

PHP2Shell คืออะไร สรุปแบบเข้าใจง่าย

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

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

จุดที่ทำให้เคสนี้หนักคือ Wiz ระบุว่า ช่องโหว่อยู่ในตัว PHP โดยไม่ขึ้นกับแอปที่รันอยู่ข้างบน แม้แต่โปรแกรม “Hello World” ธรรมดาที่รันบน PHP เวอร์ชันที่มีปัญหาก็โดนได้ และทีมวิจัยสาธิตการโจมตีโดยไม่ต้องล็อกอินกับ WordPress, Drupal และ Joomla รุ่นล่าสุดได้สำเร็จ

สองช่องโหว่ ต่างกันยังไง

ตาม ประกาศความปลอดภัยของ PHP ช่องโหว่ถูกรวมไว้ใต้ CVE สองรายการ

ทั้งสองรายการได้คะแนนความรุนแรง CVSS v4.0 ที่ 9.2 จาก 10 (ระดับ Critical) ตามที่ ทีม PHP ระบุใน GitHub Security Advisory ช่วงแรกที่ข่าวหลุดมีคนพูดถึงคะแนน 10.0 แต่ตัวเลขทางการคือ 9.2

เว็บแบบไหนโดนบ้าง

ประกาศของ PHP ใช้คำว่าเสี่ยงคือ “PHP ทุกตัวที่ให้บริการคำขอเว็บ” ครอบคลุมการรันทุกรูปแบบที่เว็บทั่วไปใช้

• PHP-FPM ที่ใช้คู่กับ Nginx หรือ Apache บน VPS ส่วนใหญ่
• Apache + mod_php ทีม PHP มองว่าเสี่ยงสูงสุด เพราะมี exploit ที่สาธิตแล้วว่าคำขอเดียวที่ไม่ต้องล็อกอินก็เริ่มโจมตีได้ก่อนโค้ดของเว็บจะทำงานด้วยซ้ำ
• LiteSpeed ที่โฮสติ้งหลายเจ้าในไทยและต่างประเทศใช้
• php-cgi และ FrankenPHP

ส่วนเรื่องเวอร์ชัน Wiz ระบุว่า PHP ทุกเวอร์ชันในรอบสิบปีที่ผ่านมาโดนอย่างน้อยหนึ่งช่องโหว่ ย้อนไปถึง PHP 5.4 แปลว่าเว็บเก่าที่ไม่เคยอัปเดต PHP มานานคือกลุ่มที่น่าห่วงที่สุด

เวอร์ชันที่แก้แล้ว

มีจุดหนึ่งที่ต้องระวัง Linux distribution อย่าง Debian หรือ Ubuntu ได้รับแพตช์ล่วงหน้า และมักนำการแก้ไขไปใส่ในแพ็กเกจที่เลขเวอร์ชันยังดูเก่ากว่า 8.3.36 ได้ The Hacker News อ้างคำแนะนำของ Debian ว่าให้ดูใน changelog ของแพ็กเกจว่ามีเลข CVE นี้หรือยัง แทนการดูเลขเวอร์ชันอย่างเดียว ในทางกลับกัน โฮสติ้งบางเจ้าก็อาจแพตช์ PHP ที่ตัวเองคอมไพล์เองแล้วโดยเลขยังเหมือนเดิม วิธีที่ชัวร์ที่สุดจึงเป็นการถามผู้ให้บริการตรงๆ

ตอนนี้มีคนโจมตีจริงหรือยัง

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

ด้าน Cloudflare ประกาศว่า เปิดกฎ WAF ป้องกันเส้นทางโจมตีที่รู้แล้วตั้งแต่ 03:02 น. UTC ของวันที่ 21 ตุลาคม ให้ลูกค้าทุกแพ็กเกจรวมถึงแพ็กเกจฟรี และระบุว่าเห็นทราฟฟิกโจมตีที่พุ่งเป้ามายังลูกค้าแล้ว พร้อมเห็นผู้โจมตีพยายามดัดแปลง payload เพื่อหลบกฎ

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

WAF ช่วยซื้อเวลาได้ แต่ไม่ได้ปิดช่องโหว่ ทาง Cloudflare เองก็ย้ำว่ายังต้องอัปเดต PHP อยู่ดี

เช็กเวอร์ชัน PHP ของเว็บ WordPress ยังไง

ไม่ต้องเข้าเซิร์ฟเวอร์ก็ดูได้จากหลังบ้าน WordPress

1. ล็อกอินเข้า wp-admin
2. ไปที่เมนู เครื่องมือ → สุขภาพเว็บ (Tools → Site Health)
3. กดแท็บ ข้อมูล (Info)
4. เปิดหัวข้อ เซิร์ฟเวอร์ แล้วดูบรรทัด รุ่นของ PHP และ PHP SAPI

บรรทัด PHP SAPI บอกว่าเว็บรัน PHP แบบไหน เช่น fpm-fcgi, apache2handler (คือ mod_php) หรือ litespeed ข้อมูลนี้มีประโยชน์ตอนคุยกับโฮสติ้ง และช่วยประเมินว่าเสี่ยงมากน้อยแค่ไหน

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

เจ้าของเว็บแต่ละแบบต้องทำอะไร

ใช้ Shared Hosting หรือ Managed WordPress

กลุ่มนี้คือเว็บธุรกิจส่วนใหญ่ PHP เป็นของผู้ให้บริการ เราอัปเดตตัว PHP เองไม่ได้ สิ่งที่ทำได้คือ

• ส่งข้อความถามโฮสติ้งตรงๆ ว่าแพตช์ CVE-2026-109618 และ CVE-2026-109619 แล้วหรือยัง สำหรับ PHP ทุกเวอร์ชันที่ให้เลือกในแผงควบคุม
• เลือกเวอร์ชันที่ยังได้รับการดูแล ถ้าเว็บยังอยู่บน PHP 7.x หรือ 8.0/8.1 ให้ถือโอกาสย้ายขึ้น 8.3 หรือ 8.4 แต่ต้องสำรองเว็บและทดสอบก่อน เพราะปลั๊กอินเก่าบางตัวอาจพังเมื่อเปลี่ยนเวอร์ชันใหญ่
• เช็กซ้ำหลังโฮสต์ตอบ ว่าเลขเวอร์ชันใน Site Health ขยับแล้ว หรือได้คำยืนยันเป็นลายลักษณ์อักษรว่าแพตช์แบบ backport แล้ว

ใช้ VPS หรือดูแลเซิร์ฟเวอร์เอง

• อัปเดตแพ็กเกจ PHP ผ่าน package manager ของ distribution ที่ใช้ แล้วตรวจ changelog ว่ามีเลข CVE ทั้งสองตัว
• รีสตาร์ต PHP-FPM, Apache หรือ LiteSpeed ทุกตัว หลังอัปเดต ถ้า worker เก่ายังรันอยู่ โค้ดเก่าก็ยังทำงานอยู่ในหน่วยความจำ
• ถ้าใช้ repository ของ rpms.remirepo.net ประกาศของ PHP แจ้งว่า repo นี้ยังไม่มีอัปเดตในวันที่ปล่อยแพตช์ และแนะนำให้เปลี่ยนไปใช้แพ็กเกจของ distribution หรือคอมไพล์จากซอร์ส
• ถ้าใช้ Docker ให้ pull image PHP เวอร์ชันใหม่แล้ว rebuild คอนเทนเนอร์ ไม่ใช่แค่ restart

มี Cloudflare หรือ WAF อยู่หน้าเว็บ

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

ถ้ายังอัปเดตไม่ได้ทันที ลดความเสี่ยงชั่วคราวยังไง

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

สำหรับ CVE-2026-109618

• ตั้ง memory_limit=-1 ในระดับที่แอปเขียนทับไม่ได้ เช่น php_admin_value ใน pool ของ FPM หรือคอนฟิกของ Apache และตรวจว่าไม่มีที่ไหนกำหนดค่าจำกัดกลับมา ข้อนี้สวนทางกับที่เราคุ้นเคย เพราะปกติเราจะ เพิ่ม PHP memory limit เป็นตัวเลข แต่ในเคสนี้จุดประสงค์คือตัดเงื่อนไขที่ผู้โจมตีสั่งให้หน่วยความจำเต็มได้ จึงต้องมีขอบเขตด้านอื่นมาคุมแทน
• ลด post_max_size ลง ถ้าเว็บไม่ต้องรับอัปโหลดไฟล์ให้ตั้ง 8M ถ้าต้องอัปโหลดให้ตั้ง 32M และให้ upload_max_filesize ต่ำกว่าค่านี้
• จำกัดขนาดคำขอ จำนวนฟิลด์ และจำนวน part ของ multipart ที่ระดับเว็บเซิร์ฟเวอร์หรือ proxy
• ใช้ container หรือ cgroup จำกัดหน่วยความจำแทน และห้ามใช้ RLIMIT_AS หรือ RLIMIT_DATA เพราะจะทำให้เกิดเงื่อนไขที่มีช่องโหว่เสียเอง

สำหรับ CVE-2026-109619

• ตั้ง session.upload_progress.enabled=0 ใน php.ini หรือคอนฟิกของ pool แล้วรีสตาร์ต worker ทุกตัว ห้ามใช้ ini_set() หรือ .user.ini เพราะมีผลช้าเกินไป
• ถ้าเป็น PHP 8.5 ให้ตั้ง fatal_error_backtraces=0 แล้วรีสตาร์ต
• ลบการตั้งค่าที่ไม่ถูกต้องหรือเลิกใช้แล้วซึ่งทำให้เกิดข้อความแจ้งเตือนตั้งแต่ต้นคำขอ การซ่อนข้อความด้วย display_errors หรือ @ ไม่ช่วย

ระหว่างรอ ให้คอยดูสัญญาณผิดปกติที่ Wiz แนะนำ ได้แก่ คำขอแบบ multipart แปลกๆ ตามด้วย error เรื่อง memory limit หรือ HTTP 500 ซ้ำๆ, cookie PHPSESSID ที่ยาวผิดปกติหรือรูปแบบเพี้ยน และ worker ของ PHP ที่ตายแล้วเกิดใหม่บ่อยโดยไม่มีสาเหตุ

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

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

• เปลี่ยนรหัสผ่านผู้ดูแลระบบ WordPress และรหัสผ่านฐานข้อมูล
• สร้าง salt keys ใน wp-config.php ใหม่ ซึ่งจะทำให้ทุกคนที่ล็อกอินค้างอยู่ต้องล็อกอินใหม่
• เปลี่ยน API key ของบริการที่ผูกกับเว็บ เช่น ระบบชำระเงิน อีเมล หรือ SMTP
• ตรวจหาบัญชีผู้ดูแลที่ไม่รู้จัก และไฟล์ PHP แปลกใหม่ในโฟลเดอร์ wp-content/uploads
• มีระบบสำรองข้อมูลอัตโนมัติที่เก็บไว้นอกเซิร์ฟเวอร์ ถ้ายังไม่มี ลองดูรายชื่อ ปลั๊กอิน WordPress ที่ควรมี ซึ่งรวมเรื่องสำรองข้อมูลและความปลอดภัยไว้

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

เคสนี้บอกอะไรเราเกี่ยวกับยุค AI

อีกเรื่องที่ทำให้ข่าวนี้ถูกพูดถึงมากคือวิธีค้นพบ Wiz ระบุว่าใช้ Wiz Atlas, Gemini 4 Argon และ GPT-5.6 Sol ตลอดงานวิจัย เริ่มพบช่องโหว่แรกวันที่ 19 สิงหาคม 2026 ยืนยันการรันโค้ดบน Drupal ได้ในวันถัดมา และบน WordPress ในวันที่ 21 สิงหาคม ก่อนรายงานให้ทีม PHP วันที่ 24 สิงหาคม

Wiz สรุปว่าโค้ดที่มีปัญหาอยู่มานานกว่าสิบปี สิ่งที่ AI เปลี่ยนคือความสามารถในการต่อบั๊กหลายตัวเข้าด้วยกันและปรับ exploit ให้เข้ากับแต่ละเป้าหมาย ซึ่งเมื่อก่อนต้องใช้ทีมระดับโลกหลายเดือน ตอนนี้นักวิจัยคนเดียวทำได้ในราวหนึ่งสัปดาห์ ผมมองว่าประเด็นที่เจ้าของเว็บควรเก็บไว้คือ ระยะเวลาระหว่าง “มีข่าวช่องโหว่” กับ “มีคนเอาไปโจมตีจริง” จะสั้นลงเรื่อยๆ

ความปลอดภัยของเว็บไม่ได้จบที่วันส่งมอบ แต่อยู่ที่ว่ามีใครคอยอัปเดตเมื่อข่าวแบบนี้ออกมา

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

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

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