PHP 修補程式發布 10 小時後：受影響版本及各版本應採取的措施

PHP หลังแพตช์ 10 ชั่วโมง: รุ่นไหนโดนอะไร และแต่ละรุ่นต้องทำอย่างไร?

โดย Nokka (นก-กา) | นักเขียนอิสระสาย AI และระบบเปิด | ตรวจสอบข้อมูล ณ 22 ต.ค. 2026 เวลา 07:40 น.

บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

เมื่อคืนแพตช์ออกแล้ว และเมื่อเช้าก็มีคนยิงเข้ามา

เมื่อวานเวลา 21:00 ตามเวลาไทย PHP ปล่อยแพตช์ชุดเดียวที่ครอบสองช่องโหว่ในสี่รุ่น คือ 8.5.12, 8.4.27, 8.3.36 และ 8.2.35 [1]

ผ่านมาไม่ถึงวัน สถานการณ์เปลี่ยนจาก "เตรียมตัว" เป็น "มีคนเริ่มยิงแล้ว"

ถ้าจะอ่านข่าวช่วงนี้ให้ถูก ต้องแยกสามชั้นนี้ให้ออก เพราะข่าวแต่ละสำนักพูดคนละชั้น

ชั้นที่หนึ่ง การสาธิตของนักวิจัย Sansec รายงานว่าทีมวิจัยยืนยันการโจมตีแบบไม่ต้องยืนยันตัวตนได้จริงบน Magento 2.4.9 และแอป PHP อีกสิบตัว และระบุว่าค่าตั้งเริ่มต้นของ PHP ก็อยู่ในข่ายที่โดน [11] ประกาศของทีม PHP เองก็ระบุว่า เส้นทาง RCE ที่เกี่ยวกับวงจร session ถูกตรวจสอบยืนยันแล้วทั้งบน mod_php และ FPM [12]

ชั้นที่สอง ความพยายามโจมตีจริง watchTowr บอกกับ SecurityWeek ว่าเริ่มมีทราฟฟีโจมตีเข้ามาชนเซนเซอร์ของบริษัทราวเวลาเดียวกับที่แพตช์ออก แต่ยังไม่มีรายใดสำเร็จ [3] บริษัท Hadrian ใช้ถ้อยแรงกว่านั้น คือบอกว่าเห็น php2shell ถูกใช้โจมตีในสนามเป็นวงกว้างแล้ว และเส้นทางที่เจอบ่อยที่สุดคือช่อง session upload progress [3] ส่วน Patchstack, Cloudflare และ Vega ก็รายงานว่าเจอของแบบเดียวกันเข้ามาที่ระบบเฝ้าดูของแต่ละเจ้า [3]

ชั้นที่สาม การยึดเครื่องสำเร็จที่ยืนยันได้ ชั้นนี้ยังว่างอยู่ เจค นอตต์ หัวหน้าฝ่ายข่าวกรองภัยคุกคามของ watchTowr พูดไว้ตรง ๆ ว่า ถึงตอนนี้ยังไม่มีใครทำสำเร็จ แต่เขาไม่คิดว่าจะอยู่อย่างนี้ได้นาน [3] และ CISA ออกประกาศเตือนเมื่อวานโดยระบุว่า ณ เวลาที่เผยแพร่ ยังไม่พบการโจมตี [2]

สามชั้นนี้ไม่ขัดกัน การสาธิตในแล็บไม่ใช่การยึดเครื่องจริง และถ้อยที่ว่า php2shell ถูกใช้โจมตีในสนาม กับการยืนยันว่ายึดเครื่องได้สำเร็จ ก็ยังต่างกันอยู่

สรุปสั้นสำหรับคนที่ไม่มีเวลาอ่าน

ถ้าคุณจำได้แค่บรรทัดเดียว ให้จำบรรทัดนี้

PHP 8.2 ถึง 8.5 อัปเดตได้ทันทีเป็น 8.2.35, 8.3.36, 8.4.27 หรือ 8.5.12 ส่วน 8.1, 8.0 และ 7.4 ต้องใช้ source backport หรือแพ็กเกจจากผู้จำหน่าย และ 7.3 ลงไปจนถึง 5.x ทีม PHP ไม่มีแพตช์ให้ และไม่มี source backport ทางการ ผู้จำหน่ายบางรายอาจมี ต้องถามก่อน

