1. บทสรุปผู้บริหาร (Executive Threat Summary)

เมื่อ 22 ตุลาคม 2569 ที่ผ่านมามีรายงานการตรวจพบช่องโหว่ความรุนแรงระดับวิกฤตคู่บนแกนกลางของตัวแปลภาษา PHP ได้แก่ CVE-2026-109618 และ CVE-2026-109619 โดยมีคะแนนความรุนแรง CVSS v4.0 สูงถึง 9.2 กลุ่มนักวิจัยตั้งชื่อช่องโหว่นี้ว่า “PHP2Shell” (Tzadik et al., 2026; watchTowr, 2026)

ช่องโหว่นี้ส่งผลให้ผู้โจมตีสั่งรันโค้ดจากระยะไกลแบบ Unauthenticated Remote Code Execution (RCE) ได้ทันทีโดยไม่ต้องผ่านการยืนยันตัวตน จุดอันตรายสูงสุดคือ โค้ดอันตรายจะถูกประมวลผลบนแกนกลาง PHP Core (Zend Engine) ในขั้นตอนการอ่านค่า HTTP Request ก่อนที่โค้ดของแอปพลิเคชันหรือเฟรมเวิร์กอย่าง WordPress, Drupal หรือ Laravel จะเริ่มทำงาน (Tzadik et al., 2026)

รายงานจาก CrowdStrike ระบุว่า โค้ดสาธิตการโจมตี (Proof-of-Concept: PoC) สาธารณะบน GitHub ส่วนใหญ่ยังเป็นเพียง Crash PoC ที่ทำให้บริการหยุดทำงาน (Duque & Conrad, 2026) อย่างไรก็ดี ข้อมูลล่าสุดยืนยันว่าภัยคุกคามนี้เข้าสู่ขั้นปฏิบัติการจริงแล้ว:

  • การโจมตีจริงเกิดขึ้นก่อนการเปิดเผยแพตช์: เครือข่าย Honeypot "MadPot" ของ Amazon ตรวจพบความพยายามส่ง Exploit ตั้งแต่วันที่ 17 ตุลาคม 2569 ซึ่งเกิดขึ้นก่อนหน้าการประกาศแพตช์ทางการ (Amazon Threat Intelligence, 2026)
  • มี Exploit เชิงพาณิชย์และระบบทดสอบที่สำเร็จแล้ว: VulnCheck พัฒนา Weaponized Exploit สำหรับสถาปัตยกรรม AMD64 และ ARM64 สำเร็จ ขณะเดียวกันทีม Wiz สาธิตการทำ RCE บน Container Image ทางการของ WordPress และ Drupal ได้อย่างสมบูรณ์ (Tzadik et al., 2026; VulnCheck, 2026)
  • การสแกนหาเป้าหมายวงกว้าง: เครือข่ายเฝ้าระวังความปลอดภัยตรวจพบการส่ง Payload สแกนหาเครื่องเป้าหมายบนอินเทอร์เน็ตอย่างต่อเนื่องตั้งแต่วันที่ 21 ตุลาคม 2569 (watchTowr, 2026)

2. วิเคราะห์ Attack Surface ในประเทศไทย: เจาะลึกสถิติ Attack Surface การโจมตีเว็บไทย

การประเมินความเสี่ยงต่อประเทศไทย อ้างอิงจากชุดข้อมูลการสำรวจพื้นผิวการโจมตีภายนอก (External Attack Surface Reconnaissance Telemetry) ของกลุ่มตัวอย่างบริการเว็บสาธารณะในไทย (Cyber Guard Intelligence, 2026) โดยผลการวิเคราะห์เชิงสถิติพบประเด็นสำคัญดังนี้:

2.1 กับดักเวอร์ชันหมดอายุ (EOL Trap) สูงถึง 72.20%

