php2shell (CVE-2026-109618 / 109619) ตรวจด้วย php -v ไม่ได้ — เลขเวอร์ชันที่คลาดเคลื่อนระหว่าง FPM, Docker และดิสโทร

หาก PHP ที่รับคำขอเว็บ (PHP-FPM, mod_php ของ Apache, php-cgi, FrankenPHP, LiteSpeed) เก่ากว่า 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 จะได้รับผลกระทบจาก CVE-2026-109618 และ CVE-2026-109619 ที่เรียกกันว่า php2shell วิธีแก้คืออัปเกรดเป็นเวอร์ชันเหล่านี้ (หรือแพ็กเกจที่แก้แล้วในกรณีแพ็กเกจของดิสโทร) แล้วรีสตาร์ตโปรเซส สิ่งที่ต้องตรวจไม่ใช่ php -v ในเครื่อง แต่เป็น “PHP ที่ให้บริการเว็บจริง” และ “เวอร์ชันของแพ็กเกจที่ติดตั้ง”

บทความนี้เน้นสี่จุดที่การตัดสินจากเลขเวอร์ชันอย่างเดียวนำไปสู่ข้อสรุปที่ผิด ตัวเลขและสถานะทั้งหมดเป็นข้อมูล ณ วันที่ 2026-10-22 และแหล่งที่มาของแต่ละหัวข้อแสดงไว้ท้ายบทความ

สิ่งที่ทราบ ณ วันที่ 2026-10-22

ประกาศของ PHP ระบุว่า “วิธีแก้ที่สมบูรณ์เพียงอย่างเดียวคือการอัปเดต” มาตรการบรรเทาสำหรับช่วงก่อนที่จะอัปเดตได้อยู่ในส่วนหลังของบทความนี้

ข้อควรระวัง 1: php -v กับ PHP ฝั่งเว็บอาจเป็นคนละตัว

php -v ที่พิมพ์ผ่าน SSH แสดงเวอร์ชันของ PHP แบบ CLI ส่วนคำขอเว็บถูกจัดการโดยโปรเซส PHP-FPM หรือ mod_php ที่โหลดอยู่ใน Apache ซึ่งเป็นไบนารีและแพ็กเกจคนละตัว หากคุณติดตั้ง PHP ใหม่เฉพาะสำหรับ CLI, ติดตั้งหลายเวอร์ชันคู่กัน หรือมี FPM pool ที่ชี้ไปยังอีกเวอร์ชัน ฝั่งเว็บก็อาจยังเป็นเวอร์ชันเก่าได้แม้ php -v จะแสดงเวอร์ชันที่แก้แล้ว

มีหลายวิธีในการดูเวอร์ชันจริงของฝั่งเว็บ

# FPM บน Debian / Ubuntu (ชื่อแยกตามเวอร์ชัน)
php-fpm8.3 -v

# FPM บนตระกูล RHEL
php-fpm -v

# ตรวจว่า Apache โหลด mod_php อยู่หรือไม่
apachectl -M | grep -i php

วิธีที่เชื่อถือได้ที่สุดคือให้ PHP ที่รันผ่านเว็บจริงรายงานเวอร์ชันของตัวเอง วางไฟล์ชั่วคราวที่ตั้งชื่อให้เดายาก และลบทิ้งทันทีเมื่อตรวจเสร็จ

<?php echo PHP_VERSION, ' ', PHP_SAPI;

หาก PHP_SAPI เป็น fpm-fcgi แปลว่ารันภายใต้ FPM, apache2handler คือ mod_php, cgi-fcgi คือ CGI อย่าปล่อย phpinfo() ทิ้งไว้ เพราะตัวมันเองก็ทำให้ข้อมูลรั่วไหล

การรีสตาร์ตเป็นอีกขั้นตอนที่พลาดได้ง่าย แม้แพ็กเกจจะถูกแทนที่แล้ว โปรเซส php-fpm หรือ Apache ที่รันอยู่ก็อาจยังรันโค้ดเก่าต่อไป บางระบบรีสตาร์ตอัตโนมัติเมื่ออัปเดตแพ็กเกจ แต่บางระบบไม่ทำ หลังอัปเดตให้รีสตาร์ต FPM / Apache และตรวจเวอร์ชันฝั่งเว็บอีกครั้งด้วยวิธีข้างต้น

ข้อควรระวัง 2: กับ Docker ตัดสินจากชื่อแท็กไม่ได้

