PHP2Shell 安全披露時間表提前兩日外洩，AI 加速漏洞挖掘考驗協調流程

โดย Nokka (นก-กา) | ตรวจข้อมูล 24 ต.ค. 2026

บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

วันที่ 21 ตุลาคม 2026 ทีม PHP ออกรุ่นใหม่สี่รุ่นเพื่อปิดช่องโหว่ระดับ critical สองตัวที่ทำให้คนแปลกหน้าเรียกโค้ดบนเซิร์ฟเวอร์ได้ ภายใต้เงื่อนไขที่เหมาะสม

เรื่องที่ผมสนใจไม่ใช่ตัวช่องโหว่ แต่เป็นวันที่ 20 ตุลาคม ซึ่งเป็นสองวันก่อนกำหนดเดิม และเป็นหนึ่งวันก่อนรุ่นจริงจะออก ที่แผนประกาศค่อย ๆ แตกออกเป็นชิ้น ๆ

เคสนี้เป็นกรณีศึกษาที่ดีของ coordinated disclosure ในยุคที่เครื่องมือ AI ช่วยให้คนหาช่องโหว่ได้เร็วขึ้นมาก จนกรอบเวลาที่เคยพอเริ่มไม่พออีกต่อไป

ช่องโหว่สองตัวที่อยู่ตรงหัวใจของ PHP

ทั้งสองตัวมีคะแนน CVSS 9.2 และถูกจัดเป็น critical [1][2][7]

CVE-2026-109618 เกิดจากหน่วยความจำหมดในจังหวะที่ผิด ถ้าคำขอหนึ่งไปชนเพดาน memory_limit พอดี PHP อาจทิ้งข้อมูลภายในที่สร้างยังไม่เสร็จไว้ แล้วภายหลังกลับมองว่าข้อมูลนั้นใช้ได้ [1]

ผลคือหน่วยความจำเสียหาย และบน Apache ที่ใช้ mod_php ผู้โจมตีที่ยังไม่ยืนยันตัวตนสามารถกระตุ้นเรื่องนี้ได้ก่อนที่โค้ดแอปพลิเคชันจะเริ่มทำงานด้วยซ้ำ และมีการสาธิตเรียกโค้ดได้เต็มรูปแบบด้วยค่าตั้งต้น [1][5]

CVE-2026-109619 เกิดจากสถานะส่วนกลางที่ค้างอยู่ ถ้าเกิด fatal error ในจังหวะที่ผิด สถานะภายในอาจยังชี้ไปที่หน่วยความจำของคำขอก่อนหน้า แล้วคำขอถัดไปที่ worker ตัวเดียวกันรับผิดชอบก็ไปใช้หน่วยความจำที่ถูกคืนไปแล้ว [1]

ผู้รายงานสาธิต remote code execution กับแอปจริงที่รันบน Apache mod_php ได้ [1][6]

ทีม PHP ระบุด้วยว่า PHP-FPM ก็ยืนยันได้ว่าเรียกโค้ดได้ ผ่านเส้นทางระดับแอปพลิเคชัน ไม่ใช่เฉพาะ mod_php [1]

จุดที่ทำให้สองตัวนี้น่ากังวลคือมันอยู่ในส่วนที่แทบทุกคำขอต้องแตะ คือการจัดการหน่วยความจำและการจัดการข้อผิดพลาด ไม่ใช่ปลั๊กอินหรือไลบรารีเสริม [1]

ไทม์ไลน์ที่หลุดมือ

ทางการวางแผนออกรุ่นวันที่ 22 ตุลาคม 2026 เวลา 14:00 UTC ซึ่งตรงกับ 21:00 เวลาบ้านเรา [1]

แผนนั้นพังก่อนกำหนดสองวัน

20 ตุลาคม ประมาณ 15:00 UTC มีคนโพสต์รหัส CVE ทั้งสองตัวในฟอรัมและโซเชียลมีเดีย พร้อมเวลาเปิดตัวที่ผิด และคะแนน CVSS ที่ผิดว่า 10.0 ซึ่งของจริงคือ 9.2 [1]

