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

> คู่มือแพตช์ PHP2Shell: หา PHP ทุกตัวบนเครื่อง อัปเดตเป็น 8.5.12, 8.4.27, 8.3.36, 8.2.35 หรือแพ็กเกจที่แก้แล้วของ distro และแผงควบคุม แล้วรีสตาร์ตและตรวจผล

- ประเภท: คู่มือ · หมวด: Cybersecurity
- เผยแพร่: 2026-10-22T12:12:00.000Z · อัปเดต: 2026-10-22T12:12:00.000Z
- โดย: กองบรรณาธิการ THAI DATA, THAI DATA IT BUSINESS ENTERPRISE
- ที่มา: https://thaidata.co.th/security/php2shell-patch-guide-check-php-version/

## สรุปประเด็นสำคัญ

- ทีม PHP ออกแพตช์ PHP2Shell ในรุ่น **8.5.12, 8.4.27, 8.3.36 และ 8.2.35** เมื่อ **21 ตุลาคม 2026** เพื่อปิด **CVE-2026-109618** และ **CVE-2026-109619** ซึ่ง GitHub advisory ของโครงการให้คะแนน **CVSS v4.0 9.2** ทั้งคู่
- แพตช์ PHP2Shell มาถึงผ่านหลายช่องทางในวันเดียวกัน: Ubuntu **USN-8948-1**, Debian **DSA-6574-1**, Red Hat **RHSA-2026:87070** และชุดถัดไป, Docker image ทางการ, cPanel **EasyApache 4 25.91**, Plesk และ DirectAdmin
- แพ็กเกจแพตช์ PHP2Shell ของ distro อาจใช้เลขเวอร์ชันเดิม เช่น Ubuntu 24.04 แก้ใน **8.3.6-0ubuntu0.24.04.13** จึงต้องเทียบเลขแพ็กเกจกับประกาศของผู้ผลิต ไม่ใช่ดูแค่ php -v
- PHP **8.1 และเก่ากว่า**ไม่ได้รุ่นใหม่จาก php.net แต่ทีม PHP ทำแพตช์ PHP2Shell แบบ backport ซอร์สให้ 7.4, 8.0 และ 8.1 ส่วน cPanel, Plesk, DirectAdmin และ Ubuntu Pro มีแพ็กเกจ backport ให้
- ติดตั้งแพตช์ PHP2Shell แล้วต้อง**รีสตาร์ต Apache, PHP-FPM และ worker ทุกตัว** มาตรการชั่วคราวของ php.net เช่น memory_limit=-1 และ session.upload_progress.enabled=0 ลดความเสี่ยงได้บางทางเท่านั้น

แพตช์ PHP2Shell คือการอัปเดต PHP เป็นรุ่น 8.5.12, 8.4.27, 8.3.36 หรือ 8.2.35 ที่ทีม PHP ออกเมื่อ 21 ตุลาคม 2026 เพื่อปิดช่องโหว่ CVE-2026-109618 และ CVE-2026-109619 (CVSS v4.0 9.2 ทั้งคู่) ที่เปิดทางให้รันโค้ดจากระยะไกลโดยไม่ต้องล็อกอิน จากนั้นต้องรีสตาร์ต PHP-FPM และ Apache ให้โหลดตัวใหม่ คู่มือนี้ไล่ตั้งแต่หาเวอร์ชันจนถึงตรวจผล

ประกาศของ php.net ระบุว่าทุกการติดตั้ง PHP ที่ให้บริการเว็บมีความเสี่ยง ทั้ง PHP-FPM, Apache กับ mod_php, php-cgi, FrankenPHP และ LiteSpeed โดยเสี่ยงที่สุดกับ mod_php ซึ่งคำขอที่ไม่ต้องล็อกอินเริ่มการโจมตีได้ก่อนโค้ดของแอปพลิเคชันจะทำงานเสียอีก ทีมวิจัยจาก Wiz, OpenAI และ Calif ที่ค้นพบช่องโหว่ย้ำว่าการอัปเดตแอปพลิเคชันอย่าง WordPress หรือ Drupal ไม่ได้อัปเดต PHP ที่อยู่ข้างใต้ (ภาพรวมของช่องโหว่อ่านได้ในข่าว[ช่องโหว่ PHP ระดับวิกฤต](/software/php-vulnerabilities-critical-security-release-oct-2026/))

## แพตช์ PHP2Shell ต้องอัปเดตเป็นรุ่นใด

