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

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

1. 1

   ตรวจดูว่าร้านใช้ PHP เวอร์ชันใด

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

2. 2

   อัปเดต PHP หรือให้โฮสติ้งยืนยันว่าแพตช์แล้ว

   อัปเดตเป็น PHP 8.5.12, 8.4.27, 8.3.36 หรือ 8.2.35 หรือสอบถามผู้ให้บริการโฮสติ้งเป็นลายลักษณ์อักษรว่าเซิร์ฟเวอร์ได้รับการแก้ไขวันที่ 21 ตุลาคม 2026 สำหรับ CVE-2026-109618 และ CVE-2026-109619 แล้วหรือยัง

3. 3

   สำรองข้อมูลทั้งก่อนและหลัง

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

4. 4

   อัปเดตระบบร้านและปลั๊กอินทุกตัว

   ติดตั้งอัปเดตที่ค้างอยู่ของ WordPress, WooCommerce หรือแพลตฟอร์มร้าน ธีม และปลั๊กอินหรือโมดูลทุกตัว แล้วลบตัวที่ไม่ได้ใช้แล้วออก

5. 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 ^S5S6 ทั้งสองได้คะแนนความรุนแรง 9.2 จาก 10 ^S5

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

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

ปัญหาอีกรายการหนึ่งคือ 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 หรือเวอร์ชัน PHP ส่วนใน WordPress ไปที่ เครื่องมือ > สุขภาพเว็บไซต์ > แท็บข้อมูล แล้วเปิดหัวข้อเซิร์ฟเวอร์ เวอร์ชันที่แก้ไขแล้วคือ 8.5.12, 8.4.27, 8.3.36 และ 8.2.35 หรือใหม่กว่าในแต่ละสาย ^S1

หมายเลขเวอร์ชันอาจไม่ได้บอกทุกอย่าง ดิสทริบิวชัน Linux และผู้ให้บริการโฮสติ้งได้รับแพตช์ล่วงหน้า และอาจนำการแก้ไขไปใส่ในแพ็กเกจของตัวเองโดยไม่เปลี่ยนหมายเลขเวอร์ชัน ^S1S6 หากไม่แน่ใจ ให้ถามผู้ให้บริการโฮสติ้งโดยตรงว่าเซิร์ฟเวอร์มีการแก้ไขสำหรับ 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 ของเซิร์ฟเวอร์ติดบัญชีดำ

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

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

หน้าที่ทางกฎหมายหลังข้อมูลรั่วไหลแตกต่างกันในแต่ละประเทศ กฎหมายคุ้มครองข้อมูลส่วนบุคคลหลายฉบับกำหนดให้แจ้งหน่วยงานกำกับ ลูกค้าที่ได้รับผลกระทบ หรือทั้งสองฝ่ายภายในเวลาที่กำหนด ในประเทศไทย PDPA กำหนดให้ผู้ควบคุมข้อมูลแจ้งเหตุละเมิดข้อมูลส่วนบุคคลต่อสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลโดยไม่ชักช้า และภายใน 72 ชั่วโมงเท่าที่ทำได้ เว้นแต่เหตุนั้นไม่มีความเสี่ยงต่อสิทธิและเสรีภาพของบุคคล และหากมีความเสี่ยงสูงต้องแจ้งเจ้าของข้อมูลด้วย ^S8 ควรตรวจสอบกฎของทุกตลาดที่คุณขาย หรือปรึกษาทนายความก่อนติดต่อลูกค้า คู่มือกฎหมายอีเมลการตลาด ของเราสรุปกฎเรื่องความยินยอมในแต่ละตลาด ส่วนกฎการแจ้งเหตุข้อมูลรั่วไหลเป็นอีกเรื่องหนึ่งและขึ้นอยู่กับกฎหมายท้องถิ่น

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

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

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

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

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

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

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

คำถามที่พบบ่อย#