ช่องโหว่ PHP: แพตช์ PHP2Shell และวิธีตรวจสอบเวอร์ชัน PHP (WordPress)

PHP2Shell คือชื่อเรียกช่องโหว่ PHP สองรายการ (CVE-2026-109618 · CVE-2026-109619) ที่มีการเผยแพร่แพตช์เมื่อวันที่ 21 ตุลาคม 2026 ช่องโหว่ทั้งสองเป็นช่องโหว่การเรียกใช้โค้ดจากระยะไกลที่ทำให้แม้คำขอที่ไม่ได้ล็อกอินก็สั่งรันโค้ดบนเซิร์ฟเวอร์ได้ สิ่งแรกที่ต้องทำจึงเป็นการตรวจสอบเวอร์ชัน PHP ที่เว็บไซต์ของคุณใช้แล้วอัปเกรดเป็นเวอร์ชันที่แพตช์แล้ว ต่อไปนี้คือขั้นตอนบนเซิร์ฟเวอร์แบบ Nginx + Apache ที่ใช้ WordPress 7.1.3 ตั้งแต่ตรวจสอบเวอร์ชัน PHP ในหน้าสุขภาพเว็บ อัปเกรดเฉพาะแพ็กเกจ php เป็นเวอร์ชันที่แพตช์แล้ว จนถึงตรวจสอบอีกครั้ง

1️⃣ ช่องโหว่ PHP PHP2Shell: หลักการของช่องโหว่และขอบเขตผลกระทบ

ช่องโหว่นี้อยู่ในเอนจิน PHP ที่อ่านคำขอก่อนโค้ด WordPress จะทำงาน แม้คุณจะอัปเดตปลั๊กอินและธีมให้ใหม่อยู่เสมอ ถ้าไม่อัปเกรด PHP ช่องโหว่ก็ยังคงอยู่ ตามประกาศเตือนของ CERT-EU ช่องโหว่ทั้งสองมีคะแนน CVSS 9.2 รายละเอียดทางเทคนิคถูกเปิดเผยและมีการพูดถึงกันแล้ว และโค้ดพิสูจน์แนวคิด (proof of concept) ช่วงแรกก็เริ่มแพร่ออกมา

CVE-2026-109618 เป็นช่องโหว่ที่เมื่อคำขอใช้หน่วยความจำเกินขีดจำกัด (memory_limit) แล้วถูกหยุดกลางทาง ขั้นตอนเก็บกวาดจะถือว่าข้อมูลคำขอที่เตรียมไว้เพียงครึ่งเดียวเป็นข้อมูลปกติ ส่วน CVE-2026-109619 เป็นช่องโหว่ที่สถานะของหน่วยความจำซึ่งถูกปล่อยคืนหลังเกิด fatal error ยังค้างอยู่ และถูกนำกลับมาใช้ก่อนการเตรียมค่าเริ่มต้นในคำขอถัดไปที่ worker ตัวเดียวกันรับไปทำงาน

ตามประกาศของ php.net การติดตั้ง PHP ทุกแบบที่รับคำขอเว็บได้รับผลกระทบ และในจำนวนนั้นถือว่า Apache mod_php เป็นรูปแบบที่อันตรายที่สุด เพราะมีการสาธิตบน mod_php ว่าคำขอที่ไม่ได้ล็อกอินเพียงครั้งเดียวทำให้การโจมตีเกิดขึ้นก่อนโค้ดของแอปพลิเคชันจะทำงาน

เวอร์ชันที่แก้ไขแล้วคือ 8.2.35, 8.3.36, 8.4.27 และ 8.5.12 ส่วนเวอร์ชันที่ต่ำกว่านี้ในสาย 8.2–8.5 ได้รับผลกระทบทั้งหมด PHP 8.1 ลงไปเป็นสายที่โครงการ PHP สิ้นสุดการสนับสนุนแล้ว จึงไม่มีเวอร์ชันแพตช์อย่างเป็นทางการ และต้องพึ่งการแก้ไขที่ดิสทริบิวชันหรือผู้ให้บริการโฮสติ้งนำมาใส่ให้ (backport)