ผลการตรวจสอบสถานะระบบพบว่า บริการเว็บในไทยมีสัดส่วนสูงถึง 72.20% ที่ถูกจัดอยู่ในกลุ่มหมดอายุการสนับสนุน (End-of-Life: EOL-product) เมื่อวิเคราะห์ในระดับหมายเลข IP สาธารณะ พบว่ามีสัดส่วนสูงถึง 81.15% ที่ยังคงเปิดบริการซึ่งหมดอายุทิ้งไว้

สถานการณ์นี้นับเป็นความเสี่ยงขั้นวิกฤตเนื่องจาก:

  • PHP Core Team ยุติการออก Binary Release ทางการให้กับ PHP 8.1 และเวอร์ชันก่อนหน้าอย่างถาวร
  • ระบบในไทยที่ใช้งาน PHP 7.4 ลงไปจนถึง PHP 5.6 และ 5.4 จะไม่ได้รับแพตช์ผ่านคำสั่งอัปเดตปกติของระบบปฏิบัติการ ผู้ดูแลระบบต้องดาวน์โหลด Minimal Source Patch มาคอมไพล์เอง หรือจัดซื้อบริการ Extended Commercial Support เท่านั้น (Help Net Security, 2026)
  • หากไม่ดำเนินการแก้ไข เซิร์ฟเวอร์กลุ่มนี้จะตกเป็นเป้าหมายถาวรของผู้โจมตีที่ใช้เครื่องมือสแกนอัตโนมัติ

2.2 สถาปัตยกรรม Apache mod_php เวกเตอร์เสี่ยงสูงสุดครองส่วนแบ่งอันดับหนึ่ง

ผลการวิจัยทางเทคนิคชี้ตรงกันว่า สถาปัตยกรรม Apache ร่วมกับโมดูล mod_php คือสภาพแวดล้อมที่เปราะบางที่สุด เนื่องจากสภาวะหน่วยความจำล้น (OOM) จะไม่สั่งปิด Worker Process เหมือนกับ PHP-FPM ผู้โจมตีจึงสามารถใช้ HTTP POST เพียง Request เดียวในการควบคุม Memory Layout และรันโค้ดได้ทันที (Duque & Conrad, 2026; Serper, 2026)

จากการวิเคราะห์สัดส่วนเว็บเซิร์ฟเวอร์ที่ตรวจพบในไทย พบการกระจายตัวเชิงสถิติดังนี้:

  • Apache httpd: ครองส่วนแบ่ง 39.99% ของบริการทั้งหมด (และคิดเป็น 67.76% ของเว็บเซิร์ฟเวอร์ที่ระบุชนิดได้)
  • Nginx: ครองส่วนแบ่ง 12.67% ของบริการทั้งหมด (และคิดเป็น 21.46% ของเว็บเซิร์ฟเวอร์ที่ระบุชนิดได้)
  • Microsoft IIS: ครองส่วนแบ่ง 5.37% ของบริการทั้งหมด (และคิดเป็น 9.11% ของเว็บเซิร์ฟเวอร์ที่ระบุชนิดได้)
  • บริการอื่นหรือไม่ระบุแบนเนอร์ชัดเจน: คิดเป็น 41.97%

เมื่อตรวจสอบโครงสร้างเวอร์ชันของ Apache httpd ยังพบปัญหาหนี้ทางเทคนิค (Technical Debt) รุนแรง:

  • Apache 2.4.6: ครองสัดส่วน 16.52% ของ Apache ทั้งหมด เวอร์ชันนี้ผูกติดมากับระบบปฏิบัติการ CentOS 7 ซึ่งยุติการสนับสนุนไปแล้วตั้งแต่เดือนมิถุนายน 2024 และมักติดตั้งคู่กับ PHP 5.4.16
  • Apache 2.2.15: ครองสัดส่วน 7.45% ของ Apache ทั้งหมด เป็นเวอร์ชันดั้งเดิมของ CentOS 6 ซึ่งหมดอายุไปตั้งแต่ปี 2020 และมักรันร่วมกับ PHP 5.3.3
  • Apache 2.2.8: ครองสัดส่วน 3.52% ของ Apache ทั้งหมด ซึ่งเป็นซอฟต์แวร์รุ่นเก่าที่หยุดพัฒนาไปแล้ว
