PHP2Shell: ช่องโหว่ PHP ร้ายแรง 2 รายการ และวิธีแก้

PHP2Shell เป็นชื่อเรียกช่องโหว่ร้ายแรง 2 รายการในตัว PHP เอง คือ CVE-2026-109618 และ CVE-2026-109619 (CVE คือรหัสมาตรฐานที่ใช้อ้างถึงช่องโหว่แต่ละรายการ) PHP เป็นภาษาที่เว็บไซต์จำนวนมากใช้ประมวลผลฝั่งเซิร์ฟเวอร์ ผู้ดูแล PHP เปิดเผยช่องโหว่เมื่อ 21 ตุลาคม 2026 ผู้โจมตีที่ยังไม่ได้ login แค่ส่งคำขอเว็บ (request) ไปที่เซิร์ฟเวอร์ ก็สั่งให้เซิร์ฟเวอร์รันโค้ดของผู้โจมตีได้ ช่องโหว่แต่ละรายการทำได้ด้วยตัวเอง วิธีแก้ที่สมบูรณ์มีวิธีเดียว คือ อัปเดต PHP เป็นรุ่นที่แก้แล้ว และรีสตาร์ตบริการ

เกิดอะไรขึ้น

PHP ประกาศเตือนด้านความปลอดภัย (security advisory) พร้อมรุ่นที่แก้แล้วเมื่อ 21 ตุลาคม 2026 Cloudflare ระบุว่ารายละเอียดรั่วออกมาก่อนวันเผยแพร่ที่วางแผนไว้ มีผู้ให้บริการ 3 รายรายงานว่าเกิดการโจมตีแล้ว Amazon Threat Intelligence ระบุว่า honeypot (เซิร์ฟเวอร์ล่อที่สร้างไว้เพื่อบันทึกการโจมตี) ของตนเห็นความพยายามโจมตีเมื่อ 17 ตุลาคม ซึ่งเร็วกว่าวันเปิดเผย 4 วัน watchTowr ระบุว่า honeypot ของตนเห็นการโจมตีตั้งแต่ 21 ตุลาคม ส่วน Cloudflare ระบุว่าเห็นการโจมตีลูกค้าของตน รวมถึง payload (ข้อมูลที่ผู้โจมตีส่งมาเพื่อโจมตี) ที่ถูกดัดแปลงให้ผ่านตัวกรองของ Cloudflare ไปได้ รายงานทั้งหมดนี้มาจากผู้ให้บริการแต่ละราย เรายังไม่ได้ตรวจสอบเอง

ช่องโหว่ทั้งสองรายการ

ช่องโหว่ทั้งสองอยู่ในขั้นตอนที่ PHP ประมวลผลคำขอเว็บ 1 คำขอตั้งแต่ต้นจนจบ PHP worker คือโปรเซส (โปรแกรมที่กำลังทำงานอยู่) ที่รับคำขอเว็บทีละคำขอ เมื่อทำเสร็จแล้ว จะถูกนำกลับมารับคำขอถัดไป

• CVE-2026-109618 การรันโค้ดจากระยะไกล (RCE คือผู้โจมตีสั่งให้เซิร์ฟเวอร์รันโค้ดของตน) ผ่านข้อมูลเสียหายตอนหน่วยความจำหมด: เมื่อหน่วยความจำหมด PHP ใช้คำสั่งกระโดด (longjmp()) เพื่อเลิกทำคำขอนั้นกลางคัน ในบางสถานการณ์ โค้ดอาจเข้าถึงหน่วยความจำของคำขอก่อนที่การเตรียมจะเสร็จ ถ้าหน่วยความจำหมดตรงจุดนั้น ข้อมูลที่ค้างอยู่จะไม่ถูกต้อง แล้ว PHP ก็นำข้อมูลนั้นไปประมวลผลต่อตอนปิดคำขอ
• CVE-2026-109619 RCE ผ่านสถานะส่วนกลางที่ตกค้าง (stale global state): ข้อมูลบางส่วนของคำขอ เช่น ข้อผิดพลาด session object และส่วนเสริม (extension) อาจยังอยู่ ทั้งที่หน่วยความจำที่มันชี้ไปหายไปแล้ว เพราะข้อผิดพลาดร้ายแรง (fatal error) อาจทำให้ข้ามขั้นตอนล้างค่า โค้ดที่ทำงานก่อนเริ่มคำขอถัดไปจึงอาจใช้ตัวชี้ (ตำแหน่งที่อ้างถึงข้อมูลในหน่วยความจำ) ที่ค้างอยู่นั้น ซึ่งเรียกว่า use-after-free (ใช้หน่วยความจำที่ถูกคืนระบบไปแล้ว)