ณ เวลาที่ CISA ออกประกาศเมื่อวันที่ 21 ตุลาคม ยังไม่มีการยืนยันว่าถูกนำไปโจมตีจริง แต่ CISA ประเมินว่าการปล่อยระบบไว้โดยไม่แพตช์เป็นเรื่องอันตราย และแนะนำให้แพตช์ทันทีโดยเริ่มจากระบบที่เปิดออกสู่อินเทอร์เน็ต ส่วน CERT-EU ประเมินในประกาศเตือนวันเดียวกันว่าเมื่อโค้ดพิสูจน์แนวคิดเริ่มแพร่ออกมา โอกาสที่ผู้โจมตีกำลังใช้ช่องโหว่นี้อยู่แล้วก็สูงขึ้น

2️⃣ ตรวจสอบเวอร์ชัน PHP: สุขภาพเว็บ › ข้อมูล › เซิร์ฟเวอร์

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

แถว [PHP SAPI] ที่อยู่ใต้ [รุ่นของ PHP] บอกวิธีการทำงานของ PHP โดย fpm-fcgi หมายถึงการตั้งค่าแบบ PHP-FPM ในที่นี้ดูแค่สองแถวในส่วน [เซิร์ฟเวอร์] คือ [รุ่นของ PHP] และ [PHP SAPI]

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

[php -v] ในเทอร์มินัลแสดงแค่เวอร์ชันของ PHP ค่าเริ่มต้นในบรรทัดคำสั่ง ในการตั้งค่าที่ติดตั้ง PHP หลายเวอร์ชันบนเซิร์ฟเวอร์เครื่องเดียว เช่น EA-PHP ของ cPanel หรือ alt-php ของ CloudLinux อาจไม่ตรงกับเวอร์ชันที่เว็บไซต์ใช้ จึงยึดค่า [รุ่นของ PHP] ในสุขภาพเว็บเป็นเกณฑ์

php -v

PHP 8.3.xx (cli) (built: Jun  3 2025 17:17:57) (NTS gcc x86_64)

3️⃣ ถ้าต่ำกว่า PHP 8.2: สอบถามโฮสติ้งว่ามีการ backport แล้วหรือยัง ถ้ายังให้ร้องขอ

ถ้า [รุ่นของ PHP] ในสุขภาพเว็บต่ำกว่า 8.2 (7.x · 8.0 · 8.1) จะไม่มีเวอร์ชันแพตช์อย่างเป็นทางการจาก php.net ตามตารางเวอร์ชันที่รองรับของ php.net (ตรวจสอบเมื่อ 22 ตุลาคม 2026) สายที่ยังรองรับมีเพียงสี่สาย คือ 8.2 · 8.3 · 8.4 · 8.5 และเวอร์ชันทางการตั้งแต่ 8.1 ลงไปจะไม่ได้รับแพตช์ความปลอดภัย

แทนที่จะเป็นแบบนั้น ดิสทริบิวชันหรือผู้ให้บริการโฮสติ้งบางรายจะออกแพ็กเกจที่คงหมายเลขเวอร์ชันเดิมไว้แต่ใส่เฉพาะส่วนที่แก้ไข (backport) แพ็กเกจ 7.4.33 · 8.0.30 · 8.1.34 บนเซิร์ฟเวอร์ทดสอบของโฮสติ้งแบบมีผู้ดูแลรายหนึ่งคือตัวอย่าง ในบันทึกการเปลี่ยนแปลงมีบรรทัด [Backported from 8.2.35 — CVE-2026-109618, CVE-2026-109619] อยู่

ต่อให้หมายเลขเวอร์ชันเท่าเดิม ก็ตรวจได้ว่ามีการแก้ไขหรือไม่โดยค้นหาหมายเลข CVE ในบันทึกการเปลี่ยนแปลงของแพ็กเกจ ในตระกูล Debian · Ubuntu ให้ค้นแบบ [zcat /usr/share/doc/php8.2-cli/changelog.Debian.gz | grep 109618] ส่วนตระกูล RPM ใช้รูปแบบ [rpm -q --changelog php-common | grep 109618] และปรับหมายเลขเวอร์ชันในชื่อแพ็กเกจให้ตรงกับเวอร์ชันที่เว็บไซต์ใช้

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

CISA แนะนำให้องค์กรที่ใช้ 8.1 ลงไปและยังอัปเดตทันทีไม่ได้ ปิดระบบที่ใช้ PHP ไว้แบบออฟไลน์จนกว่าจะแพตช์หรืออัปเกรด

