ยังใช้ PHP 7.4, 8.0 หรือ 8.1 อยู่ จะรับมือ PHP2Shell อย่างไรเมื่อ PHP ไม่ออกเวอร์ชันแก้ให้
ยังใช้ PHP 7.4, 8.0 หรือ 8.1? PHP ไม่ออกเวอร์ชันแก้ PHP2Shell ให้ มีแค่ source backport ดูวิธีเลือกระหว่างย้าย branch ใช้แพ็กเกจของ vendor build เอง หรือแยกระบบ
ยังใช้ PHP 7.4, 8.0 หรือ 8.1 อยู่ จะรับมือ PHP2Shell อย่างไรเมื่อ PHP ไม่ออกเวอร์ชันแก้ให้
วันที่ 21 ตุลาคม 2026 PHP ออก 8.5.12, 8.4.27, 8.3.36 และ 8.2.35 เพื่อปิด PHP2Shell (สรุปตัวช่องโหว่อ่านได้ที่นี่) แต่ไม่มีเวอร์ชันใหม่ของ 7.4, 8.0 หรือ 8.1 เพราะทั้งสาม branch หมดอายุไปแล้ว ทีมที่ดูแลระบบเหล่านี้ต้องเลือกทางจากตัวเลือกด้านล่าง
คำตอบสั้น: ทีม security ของ PHP ทำ source backport ไว้ให้ 7.4, 8.0 และ 8.1 แต่ไม่ได้ออกเป็น release และไม่มีเลขเวอร์ชันใหม่ ให้ไล่ตามลำดับนี้
- ย้ายไป branch ที่ยังได้ security fix ถ้าทำได้
- ถ้ายังย้ายไม่ได้ ใช้แพ็กเกจที่ distro หรือ vendor แก้มาแล้ว
- ถ้าไม่มีทั้งสองทาง และทีม build PHP จาก source เป็นอยู่แล้ว ค่อย build จาก backport เอง
- ถ้าไม่เข้าข้อไหนเลย ให้เอาระบบออฟไลน์ตามที่ CISA แนะนำ หรือแยกออกจากเครือข่ายสาธารณะตามที่ศูนย์ไซเบอร์ของแคนาดาแนะนำ
ระหว่างที่ยังอัปเดตไม่ได้ ใช้ข้อ 4 ไปก่อนได้เลย ไม่ต้องรอให้ข้อ 1 ถึง 3 ล้มเหลว ส่วนเครื่องที่ใช้ 8.2 มี 8.2.35 ให้แพตช์ได้ทันที แต่ต้องวางแผนย้ายต่อ เพราะ 8.2 หมดอายุวันที่ 31 ธันวาคม 2026
ขั้นที่ 1: ย้ายไป branch ไหนดี ดูจากตารางอายุของ php.net
ถ้าจะย้ายจาก 7.4 หรือ 8.1 ให้เล็งที่ 8.3 ขึ้นไป ถ้าทำได้ 8.4 หรือ 8.5 จะคุ้มกว่า เพราะย้ายไป 8.2 ตอนนี้ได้อายุเพิ่มแค่ราวสองเดือน งานหลักของการย้ายคือทดสอบแอปกับ PHP ตัวใหม่ ซึ่งอยู่นอกขอบเขตบทความนี้
CVE record ของ PHP2Shell ระบุเวอร์ชันที่ได้รับผลกระทบไว้แค่ 8.2 ถึง 8.5 ส่วน 7.3 และเก่ากว่า watchTowr และ Tenable ซึ่งเป็นบุคคลที่สามประเมินว่าได้รับผลกระทบด้วย และ PHP ไม่มี fix ให้ วันที่ด้านล่างมาจาก php.net ณ 25 ต.ค.
| Branch | สถานะ (php.net) | ได้ security fix ถึง | release ล่าสุด | release หรือ source backport จาก PHP |
|---|
| 7.2 และเก่ากว่า | หมดอายุ | — | — | ไม่มี fix จาก PHP |
| 7.3 | หมดอายุ 6 ธ.ค. 2021 | — | 7.3.33 | ไม่มี fix จาก PHP |
| 7.4 | หมดอายุ 28 พ.ย. 2022 | — | 7.4.33 | มีแค่ source backport |
| 8.0 | หมดอายุ 26 พ.ย. 2023 | — | 8.0.30 | มีแค่ source backport |
| 8.1 | หมดอายุ 31 ธ.ค. 2025 | — | 8.1.34 | มีแค่ source backport |
| 8.2 | ได้แค่ security fix | 31 ธ.ค. 2026 | 8.2.35 | release ที่แก้แล้ว |
| 8.3 | ได้แค่ security fix | 31 ธ.ค. 2027 | 8.3.36 | release ที่แก้แล้ว |
| 8.4 | active support ถึง 31 ธ.ค. 2026 | 31 ธ.ค. 2028 | 8.4.27 | release ที่แก้แล้ว |
| 8.5 | active support ถึง 31 ธ.ค. 2027 | 31 ธ.ค. 2029 | 8.5.12 | release ที่แก้แล้ว |
ถ้าเครื่องในองค์กรกระจายอยู่หลาย branch จนไล่ตารางนี้ด้วยมือไม่ไหว ดูแพ็กเกจและราคาประกอบการตัดสินใจได้
Source backport คืออะไร ทำไมเลขเวอร์ชันถึงไม่เปลี่ยน
php.net บอกว่าเพราะช่องโหว่ร้ายแรง ทีม security จึงทำ "minimal source-backports" ให้ 7.4, 8.0 และ 8.1 สำหรับคนที่ build PHP เองหรือไม่มี LTS vendor ตัว backport อยู่ใน Git branch ของ php-src แยกตามเวอร์ชัน คือ 7.4, 8.0 และ 8.1
แต่ละ branch มี commit เพิ่มมาหนึ่งตัว ชื่อ "Avoid state corruption via bailout" ข้อความ commit เขียนว่า "Minimal mitigation for EOL version." และระบุว่าแก้ทั้ง CVE-2026-109618 และ CVE-2026-109619 คือ commit เดียวปิดทั้งสองตัว
แต่ไม่มี release ไม่มี tag ใหม่หรือ tarball และ advisory ทั้งสองฉบับของ PHP ระบุ patched versions ไว้แค่ 8.2.35, 8.3.36, 8.4.27 และ 8.5.12
เลขเวอร์ชันจึงใช้เป็นหลักฐานไม่ได้ commit backport ไม่ได้แตะไฟล์เวอร์ชัน ถ้า build จาก branch ของ 8.0 หรือ 8.1 ค่าใน configure.ac ยังเป็น 8.0.30 และ 8.1.34 phpversion() จะตอบเลขเดิมเป๊ะ ส่วน branch ของ 7.4 มีค่า 7.4.34-dev ค้างมาจาก commit ปี 2022 ซึ่งก็ไม่ใช่ release
แพ็กเกจของ vendor ก็คล้ายกัน เลข upstream อาจเท่าเดิม แต่เลข release ของแพ็กเกจอาจเปลี่ยน เช่น Synology 8.1.34-0120 ส่วน Plesk ใช้เลขเดิมแต่วันที่ build ใหม่
ขั้นที่ 2: ใช้ fix จาก distro หรือ vendor
ตารางนี้คือสิ่งที่เห็นบนหน้าของ vendor ณ 25 ตุลาคม 2026 advisory ฉบับปัจจุบันของ vendor คือข้อมูลที่ต้องยึด เปิดลิงก์ในแถวนั้นดูก่อนลงมือ รวมถึงรายการ "ยังไม่ยืนยัน" และ "ไม่มี fix" ด้านล่าง
| แหล่ง | branch เก่าที่มี fix | วิธีเช็ค |
|---|
| Ubuntu 22.04 (ฟรี) | php8.1 | 8.1.2-1ubuntu2.28 ขึ้นไป |
| Ubuntu Pro (ESM) | php7.4 (20.04), php7.2 (18.04), php7.0 (16.04), php5 (14.04) | เช่น php7.4 คือ 7.4.3-4ubuntu2.29+esm5 |
| Red Hat (RHSA-2026:87080, RHSA-2026:87151) | module php:7.4 บน RHEL 8, php 8.0 บน RHEL 9 | เลขแพ็กเกจตาม RHSA |
| AlmaLinux | ทุก PHP stream บน 8, 9 และ 10 | เทียบ rpm -q php-common กับประกาศ (PHP 8.4 บน AlmaLinux 10 ใช้ rpm -q php8.4-common) |
| cPanel EasyApache 4 | ea-php74, ea-php80, ea-php81 | 25.91 ระบุ backport ส่วน 25.92 rebuild ea-php74-meta, ea-php80-meta, ea-php81-meta ให้ changelog ระบุด้วย |
| CloudLinux | alt-php 5.2–5.6, 7.0–7.4 และ 8.0–8.5, ea-php52 ถึง ea-php85 | changelog ของแพ็กเกจ alt-php (คำสั่งด้านล่าง) |
| Plesk for Linux | 7.4.33, 8.0.30, 8.1.34 | วันที่ build 21 ต.ค. 2026 หรือหลังจากนั้น |
| DirectAdmin CustomBuild | 8.1, 8.0, 7.4 ตามด้วย 7.3, 7.2, 7.1, 7.0 และ 5.6 | มี * ต่อท้ายเวอร์ชัน |
| Synology | แพ็กเกจ PHP 7.4, 8.0, 8.1 | 7.4.33-0131, 8.0.30-0122, 8.1.34-0120 ขึ้นไป |
แพ็กเกจ alt-php ของ CloudLinux เช็คได้ด้วยคำสั่งนี้ (อ่านอย่างเดียว เปลี่ยนเลขเวอร์ชันในชื่อแพ็กเกจตามเครื่อง) ควรเจอทั้งสอง CVE:
rpm -q --changelog alt-php74-common | grep -E "CVE-2026-(109618|109619)"
ข้อยกเว้นคือ PHP 8.2 และ 8.3 แบบ native ที่ rebase เป็น 8.2.35 หรือ 8.3.36 ซึ่ง changelog ไม่ระบุ CVE ให้ดูเลขจาก rpm -q php-cli แทน คำสั่งเหล่านี้ดูแค่แพ็กเกจที่ติดตั้ง ไม่ได้บอกว่าเว็บใช้แพ็กเกจนั้นอยู่
ขั้นตอนอัปเดตอยู่ในบทความเรื่อง hosting panel และเรื่องเซิร์ฟเวอร์ของตัวเอง ส่วน PHP ในอุปกรณ์ ดูอุปกรณ์ที่มี PHP อยู่ข้างใน เช่น hotfix ของ Check Point ที่ใช้ fix 7.4 ของ PHP
ยังไม่ยืนยัน: build ใหม่ของ php7.4, 8.0 และ 8.1 บน PPA ของ Ondřej Surý มี changelog แค่ "No-change backport" ส่วน package index ของ deb.sury.org มีรายการลงวันที่ 21 ต.ค. แต่ไม่ได้บอกว่าแก้ CVE หรือไม่ Remi, Freexian ELTS, TuxCare ELS และ ZendPHP LTS มีแค่ Sansec ที่บอกว่ามี fix ถ้าจะใช้ ให้ขอคำยืนยันเป็นลายลักษณ์อักษรว่าแก้ทั้งสอง CVE
ไม่มี fix (ณ 25 ต.ค.): image ทางการ php:8.1 และ php:8.0 บน Docker Hub ยังไม่ถูก build ใหม่ และ Azure App Service แจ้งว่า PHP รุ่นที่หมดอายุจะไม่ได้แพตช์นี้
ขั้นที่ 3: build จาก backport เอง ทำเมื่อทีมทำเป็นเท่านั้น
ทางนี้เสี่ยงที่สุด เหมาะกับทีมที่ build และดูแล PHP จาก source อยู่แล้วเท่านั้น ถ้า PHP มาจากแพ็กเกจของ distro อย่าเอา build มือไปทับ บทความนี้จึงไม่ให้คำสั่ง build ทีมที่ทำเป็นให้ทำตาม README ของ php-src และยึดหลักนี้
- build ด้วย option เดิม คู่มือ PHP บอกว่า
php-config --configure-options คืนค่า option ที่ใช้สร้าง PHP ตัวที่ติดตั้งอยู่
- build จาก branch ที่ถูกต้องและจดที่มา commit ของ backport คือ
1d7dec178a094e6e75b229ce22754045f8c6070a (8.1), 82f8f31b16a035c1b67cc253e79f7cc288f4cc20 (8.0) และ 712e60f9edfd03f0960fc4fc3c2c375f42b90aa2 (7.4) จด commit SHA ไว้คู่กับ build เพราะดูเลขเวอร์ชันอย่างเดียวจะไม่รู้ว่ามี backport นี้แล้วหรือยัง
- ลองบน staging ก่อน deploy
ถ้าจะเช็ค source tree ที่ใช้ build คำสั่งนี้ (อ่านอย่างเดียว) จบด้วย exit status 0 เมื่อ commit นั้นเป็น ancestor ของ HEAD ตามเอกสารของ Git:
git merge-base --is-ancestor 1d7dec178a094e6e75b229ce22754045f8c6070a HEAD && echo "commit นี้เป็น ancestor ของ HEAD"
ผลนี้บอกแค่ประวัติ commit ไม่ได้บอกว่าโค้ดไม่ถูก revert, working tree ตรงกับที่ build หรือ binary ที่รันอยู่มาจาก tree นี้ จึงยังต้องมีบันทึกการ build และการเช็คจากฝั่งเว็บแยกกัน Bitdefender มองว่าการย้าย branch เป็นทางเดียวที่เชื่อถือได้
ขั้นที่ 4: เอาออฟไลน์หรือแยกออก ระหว่างที่ยังอัปเดตไม่ได้
alert ของ CISA (แก้ไขล่าสุด 23 ต.ค.) เขียนว่าองค์กรที่อัปเดตทันทีไม่ได้ หรือยังใช้ PHP 8.1 หรือเก่ากว่าที่หมดการซัพพอร์ตแล้ว ควร "take PHP-based systems offline until they can be patched or updated" และบอกว่า WAF อาจช่วยป้องกันได้บางส่วน โดยไม่ได้พูดถึง backport ส่วนศูนย์ไซเบอร์ของแคนาดาแนะนำให้แยกแอปที่เปิดสู่อินเทอร์เน็ตออกจากเครือข่ายสาธารณะจนกว่าจะแก้
ค่าชั่วคราวที่ PHP แนะนำลดความเสี่ยงได้บางเส้นทางแต่ไม่ทำให้ปลอดภัย ดูWAF ช่วยได้แค่ไหนระหว่างรอแพตช์ และเครื่องที่เปิดสู่อินเทอร์เน็ตมาตั้งแต่ 17 ต.ค. ควรไล่หาร่องรอยใน log ด้วย
ยืนยันว่าได้ผลจริง
- restart PHP worker ทุกตัว ThaiCERT อธิบายว่าต้อง restart PHP-FPM, Apache หรือ LiteSpeed เพื่อให้ binary ที่แก้แล้วถูกโหลด
- เช็ค runtime จากฝั่งเว็บ ตามวิธีในเช็คเวอร์ชัน PHP ทุกเว็บ แล้วเทียบกับบันทึกแพ็กเกจหรือ build ที่ยืนยันแล้ว เพราะเลข upstream อาจเท่าเดิม บน Linux ที่ใช้ systemd เวลาเริ่มของ service จาก
systemctl status <ชื่อ service> เป็นแค่หลักฐานประกอบ เพราะไม่ได้บอกว่า worker ครบทุกตัวหรือ binary ไหนเสิร์ฟเว็บไหน
- เก็บหลักฐานต่อเครื่อง คือเลขแพ็กเกจหรือวันที่ build, เอกสาร vendor หรือ commit SHA และผลเช็คจากฝั่งเว็บ
ถ้ายังใช้ AppServ รุ่นเก่า
AppServ รุ่นล่าสุดคือ 9.3.0 (29 กันยายน 2019) มาพร้อม PHP 7.3.10 ไม่มีรุ่นใหม่กว่านี้ และ PHP ไม่ได้ทำ source backport ให้ 7.3 จึงไม่มีทั้งอัปเดตจาก AppServ และขั้นที่ 3 vendor บางรายในขั้นที่ 2 มีแพ็กเกจ 7.3 ที่แก้แล้ว แต่เราไม่ได้ตรวจว่าใช้แทน AppServ ได้หรือไม่ ทางที่ชัดคือย้ายไป PHP ที่ยังซัพพอร์ต และระหว่างนั้นแยกเครื่องออกจากอินเทอร์เน็ต วิธีย้ายเครื่อง AppServ และ XAMPP อยู่ในอัปเดต PHP บนเซิร์ฟเวอร์ของตัวเอง
บทความนี้ไม่ครอบคลุม
- ความครบถ้วนของ backport ของ vendor ซึ่งมีแค่ vendor ที่ยืนยันได้
- backport ปิดแค่สอง CVE นี้ branch นั้นยังหมดอายุเหมือนเดิม
- ทุกขั้นตอนบอกว่าแก้แล้วหรือยัง ไม่ได้บอกว่าเครื่องโดนเจาะไปก่อนหรือเปล่า ถ้าสงสัยให้ดูลำดับงานเมื่อเว็บอาจโดนเจาะ
เตรียมรอบหน้า: 8.2 หมดอายุ 31 ธันวาคม 2026
งานนี้จะวนกลับมาอีกตอน 8.2 หมดอายุ จดไว้ตั้งแต่ตอนนี้ว่าเครื่องไหนรัน PHP branch อะไร มาจากแพ็กเกจไหน และหมดอายุวันไหน รอบหน้าจะเริ่มได้ทันที ถ้าไม่อยากดูแลรายการนี้ด้วยมือ zcrX ช่วยติดตาม product lifecycle และวันหมดอายุการสนับสนุน (EOL) ของแต่ละซอฟต์แวร์ได้ แต่ไม่ได้มาแทนการแพตช์หรือการย้าย branch
📞 ปรึกษาฟรี
zcr ให้ซอฟต์แวร์ ส่วนงานย้าย branch หรือ build แบบลงมือจริงดำเนินการผ่านพาร์ทเนอร์
บทความที่เกี่ยวข้อง
แหล่งข้อมูลอ้างอิง
- PHP News Archive 2026 — เวอร์ชันที่แก้แล้ว, source backport ของ 7.4/8.0/8.1 และเหตุผล, 8.1 ลงไปไม่ได้อัปเดตจาก PHP, 8.2 หมดอายุ 31 ธ.ค. 2026, ค่าชั่วคราวที่ไม่ทำให้ปลอดภัย
- PHP — Supported Versions และ PHP — Unsupported Branches — วันหมดอายุของแต่ละ branch และ release ล่าสุด
- php-src บน GitHub: branch PHP-7.4, PHP-8.0, PHP-8.1 และ commit 1d7dec1 (8.1) — ข้อความ commit, จำนวนไฟล์, ค่าเวอร์ชันใน
configure.ac
- GHSA-w8hw-w9fx-j79w (CVE-2026-109618) และ GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) — patched versions
- php-src README — Building PHP source code, PHP Manual — php-config และ Git — git-merge-base
- CISA — Critical Vulnerabilities in PHP Require Immediate Patching — คำแนะนำสำหรับ 8.1 ลงไป และ WAF
- Canadian Centre for Cyber Security AL26-026 — การแยกแอปออกจากเครือข่ายสาธารณะ
- Ubuntu USN-8948-1 และ USN-8948-2; Red Hat RHSA-2026:87080 และ RHSA-2026:87151; AlmaLinux
- cPanel EasyApache 4 change log, CloudLinux status, Plesk, DirectAdmin forum (staff), Synology-SA-26:14
- Check Point sk1000302
- Launchpad — ppa:ondrej/php, deb.sury.org และ Sansec — PHP2Shell — แหล่งที่ยังไม่ยืนยัน
- Docker Hub — php และ Azure App Service
- Bitdefender — PHP2Shell technical advisory
- watchTowr — PHP2Shell และ Tenable — PHP2Shell FAQ — 7.3 และเก่ากว่า
- ThaiCERT — แจ้งเตือน พบช่องโหว่ PHP2Shell (22 ต.ค. 2026) — การ restart worker หลังอัปเดต
- systemctl(1) — คำสั่ง
status
- AppServ — Download — AppServ 9.3.0, PHP 7.3.10, 2019-09-29