ประกาศเตือนของทั้งสองรายการให้คะแนน 9.2 จาก 10 เท่ากัน ตามระบบ CVSS v4.0 (ระบบให้คะแนนความรุนแรงของช่องโหว่) และใช้ vector (รหัสสรุปลักษณะการโจมตี) เดียวกัน คือ CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N อ่านง่าย ๆ ได้ว่า โจมตีผ่านเครือข่ายได้ ไม่ต้องมีสิทธิ์ใช้งานระบบ ไม่ต้องให้ผู้ใช้ทำอะไร และกระทบความลับ ความถูกต้อง และความพร้อมใช้งานของข้อมูลในระดับสูง ความซับซ้อนของการโจมตีถูกประเมินว่าสูง คือทำให้สำเร็จได้ไม่ง่าย ประกาศเตือนระบุว่าผลที่ได้คือการรันโค้ดโดยไม่ต้อง login ด้วยสิทธิ์ของบัญชีที่ worker ของเว็บใช้อยู่ ไม่ใช่สิทธิ์ผู้ดูแลระบบ Qualys ระบุว่าการโจมตีจะสำเร็จหรือไม่ขึ้นกับปัจจัย เช่น การจัดวางข้อมูลในหน่วยความจำ และลำดับที่ worker ได้รับงาน ผลจึงต่างกันไปตามรุ่นที่คอมไพล์ (สร้างโปรแกรมจากซอร์สโค้ด) และการตั้งค่า

ใครได้รับผลกระทบ

ประกาศเตือนระบุว่า PHP ทุกรุ่นก่อน 8.2.35, 8.3.36, 8.4.27 และ 8.5.12 ได้รับผลกระทบ (ตัวเลขเหล่านี้คือรุ่นที่แก้แล้วของแต่ละสายรุ่น หรือ branch) Qualys และ Help Net Security รายงานว่าทุกรูปแบบการรัน PHP เพื่อให้บริการคำขอเว็บอยู่ในขอบเขตที่ได้รับผลกระทบ ได้แก่ PHP-FPM, Apache mod_php, php-cgi, FrankenPHP และ LiteSpeed โดย mod_php (PHP ที่ทำงานอยู่ภายในเว็บเซิร์ฟเวอร์ Apache เลย) ถูกระบุว่าเสี่ยงที่สุด เพราะการโจมตีอาจสำเร็จก่อนที่โค้ดของแอปพลิเคชันจะเริ่มทำงาน ส่วน PHP-FPM (กลุ่ม worker ของ PHP ที่แยกจากเว็บเซิร์ฟเวอร์) ก็ไม่ปลอดภัยเช่นกัน เพราะประกาศเตือนของ CVE-2026-109619 ระบุว่าตรวจยืนยันแล้วว่าสั่งรันโค้ดผ่านฟีเจอร์ session (ข้อมูลที่เว็บจำผู้ใช้ไว้ข้ามคำขอ) ได้ทั้งสองแบบ

รุ่นเก่าต้องพิจารณาแยกต่างหาก:

• PHP 8.1 และรุ่นก่อนหน้า: ทีม PHP ต้นทางเลิกดูแลแล้ว Help Net Security และ Qualys รายงานว่า PHP ออก backport (การนำโค้ดที่แก้แล้วไปใส่ในรุ่นเก่า) แบบจำกัดในรูปซอร์สโค้ด สำหรับรุ่น 7.4, 8.0 และ 8.1 เพื่อให้ผู้ที่คอมไพล์เอง หรือไม่มีผู้ให้บริการ LTS (ผู้ดูแลรุ่นเก่าให้ระยะยาว) นำไปใช้ได้
• PHP 7.3 และรุ่นก่อนหน้า รวมถึง PHP 5: watchTowr ระบุว่ารุ่นเหล่านี้ได้รับผลกระทบและไม่มีรุ่นแก้ ข้อมูลนี้มาจากผู้ให้บริการรายเดียว จึงควรยืนยันด้วยตนเองกับรุ่นที่ใช้อยู่
• แพ็กเกจจาก distribution: Linux distribution (ชุดระบบปฏิบัติการ Linux ที่มีผู้จัดทำแจกจ่าย) และผู้ให้บริการ LTS อาจแก้ช่องโหว่โดยไม่เปลี่ยนเลขรุ่น จึงควรอ่านประกาศของผู้ให้บริการ แทนการเทียบเลขรุ่น
• ผลิตภัณฑ์ที่ฝัง PHP ไว้ข้างใน: Help Net Security รายงานเมื่อ 22 ตุลาคม 2026 ว่า Palo Alto Networks แจ้งว่าผลิตภัณฑ์ PAN-OS และ Panorama ของตนได้รับผลกระทบทุกรุ่น และยังไม่มีรุ่นแก้ ส่วน Fortinet กับ Cisco ยังตรวจสอบผลิตภัณฑ์ของตนอยู่ ข้อมูลนี้จะเปลี่ยนไป จึงควรเปิดดูหน้าของผู้ให้บริการแต่ละราย

