# PHP2Shell: สิ่งที่เจ้าของร้านออนไลน์ควรทำตอนนี้

> เมื่อวันที่ 21 ตุลาคม 2026 โครงการ PHP แก้ไขช่องโหว่ร้ายแรงสองรายการ คือ CVE-2026-109618 และ CVE-2026-109619 ซึ่งเรียกกันว่า PHP2Shell ช่องโหว่นี้ทำให้ผู้โจมตีรันโค้ดบนเว็บเซิร์ฟเวอร์ได้โดยไม่ต้องล็อกอิน ร้านที่โฮสต์เองและทำงานบน PHP เช่น WooCommerce, Magento, PrestaShop หรือ OpenCart ควรใช้ PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 หรือแพ็กเกจที่แก้ไขแล้วจากผู้ให้บริการโฮสติ้ง CISA ของสหรัฐฯ ได้เพิ่มช่องโหว่ทั้งสองลงในรายการช่องโหว่ที่ถูกใช้โจมตีจริงเมื่อวันที่ 26 ตุลาคม 2026

Canonical: https://tellnod.com/th/guides/php-vulnerability-online-store-checklist  
Last updated: 2026-10-30  
Author: Tellnod team

## สิ่งที่ต้องทำวันนี้

1. **ตรวจดูว่าร้านใช้ PHP เวอร์ชันใด.** ดูในแผงควบคุมโฮสติ้ง หรือใน WordPress ไปที่ เครื่องมือ > สุขภาพเว็บไซต์ > ข้อมูล > เซิร์ฟเวอร์ จดเวอร์ชันไว้ และดูว่าผู้ให้บริการโฮสติ้งดูแล PHP ให้หรือไม่
2. **อัปเดต PHP หรือให้โฮสติ้งยืนยันว่าแพตช์แล้ว.** อัปเดตเป็น PHP 8.5.12, 8.4.27, 8.3.36 หรือ 8.2.35 หรือสอบถามผู้ให้บริการโฮสติ้งเป็นลายลักษณ์อักษรว่าเซิร์ฟเวอร์ได้รับการแก้ไขวันที่ 21 ตุลาคม 2026 สำหรับ CVE-2026-109618 และ CVE-2026-109619 แล้วหรือยัง
3. **สำรองข้อมูลทั้งก่อนและหลัง.** ดาวน์โหลดไฟล์สำรองทั้งไฟล์เว็บและฐานข้อมูล แล้วเก็บสำเนาไว้นอกเซิร์ฟเวอร์ เพื่อให้กู้คืนเวอร์ชันที่สะอาดได้หากพบปัญหา
4. **อัปเดตระบบร้านและปลั๊กอินทุกตัว.** ติดตั้งอัปเดตที่ค้างอยู่ของ WordPress, WooCommerce หรือแพลตฟอร์มร้าน ธีม และปลั๊กอินหรือโมดูลทุกตัว แล้วลบตัวที่ไม่ได้ใช้แล้วออก
5. **ตรวจบัญชีผู้ดูแลและเปลี่ยนรหัสผ่าน.** ลบบัญชีผู้ดูแลระบบที่ไม่รู้จัก แล้วเปลี่ยนรหัสผ่านหลังร้าน โฮสติ้ง และฐานข้อมูล รวมถึงรหัสผ่านและคีย์ API ของบริการอีเมลที่เก็บไว้ในร้าน

## เกิดอะไรขึ้น อธิบายแบบเข้าใจง่าย

PHP เป็นภาษาโปรแกรมที่ร้านค้าออนไลน์แบบโฮสต์เองจำนวนมากใช้งานอยู่ เมื่อวันที่ 21 ตุลาคม 2026 โครงการ PHP ออกเวอร์ชัน 8.5.12, 8.4.27, 8.3.36 และ 8.2.35 เพื่อแก้ไขช่องโหว่ร้ายแรงสองรายการ คือ CVE-2026-109618 และ CVE-2026-109619 [S1] นักวิจัยด้านความปลอดภัยเรียกช่องโหว่คู่นี้ว่า PHP2Shell [S5][S6] ทั้งสองได้คะแนนความรุนแรง 9.2 จาก 10 [S5]

