ข่าวสาร

เมื่อวันที่ 21 ตุลาคม 2569 ผู้พัฒนา PHP ได้ออกชุดแก้ไข (แพตช์) เพื่อปิดช่องโหว่ร้ายแรงที่ชื่อว่า “PHP2Shell” หลายองค์กรจึงเร่งอัปเดตระบบกันไปแล้ว แต่ข้อมูลล่าสุดพบว่ามีคนพยายามใช้ช่องโหว่นี้โจมตีตั้งแต่วันที่ 17 ตุลาคม ซึ่งเป็น 4 วันก่อนที่ชุดแก้ไขจะออก คำถามสำคัญจึงไม่ใช่แค่ “อัปเดตแล้วหรือยัง” แต่คือ “ระหว่างที่ยังไม่ได้อัปเดต มีใครแอบเข้ามาแล้วหรือไม่” บทความนี้จะอธิบายว่า PHP2Shell คืออะไร เกี่ยวข้องกับระบบแบบไหน หากองค์กรพบหรือสงสัยว่าถูกโจมตีควรแก้ไขอย่างไร และต้องแจ้งใครบ้างตามกฎหมาย

PHP2Shell คืออะไร และเกี่ยวกับองค์กรของเราอย่างไร

PHP คืออะไร PHP เป็นภาษาคอมพิวเตอร์ที่ใช้สร้างเว็บไซต์ เปรียบเหมือน “เครื่องยนต์” ที่ทำงานอยู่เบื้องหลังหน้าเว็บ ทุกครั้งที่เราเปิดเว็บไซต์ กรอกแบบฟอร์ม หรือล็อกอินเข้าระบบ PHP จะเป็นตัวประมวลผลอยู่บนเครื่องเซิร์ฟเวอร์ (คอมพิวเตอร์ที่เปิดให้บริการเว็บไซต์ตลอด 24 ชั่วโมง) ปัจจุบันเว็บไซต์ทั่วโลกราว 70% ใช้ PHP

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

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

ซึ่งการ “ถูกโจมตี” อธิบายให้เข้าใจง่าย ก็คือ การที่คนร้ายเข้ามาในร้าน หรือบ้านของเราได้แล้วนั้น คนร้ายอาจจะทำเรื่องต่าง ๆ ดังต่อไปนี้

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

สถานการณ์ล่าสุดของ PHP2Shell

PHP2Shell คือช่องโหว่ 2 รายการในตัว PHP (CVE-2026-109618 และ CVE-2026-109619) ความรุนแรง CVSS 9.2 ที่เปิดทางให้ผู้โจมตีรันคำสั่งบนเซิร์ฟเวอร์ได้โดยไม่ต้องล็อกอิน และอาจดึงข้อมูลลับในหน่วยความจำ เช่น รหัสผ่านและ API Key ออกไปได้ ความเคลื่อนไหวสำคัญที่ผ่านมามีดังนี้

ทำไม “อัปเดตระบบแล้ว” ถึงยังไม่ปลอดภัยพอ?

เปรียบเทียบง่าย ๆ การอัปเดตระบบหรือการลงแพตช์ (Patch) เหมือนกับการ “เปลี่ยนกุญแจประตูบ้านใหม่” เพื่อไม่ให้โจรใช้ช่องทางเดิมแอบเข้าบ้านได้ แต่ไม่ได้เป็นการไล่คนที่เข้ามาในบ้านแล้วออกไป หากคนร้ายแอบเข้ามาก่อนที่องค์กรจะอัปเดต เขาอาจทิ้งสิ่งเหล่านี้ไว้

• ประตูลับ (Web Shell) ไฟล์เล็ก ๆ ที่ซ่อนไว้ในเว็บไซต์ ให้คนร้ายกลับเข้ามาสั่งการได้ทุกเมื่อ
• บัญชีผู้ใช้ปลอม บัญชีที่คนร้ายสร้างขึ้นเอง เพื่อเข้าระบบเหมือนเป็นพนักงานคนหนึ่ง
• คำสั่งตั้งเวลา (Cron Job) คำสั่งที่ตั้งให้ระบบทำงานเองตามเวลา เช่น แอบส่งข้อมูลออกไปให้คนร้ายทุกคืน
• รหัสผ่านที่ถูกขโมยไป เช่น รหัสเข้าฐานข้อมูล หรือรหัสเชื่อมต่อกับระบบอื่น (API Key) ซึ่งยังใช้ได้จนกว่าจะเปลี่ยนใหม่