รุ่นไหนบ้างที่ถือว่ามีปัญหา

คำถามนี้มีสามคำตอบที่ต่างกัน ขึ้นกับว่าถามใคร และผมคิดว่านี่คือจุดที่คนสับสนมากที่สุด

คำตอบที่ 1 ของผู้ดูแล PHP

ประกาศอย่างเป็นทางการระบุขอบเขตว่า PHP 8.2 ก่อน 8.2.35, PHP 8.3 ก่อน 8.3.36, PHP 8.4 ก่อน 8.4.27 และ PHP 8.5 ก่อน 8.5.12 [4]

ผมอ่านว่านี่คือขอบเขตที่เขาแก้และรับรอง ไม่ใช่ขอบเขตทั้งหมดที่โดน

อีกชั้นที่ประกาศระบุแยกไว้ คือความเสี่ยงไม่ได้เท่ากันทุก SAPI ประกาศเขียนว่า mod_php เสี่ยงสูงสุด เพราะ Apache เรียก shutdown โดยไม่มีเงื่อนไขเมื่อเกิดปัญหา ส่วน FPM มีเงื่อนไขมากกว่า คือต้องมีตัวกระตุ้นจากแอปที่ทำงานอยู่จริงและต้องเกิด fatal error ในจังหวะที่เหมาะ [1] [12]

คำตอบที่ 2 ของฐานข้อมูลกลาง

NVD ขึ้นทะเบียนทั้งสองรหัสเมื่อวันที่ 21 ตุลาคม เวลา 14:17 UTC และระบุช่วงที่กระทบว่าคือทุกเวอร์ชันก่อน 8.2.35, 8.3.0 ถึงก่อน 8.3.36, 8.4.0 ถึงก่อน 8.4.27 และ 8.5.0 ถึงก่อน 8.5.12 [5]

การเขียนว่า "ก่อน 8.2.35" แบบไม่มีจุดเริ่มต้น แปลว่าทุกอย่างที่ต่ำกว่านั้นถูกนับรวมไปด้วย

คำตอบที่ 3 ของทีมที่ค้นพบ

Wiz Research หนึ่งในสามทีมที่พบช่องโหว่ชุดนี้ ร่วมกับ Calif ของ Ryan Austin และ OpenAI เขียนว่า PHP เกือบทุกรุ่นที่ออกในทศวรรษที่ผ่านมามีปัญหาอย่างน้อยหนึ่งตัว ย้อนไปถึงรุ่น 5.4 [6]

และเขาระบุด้วยว่าช่องโหว่ชุดนี้ไม่ได้ให้แค่การรันโค้ด แต่ยังอ่านหน่วยความจำของโปรเซสได้ด้วย ซึ่งอาจมีรหัสผ่าน โทเคน API หรือใบรับรองของคำขออื่นหลุดออกไป [6]

แนวทางแยกตามรุ่น

นี่คือส่วนที่ผมอยากให้อ่านช้า ๆ เพราะสิ่งที่ต้องทำต่างกันจริงในแต่ละรุ่น

ถ้าคุณอยู่บน PHP 8.5

อัปเดตเป็น 8.5.12 [1]

นี่คือรุ่นที่ได้รับการสนับสนุนเต็มรูปแบบ และเป็นรุ่นที่แพตช์ออกพร้อมกับรุ่นอื่นในคืนเดียวกัน

ถ้าคุณใช้ PHP 8.5 อยู่ ยังมีมาตรการเสริมเฉพาะรุ่นนี้คือตั้ง fatal_error_backtraces=0 แล้วรีสตาร์ต worker ทุกตัว ซึ่ง PHP ระบุว่าช่วยปิดเส้นทางที่ยืนยันแล้วทางหนึ่ง แต่ไม่ใช่ทั้งหมด [1]

ถ้าคุณอยู่บน PHP 8.4

อัปเดตเป็น 8.4.27 [1]

สถานะของ 8.4 คือสนับสนุนเต็มถึงสิ้นปี 2026 แล้วต่อด้วยช่วงรับเฉพาะแพตช์ความปลอดภัยไปจนถึงสิ้นปี 2028 [7] แปลว่าอัปเดตตอนนี้แล้วยังได้ใช้งานอีกกว่าสองปี

ถ้าคุณอยู่บน PHP 8.3

อัปเดตเป็น 8.3.36 [1]