ปัญหาอยู่ที่ตัว PHP เอง ไม่ใช่ปลั๊กอินตัวใดตัวหนึ่ง โครงการ PHP ระบุว่าทุกการติดตั้ง PHP ที่รับคำขอจากเว็บได้รับผลกระทบ และในการตั้งค่าเซิร์ฟเวอร์บางแบบ คำขอจากคนที่ไม่ได้ล็อกอินสามารถเริ่มการโจมตีได้ก่อนที่โค้ดของร้านจะทำงานเสียอีก [S1] ดังนั้นการล็อกอินหลังร้าน ปลั๊กอินความปลอดภัย หรือรหัสผ่านที่รัดกุม เพียงอย่างเดียวจึงป้องกันไม่ได้ โครงการ PHP ระบุว่าไม่มีวิธีหลีกเลี่ยงที่สมบูรณ์ และการอัปเดตเป็นทางเลือกเดียวที่ปลอดภัย [S1]

ความพยายามโจมตีเริ่มขึ้นตั้งแต่เนิ่น ๆ Datadog รายงานว่า AWS พบความพยายามใช้ช่องโหว่ตั้งแต่วันที่ 17 ตุลาคม 2026 ก่อนที่จะมีการเผยแพร่การแก้ไข [S6] และเมื่อวันที่ 26 ตุลาคม 2026 หน่วยงานความมั่นคงปลอดภัยไซเบอร์และโครงสร้างพื้นฐานของสหรัฐฯ (CISA) ได้เพิ่ม CVE ทั้งสองรายการลงในแค็ตตาล็อก Known Exploited Vulnerabilities ซึ่งรวบรวมช่องโหว่ที่มีหลักฐานว่าถูกใช้โจมตีจริง [S3][S4]

> ปัญหาอีกรายการหนึ่งคือ CVE-2026-115560 ซึ่งโครงการ PHP เปิดเผยเมื่อวันที่ 23 ตุลาคม 2026 ไม่ได้เป็นส่วนหนึ่งของ PHP2Shell และเวอร์ชันวันที่ 21 ตุลาคมยังไม่ได้แก้ไข ปัญหานี้กระทบเฉพาะแอปพลิเคชันที่ใช้การตั้งค่า session แบบผสมที่ไม่ค่อยพบ การแก้ไขมีกำหนดอยู่ในเวอร์ชันปกติถัดไป ระหว่างนี้แนะนำให้ตั้งค่า `session.upload_progress.enabled = 0` [S2] บทความนี้อ้างอิงสถานการณ์ ณ วันที่ 30 ตุลาคม 2026

## ร้านของฉันได้รับผลกระทบหรือไม่

ถ้าคุณโฮสต์ร้านเอง ร้านของคุณน่าจะทำงานบน PHP WordPress เป็นแอปพลิเคชัน PHP [S7] ร้าน WooCommerce จึงทำงานบน PHP เช่นเดียวกับ Magento (Adobe Commerce), PrestaShop และ OpenCart บล็อก หน้าแคมเปญ หรือพื้นที่สมาชิกที่ทำด้วย WordPress ก็นับด้วย แม้ตัวร้านจะอยู่ที่อื่น

| รูปแบบร้าน | ใช้ PHP หรือไม่ | ใครอัปเดต PHP |
| --- | --- | --- |
| WooCommerce บน WordPress | ใช้ | คุณเองหรือผู้ให้บริการโฮสติ้ง ขึ้นอยู่กับแพ็กเกจ |
| Magento, PrestaShop หรือ OpenCart บนเซิร์ฟเวอร์ของคุณเอง | ใช้ | คุณเอง หรือเอเจนซีหรือนักพัฒนาที่ดูแลเซิร์ฟเวอร์ |
| WordPress แบบ managed หรือโฮสติ้งร้านค้าแบบ managed | ใช้ | ส่วนใหญ่เป็นผู้ให้บริการโฮสติ้ง ให้ขอคำยืนยันเรื่องแพตช์ |
| แพลตฟอร์มแบบโฮสต์ให้ทั้งหมด เช่น Shopify | คุณไม่ได้รัน PHP เอง | แพลตฟอร์มดูแลเซิร์ฟเวอร์ของตัวเอง |