ด้วยเหตุนี้ Amazon จึงแนะนำให้ ตรวจสอบย้อนหลังตั้งแต่วันที่ 17 ตุลาคม 2569 ซึ่งเป็นวันแรกที่พบการโจมตี ไม่ใช่นับจากวันที่ประกาศช่องโหว่

ผู้บริหารควรทำอะไรตอนนี้

ผู้บริหารไม่จำเป็นต้องลงมือแก้ไขเอง แต่ควรสอบถามฝ่ายไอทีหรือบริษัทที่ดูแลเว็บไซต์ให้ได้คำตอบครบ 4 ข้อนี้

• ใช้ PHP หรือไม่ เว็บไซต์ ระบบงาน และหลังบ้านของแอปพลิเคชันขององค์กร ระบบใดบ้างที่ใช้ PHP
• อัปเดตครบแล้วหรือยัง ขอหลักฐานยืนยันเป็นลายลักษณ์อักษร โดยเฉพาะระบบที่จ้างบริษัทภายนอกดูแล
• ตรวจแล้วหรือยังว่ามีใครแอบเข้ามา ตั้งแต่วันที่ 17 ตุลาคม 2569 เป็นต้นมา
• เปลี่ยนรหัสผ่านที่อยู่บนระบบแล้วหรือยัง เพราะรหัสผ่านอาจถูกขโมยไปก่อนการอัปเดต

หากคำตอบข้อใดข้อหนึ่งคือ “ยังไม่ทราบ” ควรถือว่าองค์กรยังมีความเสี่ยง และเร่งดำเนินการตามขั้นตอนในหัวข้อถัดไป

หากพบหรือสงสัยว่าถูกโจมตี ต้องแก้ไขอย่างไร

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

1. ตัดการเชื่อมต่อ แต่อย่าเพิ่งปิดเครื่อง แยกเครื่องที่สงสัยออกจากอินเทอร์เน็ต เพื่อไม่ให้คนร้ายใช้งานต่อ แต่ไม่ควรปิดเครื่องหรือลบไฟล์ทันที เพราะเหมือนการทำความสะอาดที่เกิดเหตุก่อนตำรวจมาเก็บหลักฐาน
2. เก็บหลักฐานไว้ก่อน สำรองบันทึกการใช้งานของระบบ (Log) ซึ่งเปรียบเหมือนภาพจากกล้องวงจรปิดของเว็บไซต์ ไว้ก่อนแก้ไขใด ๆ
3. ตรวจว่าคนร้ายทำอะไรไปบ้าง ให้ผู้เชี่ยวชาญตรวจหาไฟล์แปลกปลอม บัญชีผู้ใช้ที่ไม่รู้ที่มา คำสั่งตั้งเวลาที่ไม่ได้สร้างเอง และร่องรอยการดึงข้อมูลออกจากฐานข้อมูล
4. ล้างระบบและกู้คืน ลบสิ่งที่คนร้ายฝังไว้และอัปเดต PHP หากไม่มั่นใจว่าล้างได้หมด ให้ติดตั้งระบบใหม่จากข้อมูลสำรองที่ทำไว้ก่อนวันที่ 17 ตุลาคม 2569
5. เปลี่ยนรหัสผ่านทั้งหมดที่อยู่บนเครื่องนั้น ทั้งรหัสผ่านฐานข้อมูล รหัสเชื่อมต่อกับระบบอื่น (API Key) และรหัสผู้ดูแลระบบ เพราะคนร้ายอาจได้ไปแล้ว
6. ตรวจว่าข้อมูลลูกค้าหรือพนักงานหลุดหรือไม่ ให้เจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (DPO) ประเมินร่วมกับฝ่ายไอที เพราะผลการประเมินนี้จะเป็นตัวกำหนดว่าต้องแจ้งใครบ้างในหัวข้อถัดไป

ต้องแจ้งใครบ้าง

ข้อนี้เป็นจุดที่หลายองค์กรพลาด เพราะมัวแต่แก้ไขระบบจนเลยกรอบเวลาที่กฎหมายกำหนด สรุปผู้ที่อาจต้องได้รับแจ้งได้ ดังนี้

