สรุปสั้น

cPanel ออกแพตช์แก้ช่องโหว่ด้านความปลอดภัยที่กระทบฟังก์ชันจอดโดเมน (domain parking) และโดเมนเสริม (addon domain) ใน cPanel และ WebHost Manager (WHM) ซึ่งเปิดทางให้รันโค้ดในสิทธิ์ผู้ใช้ root ได้ ช่องโหว่นี้ได้รับรหัส CVE-2026-65643 และกระทบ cPanel และ WHM ทุกเวอร์ชันที่ยังอยู่ในการรองรับ โดยบริษัทจัดระดับว่าเป็นช่องโหว่ความปลอดภัยระดับร้ายแรง และระบุว่าผู้ถือบัญชีที่ยืนยันตัวตนแล้วและมีสิทธิ์เพิ่มโดเมนจอดหรือโดเมนเสริม สามารถสร้างไฟล์บนเซิร์ฟเวอร์ได้ตามอำเภอใจ

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

จุดที่ผู้ดูแลระบบควรสังเกตคือประกาศฉบับนี้แจ้งเฉพาะเวอร์ชันที่แก้แล้วกับวิธีอัปเดตเท่านั้น ไม่มีคะแนน CVSS กำกับ ไม่ได้ให้มาตรการบรรเทาชั่วคราวสำหรับเซิร์ฟเวอร์ที่ยังอัปเดตไม่ได้ และไม่ได้ให้วิธีตรวจสอบว่าเซิร์ฟเวอร์ถูกใช้ประโยชน์จากช่องโหว่นี้ไปแล้วหรือไม่ ขณะที่ ณ วันที่ตรวจสอบก็ยังไม่มีการเผยแพร่ระเบียนของ CVE-2026-65643 ในระบบของ CVE Program

รายละเอียดข่าว

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 28 สิงหาคม 2569 ว่า cPanel เผยแพร่ประกาศแจ้งเตือนช่องโหว่นี้เมื่อวันที่ 27 สิงหาคม 2569 พร้อมรายชื่อบิลด์ที่แก้ไขแล้วได้แก่ 11.110.0.141 ขึ้นไป, 11.134.0.53 ขึ้นไป, 11.136.0.37 ขึ้นไป, 11.138.0.2 ขึ้นไป และ 11.138.1.7 ขึ้นไปสำหรับ WP Squared โดยรายการดังกล่าวระบุถึง WP Squared ไว้ด้วย แต่ไม่ได้กล่าวถึง DNSOnly

ประเด็นที่ยังคลุมเครืออยู่สองเรื่อง เรื่องแรกคือ cPanel เพิ่งแพตช์ช่องโหว่แยกกันสามรายการไปเมื่อเดือนกรกฎาคม และบิลด์ที่แก้ไขในประกาศชุดนั้นครอบคลุมสาย 11.118 และ 11.126 ด้วย ขณะที่รายการของวันที่ 27 สิงหาคมครอบคลุมเฉพาะสาย 110, 134, 136 และ 138 โดยบริษัทไม่ได้ระบุว่าสาย 11.118 และ 11.126 ยังอยู่ในการรองรับหรือไม่ เรื่องที่สองคือในประกาศเรื่องช่องโหว่ Exim เมื่อเดือนกรกฎาคม cPanel เคยระบุว่าปัญหาอาจเปิดทางให้ยกระดับสิทธิ์จากบัญชีย่อยประเภท Team User ได้ แต่ประกาศฉบับวันที่ 27 สิงหาคมไม่ได้ระบุว่าบัญชีย่อย Team User ที่ได้รับสิทธิ์จัดการโดเมนจอดและโดเมนเสริมอยู่ในขอบเขตของช่องโหว่นี้ด้วยหรือไม่

ในแง่หลักฐานการถูกโจมตีจริง cPanel ไม่ได้ระบุว่าช่องโหว่นี้ถูกนำไปใช้โจมตีแล้วหรือยัง และช่องโหว่ดังกล่าวก็ไม่ปรากฏในบัญชี Known Exploited Vulnerabilities (KEV) ของหน่วยงาน CISA สหรัฐฯ ฉบับที่ปล่อยเมื่อวันที่ 27 สิงหาคม 2569 อย่างไรก็ตามบัญชี KEV มีช่องโหว่ในปลั๊กอินของ cPanel อยู่แล้วสองรายการ ได้แก่ CVE-2026-48172 ปัญหายกระดับสิทธิ์ในปลั๊กอิน LiteSpeed cPanel ที่ถูกเพิ่มเข้าบัญชีเมื่อวันที่ 26 พฤษภาคม 2569 ซึ่ง CISA ระบุว่าบัญชีผู้ใช้ cPanel รายใดก็ได้สามารถใช้รันสคริปต์ด้วยสิทธิ์ root และ CVE-2026-54420 ปัญหาการตามลิงก์สัญลักษณ์ในปลั๊กอินตัวเดียวกันที่ถูกเพิ่มเมื่อวันที่ 15 มิถุนายน 2569 สำหรับเซิร์ฟเวอร์โฮสติงแบบแชร์ที่ใช้ CloudLinux หรือ CageFS และผู้ใช้มีสิทธิ์เข้าถึง FTP หรือเว็บเชลล์ นอกจากนี้บัญชียังมี CVE-2026-41940 ซึ่งเป็นช่องโหว่ข้ามการยืนยันตัวตนที่แพตช์ไปเมื่อเดือนเมษายน และมีการใช้งานจริงในแคมเปญแรนซัมแวร์ (เว็บไซต์ Cloud Thunder เคยรายงานทั้งกรณี CVE-2026-41940 และ CVE-2026-54420 ไว้แล้ว)

รายละเอียดช่องโหว่

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

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

เมื่อเทียบกับกรณีอื่นที่เกิดในเดือนเดียวกัน จะเห็นความต่างของแนวปฏิบัติชัดเจน กรณีช่องโหว่ Watchdog API ของ Phusion Passenger ซึ่ง cPanel ประกาศเมื่อวันที่ 14 สิงหาคม 2569 บริษัทได้แนบคำสั่งสำหรับ grep ล็อกข้อผิดพลาดของ Apache เพื่อหาร่องรอยการถูกโจมตี พร้อมระบุว่าปัญหานั้นไม่กระทบการติดตั้งแบบค่าเริ่มต้น และมีผลเฉพาะเซิร์ฟเวอร์ที่ติดตั้งแพ็กเกจ Passenger รุ่นที่ได้รับผลกระทบ ขณะที่ Plesk ซึ่ง WebPros พัฒนาควบคู่กับ cPanel ได้อัปเดตประกาศของตัวเองสำหรับช่องโหว่เดียวกันในวันที่ 14 สิงหาคม 2569 พร้อมรายการตรวจสอบ 5 ข้อสำหรับหาร่องรอยการถูกเจาะมาก่อน โดยเริ่มจากการมองหารายการที่ไม่คาดคิดใน /etc/ld.so.preload และย้ำว่า “การแพตช์ปิดช่องโหว่สำหรับอนาคต แต่ไม่ได้ย้อนแก้สิ่งที่ผู้โจมตีอาจทำไปแล้ว” ส่วน Phusion ผู้พัฒนา Passenger ปล่อยตัวแก้ใน Passenger 6.2.0 เมื่อวันที่ 18 สิงหาคม 2569 สำหรับช่องโหว่ Watchdog API ที่ไม่มีรหัส CVE พร้อมระบุว่า “เราเห็นการใช้ประโยชน์จากช่องโหว่นี้ในโลกจริงที่ผู้ให้บริการโฮสติงแบบแชร์รายหนึ่ง”

ผลกระทบ

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

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

อีกจุดที่ควรระวังคือลูกค้าที่ยังใช้เวอร์ชันที่หมดอายุการสนับสนุน ซึ่ง cPanel ระบุชัดว่าต้องอัปเกรดขึ้นมาเป็นเวอร์ชันที่ยังรองรับก่อนจึงจะได้รับตัวแก้ กลุ่มนี้มักเป็นเซิร์ฟเวอร์เก่าที่ถูกปล่อยทิ้งไว้เพราะกลัวอัปเกรดแล้วเว็บลูกค้าพัง และมักเป็นเครื่องเดียวกับที่ยังค้างช่องโหว่เก่าอย่าง CVE-2026-41940 ที่มีการใช้งานจริงในแคมเปญแรนซัมแวร์อยู่แล้ว

คำแนะนำ

เซิร์ฟเวอร์ที่ตั้งค่าให้อัปเดตอัตโนมัติรายวันจะได้รับบิลด์ที่แก้ไขแล้วโดยอัตโนมัติตามประกาศ แต่ผู้ดูแลไม่ควรรอ ให้เข้าสู่ระบบเป็น root แล้วสั่ง /scripts/upcp --force เพื่ออัปเดตทันที หรืออัปเดตผ่าน WHM ที่เมนู Home > cPanel > Upgrade to Latest Version จากนั้นตรวจสอบบิลด์ที่ติดตั้งจริงได้ที่ Server Configuration > Update Preferences

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

เนื่องจากผู้ผลิตไม่ได้ให้วิธีตรวจสอบร่องรอยการบุกรุกไว้ ผู้ดูแลควรถือเสียว่าต้องตรวจด้วยตัวเอง โดยไล่ดูไฟล์ที่ถูกสร้างหรือแก้ไขนอกเวลาปกติในเส้นทางที่เกี่ยวกับการตั้งค่าโดเมน ตรวจบัญชีผู้ใช้ระดับระบบและงานที่ตั้งเวลาไว้ว่ามีของแปลกปลอมเพิ่มมาหรือไม่ ตรวจ /etc/ld.so.preload ตามแนวทางที่ Plesk ให้ไว้สำหรับกรณี Passenger และตรวจกุญแจ SSH ที่ได้รับอนุญาตของบัญชี root สำหรับเซิร์ฟเวอร์ที่ให้บริการลูกค้าหลายราย การจำกัดว่าบัญชีใดมีสิทธิ์เพิ่มโดเมนจอดและโดเมนเสริมได้บ้าง เป็นมาตรการลดพื้นที่โจมตีที่ควรทบทวนไปพร้อมกัน

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