แพตช์ PHP2Shell บน cPanel, Plesk, DirectAdmin และ CloudLinux — ขั้นตอนทางการ และเช็คยังไงว่าแพตช์แล้วจริง
แพตช์ PHP2Shell บน cPanel, Plesk, DirectAdmin และ CloudLinux ตามขั้นตอนทางการ วิธีเช็คว่าแพตช์แล้วจริง และคำถามที่เจ้าของเว็บ WordPress ควรถามโฮสต์ของตัวเอง
แพตช์ PHP2Shell บน cPanel, Plesk, DirectAdmin และ CloudLinux — ขั้นตอนทางการ และเช็คยังไงว่าแพตช์แล้วจริง
PHP ออกเวอร์ชัน 8.5.12, 8.4.27, 8.3.36 และ 8.2.35 เมื่อ 21 ตุลาคม 2026 เวลา 21:00 น. ตามเวลาไทย เพื่อปิดช่องโหว่คู่ที่เรียกกันว่า PHP2Shell (สรุปช่องโหว่อ่านได้ที่นี่) แต่เว็บบนพาเนลที่บทความนี้พูดถึงได้ PHP จากแพ็กเกจหรือระบบ build ของ vendor พาเนล เลขเวอร์ชันที่แก้แล้วจึงไม่ตรงกับ php.net เสมอไป และ cPanel กับ Plesk ยังมี PHP อีกชุดที่ตัวพาเนลใช้เอง ซึ่งต้องอัปเดตแยก
บทความนี้เขียนให้เว็บเอเจนซี, SME ที่ดูแลเซิร์ฟเวอร์เอง และลูกค้าโฮสติ้ง เนื้อหาเป็น snapshot จากหน้าทางการของ vendor ณ 25 ตุลาคม 2026 เรื่อง build ที่แก้แล้ว การ rollout และสิ่งที่ต้องทำ ให้ยึดหน้า advisory หรือ status ปัจจุบันของ vendor เป็นหลัก
คำตอบสั้น: อัปเดตผ่านช่องทางที่ vendor ของพาเนลกำหนด restart บริการ PHP ตาม handler ที่ใช้ แล้วเช็คด้วยวิธีของ vendor รายนั้น ส่วนลูกค้า shared หรือ managed hosting ให้ถามผู้ให้บริการตามรายการคำถามในหัวข้อ WordPress ด้านล่าง
ก่อนเริ่ม: รู้ก่อนว่าแต่ละเว็บใช้ PHP สาขาไหน
พาเนลส่วนใหญ่ให้เลือก PHP รายโดเมน จึงต้องอัปเดตให้ครบทุกสาขาที่ติดตั้งไว้ วิธีเช็คว่าเว็บไหนรัน PHP ตัวไหนจริงอยู่ที่เช็คเวอร์ชัน PHP ทุกเว็บก่อนแพตช์ PHP2Shell
ตารางสรุป: แพตช์มาจากไหน เวอร์ชันไหน เช็คยังไง
| พาเนล | แพตช์มาจาก | แพ็กเกจที่แก้แล้ว (ณ 25 ต.ค.) | เช็คยังไง |
|---|
| cPanel/WHM | EasyApache 4 รุ่น 25.91 | ea-php82 8.2.35, ea-php83 8.3.36, ea-php84 8.4.27, ea-php85 8.5.12 และ backport ให้ ea-php74/80/81 (เลขเดิม) | เลขแพ็กเกจทุกสาขา หรือ CVE ใน changelog |
| cPanel บน CloudLinux | ea-php ของ CloudLinux | ea-php52 ถึง ea-php85 เช่น ea-php84 8.4.26-2.elX.cloudlinux.1 หรือ 8.4.27-1 | CVE ใน changelog |
| PHP ของตัว cPanel | อัปเดต cPanel | cpanel-php84 8.4.27 ใน 134.0.66, 136.0.50, 138.0.18 | /usr/local/cpanel/cpanel -V |
| Plesk | Plesk Installer | Linux: 8.2.35, 8.3.36, 8.4.27, 8.5.12 และ 7.4.33/8.0.30/8.1.34 ที่ build 21 ต.ค. 2026; Windows: 8.2.35, 8.3.36, 8.4.27, 8.5.12 | PHP Settings หรือวันที่ build |
| PHP ของตัว Plesk | อัปเดต Plesk | Obsidian 18.0.81 Update 4 หรือ 18.0.80 Update 11 | plesk version |
| DirectAdmin | CustomBuild (โพสต์ staff) | 8.2.35, 8.3.36, 8.4.27, 8.5.12 และ patch ให้ 8.1 ลงไปถึง 5.6 (เลขเดิม) | * หลังเลขเวอร์ชัน หรือไฟล์ patch |
| CloudLinux alt-php | repository ของ CloudLinux | alt-php 5.2 ถึง 8.5 รวมถึง alt-php82 8.2.35-1 ถึง alt-php85 8.5.12-1 | CVE ใน changelog หรือเลขแพ็กเกจ |
| WP Engine, Kinsta, Pantheon | โฮสต์แพตช์ให้ | ตามประกาศของโฮสต์ | หน้า status และ Site Health |
| aaPanel, HestiaCP | ยังยืนยันไม่ได้ | ไม่ทราบ | ตามเอกสารของ vendor |
ถ้าต้องไล่ตารางนี้กับเซิร์ฟเวอร์หลายสิบเครื่องทุกรอบ ลองดูราคาเครื่องมือติดตามแพ็กเกจรายเครื่องของ zcrไว้ประกอบการตัดสินใจ
cPanel/WHM: EasyApache 4 และ ea-php
EasyApache 4 รุ่น 25.91 (21 ต.ค.) อัปเดต ea-php82 ถึง ea-php85 เป็นรุ่นที่แก้แล้ว ส่วน ea-php74, ea-php80 และ ea-php81 ได้ fix แบบ backport เลขจึงเหมือนเดิม (EA4 change log)
- อัปเดต ใน WHM เปิด EasyApache 4 กด Run system update ระบบจะพาไปหน้า System Update ซึ่งอัปเดตทุกแพ็กเกจในเครื่อง รวมถึงแพ็กเกจที่ไม่เกี่ยวกับ PHP กด Proceed เพื่อเริ่ม (ถ้าติ๊ก Include kernel packages ด้วย เครื่องอาจต้อง reboot) (cPanel: System Update) ทาง command line สคริปต์ตัวเดียวกันคือ
/usr/local/cpanel/scripts/rpmup2 (Upgrade to Latest Version)
- Restart ตาม handler
- เช็ค
rpm -q ea-php84-php-cli เป็นตัวอย่างของแพ็กเกจ CLI สาขา 8.4 เท่านั้น (ควรได้ 8.4.27 หรือ build ที่ใหม่กว่าตาม advisory ปัจจุบัน บน Ubuntu ใช้ dpkg -l ea-php84-php-cli) ให้เช็คแบบเดียวกันทุกสาขาที่ติดตั้ง แล้วยืนยัน runtime ที่แต่ละเว็บใช้จริงแยกกัน ส่วน ea-php74/80/81 ให้ดู changelog ของแพ็กเกจ ea-php74-meta, ea-php80-meta และ ea-php81-meta ตามชื่อใน change log ของ EA4 ซึ่งรุ่น 25.92 rebuild ให้ระบุ backport ไว้
- ea-php73 ลงไป change log ของ EA4 ไม่มี fix ให้ ย้ายโดเมนไปสาขาที่แก้แล้ว หรือใช้ TuxCare ELS ที่เอกสาร MultiPHP Manager ชี้ไว้สำหรับ PHP 5.6 และ 7.x (ขอให้ผู้ขายยืนยันว่าแก้ทั้งสอง CVE) ดูต่อที่ยังใช้ PHP รุ่นเก่าอยู่
cPanel บน CloudLinux ใช้ ea-php ที่ CloudLinux build เอง วันที่ 21 ต.ค. ออกเป็น backport ที่เลขต่ำกว่า php.net เช่น ea-php84 8.4.26-2.elX.cloudlinux.1 แล้ววันที่ 23 ต.ค. จึงออก build ที่ใช้เลขเดียวกับ php.net เช่น ea-php84 8.4.27-1 CloudLinux ยืนยันว่า build แรกมี fix ของทั้งสอง CVE แล้ว build ใหม่แค่ปรับเลขให้ตรง หลังอัปเดตให้ restart ตามข้อ 2 แล้วเช็คทุกสาขาที่ติดตั้ง (ตัวอย่างคือ ea-php84)
# CloudLinux OS 8, 9, 10 (OS 7 ใช้ yum clean all && yum update "ea-php*")
dnf clean all && dnf upgrade "ea-php*"
# เช็ค (อ่านอย่างเดียว)
rpm -q --changelog ea-php84-php-cli | grep -E 'CVE-2026-(109618|109619)'
PHP ของตัว cPanel เอง cpanel-php84 อัปเดตเป็น 8.4.27 ใน build 134.0.66, 136.0.50 และ 138.0.18 (136 change log) เช็คด้วย /usr/local/cpanel/cpanel -V ถ้ายังต่ำกว่านี้ ให้อัปเดตที่ WHM » Home » cPanel » Upgrade to Latest Version หรือ /scripts/upcp (อัปเดตภายใน release tier ที่ตั้งไว้) change log ของรุ่น 132 ที่เราอ่าน (build ล่าสุด 132.0.35 วันที่ 20 พฤษภาคม) ไม่มี fix นี้ เครื่องที่ยังอยู่ 132 หรือเก่ากว่าต้องอัปเกรด major version หรือขอคำยืนยันจาก cPanel ระวังเครื่องที่ล็อก build เป็นเลขตายตัวใน /etc/cpupdate.conf เพราะ cron ติดตั้ง security update รายชั่วโมงของ cPanel จะไม่ทำงาน (Update Preferences)
Plesk
ประกาศของ Plesk ให้ทำข้อเดียวคือ "Update Plesk to the latest available version"
- อัปเดต ไปที่ Tools & Settings > Updates กด Update Components แล้ว Continue หรือรัน
plesk installer update ทาง SSH (บน Windows ใช้ command prompt แบบ Administrator) บริการที่มี component ถูกอัปเดตจะถูก restart ให้ (How to install Plesk updates)
- เช็ค PHP ที่ Tools & Settings > PHP Settings เวอร์ชันอยู่ในชื่อ handler หรือรัน binary ของแต่ละสาขา เช่น
/opt/plesk/php/8.3/bin/php -v จะเห็นทั้งเลขและวันที่ build สาขา 7.4.33, 8.0.30 และ 8.1.34 เลขไม่เปลี่ยน ต้องเป็น build วันที่ 21 ตุลาคม 2026 หรือใหม่กว่า คำสั่งนี้เป็น CLI จึงยังต้องเช็คจากฝั่งเว็บอีกรอบ
- เช็คตัว Plesk sw-engine (Linux) และ plesk-engine (Windows) ต้องเป็น Obsidian 18.0.81 Update 4 หรือ 18.0.80 Update 11 ขึ้นไป ดูด้วย
plesk version
- Plesk for Windows มี fix เฉพาะ 8.2.35, 8.3.36, 8.4.27 และ 8.5.12
- PHP 5.6, 7.2 และ 7.3 Plesk แนะนำ TuxCare ELS แบบเสียเงิน ให้ถามผู้ขายว่ารองรับแพลตฟอร์มที่ใช้และแก้ทั้งสอง CVE หรือไม่
DirectAdmin: CustomBuild
ข้อมูลส่วนนี้มาจากโพสต์ของ staff (ผู้ใช้ fln ป้าย Staff member) ในกระทู้ "Critical PHP updates" ของฟอรัมทางการ DirectAdmin ในแหล่งที่เราตรวจ ณ 25 ต.ค. เราไม่พบหน้า advisory แยกของ DirectAdmin
- อัปเดตและ build ใหม่ ด้วย
da update แล้วตามด้วย da build php staff ระบุว่า DirectAdmin อัปเดตตัวเอง แต่ PHP ต้องสั่ง build เอง เว้นแต่เปิด cron ของ CustomBuild ไว้
- ได้อะไรบ้าง build แรก (21 ต.ค. 20:54 น. เวลาไทย) อัปเดตเป็น 8.2.35, 8.3.36, 8.4.27 และ 8.5.12 และเพิ่ม patch ให้ 8.1, 8.0, 7.4 build ถัดมาเพิ่ม patch ให้ 7.3, 7.2, 7.1, 7.0 และ 5.6 พร้อมแก้ปัญหา 8.1 build ไม่ผ่าน ช่อง legacy ของ rhel7 และ debian10 ได้ build ตามมา
- เช็ค เวอร์ชันที่มี
* ต่อท้าย คือเลขเดิมแต่เพิ่ม patch ใหม่ สำหรับ 7.4 ถ้ามีไฟล์ custombuild/patches/php-7.4/143-php-7.4-cve-2026-109618.patch และ CustomBuild ไม่มีอัปเดต 7.4 ค้าง แปลว่าเป็นปัจจุบันแล้ว staff ยืนยันว่าไฟล์ patch เดียวครอบคลุมทั้งสอง CVE
- Restart โพสต์ของ staff ไม่ได้ระบุ และเราไม่พบขั้นตอนทางการในแหล่งที่ตรวจ ให้ทำตามเอกสารของ DirectAdmin แล้วเช็คจากฝั่งเว็บ
CloudLinux: alt-php
alt-php คือ PHP ที่ลูกค้าเลือกผ่าน PHP Selector CloudLinux ออกแพ็กเกจที่แก้แล้วของ alt-php 5.2 ถึง 8.5 เข้า stable ของ CloudLinux OS 7, 8 และ 9 เมื่อ 22 ต.ค. 07:07 น. เวลาไทย ส่วน CloudLinux OS 10 ได้จาก repository ELS ALT PHP
# CloudLinux OS 8, 9, 10 (OS 7 ใช้ yum clean all && yum update "alt-php*")
dnf clean all && dnf upgrade "alt-php*"
# เช็ค (อ่านอย่างเดียว) ทำซ้ำกับทุกสาขาที่ติดตั้ง
rpm -q --changelog alt-php74-common | grep -E "CVE-2026-(109618|109619)"
rpm -q alt-php85-common
- ใช้ update ปกติ CloudLinux แจ้งว่ายังไม่มี metadata แบบ OVAL และ UpdateInfo คำสั่งอย่าง
yum --security จึงไม่เห็นแพ็กเกจเหล่านี้
- เปิด repository php-els ไว้ CloudLinux แก้ประกาศเมื่อ 23 ต.ค. ว่าไม่ต้องปิด เพราะกำลังจะเป็นแหล่งเดียวของ alt-php
- update ไม่เจออะไร ให้เช็ค
rpm -q cloudlinux-release เทียบกับ 7.9-2.17, 8.10-16, 9.8-3 หรือ 10-5 ถ้าเก่ากว่าให้อัปเดตแพ็กเกจนี้ก่อน แล้วรันใหม่
- Restart หน้า status ของ CloudLinux บอกให้ restart Apache, PHP-FPM หรือ LiteSpeed แต่ไม่ได้ให้คำสั่งรายตัว ให้ใช้เอกสารของ web server ที่ใช้อยู่
- PHP ของ OS เวอร์ชัน 8.2 และ 8.3 ที่ rebase เป็น 8.2.35 หรือ 8.3.36 ไม่มีเลข CVE ใน changelog ให้เช็คด้วย
rpm -q php-cli แทน
CloudLinux รายงานว่า ruleset 8.83 ถึง 8.85 ของ Imunify360 มุ่งที่เส้นทาง upload progress และ ณ 21 ต.ค. 23:00 UTC ยังไม่มีกฎสำหรับเส้นทาง out-of-memory ของ CVE-2026-109618 CloudLinux เรียกว่า "interim mitigation, not a fix" (ดูWAF ช่วยได้แค่ไหน)
WordPress บนโฮสต์แบบ managed: เจ้าของเว็บต้องทำอะไร
WordPress.org ประกาศเมื่อ 21 ตุลาคมว่าช่องโหว่นี้ไม่ได้เจาะจงที่ WordPress ไม่ต้องอัปเดต WordPress และไม่มีแผนออกอัปเดตเรื่องนี้ เจ้าของเว็บต้องเช็คกับโฮสต์ให้ PHP ถูกอัปเดต ดูเวอร์ชันได้ที่ Tools > Site Health > Info > Server
โฮสต์ managed WordPress รายใหญ่เคยประกาศไว้ดังนี้ (ข้อความของโฮสต์เอง ณ วันที่ประกาศ)
- WP Engine (22 ต.ค.): ลูกค้าไม่ต้องทำอะไร ทุกเว็บรัน PHP ที่แพตช์ครบแล้ว
- Kinsta (ปิด incident 22 ต.ค. 15:26 น. เวลาไทย): อัปเดต PHP 7.4 ถึง 8.5 ครบทั้งแพลตฟอร์ม และยังไม่พบหลักฐานการเจาะ
- Pantheon (ปิด incident 22 ต.ค.): ลูกค้าไม่ต้องทำอะไร เว็บ live บน 8.2 ถึง 8.5 และรุ่น LTS แพตช์เสร็จวันที่ 21 ต.ค. ส่วน environment แบบ free/sandbox แจ้งไว้เมื่อ 21 ต.ค. ว่าจะทยอยอัปเดตภายใน 24 ถึง 48 ชั่วโมง
ถ้าโฮสต์ของคุณยังเงียบ ถามเป็นลายลักษณ์อักษรตามนี้
- เว็บเรารัน PHP สาขาไหน แพ็กเกจที่ติดตั้งแก้ทั้ง CVE-2026-109618 และ CVE-2026-109619 แล้วหรือยัง ขอชื่อแพ็กเกจและเลข build เพราะ build แบบ backport อาจโชว์เลขต่ำกว่า php.net ใน Site Health ทั้งที่แพตช์แล้ว
- restart PHP worker หลังอัปเดตแล้วหรือยัง
- ตัวพาเนลเอง เช่น cPanel หรือ Plesk อัปเดตแล้วหรือยัง
- ถ้าเว็บยังอยู่บน 8.1 หรือเก่ากว่า fix มาจากไหน และจะย้ายไป 8.2 ขึ้นไปได้เมื่อไร (8.2 หมดซัพพอร์ต 31 ธันวาคม 2026)
- staging, dev และ sandbox อยู่ในรอบนี้ด้วยไหม
ถ้าคำตอบมีแค่ "เปิด WAF ไว้แล้ว" ยังนับเป็นการแพตช์ไม่ได้
ช่องว่างที่ยังยืนยันไม่ได้ (ณ 25 ตุลาคม 2026)
- aaPanel: หน้าประกาศในฟอรัมเปิดอ่านไม่ได้ตอนตรวจ เราจึงไม่มีขั้นตอนที่ยืนยันได้ ให้ดูประกาศของ aaPanel เอง
- HestiaCP: หน้า release ล่าสุดที่อ่านได้ (1.10.5 ออก 14 กันยายน) ออกก่อน PHP2Shell และเราไม่พบประกาศทางการ ให้ติดตามช่องทางของ HestiaCP โดยตรง
บทความนี้ไม่ครอบคลุมเซิร์ฟเวอร์ที่ไม่มีพาเนล (อัปเดต PHP บนเซิร์ฟเวอร์ของตัวเอง) อุปกรณ์ที่มี PHP ฝังอยู่ (ผลิตภัณฑ์ที่มี PHP ฝังอยู่) และคำถามว่าเครื่องโดนเจาะไปแล้วหรือยัง (หาร่องรอยจาก log)
ก่อนปิดงานรอบนี้
จดไว้ทุกเครื่องว่าใช้พาเนลอะไร มี PHP สาขาไหน แพ็กเกจเป็น build ไหน แพตช์และ restart เมื่อไร และเช็คจากฝั่งเว็บแล้วหรือยัง เพราะรอบหน้าต้องใช้อีก สำหรับเซิร์ฟเวอร์ Linux ที่ดูแลเอง zcrX ใช้ Agent จับคู่แพ็กเกจของแต่ละเครื่องกับ CVE advisory และสถานะ CISA KEV อย่างต่อเนื่อง แต่ไม่ได้แทนการอัปเดตและการเช็คตามขั้นตอนข้างบน
📞 ปรึกษาฟรี
zcr ให้ซอฟต์แวร์ ส่วนงานอัปเดตและตรวจเซิร์ฟเวอร์แบบลงมือจริงดำเนินการผ่านพาร์ทเนอร์
บทความที่เกี่ยวข้อง
อ่านต่อในชุดบทความ PHP2Shell:
แหล่งข้อมูลอ้างอิง
- PHP News Archive 2026 — เวอร์ชันที่แก้แล้ว, PHP 8.1 และเก่ากว่า, 8.2 หมดซัพพอร์ต 31 ธ.ค. 2026
- cPanel — EasyApache 4 Change Log 25 — รุ่น 25.91 และ 25.92
- cPanel — 132 Change Log, 134 Change Log, 136 Change Log และ 138 Change Log — cpanel-php84 8.4.27
- cPanel — EasyApache 4 Interface, System Update, Upgrade to Latest Version และ Update Preferences
- cPanel — The restartsrv Script และ MultiPHP Manager for WHM
- CloudLinux Status — Critical PHP vulnerabilities CVE-2026-109618 / CVE-2026-109619 — ea-php, alt-php, คำสั่งอัปเดตและเช็ค, Imunify360
- Plesk — Vulnerability CVE-2026-109618 and CVE-2026-109619 (PHP2Shell) และ How to install Plesk updates
- DirectAdmin Forums — Critical PHP updates — เฉพาะโพสต์ของ staff
- WordPress.org — Critical PHP Security Release
- WP Engine — Two critical CVEs affecting PHP, Kinsta Status และ Pantheon Status
- HestiaCP release 1.10.5