(Analyst Assessment): สัดส่วนของ Apache รุ่นเก่าสะท้อนว่า เซิร์ฟเวอร์ในไทยจำนวนมากทำงานอยู่บนระบบปฏิบัติการ Enterprise Linux รุ่นเก่าที่เลิกดูแล การขาดการอัปเกรดระบบปฏิบัติการทำให้ไม่สามารถรับการแก้ไขช่องโหว่ PHP2Shell ได้ตามวงจรปกติ

2.3 ภาพสะท้อนรายเซกเตอร์: สถาบันการศึกษา หน่วยงานภาครัฐ และภาคธุรกิจ

ผลการคัดกรองข้อมูล Hostname และ Domain ในกลุ่มโดเมนสำคัญของประเทศไทย พบตัวเลขความเสี่ยงเชิงโครงสร้าง:

  • ภาคธุรกิจและพาณิชย์ (.co.th): มีสัดส่วนบริการที่อยู่ในสถานะ EOL สูงถึง 86.68% และมีสัดส่วนการใช้งาน Apache httpd อยู่ที่ 53.52% ซึ่งเป็นกลุ่มที่เก็บข้อมูลธุรกรรมและข้อมูลส่วนบุคคลจำนวนมาก
  • หน่วยงานภาครัฐ (.go.th): มีสัดส่วนบริการที่อยู่ในสถานะ EOL อยู่ที่ 73.89% และมีสัดส่วนการใช้งาน Apache httpd อยู่ที่ 59.73%
  • ภาคการศึกษา (.ac.th): มีสัดส่วนบริการที่อยู่ในสถานะ EOL อยู่ที่ 72.68% และมีสัดส่วนการใช้งาน Apache httpd อยู่ที่ 60.80%

2.4 การกระจายตัวในกลุ่ม ISP และ Cloud ในไทย

บริการกลุ่มเสี่ยงกระจายตัวอยู่ในผู้ให้บริการโครงสร้างพื้นฐานหลักของประเทศ:

  • SBN-ISP / AWN-ISP (AIS Corporate & Fibre): 19.53%
  • National Telecom (NT / TOT รวมกัน): 12.87%
  • Alibaba Cloud: 11.24%
  • UniNet: 5.30%
  • 3BB (Triple T Broadband): 5.14%
  • Amazon Web Services (AWS): 4.29%
  • Huawei Cloud: 2.78%
(Analyst Assessment): สัดส่วนเซิร์ฟเวอร์บน Shared Hosting และ Local Cloud มีความเสี่ยงต่อการถูกใช้เป็นจุดเริ่มต้นของการโจมตีข้ามระบบ หากผู้โจมตียึด Process หน่วยความจำของ Worker ตัวหนึ่งได้ อาจขยายผลไปสู่การดึงข้อมูลส่วนความลับของลูกค้ารายอื่นในเครื่องเดียวกันได้

3. หักล้างมายาคติ: ทำไมระบบของคุณจึงอาจยังไม่ปลอดภัย

ผู้ดูแลระบบหลายองค์กรอาจประเมินความเสี่ยงต่ำกว่าความเป็นจริง เนื่องจากความเข้าใจคลาดเคลื่อนสำคัญ:

3.1 “ผลการสแกนด้วยเครื่องมือ Dependency ปลอดภัย แปลว่าระบบไม่ได้รับผลกระทบ”

เครื่องมือตรวจสอบ Library เช่น Dependabot หรือคำสั่ง composer audit ตรวจเฉพาะไฟล์ระดับ Application Package เท่านั้น แต่ PHP2Shell เกิดขึ้นในตัวแปลภาษา C ระดับ PHP Core แม้แต่เครื่องมือสแกน Container Image อย่าง Trivy หากตรวจสอบ Image ที่คอมไพล์ PHP จาก Source Code โดยตรง จะไม่พบช่องโหว่นี้เนื่องจากไม่มีข้อมูล Metadata ของ Package Manager (Tzadik et al., 2026; VulnCheck, 2026)