อิมเมจทางการ php มี “แท็กที่เปลี่ยนเนื้อหาได้” (moving tag) เช่น 8.3 และ 8.3-fpm ซึ่งเนื้อหาถูกเปลี่ยนแทนที่เรื่อย ๆ และแท็กที่ตรึงเวอร์ชันเช่น 8.3.30

• แม้ moving tag จะถูกเปลี่ยนเป็นเวอร์ชันที่แก้แล้วบน Docker Hub แล้ว สำเนาในเครื่องคุณก็ยังเป็นอิมเมจเก่าจนกว่าจะ pull ใหม่ คอนเทนเนอร์ที่รันอยู่ก็ใช้อิมเมจเก่าต่อไปจนกว่าจะสร้างใหม่ Dockerfile ที่ใช้ FROM php:8.3-fpm ก็ยังบิลด์บนเบสเก่าหากยังค้างอยู่ใน build cache
• แท็กที่ตรึงเวอร์ชันจะเก่าตลอดไปจนกว่าคุณจะเปลี่ยนเลขเอง

ตรวจได้ว่ามีการเผยแพร่แท็กเวอร์ชันที่แก้แล้วหรือยังด้วย Docker Hub API

curl -s "https://hub.docker.com/v2/repositories/library/php/tags?name=8.3.36&page_size=100"

นี่คือผลการสอบถามสี่สายรุ่นเมื่อวันที่ 2026-10-22 (เวลาเป็น UTC)

จากการตรวจครั้งนี้พบสามจุดที่การตัดสินจากตัวเลขอาจทำให้เข้าใจผิด

1. “อัปเดตเมื่อเร็ว ๆ นี้” ไม่ได้แปลว่า “แก้แล้ว” แท็กตรึงเวอร์ชัน 8.3.35 ถูกบิลด์ใหม่ในวันที่ 2026-10-21 แต่ PHP_VERSION ภายในยังเป็น 8.3.35 ให้ดูเวอร์ชันภายใน ไม่ใช่เวลาที่อัปเดต
2. digest ต่างกันแต่เนื้อหาอาจเหมือนกัน 8.3 กับ 8.3.36 มี digest ของแท็ก (ค่าของดัชนีแบบหลายสถาปัตยกรรม) ต่างกัน แต่อิมเมจ amd64 เป็นตัวเดียวกัน และทั้งคู่มี PHP_VERSION=8.3.36 เช่นเดียวกัน สำหรับ 8.3-fpm / 8.3.36-fpm, 8.4-apache / 8.4.27-apache, latest / 8.5.12, 8.5-fpm และ 8.2-fpm ค่า PHP_VERSION ของอิมเมจ amd64 เป็นเวอร์ชันที่แก้แล้ว
3. อิมเมจทางการของ 8.1 และเก่ากว่าไม่มีเวอร์ชันที่แก้แล้ว 8.1-fpm อัปเดตล่าสุดเมื่อ 2025-12-31

ตรวจอิมเมจในเครื่องและคอนเทนเนอร์ที่รันอยู่ได้ดังนี้:

# เวอร์ชัน PHP ของอิมเมจที่ pull ไว้ในเครื่อง
docker image inspect php:8.3-fpm --format '{{range .Config.Env}}{{println .}}{{end}}' | grep PHP_VERSION

# pull ใหม่แล้วสร้างคอนเทนเนอร์ใหม่
docker compose pull
docker compose up -d

# หากบิลด์อิมเมจเอง ให้ pull เบสใหม่ก่อนแล้วจึงบิลด์
docker compose build --pull

# เวอร์ชันภายในคอนเทนเนอร์ที่รันอยู่
docker compose exec app php -r 'echo PHP_VERSION, PHP_EOL;'

ให้แทนที่ app ในคำสั่งสุดท้ายด้วยชื่อ service ของคุณ อิมเมจทางการแต่ละตัวบิลด์ด้วย PHP_VERSION เพียงค่าเดียว เวอร์ชัน CLI ภายในคอนเทนเนอร์จึงตรงกับเวอร์ชัน FPM / Apache ของคอนเทนเนอร์นั้น (ข้อควรระวัง 1 ใช้เมื่อติดตั้ง PHP ลงบนโฮสต์โดยตรง)