วิธีแก้

ประกาศเตือนทั้งสองฉบับระบุว่า การอัปเดต PHP เป็นวิธีแก้ที่สมบูรณ์เพียงวิธีเดียว Cloudflare เสริมว่าช่องโหว่อยู่ที่ runtime (ตัวโปรแกรม PHP ที่รันเว็บ) ไม่ได้อยู่ในโค้ดเว็บไซต์ การอัปเดตโค้ดเว็บไซต์หรือปลั๊กอินจึงไม่ช่วยแก้ ให้อัปเดตเป็นรุ่นที่แก้แล้วของสายรุ่นที่ใช้อยู่ คือ 8.5.12, 8.4.27, 8.3.36 หรือ 8.2.35 ขั้นตอนมีดังนี้

• หา PHP ทุกตัวที่ติดตั้งอยู่: เริ่มจากระบบที่เปิดสู่อินเทอร์เน็ต และให้รวม container (สภาพแวดล้อมสำเร็จรูปที่แพ็กโปรแกรมไว้ด้วยกัน) PHP หลายรุ่นบนเครื่องเดียว และอุปกรณ์ที่ฝัง PHP ไว้ข้างใน Qualys เตือนว่าคำสั่ง php -v (คำสั่งดูรุ่นของ PHP) ใน shell (หน้าต่างพิมพ์คำสั่ง) อาจแสดงโปรแกรมคนละตัวกับตัวที่รับคำขอเว็บจริง
• อัปเดตให้ถูกตัว ทั้งแพ็กเกจ ตัวโปรแกรม หรือ image: ใช้แพ็กเกจที่ผู้ให้บริการแก้แล้ว หรือสร้าง container image (ไฟล์ต้นแบบที่ใช้สร้าง container) ใหม่
• รีสตาร์ตทุกบริการที่โหลด PHP: worker ที่ทำงานอยู่ยังใช้โค้ดเก่าที่ค้างในหน่วยความจำ จนกว่าจะรีสตาร์ตหรือถูกแทนที่
• ตรวจยืนยัน: ดูว่าไม่มี worker ตัวใดยังใช้รุ่นเก่า และคืนค่าที่เคยตั้งชั่วคราวไว้ให้เป็นเหมือนเดิม (ดูหัวข้อถัดไป)

ถ้ายังอัปเดตไม่ได้ทันที

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