3.2 “ระบบปฏิบัติการเปิดใช้งาน ASLR ไว้แล้ว ผู้โจมตีไม่สามารถคำนวณแอดเดรสได้”

CVE-2026-109619 มีกลไกสร้าง Memory Leak ผ่านฟังก์ชัน Upload Progress และ Fatal Error Backtrace ข้อมูลดิบใน Heap จะถูกส่งกลับมาทางคุกกี้ PHPSESSID ใน HTTP Response ผู้โจมตีสามารถนำแอดเดรสนี้ไปคำนวณ Base Address เพื่อข้ามกลไก ASLR ได้อย่างสมบูรณ์ทั้งบนสถาปัตยกรรม AMD64 และ ARM64 (Serper, 2026; Tzadik et al., 2026; VulnCheck, 2026)

3.3 “เว็บไซต์ไม่มีฟังก์ชันรับอัปโหลดไฟล์ และไม่มีระบบล็อกอิน คงไม่ตกเป็นเป้าหมาย”

บั๊กทำงานในกระบวนการ Parse ข้อมูลของ Zend Engine ก่อนที่สคริปต์ปลายทางจะเริ่มทำงาน แม้เป็นหน้าเว็บเปล่าที่เขียนเพียง <?php echo "Hello"; ?> หากทำงานอยู่บน PHP Core ที่มีช่องโหว่ ผู้โจมตีก็สามารถส่ง HTTP Request พิเศษเข้ามารบกวนหน่วยความจำเพื่อควบคุมการทำงานของเซิร์ฟเวอร์ได้ทันที (Tzadik et al., 2026)

4. กลไกเชิงลึกและห่วงโซ่การโจมตี (Attack Lifecycle)

ต้นตอของช่องโหว่เกิดจากข้อบกพร่องในระบบจัดการหน่วยความจำและการตัดการทำงานฉุกเฉินของ Zend Engine:

  • CVE-2026-109618 (Out-of-Memory Memory Corruption): เมื่อ PHP พบเงื่อนไขหน่วยความจำเต็มระหว่างรับ Request ระบบจะเรียกใช้คำสั่ง longjmp() เพื่อตัดจบการทำงาน คำสั่งนี้ข้ามขั้นตอนการคืนหน่วยความจำปกติ โครงสร้างข้อมูลที่สร้างค้างอยู่จึงกลายเป็นข้อมูลขยะ เมื่อระบบพยายามรันขั้นตอน Cleanup ขยะเหล่านี้จะนำไปสู่สภาวะ Memory Corruption ในสถาปัตยกรรม Apache mod_php ผู้โจมตีสามารถใช้ HTTP POST เพียง Request เดียวเพื่อควบคุม Flow การรันคำสั่งได้ทันที (Serper, 2026)
  • CVE-2026-109619 (Global State Use-After-Free): ตัวแปรพอยน์เตอร์ระดับ Global ยังคงชี้ไปยังแอดเดรสหน่วยความจำที่ถูกทำลายไปแล้ว คำขอถัดไปที่ส่งเข้ามายัง Worker เดิมจะเข้าถึง Dangling Pointer นั้น นำไปสู่การขโมยข้อมูลลับจาก Heap หรือรันโค้ดอันตราย (Serper, 2026; Tzadik et al., 2026)
  • CVE-2026-115560 (Session Deserialization Edge Case): ช่องโหว่เพิ่มเติมที่พบในกระบวนการสลับ Serializer ผ่านคำสั่ง ini_set() ร่วมกับการเปิดระบบ Upload Progress ซึ่งทีมพัฒนาออกคำเตือนเพิ่มเติม (Ernalbant, 2026)

5. MITRE ATT&CK Mapping

การจำแนกพฤติกรรมและเทคนิคการโจมตีตามกรอบ MITRE ATT&CK:

Initial Access

  • T1190 Exploit Public-Facing Application: ส่ง HTTP Request ออกแบบพิเศษเข้าสู่ PHP Parser บนเว็บเซิร์ฟเวอร์สาธารณะ

Execution

  • T1059.004 Unix Shell: สั่งรันคำสั่ง Arbitrary Shell Command ภายใต้สิทธิ์ของกระบวนการเว็บเซิร์ฟเวอร์ (เช่น www-data, apache)

Defense Evasion

  • T1211 Exploitation for Defense Evasion: ใช้ประโยชน์จากกลไก OOM และ Memory Leak ข้ามการป้องกัน ASLR บนหน่วยความจำ

Credential Access & Collection

  • T1056 Input Capture: ดักจับค่าตัวแปรในหน่วยความจำ
  • T1005 Data from Local System: อ่านข้อมูล Credential, Session Token และ Environment Variables ผ่านค่ารั่วไหลในคุกกี้ PHPSESSID

Command and Control

  • T1071.001 Web Protocols: อาศัยการเชื่อมต่อ HTTP/HTTPS ปกติเพื่อส่ง Payload โจมตีและรับข้อมูลที่รั่วไหลกลับออกไป

6. คำแนะนำเร่งด่วนสำหรับผู้ปกป้องระบบในประเทศไทย (Actionable Recommendations)

Amazon Threat Intelligence (2026) ระบุว่า การรับมือกับช่องโหว่ระดับวิกฤตบนระบบอินเทอร์เน็ต ต้องกำหนดกรอบเวลาการแก้ไขเป็นระดับชั่วโมง ไม่ใช่รอบประจำเดือน

ข้อ 1: อัปเกรด PHP และรีสตาร์ทโพรเซสบริการทันที

ปรับปรุงซอฟต์แวร์ PHP ไปยังเวอร์ชันทางการที่ปิดช่องโหว่แล้ว:

  • PHP 8.5: ปรับเป็น 8.5.12 หรือสูงกว่า
  • PHP 8.4: ปรับเป็น 8.4.27 หรือสูงกว่า
  • PHP 8.3: ปรับเป็น 8.3.36 หรือสูงกว่า
  • PHP 8.2: ปรับเป็น 8.2.35 หรือสูงกว่า
ข้อกำหนดทางเทคนิคสำคัญ: หลังจากติดตั้งไฟล์แพตช์ ต้องสั่ง Restart บริการ Apache httpd, PHP-FPM Workers ทั้งหมด และ Rebuild Container Image ใหม่ทันที การอัปเดตไฟล์ Binary บนดิสก์โดยไม่รีสตาร์ท จะไม่ช่วยป้องกัน Worker ที่ยังเปิดค้างอยู่ในหน่วยความจำ (Duque & Conrad, 2026; Tanium, 2026)

ข้อ 2: มาตรการบรรเทาความเสี่ยงชั่วคราว (Workarounds)

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

  • ปิดระบบ Upload Progress: กำหนดในไฟล์ php.ini หลัก: session.upload_progress.enabled = 0 (ต้องทำในระดับระบบ ห้ามใช้ ini_set() ในโค้ดแอปพลิเคชัน) (Tanium, 2026)
  • ปิด Backtrace บน PHP 8.5: กำหนดค่า: fatal_error_backtraces = 0 เพื่อตัดเส้นทางการรั่วไหลของหน่วยความจำ (VulnCheck, 2026)
  • บรรเทาความเสี่ยง CVE-2026-109618: กำหนด memory_limit = -1 ในระดับ Server Admin Value ควบคู่กับการลด post_max_size ให้เหลือเพียง 8M หรือเท่าที่จำเป็นต่อการใช้งานจริง
  • (คำเตือน) การตั้ง memory_limit = -1 ต้องควบคุมด้วย Container Memory Limits หรือ cgroups ของระบบปฏิบัติการเท่านั้น เพื่อป้องกันการโจมตีประเภท Denial of Service (VulnCheck, 2026)