รุ่น 8.3 เข้าสู่ช่วงรับเฉพาะแพตช์ความปลอดภัยแล้ว แต่ยังได้แพตช์ตัวนี้ครบ

ถ้าคุณอยู่บน PHP 8.2

อัปเดตเป็น 8.2.35 [1]

มีกำหนดที่ควรจดไว้คือ 8.2 จะสิ้นสุดช่วงรับแพตช์ความปลอดภัยในอีกสองเดือนข้างหน้า คือ 31 ธันวาคม 2026 [7]

ถ้าคุณยังอยู่บน 8.2 ควรวางแผนขึ้น 8.4 ไว้ในไตรมาสนี้ เพราะ 8.4 ได้รับการสนับสนุนไปถึงสิ้นปี 2028 ส่วน 8.3 รับเฉพาะแพตช์ความปลอดภัยถึงสิ้นปี 2027 [7] ถ้าต้องเลือกรุ่นปลายทางเดียว ผมเลือก 8.4

ถ้าคุณอยู่บน PHP 8.1

PHP ไม่ปล่อยรุ่นใหม่ให้ 8.1 แล้ว แต่ทีมความปลอดภัยทำ source backport ให้ คือแบรนช์ PHP-8.1-CVE-2026-109618-109619 บน GitHub [1] [8]

คำว่า source backport หมายความว่าคุณต้องดึงโค้ดไปคอมไพล์เอง ไม่มีไฟล์ไบนารีสำเร็จรูปจากทีม PHP ให้โหลด

ถ้าคุณใช้ดิสทริบิวชันที่มีสัญญาณสนับสนุนระยะยาว ให้เช็กแพ็กเกจจากผู้จำหน่ายก่อน เพราะ PHP ระบุว่าผู้จำหน่ายลินุกซ์และผู้ให้บริการ LTS ได้รับแพตช์ล่วงหน้าแล้ว [1]

ถ้าทำทั้งสองทางไม่ได้จริง ๆ CISA แนะนำให้เอาระบบออกจากอินเทอร์เน็ตจนกว่าจะแพตช์หรืออัปเกรดได้ [2]

ถ้าคุณอยู่บน PHP 8.0 หรือ 7.4

สถานะเหมือน 8.1 คือมี source backport ให้ แต่ไม่มีรุ่นใหม่ให้ติดตั้ง โดยแบรนช์คือ PHP-8.0-CVE-2026-109618-109619 และ PHP-7.4-CVE-2026-109618-109619 [1] [8]

ผมอ่านประกาศแล้วเห็นว่าการที่ PHP ยอมทำ backport ให้สองรุ่นที่หมดอายุไปนานแล้ว เป็นสัญญาณว่าทีมตระหนักดีว่าคนจำนวนมากยังค้างอยู่บนรุ่นเหล่านี้

แต่การคอมไพล์เองไม่ใช่ทางเลือกของทุกคน โดยเฉพาะคนที่ใช้โฮสติ้ง

ถ้าคุณอยู่บน PHP 7.3 หรือต่ำกว่า รวมถึง 5.x

ตรงนี้คือจุดที่ผมอยากพูดตรง ๆ ว่า ทีม PHP ไม่มีแพตช์ให้ และไม่มี source backport ทางการให้

การทำ backport ของ PHP หยุดที่ 7.4 ไม่ได้ไล่ลงไปถึง 7.3 หรือ 5.x [1] และหน้า EOL ของ php.net ก็ระบุรุ่นเก่าเหล่านี้หมด support ไปนานแล้ว [9]

แต่ประโยคนี้ไม่ได้แปลว่าไม่มีใครแพตช์ให้เลย เพราะประกาศของ PHP เองบอกว่าผู้จำหน่ายดิสทริบิวชันและผู้ให้บริการ LTS บางรายออกแพตช์ย้อนหลังเองได้ [1] ถ้าคุณอยู่ในดิสทริบิวชันแบบนั้น ให้ถามผู้จำหน่ายก่อนตัดสินใจ

Wiz ระบุว่าช่องโหว่ย้อนไปถึง 5.4 [6] และ Sansec เขียนว่าช่องโหว่นี้กระทบเว็บเซิร์ฟเวอร์ที่รัน PHP 5.4 ขึ้นไป โดยโค้ดที่เปราะบางมีมาตั้งแต่ 5.4.0 ที่ออกในปี 2012 [11]