• สำหรับ CVE-2026-109619 ให้ปิด session upload progress (ฟีเจอร์ติดตามความคืบหน้าการอัปโหลดไฟล์ผ่าน session) ถ้าไม่ได้ใช้: ตั้ง session.upload_progress.enabled=0 ในไฟล์ php.ini ใน pool ของ PHP-FPM (กลุ่ม worker ที่ตั้งค่าแยกกัน) หรือในค่าตั้งของเซิร์ฟเวอร์ แล้วรีสตาร์ต worker ประกาศเตือนแนะนำให้ปิดไว้แม้อัปเดตแล้ว Qualys ระบุว่าการตั้งด้วย ini_set() (คำสั่งตั้งค่าในโค้ด PHP) หรือ .user.ini (ไฟล์ตั้งค่าที่วางไว้ในโฟลเดอร์ของเว็บ) ไม่พอ
• สำหรับ CVE-2026-109618 ให้ตั้ง memory_limit=-1 ที่ระดับเซิร์ฟเวอร์: นี่เป็นค่าหลักที่ PHP ระบุไว้ แต่ยังช่วยได้ไม่ครบ ค่านี้ยกเลิกเพดานหน่วยความจำ จึงเสี่ยงที่คำขอเดียวจะใช้หน่วยความจำไปจนหมด ให้ตั้งเพดานกลับเป็นค่าจำกัดหลังอัปเดต ต้องรีสตาร์ต worker และตรวจว่าไม่มี pool โฟลเดอร์ หรือการตั้งค่าของแอปพลิเคชันใดตั้งเพดานจำกัดกลับมาอีก
• จำกัดขนาดคำขอและบล็อกสิ่งที่ไม่ใช้: ตั้ง post_max_size (ขนาดสูงสุดของข้อมูลที่ส่งมาในหนึ่งคำขอ) ให้ไม่สูงเกินจำเป็น บังคับขนาดคำขอที่ proxy ด้านหน้า (เซิร์ฟเวอร์ที่รับคำขอจากอินเทอร์เน็ตก่อนส่งต่อให้เว็บแอป) และบล็อกคำขอแบบ multipart (รูปแบบที่ใช้ส่งไฟล์อัปโหลด) ถ้าแอปพลิเคชันไม่ได้ใช้
• จำกัดหน่วยความจำที่ container หรือ cgroup แทน: cgroup คือกลไกของ Linux ที่จำกัดทรัพยากรของโปรแกรม PHP ระบุว่าอย่าใช้ RLIMIT_AS และ RLIMIT_DATA (ค่าจำกัดหน่วยความจำของระบบปฏิบัติการ) เพราะอาจทำให้เข้าสู่เส้นทางที่มีช่องโหว่
• บน PHP 8.5 ให้ตั้ง fatal_error_backtraces=0: ค่านี้ปิดได้เพียงตัวกระตุ้นเดียวที่ยืนยันแล้วของ CVE-2026-109619 และไม่ได้ช่วยเรื่องอื่น
• ตั้ง pm.max_requests=1 ใน PHP-FPM ถ้าประสิทธิภาพรับไหว: worker แต่ละตัวจะรับคำขอเพียงหนึ่งคำขอ แล้วถูกแทนที่ด้วยตัวใหม่ จึงไม่มีสถานะตกค้างเหลือให้ช่องโหว่รายการที่สองใช้
• เปิด web application firewall (WAF คือตัวกรองคำขอเว็บ) ไว้เป็นอีกชั้นป้องกัน: Cloudflare ระบุว่ากฎที่ Cloudflare ดูแลปกป้องลูกค้าให้โดยค่าเริ่มต้น แต่ผู้โจมตีกำลังปรับ payload อยู่แล้ว WAF จึงเป็นตัวช่วยระหว่างรออัปเดต ไม่ใช่สิ่งที่ใช้แทนการอัปเดต
• ถ้าทำไม่ได้เลย ให้จำกัดการเข้าถึงหรือปิดระบบ: จำกัดการเข้าถึงระบบจากอินเทอร์เน็ต ส่วน NCSC (ศูนย์ความมั่นคงปลอดภัยไซเบอร์แห่งชาติของสหราชอาณาจักร) แนะนำให้ถอดระบบออกจากอินเทอร์เน็ตจนกว่าจะป้องกันได้

ตรวจว่าถูกโจมตีไปแล้วหรือยัง

การอัปเดตปิดช่องโหว่ได้ แต่ไม่ได้ลบสิ่งที่ผู้โจมตีทิ้งไว้แล้ว NCSC ระบุว่า ถ้าอัปเดตหรือถอดระบบออกจากอินเทอร์เน็ตทันทีไม่ได้ ให้ตรวจก่อนว่ามีร่องรอยการถูกบุกรุกและ backdoor (ช่องทางลับที่ผู้โจมตีฝากไว้เพื่อกลับเข้ามาภายหลัง) หรือไม่ ถ้าองค์กรไม่มีทักษะนี้ ให้ใช้ผู้ให้บริการตอบสนองเหตุการณ์ที่ NCSC รับรอง ณ วันที่ 22 ตุลาคม 2026 watchTowr ระบุว่ายังไม่มีใครเผยแพร่ IoC (ตัวบ่งชี้การถูกบุกรุก คือร่องรอยที่รู้แล้วของการโจมตี) ต่อสาธารณะ ถ้าเซิร์ฟเวอร์ PHP เคยเข้าถึงได้จากอินเทอร์เน็ตก่อนอัปเดต ข้อแนะนำด้านล่างเป็นข้อเสนอของเราเอง ไม่ได้มาจากประกาศเตือนของ PHP