ข้อ 3: จัดการระบบที่อยู่ในสถานะ EOL อย่างเด็ดขาด

สำหรับระบบที่ใช้ PHP 8.1, 8.0, 7.4 ลงไป ซึ่งมีสัดส่วนสูงถึง 72.20% ในไทย:

  • ย้ายบริการออกจากเครือข่ายอินเทอร์เน็ตสาธารณะ หรือนำไปไว้หลัง Reverse Proxy / Web Application Firewall (WAF) ที่มีการตรวจสอบ Request อย่างเข้มงวด
  • หากจำเป็นต้องเปิดบริการ ให้ใช้ Minimal Source Patch ที่ทีมพัฒนา PHP เผยแพร่มาคอมไพล์เอง หรือติดต่อขอรับแพตช์จากผู้ให้บริการ Extended Support (Help Net Security, 2026)

ข้อ 4: Threat Hunting ย้อนหลังไปถึงวันที่ 17 ตุลาคม 2569

เนื่องจากการโจมตีจริงเริ่มขึ้นก่อนการประกาศแพตช์ ทีมความมั่นคงปลอดภัยต้องดำเนินการตรวจสอบย้อนหลัง:

  • ตรวจสอบ Web Server Error Log เพื่อค้นหาข้อความ: Allowed memory size of ... bytes exhausted ... in Unknown on line 0
    ข้อความนี้เป็นสัญญาณบ่งชี้ว่าเกิดหน่วยความจำล้นตั้งแต่ขั้นตอนการ Parse ของ Engine ก่อนที่โค้ดของแอปพลิเคชันจะทำงาน (Amazon Threat Intelligence, 2026; Serper, 2026)
  • ตรวจสอบ HTTP POST Request ที่มีพารามิเตอร์ PHP_SESSION_UPLOAD_PROGRESS เข้ามาในปริมาณผิดปกติ หรือ Multipart Request ที่ไม่สมบูรณ์
  • ตรวจสอบโปรเซสผิดปกติภายใต้สิทธิ์ของเว็บเซิร์ฟเวอร์ เช่น มีการรัน sh, bash, curl, wget หรือเครื่องมือสแกนเครือข่าย (Amazon Threat Intelligence, 2026)

ข้อ 5: ผลัดเปลี่ยน Credential (Secret Rotation) ทันที

สำหรับเซิร์ฟเวอร์กลุ่มเสี่ยงที่เปิดสู่อินเทอร์เน็ตสาธารณะ ให้ดำเนินการ Revoke และ Rotate รหัสผ่านฐานข้อมูล, API Secret Keys, JWT Signing Keys และ Access Token ทั้งหมด เนื่องจากกลไก Memory Leak สามารถดึงข้อมูลความลับจากหน่วยความจำออกไปได้ โดยที่ตัว Worker ไม่แสดงอาการ Crash (Serper, 2026; Tzadik et al., 2026)

7. ข้อมูลตัวบ่งชี้ภัยคุกคาม (Indicators of Compromise - IoCs)

ข้อมูลการโจมตีของระบบโจมตีที่ตรวจพบบนเครือข่ายระดับโลก:

IP Address (โฮสต์สแกนและส่ง Payload ยืนยันโดย Amazon Threat Intelligence):

  • 103[.]216[.]220[.]92: ตรวจพบการพยายามส่ง Exploit วันที่ 17 ตุลาคม 2569 ผ่านเครือข่ายพรางตัว
  • 31[.]223[.]184[.]166: ตรวจพบการสแกนหาวงกว้าง วันที่ 21 ตุลาคม 2569
  • 37[.]19[.]200[.]5: ตรวจพบการสแกนหาวงกว้าง วันที่ 21 ตุลาคม 2569
  • 134[.]209[.]159[.]64: ตรวจพบการสแกนหาวงกว้าง วันที่ 21 ตุลาคม 2569
  • 103[.]114[.]163[.]188: ตรวจพบการสแกนหาวงกว้าง วันที่ 21 ตุลาคม 2569
  • 95[.]217[.]98[.]37: ตรวจพบการสแกนหาวงกว้าง วันที่ 21 ตุลาคม 2569