ถ้าคุณดูแลเซิร์ฟเวอร์เองและใช้ 8.1 ลงไป สามารถติดตั้งแพ็กเกจ backport ของดิสทริบิวชัน หรือใช้แพตช์ซอร์สโค้ดสำหรับ 7.4 · 8.0 · 8.1 ที่ทีมความปลอดภัยของ PHP ออกมาได้ แต่เนื่องจากเป็นสายที่สิ้นสุดการสนับสนุนแล้ว ทางแก้ที่แท้จริงคือการย้ายไปใช้เวอร์ชันที่รองรับ

4️⃣ ถ้าเป็น PHP 8.2 ขึ้นไป: อัปเดตเป็นเวอร์ชันที่แพตช์แล้วและตรวจสอบอีกครั้ง

ถ้าใช้ 8.2 ขึ้นไปแต่ยังต่ำกว่าเวอร์ชันแพตช์ ให้อัปเกรดตัว PHP เอง สำหรับโฮสติ้งแบบมีผู้ดูแลและแชร์โฮสติ้ง ผู้ให้บริการจะใส่แพตช์ให้ทั้งเซิร์ฟเวอร์ จึงให้ตรวจจากประกาศหรือสอบถามฝ่ายซัพพอร์ตว่าใส่แล้วหรือยังและใช้บิลด์ใด แล้วดูว่า [รุ่นของ PHP] ในสุขภาพเว็บเปลี่ยนไปหรือไม่ ตามประกาศในหน้าสถานะ Cloudways เริ่มใส่แพตช์ให้ PHP ทุกเวอร์ชันที่รองรับ (5.6–8.4) เมื่อวันที่ 21 ตุลาคม เวลา 22:19 UTC และแจ้งว่าเสร็จสิ้นเมื่อวันที่ 22 ตุลาคม เวลา 10:11 UTC

เซิร์ฟเวอร์ที่ดูแลเองให้อัปเกรดด้วยแพ็กเกจจากคลังของดิสทริบิวชันหรือผู้ให้บริการ LTS ตามประกาศของ php.net ก่อนอัปเดตให้ดูรายการแพ็กเกจที่จะเปลี่ยนในโหมดพรีวิว เพื่อดูว่ามีเฉพาะแพ็กเกจที่ขึ้นต้นด้วย php ที่ถูกอัปเกรดและไม่มีแพ็กเกจอื่นติดมาด้วย และอย่าทำปนกับการอัปเดตอื่นของระบบปฏิบัติการ

dnf upgrade --assumeno 'php*'

Dependencies resolved.
================================================================================
 Package       Architecture  Version         Repository  Size
================================================================================
Upgrading:
 php           x86_64  8.3.xx-1.…        …       1.9 M
 php-cli       x86_64  8.3.xx-1.…        …       5.6 M
 php-common    x86_64  8.3.xx-1.…        …       1.3 M
 php-fpm       x86_64  8.3.xx-1.…        …       1.9 M
 (ละบรรทัดของแพ็กเกจส่วนขยาย เช่น php-gd · php-intl)

Transaction Summary
================================================================================
Upgrade  xx Packages

dnf upgrade 'php*'

Upgraded:
  php-8.3.xx-1.….x86_64
  php-cli-8.3.xx-1.….x86_64
  php-common-8.3.xx-1.….x86_64
  php-fpm-8.3.xx-1.….x86_64
  (ละบรรทัดของแพ็กเกจส่วนขยาย)

Complete!

ในการทดสอบครั้งนี้ มีเพียงแพ็กเกจที่ขึ้นต้นด้วย php ที่ถูกอัปเกรดเป็นเวอร์ชันแพตช์ และ php-fpm รีสตาร์ตเองเมื่อการติดตั้งแพ็กเกจเสร็จ เวอร์ชันที่แก้ไขแล้วจะมีผลก็ต่อเมื่อ worker ของ php-fpm รีสตาร์ต ดังนั้นในสภาพแวดล้อมที่ไม่มีการรีสตาร์ตอัตโนมัติ ให้รัน [systemctl restart php-fpm] เอง

หลังอัปเกรดให้ดูว่า [php -v] และแถว [รุ่นของ PHP] ในแท็บ [ข้อมูล] ของสุขภาพเว็บเป็นเวอร์ชันแพตช์หรือใหม่กว่าทั้งคู่ แล้วตรวจสถานะบริการ php-fpm และการตอบสนองของเว็บไซต์ด้วย ถ้าเปลี่ยนแค่ค่าในบรรทัดคำสั่งแต่ [รุ่นของ PHP] ยังเท่าเดิม ให้รีสตาร์ต php-fpm แล้วตรวจอีกครั้ง

