PHP แก้ช่องโหว่ร้ายแรง Google แนะนำให้ตอบ 503 เมื่อปิดเว็บชั่วคราว

เมื่อวันที่ 21 ตุลาคม 2569 โครงการ PHP ออกเวอร์ชัน 8.5.12, 8.4.27, 8.3.36 และ 8.2.35 เพื่อแก้ช่องโหว่ร้ายแรง 2 รายการที่อาจเปิดให้ผู้โจมตีรันโค้ดจากระยะไกลได้โดยไม่ต้องยืนยันตัวตน ทั้งสองรายการได้คะแนน CVSS v4.0 ที่ 9.2 และ PHP แนะนำให้ผู้ใช้ทุกรายอัปเดตทันที ในวันเดียวกัน Google Search Central และ John Mueller ของ Google เตือนเจ้าของเว็บไซต์ที่ต้องปิดเซิร์ฟเวอร์เพื่ออัปเดตว่าควรตอบกลับด้วย HTTP status code 503 ไม่ใช่ปล่อยให้หมดเวลา ตอบ 404 หรือแสดงหน้า error ที่ส่งสถานะ 200 เพื่อรักษาหน้าที่ถูกจัดทำดัชนีไว้ระหว่างที่เว็บล่ม ข้อมูลเวอร์ชันที่แก้ไขและรายละเอียดความเสี่ยงมาจาก ประกาศความปลอดภัยของ PHP.net ที่เผยแพร่วันที่ 21 ตุลาคม 2569

PHP ประกาศอะไรเมื่อวันที่ 21 ตุลาคม

ทีมความปลอดภัยของ PHP แจ้งล่วงหน้าเมื่อวันที่ 20 ตุลาคม 2569 ว่าจะออกรุ่นแก้ไขความปลอดภัยในวันพุธที่ 21 ตุลาคม เวลา 14:00 UTC เพื่อแก้ช่องโหว่ร้ายแรง 2 รายการที่ได้คะแนน CVSS v4.0 ที่ 9.2 ทั้งคู่ จากนั้นในวันที่ 21 ตุลาคม ก็ออกรุ่นแก้ไขครบทั้ง 4 สายเวอร์ชันที่ยังได้รับการสนับสนุน ประกาศของแต่ละรุ่นระบุตรงกันว่าไม่มีวิธีบรรเทาที่สมบูรณ์ และการอัปเดตเป็นทางเลือกเดียวที่ปลอดภัย

เวอร์ชันที่แก้ไขแล้วตามที่ PHP.net ระบุแสดงในตารางด้านล่าง หากเซิร์ฟเวอร์ของคุณใช้ patch release ที่เก่ากว่านี้ในสายเดียวกัน ถือว่ายังไม่ได้รับการแก้ไข

ช่องโหว่ทั้งสองมีรหัส CVE-2026-109618 และ CVE-2026-109619 ตามคำอธิบายของ PHP.net รายการแรกชื่อ "RCE via OOM corruption" เกิดเมื่อกลไกจัดการหน่วยความจำไม่พอขัดจังหวะการทำงานของ PHP ขณะที่ข้อมูลภายในของ request ยังตั้งค่าไม่ครบ ทำให้ขั้นตอนเก็บกวาดหลังจบ request อาจมองข้อมูลที่ไม่ถูกต้องว่าถูกต้อง รายการที่สองชื่อ "RCE via stale global state" เกิดเมื่อสถานะภายในที่ผูกกับ request ยังค้างอยู่หลังจากหน่วยความจำของมันถูกคืนไปแล้ว ทำให้ request ถัดไปที่ worker ตัวเดียวกันรับไปอาจใช้สถานะที่ค้างอยู่นั้นก่อนที่การตั้งค่าเริ่มต้นตามปกติจะรีเซ็ต

ใครมีความเสี่ยงตามที่ PHP ระบุ

PHP.net ระบุว่า PHP ทุกการติดตั้งที่ให้บริการ web request มีความเสี่ยง รวมถึง PHP-FPM, Apache ที่ใช้ mod_php, php-cgi, FrankenPHP และ LiteSpeed โดยโครงการมองว่า mod_php มีความเสี่ยงสูงสุด เพราะมีการสาธิตการโจมตีที่ request ซึ่งไม่ต้องยืนยันตัวตนสามารถกระตุ้นการโจมตีได้ก่อนที่โค้ดของแอปพลิเคชันใดจะเริ่มทำงาน สำหรับเจ้าของเว็บ WordPress นัยของประเด็นนี้คือ ไม่ควรพึ่งปลั๊กอินความปลอดภัยในกรณีนี้ เพราะถ้าการโจมตีเกิดขึ้นก่อนโค้ดของแอปพลิเคชันทำงาน ก็แปลว่าเกิดก่อน WordPress จะโหลด