ทางเลือกที่มีคือย้ายขึ้นรุ่นที่ยังได้รับการสนับสนุน หรือเอาออกจากอินเทอร์เน็ต หรือวางไว้หลัง WAF ที่ CISA บอกว่าช่วยได้บางส่วน [2] ส่วนการวางไว้หลัง VPN เป็นข้อเสนอของผมเอง ไม่ใช่ถ้อยของ CISA

ผมคิดว่านี่คือกลุ่มที่ต้องตัดสินใจเชิงธุรกิจ ไม่ใช่เชิงเทคนิค เพราะการย้ายเว็บที่รันบน PHP 5 ขึ้นมา 8.x อาจต้องแก้โค้ดจำนวนมาก

ถ้าคุณใช้คอนเทนเนอร์

อิมเมจ php อย่างเป็นทางการบน Docker ถูกอัปเดตแล้ว โดย pull request ในคลัง docker-library/php ถูกรวมเมื่อวันที่ 21 ตุลาคม เวลา 14:19 UTC หรือ 19 นาทีหลังแพตช์ออก [10]

ถ้าคุณล็อกแท็กเป็นรุ่นเจาะจง เช่น php:8.2-fpm ให้ดึงอิมเมจใหม่และตรวจว่าข้างในเป็น 8.2.35 จริง ไม่ใช่แค่เชื่อแท็ก

ถ้าคุณใช้โฮสติ้งแชร์หรือแผงควบคุม

คุณไม่ได้เป็นคนแพตช์เอง คำถามที่ต้องส่งไปหาผู้ให้บริการมีสามข้อ

• เว็บของฉันรัน PHP รุ่นอะไร
• มีแผนติดตั้ง 8.2.35, 8.3.36, 8.4.27 หรือ 8.5.12 เมื่อไหร่
• ถ้ารุ่นที่ใช้อยู่ไม่มีแพตช์ จะย้ายขึ้นรุ่นที่ได้รับการสนับสนุนให้เมื่อไหร่

ผมไม่มีข้อมูลว่าผู้ให้บริการรายใดในไทยอัปเดตแล้วหรือยัง จึงไม่สามารถบอกได้ว่าคุณปลอดภัยหรือไม่ ต้องถามตรง ๆ เท่านั้น

ถ้ายังแพตช์ไม่ได้ ระหว่างนี้ทำอะไรได้

PHP ระบุชัดว่าไม่มีมาตรการตั้งค่าที่ทำให้ปลอดภัยได้ทั้งหมด และการอัปเดตคือทางเดียวที่สมบูรณ์ [1]

แต่มีมาตรการที่ลดความเสี่ยงเฉพาะเส้นทางได้ สองชุดนี้แยกตามรหัสช่องโหว่

สำหรับ CVE-2026-109618 (ช่อง OOM)

ตั้ง memory_limit=-1 ผ่าน php_admin_value ใน FPM pool หรือในคอนฟิก Apache เพื่อไม่ให้แอปเขียนทับได้ แล้วตรวจว่าไม่มี pool หรือไดเรกทอรีใดตั้งค่ากลับเป็นค่าจำกัด [1]

ตั้ง post_max_size ให้ต่ำ ถ้าไม่มีการอัปโหลดไฟล์ให้ใช้ 8M ถ้ามีให้ใช้ 32M และให้ upload_max_filesize ต่ำกว่า post_max_size [1]

พิจารณาตั้งขีดจำกัดที่เว็บเซิร์ฟเวอร์หรือพร็อกซีด้วย ทั้งขนาดคำขอที่นับหลังถอดรหัส จำนวนฟิลด์ จำนวน part ใน multipart จำนวน header และความลึกของการซ้อน และให้ขีดจำกัดเหล่านี้ครอบคำขอที่ไม่มีความยาว Content-Length ที่ใช้ได้ด้วย เพราะเป็นช่องที่การโจมตีใช้หลบ post_max_size [1]

ในคอนเทนเนอร์ให้ใช้ขีดจำกัดของ cgroup เป็นเส้นแบ่งเรื่องความพร้อมใช้งาน และตั้งนโยบายให้ฆ่าเฉพาะ worker ที่มีปัญหา ไม่ใช่ทั้งคอนเทนเนอร์ [1]

