วิธีแพตช์ PHP2Shell: เช็กเวอร์ชัน PHP แล้วอัปเดตบน Ubuntu, RHEL, Docker และ cPanel/Plesk

แพตช์ PHP2Shell บน RHEL, Rocky Linux และ AlmaLinux

Red Hat ออกประกาศ RHSB-2026-013 และประเมิน CVE-2026-109618 ที่ระดับ Important (CVSS 3.1 8.1) โดยให้เหตุผลว่า RHEL ตั้งค่ามาตรฐานให้ใช้ PHP-FPM แทน mod_php และ worker ของ PHP-FPM จะออกเมื่อเริ่มคำขอไม่สำเร็จ การรันโค้ดจึงทำได้ยากกว่าในทางปฏิบัติ แต่เครื่องที่ใช้ mod_php เสี่ยงกว่า ข้อมูล VEX ของ Red Hat ณ 22 ตุลาคมระบุแพ็กเกจที่แก้แล้วดังนี้

• RHEL 10: php 8.3.36 (RHSA-2026:87070) และ php8.4 8.4.27 (RHSA-2026:87071)
• RHEL 9: โมดูล php:8.3 รุ่น 8.3.36 (RHSA-2026:87079), php:8.2 รุ่น 8.2.35 (RHSA-2026:87072) และ php 8.0.30-8.el9_8.1 (RHSA-2026:87151) ส่วนโมดูล php:8.4 ยังอยู่ในสถานะได้รับผลกระทบและยังไม่มีแพ็กเกจแก้
• RHEL 8: โมดูล php:8.2 รุ่น 8.2.35 (RHSA-2026:87073) และ php:7.4 (RHSA-2026:87080)

บทความ How do I apply package updates to my RHEL system? ของ Red Hat ให้ใช้ dnf upgrade บน RHEL 9 ส่วน Rocky Linux ออก RLSA เลขเดียวกัน (เช่น RLSA-2026:87079) สำหรับ Rocky Linux 8, 9 และ 10 เมื่อ 22 ตุลาคม ส่วนฐานข้อมูล errata ของ AlmaLinux ณ บ่ายวันที่ 22 ตุลาคมยังไม่มีประกาศ ALSA สำหรับสอง CVE นี้ ผู้ใช้ AlmaLinux ควรตรวจซ้ำก่อนสรุปว่าเครื่องได้แพตช์ PHP2Shell แล้ว

แพตช์ PHP2Shell ใน repo ของ Ondřej Surý และ Remi

เครื่องจำนวนมากติดตั้ง PHP หลายเวอร์ชันจาก repo ของนักพัฒนาอิสระสองราย ซึ่งตามแพตช์มาแล้ว

• PPA ondrej/php บน Launchpad (Ubuntu): เผยแพร่ php8.5 8.5.12, php8.4 8.4.27, php8.3 8.3.36 และ php8.2 8.2.35 สำหรับ Ubuntu 24.04 และ 22.04 เมื่อ 21 ตุลาคม 2026 เวลา 14:45 UTC อัปเดตด้วย apt เหมือนแพ็กเกจของ Ubuntu
• Remi repository (EL): โฟลเดอร์แพ็กเกจสำหรับ EL9 มี php-cli 8.5.12, 8.4.27, 8.3.36 และ 8.2.35 แล้ว ณ วันที่ 22 ตุลาคม แต่ยังไม่มีบล็อกประกาศจาก Remi

Docker: แพตช์ PHP2Shell ใน image ทางการ

โครงการ docker-library/php ที่ดูแล image php บน Docker Hub รวมคอมมิต "[security] Update to 8.5.12, 8.4.27, 8.3.36, 8.2.35" เมื่อ 21 ตุลาคม 2026 และแท็กอย่าง 8.5.12-fpm, 8.4.27-fpm, 8.3.36-apache และ 8.2.35-fpm ถูก push ในวันเดียวกันตามเวลา UTC

image ที่สร้างจาก FROM php:8.x-... ไม่ได้รับแพตช์เอง ต้องสร้างใหม่ด้วย docker build --pull ซึ่งเอกสารของ Docker อธิบายว่าจะพยายามดึง image ต้นทางทุกตัวใหม่เสมอ แล้ว deploy คอนเทนเนอร์ชุดใหม่แทนชุดเดิม ข้อควรระวังคือแท็ก 8.1-fpm บน Docker Hub ถูก push ครั้งล่าสุดวันที่ 31 ธันวาคม 2025 และ 7.4-fpm ปี 2022 จึงไม่มีแพตช์ PHP2Shell คอนเทนเนอร์ที่ยังใช้สองสายนี้ต้องย้ายไปสาขาที่รองรับ

แพตช์ PHP2Shell บน cPanel, Plesk และ DirectAdmin