IP Address (โฮสต์เตรียมการโจมตียืนยันโดย SOCRadar):

  • 206[.]188[.]197[.]105: เซิร์ฟเวอร์เก็บสคริปต์เตรียมการโจมตีและสแกนระบบ Apache mod_php

Log Artifacts สำหรับการตรวจจับ:

  • Allowed memory size of %d bytes exhausted (tried to allocate %d bytes) in Unknown on line 0
  • ค่าคุกกี้ PHPSESSID ใน HTTP Response ที่มีความยาวผิดปกติ หรือมีข้อมูลไบนารีจาก Heap หลุดออกมา

8. รายการอ้างอิง (References - APA 7th Edition)

Amazon Threat Intelligence. (2026, October 21). Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot. AWS Security Blog. https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
CNBC. (2026, October 22). 'PHP2Shell' vulnerability: What is it, and is your data at risk? CNBC International. https://www.cnbc.com/2026/10/22/php2shell-vulnerability-what-is-it-and-is-your-data-at-risk.html
Cyber Guard Intelligence. (2026, October 24). Thailand external attack surface telemetry: Web servers and legacy software exposure [Data set]. Cyber Guard Intelligence Research.
Duque, J., & Conrad, B. (2026, October 23). Obstacles to weaponizing PHP2Shell likely constrain immediate widespread exploitation. CrowdStrike Counter Adversary Operations. https://www.crowdstrike.com/en-us/blog/obstacles-to-weaponizing-php2shell-likely-constrain-exploitation/
Ernalbant, Y. (2026, October 21). PHP2Shell (CVE-2026-109618 & CVE-2026-109619): Critical PHP RCE flaws, affected versions, and how to fix them. SOCRadar Cyber Intelligence. https://socradar.io/blog/php2shell-cve-2026-109618-cve-2026-109619/
Help Net Security. (2026, October 21). PHP2Shell: Critical PHP vulnerabilities patched, update now! Help Net Security. https://helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/
Lilting. (2026, October 21). php2shell needs the PHP patch, not just session.upload_progress=0. Lilting Security. https://lilting.ch/en/articles/php2shell-official-patch
SentinelOne. (2026, October 22). Stopping PHP2SHELL: How SentinelOne protects customers from this attack technique. SentinelOne Research. https://www.sentinelone.com/blog/stopping-php2shell-how-sentinelone-protects-customers-from-this-attack-technique/
Serper, A. (2026, October 21). CrowdStrike protects customers from threats delivered via PHP2Shell. CrowdStrike Counter Adversary Operations. https://www.crowdstrike.com/en-us/blog/crowdstrike-protects-customers-from-php-rce-zero-days/
Tanium. (2026, October 21). PHP2Shell: Responding to CVE-2026-109618 and CVE-2026-109619. Tanium Threat Research. https://www.tanium.com/blog/php2shell-responding-to-cve-2026-109618-and-cve-2026-109619/
Tzadik, S., Tamari, S., Ohfeld, N., & Schwartz, T. (2026, October 21). PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet. Wiz Research. https://www.wiz.io/blog/php2shell-php-rce
Ullrich, J. (2026, October 21). Critical PHP vulnerability (CVE-2026-109618, CVE-2026-109619) [infocon yellow]. SANS Internet Storm Center. https://isc.sans.edu/diary.html?storyid=33665
VulnCheck. (2026, October 21). PHP2Shell vulnerabilities: CVE-2026-109618 and CVE-2026-109619. VulnCheck Advisory. https://www.vulncheck.com/blog/php2shell-vulnerabilities
watchTowr. (2026, October 21). PHP Remote Code Execution (“PHP2Shell” CVE-2026-109618 & CVE-2026-109619). watchTowr Intelligence. https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/