และ ห้ามใช้ RLIMIT_AS หรือ RLIMIT_DATA แทน เพราะ PHP ระบุว่าค่าเหล่านี้ทำให้เกิดการจัดสรรหน่วยความจำล้มเหลวซึ่งเป็นตัวจุดชนวนเส้นทางที่เปราะบาง [1]

สำหรับ CVE-2026-109619 (ช่องสถานะค้าง)

ตั้ง session.upload_progress.enabled=0 แล้วรีสตาร์ต worker ทุกตัว โดยต้องตั้งผ่าน php.ini หรือคอนฟิก FPM หรือเซิร์ฟเวอร์ที่ทำงานก่อนการอ่านคำขอ ห้ามพึ่ง ini_set() หรือ .user.ini [1]

มาตรการนี้ปิดเส้นทาง session ที่ยืนยันแล้ว แต่ไม่ได้ปิดทุกรูปแบบ [1]

ถ้าคุณใช้ FPM และรับภาระเรื่องประสิทธิภาพได้ ประกาศแนะนำ pm.max_requests=1 ด้วย เพื่อไม่ให้ worker ตัวเดิมรับคำขอถัดไป ซึ่งตัดโอกาสที่สถานะจะค้างข้ามคำขอ [12]

และให้ลบการตั้งค่า ini ที่ไม่ถูกต้องหรือเลิกใช้แล้วซึ่งถูกใช้ต่อคำขอและทำให้เกิดข้อความเตือนก่อนการเริ่มต้นคำขอ เพราะการซ่อนข้อความด้วย error_reporting, display_errors หรือ @ ไม่ช่วย [1]

ข้อสุดท้ายที่ประกาศระบุคือให้แก้ fatal error และการหมดเวลาทำงานที่ผู้โจมตีกระตุ้นได้จริง ทั้งใน callback การอัปโหลดหรือนำเข้า และช่วงเก็บกวาดหลังจบคำขอ [1]

ตัวอย่างการตรวจว่าค่ามีผลจริง

วิธีที่ตรงที่สุดคือวางไฟล์ probe ชั่วคราวในเว็บที่ใช้ FPM หรือ mod_php แล้วเปิดผ่านเบราว์เซอร์

<?php
var_dump(ini_get('memory_limit'), ini_get('post_max_size'),
         ini_get('upload_max_filesize'), ini_get('session.upload_progress.enabled'));

เปิดดูแล้วลบไฟล์ทิ้งทันที เพราะไฟล์นี้เผยค่าตั้งของเซิร์ฟเวอร์ให้ใครก็ได้ที่เปิดเจอ

ส่วนคำสั่งนี้ใช้ดูค่าอ้างอิงของ PHP ฝั่ง command line เท่านั้น ไม่ใช่ค่าที่เว็บใช้จริง

php -i | grep -E "memory_limit|post_max_size|upload_max_filesize"

ตรวจว่าโดนไปแล้วหรือยัง

CISA แนะนำให้เฝ้าดูโปรเซส worker ของ PHP ที่ไปเรียกเชลล์หรือดาวน์โหลดเครื่องมือ [2]

ถ้าพบโปรเซสที่ไม่มีเหตุผล ให้แยกเครื่องออกจากเครือข่ายก่อน แล้วค่อยเก็บหลักฐาน

รายการที่ผมแนะนำให้เก็บเป็นข้อเสนอของผมเอง ไม่ได้มาจากประกาศไหน คือ access log ย้อนหลังอย่างน้อย 24 ชั่วโมง ซึ่งเป็นช่วงที่ครอบทั้งก่อนและหลังแพตช์ออก, log ของ PHP-FPM, รายการไฟล์ที่ถูกแก้ในโฟลเดอร์เว็บ และรายการงานตามเวลาที่ถูกเพิ่มใหม่

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

และเพราะช่องโหว่นี้ยังอ่านหน่วยความจำได้ [6] ถ้าคุณสงสัยว่าโดน ควรถือว่ารหัสผ่าน โทเคน และคีย์ที่อยู่ในเครื่องนั้นรั่วแล้ว และหมุนเวียนค่าเหล่านี้

ผมเปิดอะไรเองบ้าง และอะไรที่ยังไม่ได้เปิด

ผมเปิดประกาศบน php.net อ่านเต็มฉบับ รวมถึงส่วนมาตรการลดความเสี่ยงและรายการ source backport [1]

ผมเปิดบันทึก CVE ทั้งสองตัวบน NVD และตรวจช่วงเวอร์ชันที่ระบุไว้จริง [5]