• cPanel: EasyApache 4 รุ่น 25.91 (21 ต.ค.) อัปเดต ea-php82 เป็น 8.2.35, ea-php83 เป็น 8.3.36, ea-php84 เป็น 8.4.27 และ ea-php85 เป็น 8.5.12 พร้อม backport ใน ea-php74, ea-php80 และ ea-php81 นอกจากนี้ตามบันทึกรุ่นของ cPanel PHP ภายในของ cPanel & WHM เอง (ใช้กับหน้า cPanel และ Roundcube) ได้ 8.4.27 ในรุ่น 138.0.18, 136.0.50 และ 134.0.66 ส่วนรุ่น 110.0.153 ได้ backport ให้ PHP 8.1.34
• Plesk: ชุด PHP Updates วันที่ 21 ตุลาคมอัปเดตเป็น 8.5.12, 8.4.27, 8.3.36 และ 8.2.35 และบนลินุกซ์ backport ให้ 8.1.34, 8.0.30 และ 7.4.33 ที่หมดอายุแล้ว ส่วน Plesk Obsidian 18.0.81 Update 4 และ 18.0.80 Update 11 อัปเดต PHP ที่ตัว Plesk ใช้เอง (plesk-engine และ sw-engine) เป็น 8.4.27
• DirectAdmin: ทีมงานประกาศในฟอรัมทางการว่า build ใหม่ขึ้นช่อง current และ stable แล้ว ให้รัน da update ตามด้วย da build php เพราะ DA อัปเดตตัวเองอัตโนมัติ แต่ PHP ต้องสั่ง build เอง (ยกเว้นเปิด cron ของ CustomBuild) build ถัดมาเพิ่มแพตช์ให้ 7.3, 7.2, 7.1, 7.0 และ 5.6

แพตช์ PHP2Shell บน Windows

php.net มีไฟล์ zip ของรุ่นที่แก้แล้วในหน้าดาวน์โหลดสำหรับ Windows เช่น PHP 8.5.12 แบบ VS17 x64 ที่สร้างเมื่อ 21 ตุลาคม 2026 เวลา 13:48 UTC หน้าเดียวกันอธิบายว่าถ้าใช้ PHP แบบ FastCGI กับ IIS ให้เลือก Non Thread Safe (NTS) ถ้าโหลดเป็นโมดูลของ Apache ให้เลือก Thread Safe (TS) เลือกแบบเดียวกับที่ติดตั้งไว้เดิม แล้วรีสตาร์ต IIS หรือ Apache ให้โหลดตัวใหม่

ขั้นตอนที่ 3: รีสตาร์ตทุกบริการหลังแพตช์ PHP2Shell

การติดตั้งแพตช์ PHP2Shell ยังไม่พอ ทีมวิจัยระบุว่าต้องรีสตาร์ต Apache, PHP-FPM และ PHP worker ที่รันค้างอยู่นานหลังติดตั้งรุ่นที่แก้แล้วทุกครั้ง เพราะโปรเซสเดิมยังใช้โค้ดเก่าในหน่วยความจำ

• Apache กับ mod_php บน Ubuntu: คู่มือของ Ubuntu ใช้คำสั่ง sudo systemctl restart apache2.service
• PHP-FPM: รีสตาร์ตบริการ FPM ของทุกเวอร์ชันที่จดไว้ในขั้นตอนที่ 1 (ชื่อบริการต่างกันตาม distro และเวอร์ชัน) ไม่ใช่เฉพาะเวอร์ชันหลัก
• คอนเทนเนอร์: สร้างคอนเทนเนอร์ใหม่จาก image ที่ build ใหม่ การ restart คอนเทนเนอร์เดิมไม่ได้เปลี่ยน image
• แผงควบคุม: cPanel, Plesk และ DirectAdmin จัดการบริการเองหลังอัปเดต แต่ควรตรวจในขั้นตอนที่ 4 ว่าทุกเว็บได้เวอร์ชันใหม่จริง

ขั้นตอนที่ 4: ตรวจว่าแพตช์ PHP2Shell ได้ผล

• เปิดหน้า phpinfo() ของทุกเว็บอีกรอบ (แล้วลบทิ้ง) ดูว่าเวอร์ชันตรงกับรุ่นที่แก้แล้วในตารางด้านบน หรือตรงกับเลขแพ็กเกจในประกาศของ distro
• บน Ubuntu ที่ใช้ Ubuntu Pro ใช้ pro fix กับเลข CVE เพื่อให้ระบบบอกสถานะของเครื่อง
• บน DirectAdmin ทีมงานระบุว่าถ้ามีไฟล์ custombuild/patches/php-7.4/143-php-7.4-cve-2026-109618.patch และ CustomBuild ไม่แสดงอัปเดตของ PHP 7.4 แปลว่าเป็นรุ่นล่าสุดแล้ว
• ตรวจ Docker ด้วยการดูว่าคอนเทนเนอร์ที่รันอยู่สร้างจาก image ใหม่ ไม่ใช่ image เก่าที่ค้างในเครื่อง
• ถ้าใช้มาตรการชั่วคราวในหัวข้อถัดไประหว่างรอแพตช์ ให้ทบทวนค่าเหล่านั้นหลังอัปเดต ทีมวิจัยระบุว่าแพตช์เพิ่มขีดจำกัดหน่วยความจำชั้นที่สอง (hard limit) ซึ่งเมื่อถึงแล้วโปรเซสจะจบทันทีโดยไม่รัน shutdown handler จึงควรทดสอบผลกับแอปพลิเคชันด้วย