PHP เวอร์ชันเก่า

PHP 8.1 และเวอร์ชันที่เก่ากว่าไม่ได้รับการอัปเดตจากโครงการ PHP แล้ว PHP.net ระบุว่าผู้ให้บริการ Linux distribution และผู้ให้บริการ LTS บางรายมี backport ให้ และด้วยความร้ายแรงของช่องโหว่ ทีมความปลอดภัยของ PHP จึงเผยแพร่ source backport แบบขั้นต่ำสำหรับ PHP 7.4, 8.0 และ 8.1 ให้ผู้ที่ build จาก source เองหรือไม่มีผู้ให้บริการ LTS นอกจากนี้ Linux distribution และผู้ให้บริการ LTS ได้รับ patch ล่วงหน้า PHP จึงแนะนำให้ตรวจสอบแพ็กเกจที่อัปเดตแล้วจากผู้ให้บริการของคุณ ด้าน Search Engine Roundtable ซึ่งรายงานว่าช่องโหว่นี้ถูกเรียกว่า "PHP2Shell" ระบุว่าทุกเวอร์ชันตั้งแต่ 5.4 ถึง 8.5.11 ได้รับผลกระทบ

ถ้ายังอัปเดตทันทีไม่ได้

PHP.net ระบุมาตรการชั่วคราวไว้ แต่ย้ำว่ามาตรการเหล่านี้เพียงลดโอกาสถูกโจมตีผ่านบางเส้นทาง และไม่ได้ทำให้ระบบปลอดภัย มาตรการทั้งหมดเป็นการตั้งค่าเซิร์ฟเวอร์ เช่น ตั้งค่า session.upload_progress.enabled=0 แล้วรีสตาร์ท worker ทุกตัว ตั้งค่า post_max_size ให้ต่ำ และบน PHP 8.5 ให้ตั้ง fatal_error_backtraces=0 ประกาศระบุเงื่อนไขของแต่ละข้อไว้อย่างละเอียด รวมถึงข้อที่ว่าการตั้งค่าบางอย่างต้องทำใน php.ini หรือ FPM pool ไม่ใช่ผ่าน ini_set() หรือ .user.ini งานเหล่านี้เป็นหน้าที่ของผู้ดูแลเซิร์ฟเวอร์ และเป็นเพียงทางออกชั่วคราว ไม่ใช่การแก้ไข

ทำไมหลายเว็บต้องปิดตัว และทำไมเรื่องนี้เกี่ยวกับ SEO

Search Engine Roundtable รายงานเมื่อวันที่ 21 ตุลาคมว่า หลายเว็บไซต์อัปเดตได้โดยไม่ต้องปิดระบบ แต่อีกหลายแห่งเลือกปิดเว็บจนกว่าจะอัปเดตเสร็จ โดยอ้างรายงานของ Reuters ว่าเว็บไซต์ของหน่วยงานรัฐ โรงเรียน และโรงพยาบาลหลายแห่งในยุโรปถูกปิดชั่วคราวขณะที่องค์กรต่างๆ เร่งป้องกันตัวเอง การปิดเว็บเป็นการตัดสินใจด้านความปลอดภัยที่สมเหตุสมผล แต่สิ่งที่เว็บตอบกลับระหว่างที่ปิดอยู่คือตัวกำหนดว่าอันดับและหน้าที่ถูกจัดทำดัชนีใน Google จะรอดมาครบหรือไม่

Google Search Central: "อย่าลืม 503"

PPC Land รายงานว่า Google Search Central โพสต์เตือนบนหน้า LinkedIn เมื่อวันที่ 21 ตุลาคม 2569 ถึงทุกคนที่กำลังอัปเดต PHP แบบเร่งด่วนหรือปิดเซิร์ฟเวอร์ ว่าการตอบกลับด้วยสถานะ 503 (Service Unavailable) ช่วยให้ URL ที่ถูกจัดทำดัชนีแล้วยังคงอยู่ใน Search ระหว่างที่คุณทำงาน เมื่อเว็บกลับมาตอบ 200 ทุกอย่างจะกลับสู่ปกติ และควรหลีกเลี่ยงการตอบ 404 แบบทั่วไปหรือหน้า error ที่ส่งสถานะ 200 ระหว่างที่เว็บล่ม โพสต์นี้ลิงก์ไปยังเอกสาร "How HTTP status codes affect Google's crawlers" ของ Google ซึ่งระบุวันที่อัปเดตล่าสุดเป็นวันที่ 4 กุมภาพันธ์ 2569 แปลว่าแนวทางนี้ไม่ใช่เรื่องใหม่