ข่าวดีคือรอบนั้นยังไม่มีรายละเอียดทางเทคนิคหลุดออกมา

20 ตุลาคม 19:30 UTC ทีม PHP ตัดสินใจเลื่อนประกาศล่วงหน้าออกมา และย้ายวันออกรุ่นจาก 22 ตุลาคมมาเป็น 21 ตุลาคม เวลาเดียวกัน [1]

เหตุผลที่เลือกเลื่อนแค่หนึ่งวัน ไม่ใช่ออกทันที คือผู้จัดจำหน่ายยังจัดแพ็กเกจไม่เสร็จ ถ้าออกทันที ผู้ใช้จำนวนมากจะไม่มีทางอัปเดตที่ง่าย [1]

20 ตุลาคม ประมาณ 20:00 UTC บริษัทความปลอดภัย Calif ซึ่งเป็นหนึ่งในทีมที่รายงานช่องโหว่ เผลอปล่อยวิดีโอออกมา วิดีโอแสดง PoC ที่ทำงานได้กับเป้าหมายหลายราย และเผยรายละเอียดเพิ่มเล็กน้อย [1]

วิดีโอนั้นถูกลบ แต่สำเนาแพร่ต่อในโซเชียลมีเดีย และเร่งให้คนอื่นสร้าง PoC ตามมาจนถึงวันที่ 21 [1]

20 ตุลาคม ประมาณ 23:00 UTC คำแนะนำการบรรเทาความเสี่ยงที่ทีม PHP ส่งให้ผู้ให้บริการโครงสร้างพื้นฐานสำคัญบางราย อาจหลุดออกมาด้วย [1]

21 ตุลาคม 07:41 UTC Chainguard ปล่อย image ที่มีแพตช์แล้วออกสู่สาธารณะ ก่อนเวลาประกาศกว่าหกชั่วโมง [1]

ทำไม image ที่มีแพตช์ถึงเป็นปัญหา

Chainguard ได้แพตช์ล่วงหน้าเหมือนผู้จัดจำหน่ายรายอื่น เพื่อให้ผู้ใช้ของเขาอัปเดตได้ทันทีที่ประกาศ [1]

แต่การปล่อย image ก่อนกำหนดหมายความว่าใครก็ตามสามารถเอาไบนารีที่แพตช์แล้วไปศึกษาตัวแพตช์ได้ ขณะที่ผู้ใช้ PHP รายอื่นยังรอวันประกาศอยู่ [1]

มูลนิธิ PHP ระบุว่าการกระทำนี้คือการทำลาย embargo ฝ่ายเดียว และมองข้ามงานหลายสัปดาห์ของผู้เกี่ยวข้อง [1]

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

ทีม PHP ระบุว่าในเวลาที่ประกาศ พวกเขายังไม่พบ exploit ที่ใช้งานได้จริงจาก PoC ที่หลุดมา [1]

แต่คำว่า "ยังไม่พบ" ไม่ได้แปลว่าจะไม่มีใครทำได้ และไม่ควรใช้เป็นเหตุผลให้ชะลอการอัปเดต

ทำไมช่องโหว่คู่นี้ถึงแก้ช้า

ส่วนนี้ผมคิดว่าเป็นส่วนที่กล้าหาญที่สุดของประกาศ เพราะทีม PHP เขียนเองว่า "ความล่าช้าเป็นความล้มเหลวเชิงโครงสร้าง" [1]

ย้อนไปปี 2024 มีการตรวจสอบความปลอดภัยจากภายนอกครั้งแรกในรอบหลายปี โดยได้ทุนจาก Sovereign Tech Agency จัดผ่าน OSTIF และดำเนินการโดย Quarkslab [1]

ระหว่างแก้ปัญหารายการหนึ่งที่ Quarkslab รายงาน นักพัฒนาหลักที่ได้รับทุนจากมูลนิธิพบสัญญาณแรกของปัญหา OOM ที่กลายเป็น CVE-2026-109618 ในเวลาต่อมา [1]

