PHP2Shell คืออะไร? ช่องโหว่ PHP ร้ายแรงที่ทำให้เว็บทั่วโลกต้องปิดชั่วคราว ใครกระทบ แก้อย่างไร 2569

1. เกิดอะไรขึ้น ไทม์ไลน์ 3 วันที่ทำให้เว็บทั่วโลกปิดชั่วคราว

PHP เป็นภาษาที่อยู่เบื้องหลังเว็บไซต์ 69.3% ของเว็บทั้งหมดที่ระบุภาษาฝั่งเซิร์ฟเวอร์ได้ (W3Techs, 22 ตุลาคม 2569) ตั้งแต่ WordPress, Joomla, Drupal ไปจนถึงระบบภายในองค์กรที่จ้างพัฒนา เมื่อทีม PHP ประกาศล่วงหน้าคืนวันที่ 20 ตุลาคมว่าจะออกแพตช์ "ช่องโหว่ระดับวิกฤต 2 รายการ" และเลข CVE (Common Vulnerabilities and Exposures คือรหัสกลางที่ทั่วโลกใช้อ้างถึงช่องโหว่) หลุดออกมาก่อนกำหนด หน่วยงานหลายประเทศจึงเลือกปิดเว็บชั่วคราวแทนการรอ

2. ช่องโหว่ 2 ตัวคืออะไร อธิบายแบบไม่ต้องอ่านโค้ด

ทั้งสองรายการอยู่ใน "ตัวเครื่องยนต์" ของ PHP เอง ไม่ใช่ในปลั๊กอิน ธีม หรือโค้ดที่คุณเขียน Wiz ซึ่งเป็นหนึ่งในผู้ค้นพบสรุปว่า แอป Hello World ที่ไม่มีอะไรเลยบน PHP เวอร์ชันที่กระทบก็โจมตีได้ และแอปไม่จำเป็นต้องเรียกใช้ session เลยด้วยซ้ำ

ทั้งคู่ได้คะแนน CVSS (Common Vulnerability Scoring System คือมาตรวัดความรุนแรงของช่องโหว่) เวอร์ชัน 4.0 เท่ากันที่ 9.2 จาก 10 ระดับวิกฤต เวกเตอร์ระบุว่าโจมตีผ่านเครือข่าย ไม่ต้องมีสิทธิ์ ไม่ต้องให้ผู้ใช้คลิกอะไร แต่ "ความซับซ้อนสูง" เพราะผู้โจมตีต้องจัดเรียงหน่วยความจำให้ตรงกับ PHP แต่ละรุ่น แต่ละ build และแต่ละเว็บเซิร์ฟเวอร์ Wiz บอกว่าโมเดล AI ช่วยปรับโค้ดโจมตีให้เข้ากับแต่ละเวอร์ชันได้เร็วขึ้นมาก และนักวิจัยคนเดียวทำงานที่เคยต้องใช้ทีมระดับโลกหลายเดือนเสร็จในสัปดาห์เดียว ส่วน watchTowr ให้คะแนนเองที่ 10.0

3. ใครกระทบบ้าง

3.1 ทุกเวอร์ชันในรอบสิบกว่าปี ทุกวิธีติดตั้งที่รับ request จากเว็บ

ช่วงเวอร์ชันที่กระทบคือ PHP 5.4 (ออกปี 2555) จนถึง 8.5.11 ทีม PHP ระบุว่าความเสี่ยงครอบคลุม "ทุกการติดตั้ง PHP ที่รับ request จากเว็บ" ไม่ว่าจะรันผ่านวิธีไหน (SAPI, Server API คือตัวกลางที่เว็บเซิร์ฟเวอร์ใช้เรียก PHP) ระดับความเสี่ยงต่างกันตามวิธีรัน

3.2 ซอฟต์แวร์ที่หน่วยงานไทยใช้แล้ว "มี PHP ซ่อนอยู่"

หลายองค์กรตอบว่า "เราไม่ได้เขียน PHP" แต่มี PHP รันอยู่โดยไม่รู้ตัว รายการนี้คือซอฟต์แวร์ที่เขียนด้วย PHP ซึ่งพบบ่อยในหน่วยงานรัฐ มหาวิทยาลัย และบริษัทไทย

3.3 ขนาดของปัญหาเป็นตัวเลข