John Mueller: ทำนอก PHP

John Mueller ของ Google เขียนบน Bluesky เมื่อวันที่ 21 ตุลาคม 2569 (อ้างโดย Search Engine Roundtable)ว่า ใครที่ต้องปิดเว็บ PHP ควรใช้ HTTP 503 แทนการปล่อยให้ request หมดเวลา หรือตอบ 404 หรือ 500 และสามารถทำได้จากนอก PHP โดยชี้ DNS ไปที่อื่น หรือทำที่ CDN เหตุผลในทางปฏิบัติคือ ถ้า PHP เป็นตัวที่กำลังถูกอัปเดต ปลั๊กอินโหมดซ่อมบำรุงที่สร้าง 503 ด้วย PHP ก็อาจใช้งานไม่ได้ 503 จึงต้องมาจาก web server, load balancer, กฎบน CDN หรือโฮสต์แยกต่างหาก

Google จัดการ status code แต่ละแบบอย่างไรระหว่างเว็บล่ม

เอกสารของ Google อธิบายกลไกเบื้องหลังคำแนะนำนี้ไว้ดังนี้

• 5xx รวมถึง 503: crawler ของ Google จะชะลอการ crawl ชั่วคราว URL ที่ถูกจัดทำดัชนีแล้วจะยังอยู่ในดัชนี แต่จะถูกนำออกในที่สุด เนื้อหาที่ได้รับพร้อม 5xx จะถูกเพิกเฉย เมื่อเซิร์ฟเวอร์กลับมาตอบ 2xx Google จะค่อยๆ เพิ่มอัตราการ crawl กลับขึ้นมา และ Google ระบุว่าระบบจัดทำดัชนีจะนำ URL ที่ตอบ server error ต่อเนื่องออกจากดัชนี
• 404 และ 410: คู่มือการหยุดเว็บไซต์ชั่วคราวของ Google ระบุว่าการตอบ 403, 404 หรือ 410 หรือการใช้ noindex จะทำให้ URL ของเว็บถูกนำออกจาก Google Search
• 200 ที่แสดงข้อความ error: ถ้าเนื้อหาของหน้าที่ตอบ 200 ดูเหมือนหน้า error หรือหน้าว่าง Search Console จะรายงานเป็น soft 404
• การหมดเวลา (timeout): Mueller ระบุว่าการปล่อยให้ request หมดเวลาเป็นสิ่งที่ควรหลีกเลี่ยง

สรุปคือ 503 เป็นการป้องกันที่มีเวลาจำกัด ช่วยซื้อเวลาได้ แต่ไม่ได้รักษาหน้าไว้ในดัชนีตลอดไป

ปิดเว็บได้นานแค่ไหนตามเอกสารของ Google

คู่มือ "Temporarily pause or disable a website" ของ Google ระบุว่าการปิดทั้งเว็บไซต์เป็นมาตรการสุดโต่งที่ควรทำในช่วงสั้นมากเท่านั้น คือไม่เกินไม่กี่วัน หากต้องปิดเร่งด่วน 1-2 วัน Google แนะนำให้แสดงหน้าแจ้งข้อมูลพร้อมสถานะ 503 ถ้าต้องปิดนานกว่านั้น ให้ใช้หน้าแรกชั่วคราวที่ Google จัดทำดัชนีได้และตอบสถานะ 200 แทน บล็อก Search Central ของ Google เรื่องการปิดเว็บตามแผนเมื่อปี 2554 ยังระบุเพิ่มว่า 503 ที่ต่อเนื่องนานอาจถูกมองว่าเซิร์ฟเวอร์ไม่พร้อมใช้งานถาวร และอาจนำไปสู่การนำ URL ออกจากดัชนี นอกเหนือจากแนวทางนี้ Google ไม่ได้ระบุจำนวนชั่วโมงที่แน่นอน