ในปี 2024 มีการตั้งสมมติฐานว่าปัญหานี้น่าจะโจมตีได้ แต่ยังไม่มีเส้นทางจริง และมีปัญหาอื่นที่ชัดเจนกว่ามาบังหน้าไว้ [1]

การแก้ต้องเลือกระหว่างทางที่แลกมาด้วยความเข้ากันได้ย้อนหลัง การเปิดช่อง denial of service ใหม่ หรือการบังคับให้ส่วนขยายบุคคลที่สามแก้โค้ดตาม ซึ่งประสานงานแทบเป็นไปไม่ได้ [1]

ทีมความปลอดภัยตัดสินใจแบบฉันทามติ จึงเลือกไม่ถูกสักทาง และงานก็หยุด ๆ เริ่ม ๆ หลายเดือน [1]

จุดเปลี่ยนมาถึงเมื่อมีรายงานหลายทางเข้ามาเกือบพร้อมกัน

• 30 กรกฎาคม 2026 โครงการ PHP เข้าร่วม Patch the Planet และบริษัท Calif เริ่มตรวจโค้ด [1]
• 11 สิงหาคม Ryan A จาก Calif รายงาน remote code execution ที่ไม่ต้องมีเงื่อนไข ต้นเหตุเดียวกับปัญหา OOM [1]
• 24 สิงหาคม Wiz รายงานเวกเตอร์เพิ่มเติม [1]
• 18 กันยายน OpenAI รายงานเวกเตอร์เพิ่มเติมอีกชุด [1]

ตั้งแต่วันที่ 11 สิงหาคมเป็นต้นมา การแก้ปัญหา OOM กลายเป็นงานสำคัญอันดับหนึ่งของทุกคนในทีมความปลอดภัยของมูลนิธิ [1]

AI ทำให้ทั้งสองฝ่ายเร็วขึ้น

Wiz ตั้งชื่อสคริปต์ที่รวมช่องโหว่ทั้งสองตัวไว้ว่า php2shell และระบุว่า PHP รองรับเว็บราว 70% ของทั้งโลก โดยทุกรุ่นที่ออกในทศวรรษที่ผ่านมามีอย่างน้อยหนึ่งช่องโหว่ ย้อนไปถึง 5.4 [3]

Wiz เขียนว่าช่องโหว่กลุ่มนี้ซ่อนอยู่ในโค้ด PHP มานานกว่าทศวรรษ แต่การพิสูจน์ว่าโจมตีได้ต้องใช้ลำดับขั้นที่ซับซ้อนมาก อยู่ที่ขอบของสิ่งที่นักวิจัยมนุษย์ทำได้จริง [3]

โมเดล AI ชั้นนำลดกำแพงตรงนั้นลง จนปัญหาเก่ากลายเป็น exploit ที่ใช้งานได้ [3]

ฝั่ง PHP ก็ใช้ AI เหมือนกัน ทั้งการสแกนด้วย Claude Mythos ร่วมกับ Alpha-Omega และเครื่องมือ Daybreak Red ของ OpenAI สำหรับตรวจสอบรายงานกับ PoC [1]

ผลข้างเคียงคือปริมาณรายงานที่เข้ามาเพิ่มขึ้นมาก ทีมเผยว่าได้รับรายงานกว่า 100 ฉบับที่กลายเป็นรายงานซ้ำ ทำซ้ำไม่ได้ หรือไม่ใช่ช่องโหว่จริง นับตั้งแต่วันที่ 1 กรกฎาคม [1]

AI ช่วยจัดกลุ่มรายงานที่ต้นเหตุเดียวกันได้ แต่คนยังเป็นคนตัดสินทุกครั้งและเป็นคนเขียนแพตช์ทุกตัว [1]

นี่คือสมการที่ผมคิดว่าทุกโครงการใหญ่กำลังเจอ คือเครื่องมือหา bug ถูกและเร็วขึ้น แต่คนตัดสินใจยังมีเท่าเดิม

สิ่งที่ทีม PHP เปลี่ยนไปแล้ว