GitHub advisory ของโครงการ PHP ระบุช่วงเวอร์ชันที่มีช่องโหว่ของทั้งสอง CVE เหมือนกัน ดังนี้

| สาขา PHP | รุ่นที่มีช่องโหว่ | รุ่นแรกที่แก้แล้ว | php.net ออกแพตช์ความปลอดภัยถึง |
| --- | --- | --- | --- |
| 8.5 | ต่ำกว่า 8.5.12 | 8.5.12 | 31 ธ.ค. 2029 |
| 8.4 | ต่ำกว่า 8.4.27 | 8.4.27 | 31 ธ.ค. 2028 |
| 8.3 | ต่ำกว่า 8.3.36 | 8.3.36 | 31 ธ.ค. 2027 |
| 8.2 | ต่ำกว่า 8.2.35 | 8.2.35 | 31 ธ.ค. 2026 |

CVE-2026-109618 เกิดจากการจัดการหน่วยความจำเต็ม (out-of-memory) ที่ขัดจังหวะ PHP ระหว่างที่ข้อมูลภายในของคำขอยังตั้งค่าไม่ครบ ส่วน CVE-2026-109619 เกิดจากสถานะภายในของคำขอหนึ่งที่ค้างอยู่หลังหน่วยความจำถูกคืนไปแล้ว และคำขอถัดไปที่ worker ตัวเดียวกันรับมาอาจหยิบไปใช้ ข้อสำคัญคือแพ็กเกจของ distro บางรายใส่แพตช์ไว้ในเลขเวอร์ชันเดิม เช่น Ubuntu 24.04 แก้ในแพ็กเกจ 8.3.6-0ubuntu0.24.04.13 และ RHEL 9 แก้ PHP 8.0 ในแพ็กเกจ 8.0.30-8.el9_8.1 การดูแค่เลข 8.x.y จึงตัดสินไม่ได้ ต้องเทียบเลขแพ็กเกจกับประกาศของผู้ผลิตที่เราใช้

## ขั้นตอนที่ 1: หา PHP ทุกตัวบนเครื่อง

เครื่องหนึ่งอาจมี PHP หลายเวอร์ชันพร้อมกัน เช่น เครื่องที่ใช้แผงควบคุมซึ่งให้แต่ละเว็บเลือกเวอร์ชันเอง หรือเครื่องที่ติดตั้ง php8.2 กับ php8.4 จาก repo เสริมไว้คู่กัน ทุกเวอร์ชันที่รับคำขอเว็บต้องได้แพตช์ PHP2Shell