• W3Techs (22 ต.ค. 2569): PHP ใช้ใน 69.3% ของเว็บที่ระบุภาษาได้ และในกลุ่มเว็บ PHP นั้น PHP 7 ยังมี 26.9% PHP 5 อีก 7.7% รวมแล้วราว 1 ใน 3 เป็นเวอร์ชันที่หมดอายุและไม่มีแพตช์ทางการ
• Qualys (ข้อมูลจากลูกค้า 12,000 ราย): พบ PHP 167 ล้านชุดติดตั้ง 73% อยู่บนเครื่องที่ต่ออินเทอร์เน็ต และ 71% ของชุดที่รู้เวอร์ชันเป็นรุ่นหมดอายุ (5.4 ถึง 8.1) ใน 12 ชั่วโมงแรกหลังเปิดเผย อัปเดตไปแล้วเพียง 199,000 ชุด
• VirusTotal (ผ่าน BleepingComputer): โฮสต์ PHP ที่มองเห็นจากอินเทอร์เน็ตมากกว่า 5.1 ล้านเครื่อง ราว 3.8 ล้านเครื่องมีพอร์ตเปิดอย่างน้อยหนึ่งพอร์ต

3.4 ในประเทศไทย

22 ตุลาคม 2569 ศ.ดร.ยศชนัน วงศ์สวัสดิ์ รองนายกรัฐมนตรีและรัฐมนตรีว่าการกระทรวงการอุดมศึกษา วิทยาศาสตร์ วิจัยและนวัตกรรม (อว.) สั่งหน่วยงานในกำกับ โดยเฉพาะมหาวิทยาลัย โรงพยาบาล และโรงเรียนแพทย์ ดำเนินการ 3 ขั้น (1) ให้ฝ่าย IT ตรวจทุกเว็บและระบบที่ใช้ PHP เริ่มจากระบบข้อมูลผู้ป่วยและฐานข้อมูลนักศึกษา (2) เปิดมาตรการชั่วคราว เช่น WAF (Web Application Firewall คือด่านกรอง request ก่อนถึงเว็บ) และเฝ้าระวังการใช้งานผิดปกติ (3) ทดสอบและอัปเกรด PHP โดยเร็ว เพราะมาตรการชั่วคราวแทนการแก้ซอฟต์แวร์ไม่ได้

ด้านนายภราดร ปริศนานันทกุล รัฐมนตรีประจำสำนักนายกรัฐมนตรี ซึ่งกำกับ สกมช. (สำนักงานคณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติ) ให้ ThaiCERT ดำเนินการ 4 ด้าน แจ้งเตือนหน่วยงานรัฐและโครงสร้างพื้นฐานสำคัญ ประเมินความเสี่ยงระบบที่ต่ออินเทอร์เน็ต เฝ้าระวังพฤติกรรมการโจมตี และติดตามผลการแก้ไข ยังไม่มีการเปิดเผยจำนวนระบบของไทยที่กระทบ และยังไม่มีรายงานยืนยันว่าหน่วยงานใดถูกเจาะ

สำหรับหน่วยงานรัฐ เรื่องนี้ต่อเนื่องกับมาตรฐาน Website Security ของ สกมช. ที่เริ่มบังคับใช้เดือนกันยายน 2569 ซึ่งกำหนดเรื่องการอัปเดตซอฟต์แวร์และการจัดการช่องโหว่ไว้อยู่แล้ว และย้ำภาพที่เราเขียนไว้ในบทความภัยไซเบอร์ไทยสูงกว่าค่าเฉลี่ยโลก ว่าเครื่องที่ต่ออินเทอร์เน็ตในไทยถูกสแกนตลอดเวลา

4. ต้องแก้ยังไง ทำตามลำดับนี้

ขั้นที่ 1 หาให้เจอก่อนว่ามี PHP อยู่ตรงไหน

คำสั่ง php -v บอกแค่ PHP ตัวที่อยู่ใน PATH ของ shell ซึ่งอาจไม่ใช่ตัวที่รับเว็บอยู่จริง (Qualys และ Datadog เตือนตรงกัน) ให้ดูจาก process ที่รันอยู่และแพ็กเกจที่ติดตั้ง รวมถึง container ทุกตัว

# Linux: มี PHP ตัวไหนรันรับเว็บอยู่บ้าง
ps -eo pid,user,cmd | grep -E 'php-fpm|php-cgi|httpd|apache2|litespeed|frankenphp' | grep -v grep
# Apache โหลด mod_php หรือไม่
apachectl -M 2>/dev/null | grep -i php
# แพ็กเกจบน Debian / Ubuntu
dpkg -l | grep -E '^ii\s+(php|libapache2-mod-php)'
# แพ็กเกจบน RHEL / Rocky / AlmaLinux
rpm -qa | grep -E '^php'
# Docker: image ที่มี PHP
docker ps --format '{{.Names}} {{.Image}}' | grep -i php