ผมเปิด advisory สองฉบับบนคลัง php-src ฉบับแรก GHSA-w8hw-w9fx-j79w ว่าด้วยตัว OOM อีกฉบับ GHSA-6wmf-4rv5-p3rp ว่าด้วยสถานะค้าง แล้วอ่านสรุปทางเทคนิคของทั้งคู่ [4] [12]

ผมเปิดประกาศของ CISA ฉบับวันที่ 21 ตุลาคม อ่านข้อแนะนำครบทุกข้อ [2]

ผมเปิดงานของ Wiz Research อ่านข้อความเรื่องขอบเขตที่ย้อนไปถึง 5.4 และเรื่องการอ่านหน่วยความจำ [6]

ผมตรวจ pull request ของ docker-library/php และยืนยันว่า ถูกรวมเมื่อวันที่ 21 ตุลาคม เวลา 14:19 UTC [10]

สิ่งที่ผมยังไม่ได้ตรวจ ผมไม่ได้ทดสอบช่องโหว่หรือแพตช์ด้วยตัวเอง และไม่มีแล็บให้ทดสอบ

ผมไม่ได้ตรวจว่าโฮสติ้งรายใดในประเทศไทยอัปเดตแล้วหรือยัง

และผมไม่ได้ยืนยันตัวเลข "70 เปอร์เซ็นต์ของเว็บทั่วโลก" ที่ Wiz ใช้ เพราะเป็นตัวเลขของผู้ให้บริการรายนั้น ไม่ใช่สถิติที่ผมวัดเอง

คำถามที่ผมอยากฝากถึงคนดูแลระบบ

ถ้าคุณดูแลเว็บหลายสิบเว็บ คำถามที่ไม่ใช่ "แพตช์แล้วหรือยัง" แต่คือ "คุณรู้หรือไม่ว่าทั้งหมดมีกี่เว็บ และรุ่นไหนบ้าง"

เพราะในคืนที่แพตช์ออก สิ่งที่ทำให้คนแพตช์ไม่ทันมักไม่ใช่ความยากของการติดตั้ง แต่คือการไม่รู้ว่ามีอะไรอยู่ในมือ

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

[1] The PHP Development Team, "Security advisory: Critical remote code execution vulnerabilities, update now", php.net News Archive, 21 ต.ค. 2026 (8.5.12 · 8.4.27 · 8.3.36 · 8.2.35 · SAPI ที่เสี่ยง · รายละเอียดทั้งสอง CVE · source backport สำหรับ 7.4, 8.0, 8.1 · มาตรการลดความเสี่ยง memory_limit, post_max_size, session.upload_progress, fatal_error_backtraces · ห้ามใช้ RLIMIT_AS/RLIMIT_DATA). https://www.php.net/archive/2026.php#2026-10-21-5

[2] CISA, "Critical Vulnerabilities in PHP Require Immediate Patching", 21 ต.ค. 2026 (แนะนำให้อัปเดตเป็น 8.5.12, 8.4.27, 8.3.36 หรือ 8.2.35 · ยังไม่พบการโจมตี ณ เวลาเผยแพร่ · แนะนำ inventory · ให้ระบบที่ใช้ 8.1 หรือเก่าออกออฟไลน์จนกว่าจะแพตช์ · WAF ช่วยได้บางส่วน · เฝ้าดู PHP worker เรียกเชลล์). https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching

[3] Ionut Arghire, "PHP2Shell Patches Land as First Exploitation Attempts Hit Sensors", SecurityWeek, 21 ต.ค. 2026 (watchTowr เห็นความพยายามโจมตีราวเวลาที่แพตช์ออกแต่ยังไม่มีรายสำเร็จ · คำพูดของ Jake Knott · Hadrian เห็นการโจมตีวงกว้างและเส้นทาง session upload progress · Patchstack, Cloudflare, Vega เห็นความพยายามโจมตี · ขอบเขตย้อนถึง 5.4 · การอ่านหน่วยความจำ). https://securityweek.com/php2shell-patches-land-as-first-exploitation-attempts-hit-sensors/