ดูเวอร์ชัน PHP ได้ในแผงควบคุมโฮสติ้ง ซึ่งมักอยู่ในเมนูตั้งค่า PHP หรือเวอร์ชัน PHP ส่วนใน WordPress ไปที่ เครื่องมือ > สุขภาพเว็บไซต์ > แท็บข้อมูล แล้วเปิดหัวข้อเซิร์ฟเวอร์ เวอร์ชันที่แก้ไขแล้วคือ 8.5.12, 8.4.27, 8.3.36 และ 8.2.35 หรือใหม่กว่าในแต่ละสาย [S1]

หมายเลขเวอร์ชันอาจไม่ได้บอกทุกอย่าง ดิสทริบิวชัน Linux และผู้ให้บริการโฮสติ้งได้รับแพตช์ล่วงหน้า และอาจนำการแก้ไขไปใส่ในแพ็กเกจของตัวเองโดยไม่เปลี่ยนหมายเลขเวอร์ชัน [S1][S6] หากไม่แน่ใจ ให้ถามผู้ให้บริการโฮสติ้งโดยตรงว่าเซิร์ฟเวอร์มีการแก้ไขสำหรับ CVE-2026-109618 และ CVE-2026-109619 แล้วหรือยัง

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

## สิ่งที่ต้องทำวันนี้

รายการที่มีหมายเลขด้านบนเป็นฉบับย่อ รายละเอียดต่อไปนี้ช่วยให้แต่ละขั้นตอนปลอดภัยขึ้น

### ถ้าคุณดูแลเซิร์ฟเวอร์เอง

อัปเดต PHP ผ่านแพ็กเกจของระบบหรือแผงควบคุม แล้วรีสตาร์ต PHP และเว็บเซิร์ฟเวอร์ เพื่อให้ทุก worker ใช้เวอร์ชันที่แก้ไขแล้ว CISA แนะนำให้แพตช์ระบบที่เปิดสู่อินเทอร์เน็ตทันที และถ้าแพตช์ได้ไม่เร็ว ให้นำระบบออฟไลน์หรือวาง web application firewall ไว้ด้านหน้าเป็นการชั่วคราว [S3] โครงการ PHP ระบุการตั้งค่าชั่วคราวไว้บางส่วน แต่เตือนว่าการตั้งค่าเหล่านั้นไม่ได้ทำให้ระบบปลอดภัย [S1]

### ถ้าโฮสติ้งหรือเอเจนซีดูแลให้

ส่งคำขอสั้น ๆ เป็นลายลักษณ์อักษร: “รบกวนยืนยันว่าเซิร์ฟเวอร์ของเราได้รับการแก้ไข PHP สำหรับ CVE-2026-109618 และ CVE-2026-109619 ที่ออกเมื่อวันที่ 21 ตุลาคม 2026 แล้ว และแจ้งเวอร์ชันหรือแพ็กเกจ PHP ที่เราใช้อยู่” แล้วเก็บคำตอบไว้เป็นหลักฐาน

### สำรองข้อมูลก่อนแก้ไขอะไร

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

### อัปเดตปลั๊กอินและตรวจบัญชีผู้ดูแล

การอัปเดต PHP ปิดช่องโหว่นี้ได้ แต่ส่วนอื่นของร้านก็ยังต้องดูแล อัปเดต WordPress, WooCommerce หรือแพลตฟอร์มของคุณ ธีม และปลั๊กอินทุกตัว ตรวจรายชื่อผู้ใช้ว่ามีบัญชีผู้ดูแลที่คุณไม่ได้สร้างหรือไม่ จากนั้นเปลี่ยนรหัสผ่าน และสร้างคีย์ API กับรหัสผ่าน SMTP ที่เก็บไว้ในร้านใหม่ เช่น ของระบบชำระเงิน ขนส่ง และอีเมล เพราะใครก็ตามที่เคยเข้าถึงเซิร์ฟเวอร์อาจอ่านข้อมูลเหล่านี้ได้