ข้อควรระวัง กรอบเวลา 72 ชั่วโมงของ PDPA นับจาก “เวลาที่ทราบเหตุ” ไม่ใช่เวลาที่สอบสวนเสร็จ ตัวอย่างเช่น หากฝ่ายไอทีพบเหตุเมื่อวันจันทร์ เวลา 09.00 น. องค์กรต้องแจ้ง สคส. ภายในวันพฤหัสบดี เวลา 09.00 น. แม้ยังไม่รู้สาเหตุทั้งหมดก็ตาม (ส่งข้อมูลเพิ่มเติมภายหลังได้) หากแจ้งเกินกำหนดต้องชี้แจงเหตุผลความล่าช้า ส่วนองค์กรทั่วไปที่ไม่ได้อยู่ในกลุ่มโครงสร้างพื้นฐานสำคัญ ก็สามารถติดต่อ ThaiCERT เพื่อขอความช่วยเหลือได้ที่ โทร. 02-114-3531 (24 ชั่วโมง)

มุมมอง IT Audit: บทเรียนที่ควรนำไปปรับปรุง

เหตุการณ์ PHP2Shell สะท้อนว่าความพร้อมรับมือไม่ได้อยู่ที่เทคโนโลยีเพียงอย่างเดียว แต่อยู่ที่ระบบควบคุมที่เตรียมไว้ล่วงหน้า ประเด็นที่ผู้ตรวจสอบมักพบและควรนำไปทบทวน ได้แก่

สรุป

PHP2Shell เป็นช่องโหว่ร้ายแรงในภาษา PHP ซึ่งอยู่เบื้องหลังเว็บไซต์และระบบงานผ่านเว็บจำนวนมาก และมีคนพยายามใช้โจมตีตั้งแต่ก่อนชุดแก้ไขจะออก การอัปเดตจึงเป็นเพียงจุดเริ่มต้น องค์กรควรตรวจสอบย้อนหลังว่ามีใครแอบเข้ามาตั้งแต่วันที่ 17 ตุลาคม 2569 หรือไม่ เปลี่ยนรหัสผ่านที่อยู่บนระบบ และหากพบว่าข้อมูลส่วนบุคคลรั่วไหล ต้องแจ้ง สคส. ภายใน 72 ชั่วโมง (3 วัน) นับแต่ทราบเหตุ รวมถึงแจ้งเจ้าของข้อมูล หน่วยงานกำกับ และผู้เกี่ยวข้องตามที่กฎหมายและสัญญากำหนด การมีแผนที่ระบุชัดว่า “ใครต้องแจ้งใคร ภายในเวลาเท่าใด” จะช่วยให้องค์กรตัดสินใจได้ทันเมื่อเกิดเหตุจริง

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

สำหรับผู้บริหาร / เจ้าของธุรกิจ

Q1: ยังไม่แน่ใจว่าข้อมูลรั่วหรือไม่ ต้องแจ้ง สคส. แล้วหรือยัง?

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

Q2: เว็บไซต์ฝากไว้กับผู้ให้บริการ Hosting ภายนอก ใครเป็นผู้รับผิดชอบการแจ้งเหตุ?

องค์กรซึ่งเป็นเจ้าของข้อมูลลูกค้า (ทางกฎหมายเรียกว่า “ผู้ควบคุมข้อมูลส่วนบุคคล”) ยังเป็นผู้รับผิดชอบหลักในการแจ้ง สคส. และเจ้าของข้อมูล ส่วนผู้ให้บริการ Hosting มีหน้าที่แจ้งเหตุให้องค์กรทราบ จึงควรสอบถามผู้ให้บริการให้ยืนยันสถานะการแก้ไขและผลการตรวจสอบเป็นลายลักษณ์อักษร

Q3: ถ้าไม่แจ้งเหตุตามกฎหมาย มีบทลงโทษอย่างไร?

ผู้ควบคุมข้อมูลที่ไม่ปฏิบัติตามหน้าที่แจ้งเหตุตาม PDPA มาตรา 37 อาจถูกลงโทษปรับทางปกครองไม่เกิน 3 ล้านบาท ตามมาตรา 83 และอาจต้องรับผิดทางแพ่งหากเกิดความเสียหายต่อเจ้าของข้อมูล นอกจากนี้ความเสียหายต่อชื่อเสียงจากการปกปิดเหตุมักรุนแรงกว่าค่าปรับ