[4] PHP Security Team (bukka), "RCE via OOM corruption", GHSA-w8hw-w9fx-j79w, 21 ต.ค. 2026 (affected: ก่อน 8.2.35 · 8.3.0 ถึงก่อน 8.3.36 · 8.4.0 ถึงก่อน 8.4.27 · 8.5.0 ถึงก่อน 8.5.12 · patched: 8.2.35, 8.3.36, 8.4.27, 8.5.12 · กลไก OOM ผ่าน multipart · mod_php เรียก shutdown โดยไม่เงื่อนไข · FPM ออก child เมื่อ startup ล้มเหลว · FrankenPHP และ LSAPI). https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w (คู่แฝดของ CVE-2026-109619 คือ GHSA-6wmf-4rv5-p3rp)

[5] NIST, National Vulnerability Database, CVE-2026-109618 และ CVE-2026-109619, เผยแพร่ 21 ต.ค. 2026 เวลา 14:17 UTC (CVSS v4.0 9.2 · CVSS v3.1 9.8 · ช่วง CPE: ก่อน 8.2.35, 8.3.0 ถึงก่อน 8.3.36, 8.4.0 ถึงก่อน 8.4.27, 8.5.0 ถึงก่อน 8.5.12). https://nvd.nist.gov/vuln/detail/CVE-2026-109618 · https://nvd.nist.gov/vuln/detail/CVE-2026-109619

[6] Sagi Tzadik และคณะ, "PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet", Wiz Blog, 21 ต.ค. 2026 (PHP เกือบทุกรุ่นย้อนถึง 5.4 มีปัญหาอย่างน้อยหนึ่งตัว · อ่านหน่วยความจำโปรเซสได้ · ใช้โมเดล AI ช่วยค้นหา · ตัวเลข 70 เปอร์เซ็นต์เป็นของผู้ให้บริการรายนี้). https://www.wiz.io/blog/php2shell-php-rce

[7] The PHP Group, "Supported Versions", php.net, สืบค้น 22 ต.ค. 2026 (8.2 หมดช่วงสนับสนุนความปลอดภัย 31 ธ.ค. 2026 · 8.3 ถึง 31 ธ.ค. 2027 · 8.4 ถึง 31 ธ.ค. 2028 · 8.5 ถึง 31 ธ.ค. 2029). https://www.php.net/supported-versions.php

[8] php-src, แบรนช์ source backport, GitHub, สืบค้น 22 ต.ค. 2026 (PHP-7.4-CVE-2026-109618-109619 · PHP-8.0-CVE-2026-109618-109619 · PHP-8.1-CVE-2026-109618-109619). https://github.com/php/php-src/branches/all

[9] The PHP Group, "Unsupported Branches", php.net, สืบค้น 22 ต.ค. 2026 (7.4 หมด 28 พ.ย. 2022 · 7.3 หมด 6 ธ.ค. 2021 · 5.6 หมด 31 ธ.ค. 2018). https://www.php.net/eol.php

[10] docker-library/php, "Update to 8.5.12, 8.4.27, 8.3.36, 8.2.35", pull request 1694, รวมเมื่อ 21 ต.ค. 2026 เวลา 14:19 UTC. https://github.com/docker-library/php/pull/1694

[11] Sansec Forensics Team, "PHP2Shell: critical RCE and memory disclosure in PHP", Sansec Threat Research, 21 ต.ค. 2026 (กระทบเว็บเซิร์ฟเวอร์ที่รัน PHP 5.4 ขึ้นไป · โค้ดเปราะบางมีมาตั้งแต่ 5.4.0 ปี 2012 · ยืนยัน RCE แบบไม่ต้องยืนยันตัวตนบน Magento 2.4.9 และแอป PHP อีกสิบตัว · mod_php และ FPM ได้รับผลทั้งคู่ · ค่าตั้งเริ่มต้นก็อยู่ในข่าย · การอ่านหน่วยความจำเกิดได้แม้แอปไม่เรียก session_start). https://sansec.io/research/php2shell

[12] PHP Security Team (bukka), "RCE via stale global state", GHSA-6wmf-4rv5-p3rp, 21 ต.ค. 2026 (affected: ก่อน 8.2.35 · 8.3.0 ถึงก่อน 8.3.36 · 8.4.0 ถึงก่อน 8.4.27 · 8.5.0 ถึงก่อน 8.5.12 · patched 4 รุ่น · กลไกสถานะค้างข้ามคำขอใน worker เดียวกัน · มาตรการ session.upload_progress.enabled=0 และ fatal_error_backtraces=0). https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp