Sanae Takaichi เรียกวิกฤต PHP ว่าเป็นเรื่องฉุกเฉิน ผู้ใช้ทั่วไปควรป้องกันตัวอย่างไร?

บทความนี้มาจาก:Decrypt

เรียบเรียงโดย｜Odaily (@OdailyChina)；ผู้แปล｜Moni

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

เมื่อคืนวานนี้ นายกรัฐมนตรีญี่ปุ่น ซานาเอะ ทาคาอิจิ โพสต์บน X ว่า “มีคำขอเร่งด่วนที่ทุกคนต้องรับมือ” พร้อมเตือนถึงความเสี่ยงที่เกี่ยวข้องกับ PHP

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

หากคุณได้ใช้อินเทอร์เน็ตในช่วงสองวันที่ผ่านมา คุณคงมีโอกาสสูงที่จะเห็นความตื่นตระหนกทางไซเบอร์นี้: ช่องโหว่ร้ายแรงกำลังคุกคามเว็บไซต์เกือบทั้งหมดทั่วโลก——ฟินแลนด์ประกาศปิดเว็บไซต์ของรัฐบาล สหรัฐอเมริกาโดยสำนักงานความมั่นคงแห่งชาติ (NSA) แนะนำให้ทุกองค์กรที่ใช้ PHP ปิดเว็บไซต์ของตน และเนเธอร์แลนด์กับฝรั่งเศสก็ใช้มาตรการเช่นเดียวกัน

อย่างไรก็ตาม นี่ไม่ใช่สงครามไซเบอร์ แต่เป็นเพราะ PHP ถูกเปิดเผยว่ามีช่องโหว่ความปลอดภัยครั้งใหญ่สองรายการ

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

อนึ่ง เว็บไซต์ของ Wordfence เองก็ล่มเช่นกัน

ทำไมช่องโหว่ PHP จึงน่ากังวล? ที่จริงแล้ว ช่องโหว่ดังกล่าวทำให้คนแปลกหน้าสามารถรันคำสั่งของตนเองบนเซิร์ฟเวอร์ได้โดยตรงโดยไม่ต้องเข้าสู่ระบบ อุตสาหกรรมความปลอดภัยเรียกช่องโหว่ประเภทนี้ว่า “การรันโค้ดจากระยะไกลโดยไม่ต้องยืนยันตัวตน” (Unauthenticated Remote Code Execution หรือ RCE)

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

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

ทางการ PHP ประกาศอะไรบ้าง?

มูลนิธิ PHP (PHP Foundation) องค์กรไม่แสวงหาผลกำไรที่รับผิดชอบการสนับสนุนการพัฒนาภาษา PHP ได้ออกคำเตือน:

ทีมความปลอดภัย PHP แจ้งล่วงหน้า: มีแผนเผยแพร่การอัปเดตความปลอดภัยในวันพุธที่ 21 ตุลาคม 2026 เวลา 14:00 UTC ซึ่งประกอบด้วยช่องโหว่ร้ายแรงสองรายการ โดยทั้งสองมีคะแนน CVSS v4 อยู่ที่ 9.2 แนะนำให้ผู้ใช้ PHP เตรียมพร้อมอัปเดตล่วงหน้า หากรายละเอียดถูกเปิดเผยก่อนกำหนด หรือมีหลักฐานว่าช่องโหว่กำลังถูกใช้โจมตีอยู่ การอัปเดตอาจเผยแพร่เร็วขึ้น

คะแนน 9.2 นี้มาจากระบบให้คะแนนช่องโหว่ทั่วไป (CVSS) ซึ่งประเมินระดับอันตรายของช่องโหว่จากปัจจัยต่างๆ เช่น ช่องโหว่สามารถเข้าถึงได้ง่ายเพียงใดผ่านอินเทอร์เน็ต และอาจสร้างความเสียหายได้มากเพียงใด คะแนนอยู่ในช่วง 0 ถึง 10 โดย 9.0 ขึ้นไปถือเป็นช่องโหว่ระดับร้ายแรง ดังนั้นแม้จะยังไม่ถึงคะแนนเต็ม 10 ช่องโหว่ทั้งสองนี้ก็ถือว่าอันตรายในระดับสูงมากแล้ว

วันพุธที่ผ่านมา ทางการ PHP ได้เผยแพร่เวอร์ชันแก้ไขล่วงหน้าสองสามนาที ได้แก่ PHP 8.5.12, 8.4.27, 8.3.36 และ 8.2.35 พร้อมยืนยันว่าช่องโหว่นี้ส่งผลกระทบต่อสภาพแวดล้อม PHP ที่จัดการคำขอเว็บ เช่น PHP-FPM, Apache mod_php, php-cgi, FrankenPHP และ LiteSpeed โดย Apache mod_php มีความเสี่ยงสูงเป็นพิเศษ เพราะการโจมตีสามารถเกิดขึ้นได้ก่อนที่โค้ดแอปพลิเคชันจะทำงาน

อย่างไรก็ตาม ประกาศความปลอดภัยอย่างเป็นทางการระบุอย่างชัดเจนว่า “ขอแนะนำอย่างยิ่งให้ผู้ใช้ PHP ทุกคนอัปเดตทันที”

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

ช่องโหว่เหล่านี้ทำงานอย่างไร?

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

ช่องโหว่ที่สอง CVE-2026-109619 ทำให้ข้อมูลตกค้างจากคำขอของผู้เยี่ยมชมรายหนึ่งยังคงอยู่ในหน่วยความจำหลังจากที่ควรถูกล้างออกไปแล้ว ส่งผลให้คำขอ subsequent อาจได้รับผลกระทบจากข้อมูลตกค้างเหล่านี้

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

PHP ระบุว่าเซิร์ฟเวอร์ที่ใช้ mod_php ซึ่งเป็นการกำหนดค่า Apache รูปแบบหนึ่งที่พบได้บ่อย มีความเสี่ยงสูงที่สุด ภายใต้การกำหนดค่านี้ การโจมตีที่สาธิตแล้วยังสามารถทำงานได้ “ก่อนที่โค้ดแอปพลิเคชันใดๆ จะทำงาน”

กล่าวอีกนัยหนึ่ง กลไกป้องกันของเว็บไซต์เอง เช่น หน้าเข้าสู่ระบบและปลั๊กอินความปลอดภัยของ WordPress ยังไม่ทันเริ่มทำงาน

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

ข้อมูลช่องโหว่รั่วไหล การโจมตีตามมา

ข้อมูลเกี่ยวกับช่องโหว่เหล่านี้ไม่ควรถูกเปิดเผยเร็วขนาดนี้ ที่จริงแล้วเมื่อวันอังคาร มีคนโพสต์ในฟอรัม Hacker News ว่าช่องโหว่ PHP สองรายการมีกำหนดเปิดเผยในวันพฤหัสบดีของสัปดาห์นั้น พร้อมยอมรับว่าตนเอง “ไม่มีหลักฐานใดๆ นอกเหนือจาก ‘แหล่งข่าว: เชื่อฉันเถอะเพื่อน’ ”

ปรากฏว่าผู้ใช้ออนไลน์รายนี้พูดถูก

บริษัทความปลอดภัย watchTowr ยืนยันว่าช่องโหว่ทั้งสองมีอยู่จริง และในขณะนั้นยังอยู่ในช่วงห้ามเปิดเผย (embargo) ซึ่งเป็นข้อตกลงระหว่างฝ่ายต่างๆ ที่จะไม่เปิดเผยรายละเอียดช่องโหว่จนกว่าแนวทางแก้ไขจะพร้อม หลังจากนั้น PHP จึงเลื่อนเวลาการเผยแพร่การอัปเดตเร็วขึ้นหนึ่งวัน

Dane Knecht ประธานเจ้าหน้าที่ฝ่ายเทคโนโลยีของ Cloudflare โพสต์บน X ในช่วงเช้ามืดวันพุธว่า “เราได้เห็นการโจมตีระยะแรกเริ่มเกิดขึ้นแล้ว และกำลังอัปเดตมาตรการบรรเทาผลกระทบอย่างต่อเนื่องเมื่อมีเส้นทางการโจมตีใหม่ๆ ปรากฏขึ้น”

ขณะที่โพสต์นี้เผยแพร่ ยังเหลือเวลาอีกเกือบหกชั่วโมงก่อนแพตช์จะเผยแพร่อย่างเป็นทางการ

Cloudflare ได้推送กฎไฟร์วอลล์ฉุกเฉินไปยังลูกค้าทุกรายทันที เพื่อสกัดกั้นรูปแบบการโจมตีที่ทราบแล้วผ่านตัวกรอง อย่างไรก็ตาม Dane Knecht เน้นว่ามาตรการเหล่านี้ “ใช้ได้เพียงเป็นมาตรการรับมือชั่วคราวเท่านั้น”

รัฐบาลหลายประเทศเร่งปิดระบบ

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

ในฝรั่งเศส กระทรวงมหาดไทยระบุว่าเว็บไซต์ของรัฐบาลจังหวัดต่างๆ ได้ “ปิดให้บริการชั่วคราว” จนกว่าผู้เผยแพร่กรอบการทำงานที่เกี่ยวข้องจะออกแพตช์ความปลอดภัย