FrankenPHP ฝัง PHP ไว้ภายใน เวอร์ชันของ FrankenPHP กับเวอร์ชันของ PHP ที่ฝังจึงเป็นคนละตัวเลข บันทึกการออกรุ่นของ FrankenPHP 1.13.2 ที่เผยแพร่เมื่อ 2026-10-21 ระบุว่าอิมเมจ Docker บิลด์ด้วย PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 และไบนารีแบบ static บิลด์ด้วย PHP 8.5.12

ข้อควรระวัง 3: แพ็กเกจของดิสโทร “แก้แล้วแต่เลขยังเก่า”

Ubuntu และ RHEL นำเฉพาะการแก้ไขไปใส่ในเวอร์ชันเก่า (backport) เลขที่ php -v แสดงจึงยังเก่า การเช็กด้วยตัวเลขแบบ “ต่ำกว่า 8.3.36 จึงมีช่องโหว่” จะตีว่าระบบที่แก้แล้วมีช่องโหว่ ในทางกลับกันก็วางใจจากตัวเลขไม่ได้เช่นกัน ให้ตัดสินจากเวอร์ชันแพ็กเกจและ security tracker ของแต่ละดิสโทร

แพ็กเกจที่แก้แล้วซึ่งระบุไว้ในแต่ละ tracker ณ วันที่ 2026-10-22 (เหมือนกันทั้งสอง CVE):

ตารางนี้แสดงให้เห็นตรง ๆ ว่าทำไมเลขอย่างเดียวจึงไม่พอ PHP ที่แก้แล้วของ Ubuntu 24.04 เป็นเวอร์ชันที่ขึ้นต้นด้วย 8.3.6 ซึ่งต่ำกว่า 8.3.36 ของ upstream มาก PHP ค่าเริ่มต้นของ RHEL 9 แก้แล้วทั้งที่ยังเป็น 8.0.30 แม้ upstream จะไม่ออกการแก้ไขสำหรับ 8.0 อีกแล้ว ส่วน Debian ขยับไปใช้เลขเดียวกับ upstream (8.2.35 / 8.4.27)

บางแพ็กเกจยังไม่ได้แก้ (ณ วันที่ 2026-10-22)

• php module 8.4 ของ RHEL 9 ระบุว่า “ได้รับผลกระทบ ยังไม่มีการแก้ไข”
• Debian forky (testing) มี php8.4 8.4.26-1 ซึ่งระบุว่า “vulnerable” ส่วน php8.4 ใน sid (unstable) เป็น 8.4.27-1 และแก้แล้ว

ตัวอย่างคำสั่งสำหรับตรวจเซิร์ฟเวอร์ของคุณเอง:

# Debian / Ubuntu: เวอร์ชันที่ติดตั้งและเวอร์ชันที่ติดตั้งได้
apt-cache policy php8.3-fpm libapache2-mod-php8.3

# Ubuntu: ตรวจว่า CVE นี้ถูกแก้บนเซิร์ฟเวอร์นี้แล้วหรือยัง
pro fix CVE-2026-109618
pro fix CVE-2026-109619

# ตระกูล RHEL: ตรวจว่ามีอัปเดตที่แก้ CVE นี้หรือไม่ และเวอร์ชันที่ติดตั้ง
dnf updateinfo list --cve CVE-2026-109618
rpm -q php-fpm php-cli

ปรับชื่อแพ็กเกจ (php8.3-fpm ฯลฯ) ให้ตรงกับสภาพแวดล้อมของคุณ เทียบเวอร์ชันที่แสดงกับ “เวอร์ชันที่แก้แล้ว” ในตารางข้างต้นหรือใน tracker หากเท่ากันหรือสูงกว่าแปลว่าการแก้ไขอยู่ในระบบแล้ว จากนั้นให้ทำการรีสตาร์ตและตรวจฝั่งเว็บตามข้อควรระวัง 1 ให้ครบ

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

ข้อควรระวัง 4: บนโฮสติ้งแบบแชร์และสภาพแวดล้อมแบบ managed คุณอัปเกรด PHP เองไม่ได้

บนโฮสติ้งแบบแชร์และสภาพแวดล้อม PHP แบบ managed ผู้ให้บริการเป็นผู้เปลี่ยนรันไทม์ PHP ตรงนี้ก็เช่นกัน เลขอย่างเดียวไม่พอ หากผู้ให้บริการบิลด์ PHP เองหรือทำ backport การแก้ไข เลขเวอร์ชันก็อาจยังเก่า

มีสามอย่างที่คุณทำเองได้