แนวปฏิบัติของ Google สำหรับหน้า 503

• ให้ robots.txt เข้าถึงได้ตามปกติ Google ระบุว่าไม่ควรตอบ 503 ให้ robots.txt เพราะจะบล็อกการ crawl ทั้งหมด และไม่ควรใช้ robots.txt ที่สั่งห้าม crawl ทั้งเว็บ
• ใส่ header Retry-After พร้อมวันที่หรือระยะเวลาที่คาดการณ์ได้ดีที่สุด บล็อกของ Google ปี 2554 ระบุว่า Googlebot อาจใช้ค่านี้กำหนดเวลาที่จะกลับมา crawl
• ใช้ HTML แบบ static ที่พึ่งทรัพยากรภายนอกให้น้อยที่สุด และบอกผู้เข้าชมว่าเว็บจะกลับมาเมื่อใดและติดต่อได้ทางไหน
• ตรวจ status code ด้วยตัวเอง เช่น ใช้คำสั่ง curl -I -X GET กับหน้าแรก แล้วดูว่าบรรทัดแรกของ response เป็น 503
• อย่าใช้เครื่องมือนำออกชั่วคราวใน Search Console สำหรับการปิดเว็บ

ขั้นตอนสำหรับเจ้าของเว็บ WordPress และ PHP ในประเทศไทย

ขั้นตอนด้านล่างเป็นแนวทางที่เรียบเรียงจากประกาศของ PHP และเอกสารของ Google คำแนะนำของผู้ให้บริการโฮสติ้งของคุณมีลำดับความสำคัญสูงกว่า

1. ดูเวอร์ชัน PHP ใน WordPress ใน wp-admin ไปที่ เครื่องมือ (Tools) แล้วเลือก สุขภาพเว็บไซต์ (Site Health) แท็บ ข้อมูล (Info) และเปิดส่วน เซิร์ฟเวอร์ (Server) จะเห็นเวอร์ชัน PHP ที่เว็บใช้อยู่ ให้เทียบเลขเต็ม ไม่ใช่แค่สายเวอร์ชัน เช่น 8.3.35 ยังมีช่องโหว่ แต่ 8.3.36 แก้แล้ว
2. ตรวจในแผงควบคุมโฮสติ้ง แผงควบคุมอย่าง cPanel, Plesk และ DirectAdmin แสดงเวอร์ชัน PHP แยกตามโดเมน ถ้าใช้ shared hosting คุณมักอัปเดต PHP เองไม่ได้ ผู้ให้บริการโฮสต์ต้องเป็นคนอัปเดต
3. ถามโฮสต์ให้ตรงประเด็น ถ้าโฮสต์ใช้แพ็กเกจของ Linux distribution เลขเวอร์ชันอาจเป็นไปตามระบบของผู้ให้บริการนั้น ไม่ใช่ของ PHP.net ให้ถามว่า PHP ที่รันเว็บของคุณมีการแก้ไข CVE-2026-109618 และ CVE-2026-109619 แล้วหรือยัง และขอคำตอบเป็นลายลักษณ์อักษร
4. ถ้าใช้ PHP 8.1 หรือเก่ากว่า ให้วางแผนอัปเกรดไปยังสายเวอร์ชันที่ยังได้รับการสนับสนุน หรือยืนยันว่าผู้ให้บริการมี backport ตามที่ PHP.net แนะนำ และทดสอบธีมกับปลั๊กอินบนเว็บสำเนา (staging) ก่อน
5. ถ้าจำเป็นต้องปิดเว็บ ให้ส่ง 503 จากนอก PHP เช่น web server, CDN หรือโฮสต์แยก ให้ robots.txt ยังตอบ 200 ใส่ Retry-After และจำกัดเวลาปิดไว้ไม่เกิน 1-2 วันตามแนวทางของ Google
6. อย่าใช้หน้าซ่อมบำรุงที่ตอบ 200 ระบบโหมดซ่อมบำรุงหรือหน้า "coming soon" บางแบบอาจตอบ 200 จึงควรตรวจ status code ด้วย curl เพราะ Google จัดหน้า error ที่ตอบ 200 เป็น soft 404
7. หลังอัปเดตเสร็จ ตรวจว่าเว็บกลับมาตอบ 200 ติดตามรายงานการจัดทำดัชนีหน้าเว็บ (Page indexing) และสถิติการ crawl ใน Search Console ในช่วงหลายวันถัดไป และยืนยันเวอร์ชัน PHP ใหม่ใน Site Health