1. **ฝั่งคอมมานด์ไลน์** [คู่มือของ php.net](https://www.php.net/manual/en/features.commandline.options.php) ระบุว่า `php -v` แสดงชื่อ SAPI และเวอร์ชันของ PHP ส่วน `php --ini` แสดงไฟล์ php.ini ที่โหลดและโฟลเดอร์ที่สแกน คำสั่งนี้บอกเฉพาะตัว `php` ที่อยู่ใน PATH ซึ่งอาจไม่ใช่ตัวเดียวกับที่ให้บริการเว็บ
2. **ฝั่งเว็บ** วางไฟล์ทดสอบที่มี `<?php phpinfo(); ?>` ไว้ใน DocumentRoot ตามที่[คู่มือ PHP ของ Ubuntu](https://documentation.ubuntu.com/server/how-to/web-services/install-php/) แนะนำ แล้วเปิดผ่านเบราว์เซอร์ phpinfo() แสดงเวอร์ชันของ PHP ข้อมูลเซิร์ฟเวอร์ และค่าคอนฟิกที่ใช้จริง ทำแยกทุกเว็บที่ตั้งเวอร์ชันต่างกัน และลบไฟล์ทิ้งทันทีหลังตรวจ เพราะหน้านี้เปิดเผยข้อมูลเครื่อง
3. **PHP-FPM pool** แต่ละ pool อาจผูกกับ PHP คนละเวอร์ชัน และ[คู่มือ FPM ของ php.net](https://www.php.net/manual/en/install.fpm.configuration.php) ระบุว่าค่าที่ตั้งด้วย `php_admin_value` ใน pool แอปพลิเคชันแก้ทับด้วย ini_set() ไม่ได้ ให้จดว่า pool ใดใช้เวอร์ชันใด เพราะต้องรีสตาร์ตทุกตัวในขั้นตอนที่ 3
4. **คอนเทนเนอร์และเครื่องที่ไม่ได้ดูแลเอง** ไล่ดู Dockerfile, image ที่รันอยู่ และเว็บที่ฝากไว้กับผู้ให้บริการโฮสติ้ง ซึ่งต้องสอบถามผู้ให้บริการว่าแพตช์แล้วหรือยัง

## ขั้นตอนที่ 2: เลือกแพตช์ PHP2Shell ตามแหล่งที่ติดตั้ง

php.net ระบุว่า distro ลินุกซ์และผู้ให้บริการ LTS ได้รับแพตช์ล่วงหน้า จึงควรอัปเดตจากแหล่งเดิมที่ติดตั้ง PHP ไว้ ไม่ควรเอา PHP จากที่อื่นมาทับ ตารางนี้สรุปว่าแพตช์ PHP2Shell ของแต่ละแหล่งอยู่ในประกาศใด

| ติดตั้ง PHP จาก | ประกาศที่ต้องดู | สิ่งที่แก้แล้ว |
| --- | --- | --- |
| Ubuntu | USN-8948-1 และ USN-8948-2 (21 ต.ค.) | แพ็กเกจ php8.1, php8.3, php8.5 และรุ่นเก่าผ่าน Ubuntu Pro |
| Debian | DSA-6574-1 และ DLA-4848-1 (21 ต.ค.) | php8.4 บน Debian 13 และ php8.2 บน Debian 12 |
| RHEL / Rocky Linux | RHSA-2026:87070, 87071, 87072, 87073, 87079, 87080, 87151 และ RLSA ของ Rocky Linux | php 7.4, 8.0, 8.2, 8.3 และ 8.4 ตามรุ่น RHEL |
| Docker image ทางการ | docker-library/php (21 ต.ค.) | แท็ก 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
| cPanel | EasyApache 4 25.91 (21 ต.ค.) | ea-php82 ถึง ea-php85 และ backport ใน ea-php74 ถึง ea-php81 |
| Plesk | PHP Updates (21 ต.ค.) | 8.2 ถึง 8.5 และ backport ใน 8.1.34, 8.0.30, 7.4.33 |
| DirectAdmin | DA build ใหม่ (21 ต.ค.) | 8.2 ถึง 8.5 และแพตช์สำหรับ 5.6 ถึง 8.1 |
| Windows | php.net/downloads | ไฟล์ zip ของ 8.5.12, 8.4.27, 8.3.36, 8.2.35 |

## Ubuntu: แพตช์ PHP2Shell ผ่าน USN-8948

Canonical จัด CVE-2026-109618 เป็นลำดับความสำคัญ critical และออก USN-8948-1 วันที่ 21 ตุลาคม 2026 สำหรับรุ่นที่ยังได้รับการสนับสนุนปกติ แพ็กเกจที่แก้แล้ว (ทั้ง libapache2-mod-php, php-cgi, php-cli และ php-fpm) มีดังนี้

| Ubuntu | แพ็กเกจ | รุ่นที่แก้แล้ว |
| --- | --- | --- |
| 26.10 | php8.5 | 8.5.9-0ubuntu2.1 |
| 26.04 LTS | php8.5 | 8.5.4-0ubuntu1.5 |
| 24.04 LTS | php8.3 | 8.3.6-0ubuntu0.24.04.13 |
| 22.04 LTS | php8.1 | 8.1.2-1ubuntu2.28 |

![ตารางแพ็กเกจที่แก้แล้วใน USN-8948-1 ของ Ubuntu แยกตามรุ่น 26.10, 26.04 LTS, 24.04 LTS และ 22.04 LTS](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/php2shell-patch-guide-check-php-version/php2shell-guide-ubuntu-usn-8948-1.webp?v=84225c44) _(ภาพ: Ubuntu (ภาพหน้าจอ))_

ส่วน [USN-8948-2](https://ubuntu.com/security/notices/USN-8948-2) ครอบคลุม Ubuntu 20.04, 18.04, 16.04 และ 14.04 ซึ่งได้แพ็กเกจแก้ไขผ่าน Ubuntu Pro เท่านั้น (16.04 และ 14.04 ต้องมี Legacy Support add-on) Canonical ระบุว่าการอัปเดตระบบตามปกติก็พอ [หน้าอธิบายวิธีรับแพตช์ของ Ubuntu](https://ubuntu.com/security/cves/about) ให้คำสั่ง `sudo apt update && sudo apt upgrade` และสำหรับเครื่องที่ใช้ Ubuntu Pro ใช้ `sudo pro fix CVE-2026-109618` ได้

## Debian: แพตช์ PHP2Shell ใน DSA-6574-1 และ DLA-4848-1

Debian ออก DSA-6574-1 วันที่ 21 ตุลาคม 2026 แก้แพ็กเกจ php8.4 บน Debian 13 (trixie) ในรุ่น 8.4.27-1~deb13u1 และทีม Debian LTS ออก DLA-4848-1 วันเดียวกัน แก้ php8.2 บน Debian 12 (bookworm) ในรุ่น 8.2.35-1~deb12u1 ทั้งสองประกาศแนะนำให้อัปเกรดแพ็กเกจ php ของรุ่นนั้น

ณ เวลาที่ตรวจหน้า Debian Security Tracker วันที่ 22 ตุลาคม แพ็กเกจใน forky (testing) ยังเป็น 8.4.26-1 ที่มีช่องโหว่ ส่วน sid (unstable) ได้ 8.4.27-1 แล้ว ใครใช้ testing บนเครื่องที่ให้บริการจริงควรติดตามหน้านี้จนกว่าแพตช์ PHP2Shell จะเข้ามา

## แพตช์ 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?](https://access.redhat.com/articles/11258) ของ Red Hat ให้ใช้ `dnf upgrade` บน RHEL 9 ส่วน Rocky Linux ออก RLSA เลขเดียวกัน (เช่น [RLSA-2026:87079](https://errata.rockylinux.org/RLSA-2026:87079)) สำหรับ Rocky Linux 8, 9 และ 10 เมื่อ 22 ตุลาคม ส่วน[ฐานข้อมูล errata ของ AlmaLinux](https://errata.almalinux.org/) ณ บ่ายวันที่ 22 ตุลาคมยังไม่มีประกาศ ALSA สำหรับสอง CVE นี้ ผู้ใช้ AlmaLinux ควรตรวจซ้ำก่อนสรุปว่าเครื่องได้แพตช์ PHP2Shell แล้ว

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

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

- **[PPA ondrej/php บน Launchpad](https://launchpad.net/~ondrej/+archive/ubuntu/php)** (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](https://rpms.remirepo.net/enterprise/9/php85/x86_64/) มี 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](https://hub.docker.com/_/php) รวม[คอมมิต](https://github.com/docker-library/php/pull/1694) "[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](https://docs.docker.com/reference/cli/docker/buildx/build/) อธิบายว่าจะพยายามดึง image ต้นทางทุกตัวใหม่เสมอ แล้ว deploy คอนเทนเนอร์ชุดใหม่แทนชุดเดิม ข้อควรระวังคือแท็ก `8.1-fpm` บน Docker Hub ถูก push ครั้งล่าสุดวันที่ 31 ธันวาคม 2025 และ `7.4-fpm` ปี 2022 จึงไม่มีแพตช์ PHP2Shell คอนเทนเนอร์ที่ยังใช้สองสายนี้ต้องย้ายไปสาขาที่รองรับ

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

- **cPanel:** [EasyApache 4 รุ่น 25.91](https://docs.cpanel.net/changelogs/easyapache-4-change-log-25/) (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](https://docs.cpanel.net/release-notes/release-notes/) 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](https://docs.plesk.com/release-notes/obsidian/change-log/) วันที่ 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:** ทีมงานประกาศใน[ฟอรัมทางการ](https://forum.directadmin.com/threads/critical-php-updates.82726/page-3)ว่า build ใหม่ขึ้นช่อง current และ stable แล้ว ให้รัน `da update` ตามด้วย `da build php` เพราะ DA อัปเดตตัวเองอัตโนมัติ แต่ PHP ต้องสั่ง build เอง (ยกเว้นเปิด cron ของ CustomBuild) build ถัดมาเพิ่มแพตช์ให้ 7.3, 7.2, 7.1, 7.0 และ 5.6

![change log ของ EasyApache 4 รุ่น 25.91 วันที่ 21 ตุลาคม 2026 แสดงการ backport ใน ea-php74 ถึง ea-php81 และอัปเดต ea-php82 ถึง ea-php85](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/php2shell-patch-guide-check-php-version/php2shell-guide-cpanel-easyapache-25-91.webp?v=21ac9885) _(ภาพ: cPanel (ภาพหน้าจอ))_

## แพตช์ PHP2Shell บน Windows

php.net มีไฟล์ zip ของรุ่นที่แก้แล้วใน[หน้าดาวน์โหลดสำหรับ Windows](https://www.php.net/downloads.php?os=windows&version=8.5) เช่น 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 ว่าทุกเว็บได้เวอร์ชันใหม่จริง

![change log ของ Plesk วันที่ 21 ตุลาคม 2026 แสดงชุด PHP Updates ที่อัปเดต PHP 8.5, 8.4, 8.3, 8.2 และ backport การแก้ CVE-2026-109618 และ CVE-2026-109619 ให้ 8.1.34, 8.0.30 และ 7.4.33](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/php2shell-patch-guide-check-php-version/php2shell-guide-plesk-php-updates.webp?v=3e2703d8) _(ภาพ: Plesk (ภาพหน้าจอ))_

## ขั้นตอนที่ 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](/security/)

## คำถามที่พบบ่อย

### แพตช์ PHP2Shell ต้องอัปเดต PHP เป็นเวอร์ชันไหน?

แพตช์ PHP2Shell จาก php.net คือ PHP 8.5.12, 8.4.27, 8.3.36 และ 8.2.35 ออกเมื่อ 21 ตุลาคม 2026 ถ้าติดตั้ง PHP จากแพ็กเกจของ distro ให้ดูเลขแพ็กเกจในประกาศของผู้ผลิต เพราะบางรายใส่แพตช์ไว้ในเลขเดิม เช่น Ubuntu 24.04 แก้ในแพ็กเกจ php8.3 รุ่น 8.3.6-0ubuntu0.24.04.13

### ใช้ PHP-FPM แทน mod_php ต้องรีบแพตช์ PHP2Shell ไหม?

ต้องแพตช์ PHP2Shell เช่นกัน php.net ระบุว่าทุกการติดตั้งที่ให้บริการเว็บมีความเสี่ยง รวม PHP-FPM, php-cgi, FrankenPHP และ LiteSpeed แต่เสี่ยงที่สุดกับ Apache mod_php Red Hat ประเมินว่าการรันโค้ดผ่าน PHP-FPM ทำได้ยากกว่าในทางปฏิบัติ แต่ยังจัดเป็นระดับ Important และออกแพ็กเกจแพตช์ PHP2Shell แล้ว

### อัปเดต WordPress หรือ Drupal แล้ว ถือว่าแพตช์ PHP2Shell แล้วหรือยัง?

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

### ใช้ PHP 7.4 หรือ 8.1 ที่หมดอายุแล้ว จะแพตช์ PHP2Shell อย่างไร?

php.net ไม่ออกรุ่นใหม่ให้ PHP 8.1 และเก่ากว่า แต่ทีม PHP ทำ backport ซอร์สขั้นต่ำให้ 7.4, 8.0 และ 8.1 สำหรับคนที่คอมไพล์เอง ส่วน cPanel, Plesk, DirectAdmin, Ubuntu Pro และ Red Hat มีแพ็กเกจ backport ของตัวเอง ระยะยาวควรย้ายไปสาขาที่ยังได้รับแพตช์จาก php.net

### ถ้ายังทำแพตช์ PHP2Shell ไม่ได้ ลดความเสี่ยงชั่วคราวอย่างไร?

php.net แนะนำให้ตั้ง memory_limit=-1 ผ่าน php_admin_value ใน FPM pool ลด post_max_size ตั้ง session.upload_progress.enabled=0 และบน PHP 8.5 ตั้ง fatal_error_backtraces=0 แล้วรีสตาร์ต worker ทุกตัว แต่ย้ำว่ามาตรการเหล่านี้ปิดได้บางเส้นทาง ไม่ได้ทำให้เครื่องปลอดภัย แพตช์ PHP2Shell เท่านั้นที่แก้ครบ


## แหล่งอ้างอิง

- [Security advisory: Critical remote code execution vulnerabilities, update now](https://www.php.net/archive/2026.php#2026-10-21-5) — The PHP Group
- [RCE via OOM corruption (GHSA-w8hw-w9fx-j79w)](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) — PHP (GitHub Security Advisory)
- [USN-8948-1: PHP vulnerabilities](https://ubuntu.com/security/notices/USN-8948-1) — Canonical
- [CVE-2026-109618](https://security-tracker.debian.org/tracker/CVE-2026-109618) — Debian Security Tracker
- [RHSB-2026-013 Request handling memory corruption - php (CVE-2026-109618, CVE-2026-109619) - "php2shell"](https://access.redhat.com/security/vulnerabilities/RHSB-2026-013) — Red Hat
- [PHP2Shell — AI uncovers critical vulnerabilities in the backbone of the web](https://www.php2shell.com/) — Wiz Research, OpenAI และ Calif