ทีมตอบสนองเหตุฉุกเฉินทางไซเบอร์ของสหภาพยุโรป CERT-EU แนะนำว่าองค์กรที่ไม่สามารถติดตั้งแพตช์ได้ในขณะนี้ควร “พิจารณาแยกแอปพลิเคชันที่เปิดสู่อินเทอร์เน็ตออกจากเครือข่ายสาธารณะ จนกว่าแนวทางแก้ไขจะพร้อมใช้งาน”

ต่อมา หน่วยงานที่เกี่ยวข้องของออสเตรเลีย ญี่ปุ่น และสหราชอาณาจักรก็ได้ออกคำแนะนำในลักษณะเดียวกันโดยประมาณ

พูดให้เข้าใจง่ายๆ ก็คือ “ถอดสายเน็ต”

โพสต์ยอดนิยมบางส่วนบน X อ้างว่า PHP “ทุกเวอร์ชันตั้งแต่ปี 2004” ล้วนมีช่องโหว่

ข้อกล่าวอ้างนี้มาจากการประเมินเบื้องต้นว่า PHP 5 และเวอร์ชันหลังจากนั้นได้รับผลกระทบทั้งหมด แต่ CERT-EU ยอมรับว่าการประเมินนี้อ้างอิงจากโพสต์บนโซเชียลมีเดีย

บริษัทความปลอดภัยอีคอมเมิร์ซ Sansec เห็นว่าขอบเขตเวอร์ชันที่ได้รับผลกระทบเริ่มตั้งแต่ PHP 5.4 และครอบคลุมเวอร์ชันหลังจากนั้น ซึ่งหมายความว่าขอบเขตผลกระทบของช่องโหว่สามารถย้อนไปได้ถึงปี 2012 ไม่ใช่ปี 2004 อย่างไรก็ตาม นี่ก็ยังเกี่ยวข้องกับเวอร์ชันซอฟต์แวร์ที่เก่ามากอยู่ดี

ปัจจุบันทางการ PHP ให้การอัปเดตเวอร์ชันอย่างเป็นทางการสำหรับ PHP 8.2 ขึ้นไปเท่านั้น ดังนั้นข้อกล่าวอ้างที่ว่า “เวอร์ชันเก่าไม่มีแนวทางแก้ไข” จึงถูกต้องบางส่วน

เมื่อพิจารณาจากความรุนแรงของช่องโหว่นี้ ทีมความปลอดภัย PHP ยังได้เผยแพร่แพตช์ซอร์สโค้ดแบบย่อสำหรับ PHP 7.4, 8.0 และ 8.1 ด้วย โดยดิสทริบิวชันลินุกซ์ต่างๆ ก็กำลังย้อนนำโปรแกรมแก้ไขไปยังเวอร์ชันที่แต่ละรายดูแลอยู่

บริษัทความปลอดภัย Mallory ประเมินว่าจนถึงวันที่ 20 ตุลาคม มีโฮสต์ที่เปิดสู่อินเทอร์เน็ตและแสดง PHP 8.1 หรือเก่ากว่าให้เห็นภายนอกอยู่ประมาณ 884,000 เครื่อง โฮสต์เหล่านี้คิดเป็นประมาณ 59% ของโฮสต์ 1.5 ล้านเครื่องที่เปิดเผยข้อมูลเวอร์ชันต่อสาธารณะ

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

โพสต์ออนไลน์บางส่วนยังระบุถึง Node.js ว่าได้รับผลกระทบด้วย Node.js เป็นเทคโนโลยีเว็บอีกประเภทหนึ่งที่แตกต่างออกไป แต่บังเอิญมีกำหนดเผยแพร่การอัปเดตความปลอดภัยที่ไม่เกี่ยวข้องกับเหตุการณ์นี้ในวันเดียวกัน การที่เวลาตรงกันทำให้เกิดความสับสน

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

มูลนิธิ PHP ระบุในแถลงการณ์ว่า “หากคุณพึ่งพา https://rpms.remirepo.net ซึ่งดูแลโดยอาสาสมัคร เราขอแนะนำอย่างยิ่งให้คุณเปลี่ยนไปใช้แพ็กเกจอย่างเป็นทางการของดิสทริบิวชันลินุกซ์ หรือสร้างจากซอร์สโค้ดด้วยตนเองทันที เพื่อให้สามารถนำการอัปเดตไปใช้ได้ทันที คลังแพ็กเกจดังกล่าวจะไม่เผยแพร่การอัปเดตในวันนี้”

แถลงการณ์นี้หมายถึงแหล่งแพ็กเกจยอดนิยมที่ดูแลโดยอาสาสมัคร ซึ่งมุ่งเน้นเซิร์ฟเวอร์ลินุก