เวอร์ชันที่ผู้ให้บริการ Linux แก้ให้แบบ backport มักยังแสดงเลขเวอร์ชันเดิม เช่น 8.1.2 บน Ubuntu 22.04 ให้ดูจาก changelog ของแพ็กเกจว่ามีเลข CVE-2026-109618 หรือไม่ ไม่ใช่ดูจากเลขเวอร์ชันอย่างเดียว

apt changelog php8.1-fpm | head -30        # Debian / Ubuntu
rpm -q --changelog php-fpm | head -30      # RHEL ตระกูล

ขั้นที่ 2 อัปเดต แล้ว restart worker ทุกตัว

PHP 8.2 เองจะหมดอายุในวันที่ 31 ธันวาคม 2569 นี้ (อีกราว 2 เดือน) ถ้าจะลงแรงอัปเกรดรอบนี้ ให้ข้ามไป 8.3 หรือ 8.4 ที่ได้รับแพตช์ความปลอดภัยถึงสิ้นปี 2570 และ 2571 ตามลำดับ

ขั้นที่ 3 ถ้ายังอัปเดตไม่ได้ในชั่วโมงนี้ มาตรการชั่วคราวที่ทีม PHP ให้ไว้

; ตัวอย่างใน php.ini ของ FPM หรือใส่เป็น php_admin_value[...] ใน pool (เช่น /etc/php/8.3/fpm/pool.d/www.conf)
memory_limit = -1
post_max_size = 8M
upload_max_filesize = 4M
max_input_nesting_level = 16          ; ปรับตามที่แอปต้องการ ค่าเริ่มต้น 64
session.upload_progress.enabled = 0
fatal_error_backtraces = 0            ; เฉพาะ PHP 8.5
; แล้ว restart ทุก worker
; systemctl restart php8.3-fpm apache2

ขั้นที่ 4 ตรวจว่าโดนไปแล้วหรือยัง ย้อนหลังถึง 17 ตุลาคม

AWS แนะนำให้เริ่มสืบสวนจากวันที่เห็นการโจมตีครั้งแรกคือ 17 ตุลาคม ไม่ใช่วันที่แพตช์ออก สัญญาณที่ Wiz, Datadog และ AWS ให้ไว้มีดังนี้

• log ของ PHP มีข้อความ Allowed memory size of … bytes exhausted ตามด้วย Unknown on line 0 (หมายถึงหน่วยความจำหมดตั้งแต่ก่อนรันโค้ดแอป) และ log ของ Apache มี AH00052 … Segmentation fault (11) ถี่ผิดปกติ
• POST แบบฟอร์มอัปโหลดที่มีข้อความ PHP_SESSION_UPLOAD_PROGRESS ในช่วงเวลาที่ไม่มีใครอัปโหลดไฟล์
• request แบบ form-urlencoded ที่ชื่อฟิลด์ยาวผิดปกติระดับ 3.5 MB หรือมีข้อมูลไบนารีในฟิลด์ที่ไม่มีชื่อ (ตรวจว่า WAF หรือ proxy ไม่ได้ตัด body ยาว ๆ ทิ้งก่อนบันทึก)
• response ที่ตั้งคุกกี้ PHPSESSID ยาวผิดปกติหรือมีตัวอักษรแปลก ซึ่งเป็นสัญญาณของการอ่านหน่วยความจำออกไป
• multipart request จำนวนมากตามด้วย HTTP 500 หรือ worker ถูกสร้างใหม่บ่อยโดยไม่มีสาเหตุ
• สัญญาณที่หนักที่สุด: process ของ PHP (php-fpm, apache2 หรือ httpd) ไปเรียก shell (sh, bash), curl, wget หรือมีไฟล์ .php ใหม่โผล่ในโฟลเดอร์เว็บ การเจาะสำเร็จอาจตอบ HTTP 200 ตามปกติและ worker ไม่ล้ม จึงดูจากรหัสสถานะอย่างเดียวไม่ได้