## ปกป้องรายชื่อลูกค้าและชื่อเสียงผู้ส่งอีเมล

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

### สัญญาณที่บอกว่ามีบางอย่างผิดปกติ

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

[ชื่อเสียงผู้ส่ง](https://tellnod.com/glossary#sender-reputation) ของโดเมนต้องใช้เวลาสร้าง แต่ลดลงได้เร็วเมื่อมีสแปมถูกส่งออกไปในนามของคุณ เรคคอร์ด SPF, DKIM และ DMARC บอกกล่องจดหมายว่าเซิร์ฟเวอร์ใดส่งอีเมลแทนโดเมนของคุณได้ และรายงาน DMARC ช่วยให้เห็นว่าใครพยายามแอบอ้าง [คำอธิบาย SPF, DKIM และ DMARC](https://tellnod.com/th/guides/spf-dkim-dmarc-explained) อธิบายแต่ละเรคคอร์ด และ [คู่มือตั้งค่า DMARC](https://tellnod.com/th/guides/how-to-set-up-dmarc) อธิบายวิธีอ่านรายงาน ถ้าเซิร์ฟเวอร์ร้านไม่ได้มีหน้าที่ส่งอีเมลการตลาด ก็ไม่ควรใส่เซิร์ฟเวอร์นั้นในเรคคอร์ด SPF เพื่อจำกัดสิ่งที่เซิร์ฟเวอร์ที่ถูกเจาะจะทำกับโดเมนของคุณได้

### ถ้าข้อมูลลูกค้าอาจรั่วไหล

หน้าที่ทางกฎหมายหลังข้อมูลรั่วไหลแตกต่างกันในแต่ละประเทศ กฎหมายคุ้มครองข้อมูลส่วนบุคคลหลายฉบับกำหนดให้แจ้งหน่วยงานกำกับ ลูกค้าที่ได้รับผลกระทบ หรือทั้งสองฝ่ายภายในเวลาที่กำหนด ในประเทศไทย PDPA กำหนดให้ผู้ควบคุมข้อมูลแจ้งเหตุละเมิดข้อมูลส่วนบุคคลต่อสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลโดยไม่ชักช้า และภายใน 72 ชั่วโมงเท่าที่ทำได้ เว้นแต่เหตุนั้นไม่มีความเสี่ยงต่อสิทธิและเสรีภาพของบุคคล และหากมีความเสี่ยงสูงต้องแจ้งเจ้าของข้อมูลด้วย [S8] ควรตรวจสอบกฎของทุกตลาดที่คุณขาย หรือปรึกษาทนายความก่อนติดต่อลูกค้า [คู่มือกฎหมายอีเมลการตลาด](https://tellnod.com/th/guides/email-marketing-consent-laws) ของเราสรุปกฎเรื่องความยินยอมในแต่ละตลาด ส่วนกฎการแจ้งเหตุข้อมูลรั่วไหลเป็นอีกเรื่องหนึ่งและขึ้นอยู่กับกฎหมายท้องถิ่น

เมื่อแจ้งลูกค้า ให้เขียนตรงไปตรงมา: เกิดอะไรขึ้น ข้อมูลใดเกี่ยวข้อง คุณทำอะไรไปแล้ว และลูกค้าควรระวังอะไร หลังเหตุการณ์แบบนี้มักมีอีเมลฟิชชิงที่แอบอ้างเป็นร้านตามมา จึงควรบอกลูกค้าว่าร้านจะไม่ขอรหัสผ่านหรือเลขบัตรทางอีเมลเด็ดขาด สำหรับแบรนด์เสื้อผ้าอย่าง Ninefold ข้อความนี้จะส่งจากอีเมลผู้ส่งที่ใช้ประจำ โดยไม่มีข้อเสนอส่วนลด เพื่อไม่ให้ดูเหมือนอีเมลโฆษณา

## ลดจุดเสี่ยงสำหรับครั้งต่อไป

PHP2Shell จะไม่ใช่การอัปเดตเร่งด่วนครั้งสุดท้าย ร้านที่อัปเดตให้ทันสมัยได้ง่ายก็ปกป้องได้ง่ายกว่า

- **ใช้ปลั๊กอินให้น้อยลง** ปลั๊กอินหรือโมดูลทุกตัวคือโค้ดที่ทำงานบนเซิร์ฟเวอร์ของคุณและต้องอัปเดต ลบตัวที่ไม่ได้ใช้ และถ้าทำได้ ให้ใช้ปลั๊กอินที่ดูแลดีเพียงตัวเดียวแทนปลั๊กอินเล็ก ๆ หลายตัว
- **ใช้ PHP สายที่ยังได้รับการสนับสนุน** วางแผนย้ายออกจาก PHP 8.2 ก่อนสิ้นสุดการสนับสนุนในวันที่ 31 ธันวาคม 2026 และย้ายออกจากเวอร์ชันที่เก่ากว่าตั้งแต่ตอนนี้ [S1]
- **ใช้โฮสติ้งหรือบริการแบบ managed** โฮสติ้งแบบ managed หรือบริการแบบโฮสต์สำหรับการชำระเงิน การค้นหา หรืออีเมล จะย้ายงานแพตช์ไปให้ผู้ให้บริการที่ทำเรื่องนี้โดยตรง ลองถามว่าครั้งนี้พวกเขาแพตช์เสร็จเร็วแค่ไหน
- **อัปเดตอัตโนมัติและสำรองข้อมูลนอกเซิร์ฟเวอร์** เปิดการอัปเดตย่อยอัตโนมัติหากแพลตฟอร์มรองรับ และเก็บไฟล์สำรองเป็นประจำไว้นอกเซิร์ฟเวอร์
- **กำหนดผู้รับผิดชอบ** ตัดสินใจว่าใครจะติดตามข่าวความปลอดภัยของร้าน จะเป็นคุณเอง นักพัฒนา หรือโฮสติ้งก็ได้

## Tellnod เกี่ยวข้องอย่างไร

Tellnod เป็น [MCP connector](https://tellnod.com/glossary#mcp-connector) สำหรับเขียน พรีวิว และส่งอีเมลการตลาดจาก Claude หรือ ChatGPT Tellnod ทำงานเป็นบริการแบบโฮสต์บนโครงสร้างพื้นฐานของ Tellnod เอง ไม่ได้ทำงานบนเซิร์ฟเวอร์ของร้านคุณ การใช้ Tellnod แทนปลั๊กอินอีเมลการตลาดจึงหมายถึงมีปลั๊กอินที่ต้องอัปเดตบนเซิร์ฟเวอร์น้อยลงหนึ่งตัว และมีข้อมูลรับรองสำหรับส่งอีเมลที่เก็บในฐานข้อมูลร้านน้อยลงหนึ่งชุด

สิ่งนี้ลดสิ่งที่อยู่บนเซิร์ฟเวอร์ของคุณ แต่ไม่ได้ทำให้ร้านปลอดภัย คุณยังต้องแพตช์ PHP และซอฟต์แวร์ร้าน และรายชื่อลูกค้าของคุณจะถูกเก็บไว้ที่ Tellnod ด้วย การถามผู้ให้บริการทุกรายว่าปกป้องข้อมูลอย่างไรจึงเป็นเรื่องสมเหตุสมผล [หน้าความปลอดภัย](https://tellnod.com/security) อธิบายว่า Tellnod จัดการการส่งและข้อมูลอย่างไร ถ้าต้องการลองใช้ ให้[เชื่อมต่อ Tellnod](https://tellnod.com/th/connect) กับ Claude หรือ ChatGPT จะไม่มีอะไรถูกส่งออกไปจนกว่าคุณจะกด Confirm บน[การ์ดอนุมัติ](https://tellnod.com/glossary#approval-card)

## FAQ

### PHP2Shell คืออะไร

PHP2Shell คือชื่อที่นักวิจัยใช้เรียก CVE-2026-109618 และ CVE-2026-109619 ช่องโหว่ร้ายแรงสองรายการใน PHP ที่อาจทำให้ผู้โจมตีรันโค้ดบนเว็บเซิร์ฟเวอร์ได้โดยไม่ต้องล็อกอิน โครงการ PHP แก้ไขแล้วเมื่อวันที่ 21 ตุลาคม 2026 [S1][S6]

### ร้าน WooCommerce ของฉันได้รับผลกระทบหรือไม่

WooCommerce ทำงานบน WordPress ซึ่งเป็นแอปพลิเคชัน PHP [S7] จึงอยู่ในขอบเขตที่ได้รับผลกระทบ เว้นแต่เซิร์ฟเวอร์จะใช้ PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 หรือแพ็กเกจที่แก้ไขแล้วจากโฮสติ้งอยู่แล้ว [S1] หากไม่แน่ใจให้ถามผู้ให้บริการโฮสติ้ง

### ร้านบน Shopify ได้รับผลกระทบหรือไม่

บนแพลตฟอร์มแบบโฮสต์ให้ทั้งหมดอย่าง Shopify คุณไม่ได้รัน PHP บนเซิร์ฟเวอร์ของตัวเอง จึงไม่มี PHP ที่คุณต้องอัปเดต แต่เว็บไซต์อื่นที่คุณโฮสต์เอง เช่น บล็อก WordPress ยังต้องตรวจสอบ

### ปลั๊กอินความปลอดภัยหรือไฟร์วอลล์เพียงพอหรือไม่

ไม่เพียงพอ การโจมตีเริ่มได้ก่อนที่โค้ดร้านหรือปลั๊กอินจะทำงาน และโครงการ PHP ระบุว่าการอัปเดตเป็นทางเลือกเดียวที่ปลอดภัย [S1] CISA ระบุ web application firewall เป็นเพียงมาตรการชั่วคราวระหว่างแพตช์ [S3]

### อัปเดตวันที่ 21 ตุลาคมแก้ CVE-2026-115560 ด้วยหรือไม่

ไม่ CVE-2026-115560 เป็นปัญหาแยกที่เปิดเผยเมื่อวันที่ 23 ตุลาคม 2026 และมีกำหนดแก้ไขในเวอร์ชันปกติถัดไป ระหว่างนี้โครงการ PHP แนะนำให้ตั้งค่า `session.upload_progress.enabled = 0` [S2]

## Sources

- [S1] PHP: Security advisory: critical remote code execution vulnerabilities, update now: <https://www.php.net/archive/2026.php#2026-10-21-5> (checked 2026-10-30)
- [S2] PHP: Informational advisory: session upload progress: <https://www.php.net/archive/2026.php#2026-10-23-1> (checked 2026-10-30)
- [S3] CISA: Critical vulnerabilities in PHP require immediate patching: <https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching> (checked 2026-10-30)
- [S4] CISA: Known Exploited Vulnerabilities catalog: <https://www.cisa.gov/known-exploited-vulnerabilities-catalog> (checked 2026-10-30)
- [S5] Rapid7: CVE-2026-109618 and CVE-2026-109619, critical unauthenticated remote code execution in PHP: <https://www.rapid7.com/blog/post/etr-cve-2026-109618-and-cve-2026-109619-critical-unauthenticated-remote-code-execution-in-php/> (checked 2026-10-30)
- [S6] Datadog Security Labs: PHP2Shell, critical vulnerabilities in PHP: <https://securitylabs.datadoghq.com/articles/php2shell-critical-vulnerabilities-in-php/> (checked 2026-10-30)
- [S7] WordPress.org: Requirements: <https://wordpress.org/about/requirements/> (checked 2026-10-30)
- [S8] กระทรวงดิจิทัลเพื่อเศรษฐกิจและสังคม: Personal Data Protection Act B.E. 2562 (2019), unofficial translation: <https://mdes.go.th/law/detail/3577-Personal-Data-Protection-Act-B-E--2562--2019-> (checked 2026-10-30)