1. ตรวจเวอร์ชันฝั่งเว็บ ใช้ไฟล์ชั่วคราวจากข้อควรระวัง 1 เพื่อพิมพ์ PHP_VERSION และ PHP_SAPI แล้วลบทิ้งทันที หากแผงควบคุมมีตัวเลือกเวอร์ชัน PHP ให้จดไว้ด้วยว่าเลือกเวอร์ชันใดอยู่
2. อ่านประกาศของผู้ให้บริการ และสอบถามหากไม่มี ถามว่า: “การแก้ไข CVE-2026-109618 และ CVE-2026-109619 จะถูกนำมาใช้กับ PHP เวอร์ชันใดในแพ็กเกจของฉัน และเมื่อใด (หรือใช้แล้วหรือยัง)” การถามด้วยหมายเลข CVE แทนเลขเวอร์ชันจะได้คำตอบที่ครอบคลุมถึง backport ด้วย
3. หากเลือกเวอร์ชันที่หมดการสนับสนุนอยู่ ให้อัปเกรด โครงการ PHP ไม่ออกการแก้ไขสำหรับ 8.1 และเก่ากว่า และการสนับสนุน 8.2 สิ้นสุดวันที่ 2026-12-31 หากผู้ให้บริการไม่ได้ทำ backport การแก้ไข การเปลี่ยนเวอร์ชันคือทางที่แน่นอน

สถานะของผู้ให้บริการโฮสติ้งแต่ละราย (ณ วันที่ 2026-10-22)

บนโฮสติ้งแบบแชร์ ผู้ให้บริการมักเป็นผู้อัปเดตรันไทม์ PHP และประกาศของหลายรายระบุว่า “ผู้ใช้ไม่ต้องดำเนินการใด ๆ” สิ่งที่ผู้ใช้ต้องทำมีสองอย่าง คือตรวจประกาศอย่างเป็นทางการของผู้ให้บริการ และหากเลือก PHP เวอร์ชันเก่าไว้ในแผงควบคุม ให้พิจารณาว่าจะเปลี่ยนไปใช้เวอร์ชันที่ประกาศแนะนำ (เวอร์ชันที่มีรุ่นที่แก้แล้ว) หรือไม่

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

ในกรณีที่ผมหาประกาศอย่างเป็นทางการไม่พบหรือเปิดไม่ได้ ตารางระบุว่า “ยืนยันไม่ได้” หรือ “ไม่พบ” การไม่มีข้อมูลตรงนั้นไม่ได้แปลว่าผู้ให้บริการยังไม่ได้ดำเนินการ ควรตรวจสอบโดยตรงจากประกาศและฝ่ายสนับสนุนของผู้ให้บริการของคุณ

มาตรการบรรเทาระหว่างที่ยังอัปเดตทันทีไม่ได้

ประกาศของ PHP ระบุการตั้งค่าที่ช่วยลดพื้นที่การโจมตีจนกว่าจะอัปเดตได้ อย่างไรก็ตาม ประกาศเองระบุชัดเจนว่าการตั้งค่าเหล่านี้ “ไม่ได้ทำให้คุณปลอดภัย” รายการหลัก ๆ คือ:

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

NCSC ของสหราชอาณาจักรแนะนำให้พิจารณานำระบบที่อัปเดตหรือบรรเทาทันทีไม่ได้ออฟไลน์ และตรวจหาร่องรอยการถูกเจาะระบบก่อนอัปเดตหรือใช้มาตรการบรรเทา

แหล่งที่มา (ตรวจสอบเมื่อ 2026-10-22)

• php.net: Security advisory: Critical remote code execution vulnerabilities, update now (2026-10-21)
• php.net: Upcoming Critical PHP Security Release (2026-10-20)
• php.net: ประกาศการออกรุ่นของ PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
• GitHub: GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GitHub: GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Docker Hub: อิมเมจ php อย่างเป็นทางการ
• บันทึกการออกรุ่น FrankenPHP 1.13.2
• Debian Security Tracker: CVE-2026-109618 / CVE-2026-109619
• Ubuntu: CVE-2026-109618 / CVE-2026-109619 / USN-8948-1 / USN-8948-2
• Red Hat: CVE-2026-109618 / CVE-2026-109619 (เวอร์ชันของแพ็กเกจที่แก้ไขแล้วดูจาก ข้อมูล VEX ของ Red Hat)
• NCSC: Critical security issue affecting PHP