หน่วยความจำหมดอย่างเดียวไม่ได้แปลว่าถูกโจมตี และ log ที่สะอาดก็ไม่ได้พิสูจน์ว่าปลอดภัย (ทีม PHP เขียนไว้ตรง ๆ) ถ้าพบสัญญาณข้างต้นบนเครื่องที่ยังไม่ได้แพตช์ ให้ถือเป็นเหตุการณ์ (incident) แยกเครื่องออกจากเครือข่าย เปลี่ยนรหัสผ่านฐานข้อมูล คีย์ API และ secret ที่เคยอยู่ในหน่วยความจำของ worker (เป็นข้อแนะนำเดียวกับที่กระทรวงอุตสาหกรรมฯ ของจีนสั่งหน่วยงานของตน) แล้วกู้จาก backup ที่เชื่อถือได้ ดูวิธีซ้อมกู้คืนระบบให้กู้ได้จริง

5. เช็กลิสต์สำหรับทีม IT ไทย

รวบจากคำแนะนำของ CISA, NCSC สหราชอาณาจักร และคำสั่ง 3 ขั้นของ อว. เรียงตามลำดับที่ควรทำ

6. บทเรียนที่ใหญ่กว่า PHP

บั๊กที่ "ยังไม่มีใครเจาะได้" ไม่ได้แปลว่าปลอดภัย ร่องรอยของบั๊กตัวแรกอยู่ในรายงานตรวจสอบปี 2567 แต่ทีมความปลอดภัยของ PHP ที่ตัดสินใจแบบฉันทามติเลือกวิธีแก้ไม่ได้ งานจึงค้างข้ามปี PHP Foundation เรียกเรื่องนี้เองว่า "ความล้มเหลวเชิงโครงสร้าง" และประกาศเปลี่ยนเป็นตัดสินใจด้วยเสียงข้างมาก พร้อมตั้งทีม Ecosystem Security ตั้งแต่พฤษภาคม 2569 องค์กรที่มี "ช่องโหว่ที่รู้อยู่แล้วแต่ยังไม่ได้แก้เพราะยังไม่มีใครเจาะ" ควรดูกรณีนี้เป็นกระจก

AI หาช่องโหว่ได้เร็วกว่าคน ทั้งฝ่ายดีและฝ่ายร้าย ผู้ค้นพบทั้ง Calif (ใช้ GPT-5.6 Sol ของ OpenAI ในโครงการ Patch the Planet) และ Wiz (Gemini 4 Argon, GPT-5.6 Sol และเครื่องมือ Wiz Atlas) ใช้โมเดล AI ทั้งค้นหาและเขียนโค้ดโจมตี ทีม PHP เองบอกว่า Alpha-Omega กับ Claude Mythos ของ Anthropic สแกน PHP ไปก่อนหน้านี้ในปี 2569 และเพิ่ม Daybreak Red ของ OpenAI เข้ามาหลังเหตุการณ์ เรื่องนี้ต่อจากที่เราเขียนไว้ในบทความโมเดล AI ไซเบอร์ของสามค่าย ครั้งนี้ฝ่ายดีเจอก่อนราว 2 เดือน แต่ Wiz ก็ยอมรับว่าเครื่องมือเดียวกันช่วยปรับโค้ดโจมตีให้เข้ากับแต่ละเวอร์ชันได้เร็วขึ้นด้วย ช่วงเวลาระหว่างแพตช์ออกกับการโจมตีจริงจึงสั้นลงเรื่อย ๆ เหมือนกรณี Langflow ที่ถูกโจมตีภายใน 20 ชั่วโมง

องค์กรที่รอดในสัปดาห์นี้คือองค์กรที่รู้ว่าตัวเองมีอะไรอยู่ตรงไหน ไม่ใช่องค์กรที่มีไฟร์วอลล์แพงที่สุด (ซึ่งบางยี่ห้อก็มี PHP อยู่ข้างในเหมือนกัน) บัญชีระบบที่ครบและกระบวนการแพตช์ที่ซ้อมมาแล้วคือสิ่งที่ทำให้ตอบคำสั่งของรัฐมนตรีได้ภายในวันเดียว ดูแนวทางวาง Patch Management ในบทความกรณีช่องโหว่ SharePoint และหลักคิดเรื่องความปลอดภัยของข้อมูลในระบบ ERP ที่ใช้กับทุกระบบในองค์กร

สรุป