• ย้อนดูตั้งแต่ 17 ตุลาคม 2026 เป็นอย่างน้อย: เพราะความพยายามโจมตีที่เร็วที่สุดที่มีรายงานจนถึงตอนนี้ คือของ Amazon ลงวันที่นั้น
• ตรวจ log ของเว็บเซิร์ฟเวอร์และของ PHP: มองหาคำขอที่พุ่งสูงผิดปกติ ข้อผิดพลาดหน่วยความจำหมดหรือ fatal error ที่เกิดซ้ำ และ worker ที่ล่ม
• มองหาไฟล์ที่ไม่ควรมี: ไฟล์ .php ที่เพิ่มใหม่หรือถูกแก้ไขในโฟลเดอร์ของเว็บ โดยเฉพาะโฟลเดอร์ที่รับไฟล์อัปโหลด
• ถือไว้ก่อนว่าข้อมูลในหน่วยความจำอาจรั่ว: Qualys ระบุว่าผู้โจมตีอ่านหน่วยความจำของ worker ได้โดยไม่ต้อง login ซึ่งอาจเผยรหัสผ่าน token (รหัสที่ใช้พิสูจน์ตัวตนแทนรหัสผ่าน) และ API key ถ้าสงสัยว่าข้อมูลถูกเปิดเผย ให้เปลี่ยนข้อมูลลับที่แอปพลิเคชันถือไว้

ข้อผิดพลาดที่พบบ่อย

• อัปเดตปลั๊กอินหรือโค้ดเว็บไซต์แล้วถือว่าจบ: ช่องโหว่อยู่ที่ตัว PHP ไม่ใช่ที่เว็บไซต์
• ตรวจ php -v แล้วหยุดแค่นั้น: shell อาจแสดง PHP คนละตัวกับที่ให้บริการเว็บอยู่ และจะตกหล่น container กับอุปกรณ์ที่ฝัง PHP ไว้ข้างใน
• ติดตั้งอัปเดตแต่ไม่รีสตาร์ต: worker ที่ทำงานอยู่ยังใช้โค้ดที่มีช่องโหว่ จนกว่าจะรีสตาร์ต
• พึ่ง WAF อย่างเดียว: ผู้โจมตีกำลังปรับ payload เพื่อหลบตัวกรองอยู่แล้ว
• คิดว่า PHP-FPM ปลอดภัย เพราะมีแต่ mod_php ที่ถูกระบุว่าเสี่ยงที่สุด: กรณีรันโค้ดผ่าน session ถูกตรวจยืนยันบน PHP-FPM ด้วยเช่นกัน
• ปล่อย memory_limit=-1 ทิ้งไว้หลังอัปเดตแล้ว: ค่านี้ยกเลิกเพดานหน่วยความจำ จึงเสี่ยงที่คำขอเดียวจะใช้หน่วยความจำไปจนหมด
• มองว่า PHP 8.1 หรือเก่ากว่าไม่เป็นไร เพราะไม่อยู่ในรายการรุ่นที่แก้แล้ว: รุ่นเหล่านั้นไม่ได้รับรุ่นแก้ตามปกติจากทีม PHP ต้นทาง จึงต้องใช้แพ็กเกจของผู้ให้บริการ backport หรือย้ายไปใช้รุ่นที่ยังได้รับการดูแล

ขั้นแรกที่ทำได้ทันที

• ทำรายการทุกระบบที่รัน PHP โดยเริ่มจากระบบที่เปิดสู่อินเทอร์เน็ต: ถามเจ้าของแอปพลิเคชันแต่ละตัว และผู้ให้บริการของผลิตภัณฑ์ที่ฝัง PHP ไว้ข้างใน
• หารุ่นของ PHP และวิธีที่รัน (mod_php PHP-FPM หรืออย่างอื่น): ตรวจที่ตัวโปรแกรมที่รับคำขอเว็บจริง ไม่ใช่ตรวจแค่ใน shell
• กำหนดเวลาอัปเดตในช่วงบำรุงรักษาครั้งถัดไป หรือเร็วกว่านั้นสำหรับระบบที่เปิดสู่อินเทอร์เน็ต: ช่องโหว่นี้กำลังถูกโจมตีจริง จึงควรถือเป็นการเปลี่ยนแปลงฉุกเฉิน
• ใช้ค่าตั้งชั่วคราวเฉพาะระบบที่ต้องรอการอัปเดต: จดไว้ว่าใครเป็นเจ้าของ และจะเลิกใช้เมื่อไร
• ดูหน้าของผู้ให้บริการสำหรับอุปกรณ์และบริการที่ใช้อยู่
• ตรวจรายการ Known Exploited Vulnerabilities (KEV) ของ CISA อีกครั้ง: KEV คือรายการช่องโหว่ที่มีการโจมตีใช้งานจริงแล้ว CISA เป็นหน่วยงานความมั่นคงไซเบอร์ของสหรัฐฯ watchTowr ระบุว่า ณ วันที่ 22 ตุลาคม 2026 ทั้งสอง CVE ยังไม่อยู่ในรายการ และอาจเปลี่ยนได้