ทีมกำลังปรับกระบวนการรับมือให้ผู้นำมูลนิธิเข้ามาช่วยตัดสินได้เร็วขึ้น เมื่อเจอช่องโหว่ที่ทางแก้แลกมาด้วย trade-off หนัก ๆ [1]

ก่อนหน้านั้นมีหลายอย่างเกิดขึ้นแล้วในปีนี้

• พฤษภาคม 2026 ตั้ง Ecosystem Security Team ทำงานคู่กับทีมความปลอดภัยด้านการคัดกรอง ประสานงาน และเสริมความแข็งแรง [1]
• กรกฎาคม Alexandre Daubois เข้าร่วมช่วยคัดกรองและแก้รายงาน [1]
• กันยายน Daniel Scherzer เข้าร่วมทำงานด้านการเสริมความแข็งแรง [1]
• ทีมเปลี่ยนวิธีตัดสินใจให้ใช้เสียงข้างมากได้ แทนการบังคับให้ทุกคนเห็นตรงกัน [1]

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

รุ่นที่แก้แล้วคือ 8.5.12, 8.4.27, 8.3.36 และ 8.2.35 [1][4]

# ดูรุ่นที่รันอยู่จริง รวมถึง SAPI ที่ใช้
php -v
php -i | grep -i "server api"

# Debian / Ubuntu
apt list --installed 2>/dev/null | grep -E "^php[0-9.]+"

# RHEL family
rpm -qa | grep -E "^php"

ถ้าผลออกมาเป็น Apache 2.0 Handler แปลว่าคุณใช้ mod_php ซึ่งเป็นเส้นทางที่ผู้รายงานสาธิตว่าโจมตีก่อนโค้ดแอปทำงานได้ [1]

ทางที่ดีคืออัปเดตทั้งระบบ แล้วรีสตาร์ท Apache หรือ PHP-FPM ให้ worker โหลดโค้ดใหม่ เพราะการแพตช์ไฟล์อย่างเดียวไม่ทำให้โปรเซสที่รันอยู่เปลี่ยนไป

บทเรียนเรื่อง coordinated disclosure

ผมอ่านประกาศนี้แล้วนึกถึงคำถามที่คนมักเถียงกัน คือ embargo เป็นเรื่องของมารยาทหรือเป็นเรื่องของความปลอดภัย

เคสนี้ตอบว่าเป็นทั้งสองอย่าง และมีจุดเปราะหลายจุดที่ควบคุมยาก

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

ทั้งสามทางนี้ไม่ได้เกิดจากความชั่วร้าย แต่เกิดจากแรงจูงใจปกติของแต่ละฝ่าย

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

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

หรืออาจจะเป็นการเลิกถือว่าไบนารีที่แพตช์แล้วเป็นความลับ เพราะมันเทียบได้อยู่ดี

ผมยังไม่เห็นใครตอบคำถามนี้ชัด ๆ และคิดว่านี่คือโจทย์ใหญ่ของปีต่อ ๆ ไป

REF

[1] The PHP Foundation (21 ต.ค. 2026) · Today's PHP Security Release, and How We're Strengthening PHP Security. https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
[2] NVD (21 ต.ค. 2026) · CVE-2026-109618 CVSS 4.0 base 9.2 critical. https://nvd.nist.gov/vuln/detail/CVE-2026-109618
[3] Wiz Research (21 ต.ค. 2026) · PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet. https://www.wiz.io/blog/php2shell-php-rce
[4] php.net (21 ต.ค. 2026) · Security advisory: Critical remote code execution vulnerabilities, update now (PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35). https://www.php.net/archive/2026.php#2026-10-21-5
[5] GitHub Security Advisory (21 ต.ค. 2026) · GHSA-w8hw-w9fx-j79w (RCE via OOM corruption). https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
[6] GitHub Security Advisory (21 ต.ค. 2026) · GHSA-6wmf-4rv5-p3rp (RCE via stale global state). https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
[7] NVD (21 ต.ค. 2026) · CVE-2026-109619 CVSS 4.0 base 9.2 critical. https://nvd.nist.gov/vuln/detail/CVE-2026-109619