• PHP2Shell = CVE-2026-109618 (หน่วยความจำหมดระหว่างเตรียม request) + CVE-2026-109619 (state ค้างข้าม request) CVSS 9.2 ทั้งคู่ รันโค้ดจากระยะไกลโดยไม่ต้องล็อกอิน อยู่ในตัว PHP เอง แอปทุกตัวบน PHP 5.4 ถึง 8.5.11 กระทบ
• เวอร์ชันที่แก้แล้ว 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 (21 ตุลาคม 2569) · 7.4 / 8.0 / 8.1 ไม่มีรุ่นทางการ ต้องพึ่ง backport ของผู้ให้บริการ Linux หรืออัปเกรด
• เสี่ยงสุดคือ Apache mod_php (โจมตีได้ก่อนโค้ดแอปรัน) รองลงมา PHP-FPM · ไฟร์วอลล์และอุปกรณ์ที่ฝัง PHP ก็กระทบ (Palo Alto PAN-OS ยืนยันแล้ว)
• ยังไม่มีโค้ดโจมตีสาธารณะที่ใช้ได้ทั่วไป (Rapid7, 22 ต.ค.) แต่มีความพยายามโจมตีตั้งแต่ก่อนเปิดเผย (AWS, 17 ต.ค.) และ Cloudflare เห็นการโจมตีก่อนแพตช์ออก
• ลำดับทำ: หาให้เจอ → อัปเดตและ restart ทุก worker → มาตรการชั่วคราวเฉพาะเครื่องที่ยังแพตช์ไม่ได้ → ตรวจ log ย้อนถึง 17 ต.ค. → รายงาน · PHP 8.2 หมดอายุ 31 ธันวาคม 2569 วางแผนข้ามไป 8.3 หรือ 8.4

"ช่องโหว่ระดับนี้ไม่ถามว่าโค้ดของคุณเขียนดีแค่ไหน มันถามแค่สองอย่าง คุณรู้ไหมว่ามี PHP อยู่ตรงไหนบ้าง และคุณอัปเดตได้ภายในกี่ชั่วโมง"

- ไพฑูรย์ บุตรี ผู้เชี่ยวชาญด้านระบบเน็ตเวิร์คและระบบความปลอดภัยเซิร์ฟเวอร์ แกรนด์ลีนุกซ์ โซลูชั่น

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

• PHP: PHP Security Release, 21 October 2026 (เวอร์ชันแก้ไข + มาตรการชั่วคราว)
• PHP: Upcoming Critical PHP Security Release — ประกาศล่วงหน้า 20 ตุลาคม 2569
• GitHub Security Advisory GHSA-w8hw-w9fx-j79w — CVE-2026-109618 RCE via OOM corruption
• GitHub Security Advisory GHSA-6wmf-4rv5-p3rp — CVE-2026-109619 RCE via stale global state
• The PHP Foundation: Today's PHP security release and how we're strengthening PHP security (21 ตุลาคม 2569)
• PHP: Supported Versions (วันหมดอายุของ PHP 8.2–8.5)
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching (21 ตุลาคม 2569)
• NCSC (สหราชอาณาจักร): Critical security issue affecting PHP (21 ตุลาคม 2569)
• Wiz Research: PHP2Shell — AI uncovers critical RCE vulnerabilities in PHP (21 ตุลาคม 2569)
• Rapid7: CVE-2026-109618 and CVE-2026-109619 — Critical Unauthenticated RCE in PHP (อัปเดต 22 ตุลาคม 2569)
• Google Cloud: Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 (22 ตุลาคม 2569)
• AWS Security Blog: Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot (22 ตุลาคม 2569)
• Qualys: Two Critical PHP Flaws Could Hand Attackers Your Web Servers — ตัวเลขการติดตั้ง 167 ล้านชุด (อัปเดต 22 ตุลาคม 2569)
• Datadog Security Labs: PHP2Shell — detection, analysis, and remediation
• BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws (21 ตุลาคม 2569)
• Help Net Security: PHP2Shell — Critical PHP vulnerabilities patched, update now (อัปเดต 22 ตุลาคม 2569 สถานะ Palo Alto / Fortinet / Cisco)
• W3Techs: Usage statistics and market share of PHP for websites (22 ตุลาคม 2569)
• ผู้จัดการออนไลน์: จับตาช่องโหว่ PHP ร้ายแรงสะเทือนเอเชีย เกาหลีใต้-จีนเร่งให้อัปเดต ญี่ปุ่นระงับบริการบางส่วน (22 ตุลาคม 2569)
• กรุงเทพธุรกิจ: ยศชนันสั่งยกระดับความปลอดภัย หลัง OpenAI พบช่องโหว่ PHP เสี่ยงถูกเจาะข้อมูล (22 ตุลาคม 2569)
• ทีนิวส์: ภราดรสั่งทุกหน่วยรับมือช่องโหว่ เสี่ยงถูกแฮกระยะไกล — มาตรการ 4 ด้านของ สกมช./ThaiCERT (22 ตุลาคม 2569)