สำหรับฝ่ายไอที / DPO

Q4: เว็บไซต์ล่มช่วงนี้ แปลว่าถูกโจมตีด้วย PHP2Shell ใช่หรือไม่?

ไม่เสมอไปครับ เว็บไซต์อาจล่มจากสาเหตุอื่น เช่น มีการส่งผู้ใช้งานปลอมจำนวนมหาศาลเข้ามาพร้อมกันจนเว็บรับไม่ไหว (DDoS) หรือเกิดปัญหาระหว่างอัปเดตระบบ จึงต้องให้ฝ่ายไอทีตรวจสอบหลักฐานก่อนสรุป แต่ไม่ควรรอจนแน่ใจ 100% จึงเริ่มขั้นตอนรับมือ

Q5: หนังสือแจ้งเจ้าของข้อมูลควรมีข้อมูลอะไรบ้าง?

ควรประกอบด้วย (1) ลักษณะของเหตุการละเมิดโดยสังเขป (2) ช่องทางติดต่อ DPO หรือผู้ประสานงาน (3) ผลกระทบที่อาจเกิดขึ้น และ (4) มาตรการแก้ไขเยียวยาที่องค์กรดำเนินการ พร้อมคำแนะนำสิ่งที่เจ้าของข้อมูลควรทำเอง เช่น เปลี่ยนรหัสผ่าน หรือระวังข้อความหลอกลวง

Q6: ควรเก็บหลักฐานอะไรบ้าง เพื่อใช้ทั้งการสอบสวนและการตรวจสอบภายหลัง?

ไม่เสมอไปครับ เว็บไซต์อาจล่มจากสาเหตุอื่น เช่น มีการส่งผู้ใช้งานปลอมจำนวนมหาศาลเข้ามาพร้อมกันจนเว็บรับไม่ไหว (DDoS) หรือเกิดปัญหาระหว่างอัปเดตระบบ จึงต้องให้ฝ่ายไอทีตรวจสอบหลักฐานก่อนสรุป แต่ไม่ควรรอจนแน่ใจ 100% จึงเริ่มขั้นตอนรับมือ

เขียนโดย

ฝ่ายตรวจสอบเทคโนโลยีสารสนเทศ

บริษัท ตรวจสอบภายในธรรมนิติ จำกัด ให้บริการงานตรวจสอบ ครอบคลุมทั้งงานตรวจสอบภายใน (Internal Audit) การประเมินระบบควบคุมภายใน งานตรวจสอบด้านเทคโนโลยีสารสนเทศ และบริการสอบทานมาตรการต่อต้านการทุจริต (CAC) ติดต่อ โทร. 02-596-0500 ต่อ 327 หรือเยี่ยมชมเว็บไซต์ www.dir.co.th

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

• Amazon Threat Intelligence – PHP2Shell exploitation prior to public disclosure in MadPot – aws.amazon.com/blogs/security
• SecurityWeek – Mirai Botnet Operators Join PHP2Shell Attacks (23 ต.ค. 2569) – securityweek.com
• Qualys Threat Research – PHP2Shell: PHP Patches Two Critical RCE Vulnerabilities – blog.qualys.com
• ThaiCERT – แจ้งเตือน พบช่องโหว่ PHP2Shell เสี่ยงถูกควบคุมเซิร์ฟเวอร์จากภายนอก (22 ต.ค. 2569) – thaicert.or.th
• ฐานเศรษฐกิจ – “ภราดร” สั่ง สกมช. รับมือด่วน ช่องโหว่ไซเบอร์วิกฤต “PHP2Shell” (22 ต.ค. 2569) – thansettakij.com
• เดลินิวส์ – “อ.นพดล” เตือนภัยไซเบอร์ “PHP2Shell” จี้รัฐอุดช่องโหว่ (25 ต.ค. 2569) – dailynews.co.th
• พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 37 (4), 40 และ 83
• ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่อง หลักเกณฑ์และวิธีการในการแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล พ.ศ. 2565
• พระราชบัญญัติการรักษาความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562 มาตรา 57–58