PHP 8.1 และเก่ากว่า: แพตช์ PHP2Shell แบบ backport

php.net ระบุว่า PHP 8.1 และเก่ากว่าไม่ได้รับอัปเดตจากโครงการแล้ว แต่ด้วยความรุนแรงของช่องโหว่ ทีมความปลอดภัยของ PHP ทำ backport ซอร์สขั้นต่ำให้ PHP 7.4, 8.0 และ 8.1 ไว้ใน repository php-src สำหรับคนที่คอมไพล์เองหรือไม่มีผู้ให้บริการ LTS ทางเลือกตามลำดับความง่ายคือ

1. ใช้แพ็กเกจ backport จากผู้ให้บริการที่ใช้อยู่ เช่น ea-php74 ถึง ea-php81 ของ cPanel, PHP 7.4.33 ถึง 8.1.34 ของ Plesk, แพตช์ของ DirectAdmin หรือ Ubuntu Pro สำหรับ Ubuntu 20.04 และเก่ากว่า
2. คอมไพล์จาก branch backport ของ php.net ถ้าคอมไพล์ PHP เองอยู่แล้ว
3. วางแผนย้ายไปสาขาที่ยังได้รับแพตช์ โดย 8.2 จะได้แพตช์ความปลอดภัยจาก php.net ถึง 31 ธันวาคม 2026 เท่านั้น ส่วน 8.3, 8.4 และ 8.5 ได้ถึงปี 2027, 2028 และ 2029 ตามลำดับ

ยังทำแพตช์ PHP2Shell ไม่ได้: มาตรการชั่วคราวจาก php.net

php.net ระบุว่าการอัปเดตเป็นทางแก้เดียวที่ครบ มาตรการต่อไปนี้ใช้ระหว่างรอแพตช์ PHP2Shell และลดความเสี่ยงเฉพาะบางเส้นทางเท่านั้น

• CVE-2026-109618: ตั้ง memory_limit=-1 ในจุดที่แอปพลิเคชันแก้ทับไม่ได้ เช่น php_admin_value[memory_limit] = -1 ใน FPM pool หรือคอนฟิกของ Apache และตรวจว่าไม่มี pool หรือแอปใดตั้งค่าจำกัดกลับมา ลด post_max_size เหลือ 8M สำหรับแอปที่ไม่รับอัปโหลด หรือ 32M ถ้าต้องรับ และให้ upload_max_filesize ต่ำกว่า ใช้ container หรือ cgroup จำกัดหน่วยความจำ แต่ห้ามใช้ RLIMIT_AS หรือ RLIMIT_DATA แทน
• CVE-2026-109619: ตั้ง session.upload_progress.enabled=0 ใน php.ini, FPM pool หรือคอนฟิกเซิร์ฟเวอร์ (ไม่ใช้ ini_set() หรือ .user.ini) แล้วรีสตาร์ต worker ทุกตัว บน PHP 8.5 ตั้ง fatal_error_backtraces=0 เพิ่ม และแก้ fatal error กับ timeout ที่ผู้โจมตีกระตุ้นได้ การซ่อนข้อความผิดพลาดด้วย display_errors ไม่ช่วย

ทีมวิจัยเสริมว่า memory_limit=-1 โยนภาระไปที่ระบบปฏิบัติการ worker อาจถูกปิดกลางคำขอ จึงควรใช้คู่กับ cgroup v2 memory.max ทดสอบกับแอปก่อนใช้จริง และกลับไปตั้งค่าใหม่หลังแพตช์

สิ่งที่องค์กรไทยควรทำ

• ไล่ทุกเครื่องที่รัน PHP ทั้งเว็บองค์กร ระบบหลังบ้าน เครื่องทดสอบ และเว็บที่ฝากโฮสติ้ง จัดลำดับให้เครื่องที่ใช้ mod_php และเปิดออกอินเทอร์เน็ตก่อน เพราะ php.net ประเมินว่าเสี่ยงที่สุด
• ติดตั้งแพตช์ PHP2Shell จากแหล่งเดิมที่ติดตั้ง PHP แล้วเทียบเลขแพ็กเกจกับประกาศของผู้ผลิต อย่าดูแค่ php -v
• รีสตาร์ตทุกบริการและ worker แล้วตรวจผลผ่าน phpinfo() ทุกเว็บ
• ถามผู้ให้บริการโฮสติ้งเป็นลายลักษณ์อักษร ว่าแพตช์ PHP2Shell ครบทุกเวอร์ชันที่เว็บเราใช้แล้วหรือยัง โดยเฉพาะเว็บที่ยังอยู่บน PHP 7.x
• ใส่ PHP ไว้ในแผนแพตช์ประจำ เพราะ 8.2 จะหมดแพตช์ความปลอดภัยสิ้นปี 2026 ติดตามข่าวช่องโหว่อื่น ๆ ได้ที่หมวด Security