สำหรับงานที่ต้องทำเป็นประจำเบื้องหลังเรื่องนี้ ดู Patch Management: ทำอย่างไรให้ทันและไม่ทำระบบล่ม, Vulnerability Management: วิธีสร้างโปรแกรมที่ใช้ได้จริง และ CVSS, EPSS และ KEV: ตัดสินใจอย่างไรว่าต้องแก้อะไรก่อน ถ้าต้องการรู้ว่าองค์กรอยู่ในระดับใดตอนนี้ ลองใช้ แบบประเมินตนเอง

แหล่งอ้างอิงและข้อมูลเพิ่มเติม

เรื่องนี้เปลี่ยนเร็ว บทความนี้ใช้ข้อมูลที่เผยแพร่ถึงวันที่ 23 ตุลาคม 2026 รายการรุ่น สถานะของผู้ให้บริการ และรายงานการโจมตีอาจเปลี่ยนไป จึงควรเปิดเอกสารต้นฉบับดูอีกครั้งก่อนลงมือ ประกาศเตือนมาจากโครงการ PHP ส่วนรายงานการโจมตีมาจาก Amazon, watchTowr และ Cloudflare ซึ่งเรายังไม่ได้ตรวจสอบเอง เรายังไม่ได้ทดสอบช่องโหว่หรือค่าตั้งข้างต้นเอง คำแนะนำเรื่องการตรวจร่องรอยการบุกรุกเป็นความเห็นของเราเอง

• ประกาศเตือนของ PHP GHSA-w8hw-w9fx-j79w (CVE-2026-109618): ประกาศเตือนจากโครงการ PHP สำหรับช่องโหว่หน่วยความจำหมด ระบุรุ่นที่ได้รับผลกระทบ รุ่นที่แก้ และค่าตั้งที่ลดความเสี่ยง
• ประกาศเตือนของ PHP GHSA-6wmf-4rv5-p3rp (CVE-2026-109619): ประกาศเตือนสำหรับช่องโหว่สถานะส่วนกลางที่ตกค้าง
• NCSC สหราชอาณาจักร: Critical security issue affecting PHP: คำแนะนำเป็นขั้นตอนจากหน่วยงานความมั่นคงไซเบอร์ระดับชาติ
• Cloudflare: การป้องกัน php2shell: สิ่งที่ WAF ของ Cloudflare ครอบคลุม ปริมาณโจมตีที่เห็น และเหตุผลที่ยังต้องอัปเดต
• Amazon Threat Intelligence: การโจมตี PHP2Shell ก่อนเปิดเผยต่อสาธารณะ: รายงานความพยายามโจมตีเมื่อ 17 ตุลาคม
• Help Net Security: PHP2Shell ช่องโหว่ PHP ร้ายแรงที่ออกรุ่นแก้แล้ว: สรุปข่าว รวม backport และความคืบหน้าของผู้ผลิต
• Qualys: วิธีค้นหา ลดความเสี่ยง และแพตช์ PHP2Shell: ขั้นตอนตรวจหาและตรวจยืนยัน (หน้านี้อาจแสดง error เมื่อเปิดด้วยเครื่องมืออัตโนมัติ)
• watchTowr: PHP2Shell FAQ: สายรุ่นที่ได้รับผลกระทบ รายงานการโจมตี และสถานะ KEV ณ วันที่ 22 ตุลาคม (หน้านี้อาจแสดง error เมื่อเปิดด้วยเครื่องมืออัตโนมัติ)
• รายการ Known Exploited Vulnerabilities ของ CISA: ใช้ตรวจว่ามีการเพิ่ม CVE ทั้งสองเข้ารายการหรือยัง