สิ่งที่แหล่งข้อมูลไม่ได้บอก

• ประกาศของ PHP.net ไม่ได้ให้ตัวเลขว่ามีเว็บไซต์ถูกโจมตีไปแล้วกี่แห่ง และบทความนี้ไม่ประเมินตัวเลขใดๆ เอง
• Google ไม่ได้ระบุว่าเว็บไซต์หนึ่งๆ ตอบ 503 ได้กี่วัน เอกสารของ Google พูดเพียงว่าไม่เกินไม่กี่วัน
• ไม่มีแหล่งข้อมูลใดในบทความนี้ระบุว่าผู้ให้บริการโฮสติ้งรายใดในไทยอัปเดตแล้วหรือยัง

ความหมายสำหรับนักการตลาดไทย

สำหรับธุรกิจที่เว็บ WordPress หรือ WooCommerce สร้างลีดหรือยอดขาย เรื่องนี้เป็นปัญหาความปลอดภัยก่อน และเป็นปัญหา SEO ตามมา ทั้งสองเรื่องมีเวลาเป็นตัวกดดัน ตรวจเวอร์ชัน PHP วันนี้ ขอคำตอบเป็นลายลักษณ์อักษรจากโฮสต์ และถ้าต้องปิดเว็บ ให้แน่ใจว่าเว็บตอบ 503 ไม่ใช่หน้า error หากหน้าที่ถูกจัดทำดัชนีหายไปหลังช่วงอัปเดตที่ไม่ราบรื่น การตรวจ SEO เชิงเทคนิค ช่วยย้อนดูได้ว่า crawler เห็นอะไร ส่วนเว็บเก่าที่ยังติดอยู่กับ PHP ที่หมดการสนับสนุน อาจถึงเวลาทบทวนระบบร่วมกับทีม ออกแบบและพัฒนาเว็บไซต์ เพื่อรักษาผลงาน SEO ในประเทศไทย ที่สร้างไว้บนเว็บ

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

PHP เวอร์ชันไหนแก้ช่องโหว่ร้ายแรงทั้งสองรายการแล้ว?

PHP 8.5.12, 8.4.27, 8.3.36 และ 8.2.35 แก้ไขแล้ว ตามประกาศของ PHP.net วันที่ 21 ตุลาคม 2569 เวอร์ชันที่เก่ากว่าในสายเดียวกันยังไม่ได้รับการแก้ไข ส่วน PHP 8.1 และเก่ากว่าต้องใช้ backport จากผู้ให้บริการหรืออัปเกรด

ช่องโหว่นี้ร้ายแรงแค่ไหน?

ทั้งสองรายการได้คะแนน CVSS v4.0 ที่ 9.2 และอาจเปิดให้รันโค้ดจากระยะไกลได้โดยไม่ต้องยืนยันตัวตน PHP.net ระบุว่า Apache ที่ใช้ mod_php เสี่ยงที่สุด เพราะการโจมตีเกิดได้ก่อนโค้ดของแอปพลิเคชันจะทำงาน

ปิดเว็บชั่วคราวแล้วอันดับใน Google จะตกไหม?

การปิดช่วงสั้นที่ตอบสถานะ 503 ไม่ควรกระทบ เพราะ Google เก็บ URL ที่จัดทำดัชนีแล้วไว้ระหว่างที่เห็น 503 แต่การปิดนานต่างออกไป Google ระบุว่า server error ที่ต่อเนื่องจะทำให้ URL ถูกนำออกในที่สุด และแนะนำให้ปิดเว็บไม่เกินไม่กี่วัน

ทำไมไม่แสดงหน้าซ่อมบำรุงธรรมดา?

หน้าซ่อมบำรุงใช้ได้ก็ต่อเมื่อตอบสถานะ 503 ถ้าตอบ 200 Google อาจถือเป็น soft 404 และถ้าตอบ 404 URL จะถูกนำออกจาก Search

ดูเวอร์ชัน PHP ใน WordPress ได้อย่างไร?

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

อัปเดตก่อน แล้วค่อยตรวจว่า Google เห็น 503 ที่ถูกต้องและเห็นการกลับมาที่เรียบร้อย เจ้าของเว็บที่ต้องการให้ช่วยตรวจการจัดทำดัชนีหลังการอัปเดต PHP สัปดาห์นี้ สามารถติดต่อทีม Relevant Audience ได้