หลังอัปเดตแล้วก็ให้ขยายส่วน [เซิร์ฟเวอร์] ในแท็บ [ข้อมูล] ของหน้า [เครื่องมือ › สุขภาพเว็บ] เดิม แล้วดูแถว [รุ่นของ PHP] ถ้าค่านี้เปลี่ยนเป็นเวอร์ชันที่อัปเกรด แสดงว่า worker ของ php-fpm ก็ทำงานด้วยเวอร์ชันใหม่แล้ว

php -v

PHP 8.3.xx (cli) (built: Oct 19 2026 14:00:34) (NTS gcc x86_64)

systemctl is-active php-fpm

active

curl -s -o /dev/null -w '%{http_code}\n' 'https://example.com/?r=1'

200

แพ็กเกจที่หมายเลขเวอร์ชันขยับขึ้นจะยืนยันแพตช์ได้จากหมายเลขเวอร์ชันใหม่ ส่วนแพ็กเกจ backport ที่คงหมายเลขเวอร์ชันเดิมจะยืนยันได้จากหมายเลข CVE ในบันทึกการเปลี่ยนแปลง เซิร์ฟเวอร์นี้เป็นแบบแรก [rpm -q --changelog php-common] จึงไม่มีบรรทัดหมายเลข CVE และยืนยันได้จากหมายเลขเวอร์ชันใหม่ในบรรทัดแรกของบันทึกการเปลี่ยนแปลง

5️⃣ เมื่อยังอัปเกรดทันทีไม่ได้: มาตรการชั่วคราวที่ php.net แนะนำ

สำหรับเซิร์ฟเวอร์ที่อัปเกรดทันทีไม่ได้ php.net แนะนำการตั้งค่าด้านล่างเป็นมาตรการชั่วคราว พร้อมระบุว่ามาตรการเหล่านี้เพียงลดเส้นทางการโจมตีบางเส้นทาง ไม่ได้ทำให้การติดตั้งปลอดภัย และยังเขียนไว้ว่าไม่ควรตั้งขีดจำกัดหน่วยความจำด้วย RLIMIT_AS หรือ RLIMIT_DATA แทน เพราะอาจทำให้เกิดการจัดสรรหน่วยความจำล้มเหลวแบบที่เป็นช่องโหว่เสียเอง

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

🔢 FAQ & เนื้อหาแนะนำ

🔗 เนื้อหาแนะนำ

ความปลอดภัย ความปลอดภัย WP: ความปลอดภัยของ wp-admin การตั้งค่าที่ปกป้องหน้าผู้ดูแลระบบด้วยการเปลี่ยนที่อยู่ล็อกอิน จำกัดการล็อกอิน และบล็อก XML-RPC อ่านบทความ →

ความปลอดภัย ช่องโหว่ด้านความปลอดภัยของ wp-config.php วิธีป้องกันไม่ให้ไฟล์ wp-config.php ถูกเปิดเผยและเสริมการตั้งค่าความปลอดภัย ความปลอดภัย WordPress XML-RPC วิธีแยกการโจมตี xmlrpc.php จากล็อกและสามวิธีปิดใช้งาน เซิร์ฟเวอร์ คำเตือน php-fpm max_children การทดสอบจริงที่หาสาเหตุของคำเตือนจากล็อกก่อนเพิ่ม worker

ℹ️ ประกาศเรื่องลิงก์แอฟฟิลิเอต
เนื้อหาของเว็บไซต์นี้มีลิงก์แอฟฟิลิเอต หากผู้เข้าชมซื้อสินค้าหรือบริการผ่านลิงก์เหล่านี้ เว็บไซต์นี้จะได้รับค่าคอมมิชชันจากผู้ขาย ในกระบวนการนี้ ราคาที่ผู้ซื้อจ่าย^{(ราคาจะลดลงเมื่อมีโปรโมชัน↓)}จะไม่สูงขึ้นแต่อย่างใด ราคา ส่วนลด และข้อมูลสต็อกที่แสดงเป็นข้อมูล ณ เวลาที่เขียนและอาจต่างจากความเป็นจริง โปรดตรวจสอบกับผู้ขายอีกครั้งก่อนซื้อ การเลือกและการประเมินสินค้าเขียนตามเกณฑ์ของเราเอง และการได้รับค่าคอมมิชชันหรือไม่ไม่มีผลต่อลำดับการแนะนำหรือเนื้อหาการประเมิน