นักวิจัยด้านความปลอดภัย Ali Mustafa (rz1027) และ abed1526 เปิดเผยช่องโหว่ระดับร้ายแรงใน Plesk Backup Manager ที่ติดตามในรหัส CVE-2026-68488 ซึ่งเกิดจาก Race Condition ของ Symbolic Link (Symlink) ระหว่างกระบวนการ Restore ข้อมูลของ Subscription ช่องโหว่นี้เปิดทางให้ผู้ใช้ที่มีเพียงสิทธิ์ FTP ระดับ Subscription ของตนเองสามารถยกระดับสิทธิ์ขึ้นเป็น Root บนเซิร์ฟเวอร์ Linux ได้ทั้งเครื่อง ถือเป็นความเสี่ยงสูงเป็นพิเศษสำหรับผู้ให้บริการ Web Hosting ที่เปิดให้ลูกค้าหลายรายใช้งาน Plesk ร่วมกันบนเซิร์ฟเวอร์เดียว
รายละเอียดการโจมตี
ช่องโหว่คืออะไร
CVE-2026-68488 เป็นช่องโหว่ประเภท Local Privilege Escalation ที่อาศัยจังหวะ Race Condition ระหว่างการประมวลผลไฟล์ Symbolic Link ในกระบวนการ Restore ข้อมูล Backup ของ Plesk Backup Manager ผู้โจมตีที่มีบัญชีผู้ใช้ระดับ Subscription ปกติ (เช่น สิทธิ์เข้าถึง FTP หรือ Plesk Panel ของ Subscription ตนเอง) สามารถใช้ประโยชน์จากช่วงเวลาสั้นๆ ระหว่างที่ระบบตรวจสอบ Path ของไฟล์กับช่วงเวลาที่ระบบดำเนินการกับไฟล์จริง เพื่อสลับปลายทางของ Symlink ให้ชี้ไปยังไฟล์ระบบที่อยู่นอกขอบเขต Subscription ของตน
กลไกการทำงานของการโจมตี
กระบวนการ Restore ข้อมูลใน Plesk ทำงานด้วยสิทธิ์ระดับสูง (Privileged Process) เพื่อคืนค่าไฟล์ Backup กลับเข้าสู่ตำแหน่งที่ถูกต้องพร้อมปรับความเป็นเจ้าของไฟล์ (File Ownership) ให้ตรงกับผู้ใช้ของ Subscription นั้นๆ ผู้โจมตีสามารถเตรียม Symlink ที่ชี้ไปยัง Path ของไฟล์ระบบสำคัญไว้ล่วงหน้า แล้วอาศัยจังหวะ Race Condition ระหว่างขั้นตอนตรวจสอบและขั้นตอนดำเนินการจริงของกระบวนการ Restore เพื่อหลอกให้ระบบเปลี่ยนความเป็นเจ้าของไฟล์ระบบเหล่านั้นให้ตกอยู่ในการควบคุมของผู้โจมตี เมื่อควบคุมไฟล์ระบบสำคัญได้แล้ว ผู้โจมตีสามารถต่อยอดไปสู่การยึดครองสิทธิ์ Root และควบคุมเซิร์ฟเวอร์ทั้งเครื่องได้ในที่สุด
ขอบเขตผลกระทบ
ช่องโหว่นี้กระทบ Plesk Obsidian สำหรับ Linux เวอร์ชัน 18.0.80.6 และก่อนหน้า รวมถึงสาย 18.0.79.10 และก่อนหน้า ขณะที่ Plesk for Windows ไม่ได้รับผลกระทบจากช่องโหว่นี้ เนื่องจากกลไก Symlink และโครงสร้างสิทธิ์ไฟล์ของ Linux เป็นเงื่อนไขจำเป็นต่อการโจมตี บางฐานข้อมูลช่องโหว่ภายนอกรายงานระดับความรุนแรงไว้สูงถึงเกือบ Critical (CVSS ใกล้เคียง 9.9) แม้แหล่งข้อมูลหลักอย่าง Cyber Security News จะยังไม่ได้ยืนยันตัวเลข CVSS อย่างเป็นทางการก็ตาม
ผลกระทบที่อาจเกิดขึ้น
1. ผู้ให้บริการ Web Hosting แบบ Multi-Tenant มีความเสี่ยงสูงสุด
เซิร์ฟเวอร์ Plesk ที่เปิดให้ลูกค้าหลายรายใช้งาน Subscription ร่วมกันบนเครื่องเดียว (Shared/Multi-Tenant Hosting) เป็นกลุ่มที่มีความเสี่ยงสูงเป็นพิเศษ เนื่องจากลูกค้าเพียงรายเดียวที่มีสิทธิ์ต่ำสามารถยกระดับสิทธิ์เข้าควบคุมทั้งเซิร์ฟเวอร์ ส่งผลกระทบต่อลูกค้ารายอื่นทั้งหมดที่ใช้เซิร์ฟเวอร์ร่วมกัน
2. ไม่จำเป็นต้องมีสิทธิ์ผู้ดูแลระบบมาก่อน
เนื่องจากช่องโหว่นี้ใช้ได้กับผู้ใช้ที่มีเพียงสิทธิ์ FTP หรือ Subscription ระดับพื้นฐาน จึงเปิดทางให้ทั้งลูกค้าที่มีเจตนาร้ายและบัญชีที่ถูกขโมยไปสามารถโจมตีจากภายในระบบได้ง่ายกว่าช่องโหว่ที่ต้องอาศัยการเจาะระบบจากภายนอกเครือข่าย
3. ความเสี่ยงต่อข้อมูลลูกค้าทุกรายบนเซิร์ฟเวอร์
ผู้ให้บริการ Hosting ที่ไม่รีบดำเนินการแพตช์มีความเสี่ยงสูญเสียการควบคุมเซิร์ฟเวอร์ทั้งหมด ซึ่งรวมถึงข้อมูลเว็บไซต์ ฐานข้อมูล และไฟล์สำคัญของลูกค้าทุกรายที่ Host อยู่บนเซิร์ฟเวอร์เดียวกัน ไม่จำกัดเฉพาะ Subscription ที่ถูกใช้เป็นจุดเริ่มต้นโจมตี
4. ความเสียหายต่อชื่อเสียงและความน่าเชื่อถือของผู้ให้บริการ
หากเกิดเหตุการณ์โจมตีจริงและลูกค้าตรวจพบว่าข้อมูลของตนถูกกระทบจากช่องโหว่ในระบบที่ผู้ให้บริการควบคุม อาจนำไปสู่ความเสียหายด้านความน่าเชื่อถือและความเชื่อมั่นของลูกค้าในระยะยาว
สิ่งที่องค์กรควรทำ
1. อัปเดต Plesk เป็นเวอร์ชันที่แก้ไขแล้วโดยเร็วที่สุด
ผู้ดูแลระบบควรอัปเดต Plesk เป็นเวอร์ชัน 18.0.80.7 ขึ้นไป (สำหรับสาย 18.0.80) หรือ 18.0.79.11 ขึ้นไป (สำหรับสาย 18.0.79) ทันทีที่ทำได้ เนื่องจากเป็นช่องโหว่ที่มีความรุนแรงสูงและมีรายละเอียดทางเทคนิคเผยแพร่สู่สาธารณะแล้ว
2. จัดลำดับความสำคัญเซิร์ฟเวอร์ที่มีความเสี่ยงสูงก่อน
ควรให้ความสำคัญกับการแพตช์เซิร์ฟเวอร์ที่เปิดให้เข้าถึงจาก Internet และเซิร์ฟเวอร์แบบ Multi-Tenant ที่มีลูกค้าหลายรายใช้งานร่วมกันเป็นลำดับแรก เนื่องจากมีความเสี่ยงสูงสุดและมีผู้ที่อาจใช้ประโยชน์จากช่องโหว่ได้มากที่สุด
3. ตรวจสอบ Log การ Restore ข้อมูลย้อนหลัง
หากสงสัยว่าเซิร์ฟเวอร์อาจถูกโจมตีไปแล้วก่อนการแพตช์ ควรตรวจสอบ Log การ Restore ข้อมูล Subscription ย้อนหลัง โดยเฉพาะการเปลี่ยนแปลงความเป็นเจ้าของไฟล์ (Ownership) ที่ผิดปกติหรือเกิดขึ้นนอกขอบเขตของ Subscription ที่เกี่ยวข้อง
4. จำกัดสิทธิ์และเฝ้าระวังกิจกรรม Restore ที่ผิดปกติ
ควรพิจารณาจำกัดหรือเฝ้าระวังการใช้งานฟีเจอร์ Restore ข้อมูลของ Subscription อย่างใกล้ชิดในช่วงที่ยังไม่ได้แพตช์ และตรวจสอบสิทธิ์การเข้าถึง FTP และ Plesk Panel ของผู้ใช้แต่ละราย ว่าไม่มีการให้สิทธิ์เกินความจำเป็น
แนวทางลดความเสี่ยงระยะยาว
1. จัดทำกระบวนการแพตช์ระบบ Hosting/Panel อย่างเป็นระบบ
ผู้ให้บริการ Web Hosting ควรมีกระบวนการติดตามประกาศช่องโหว่และแพตช์สำหรับ Control Panel อย่าง Plesk, cPanel หรือซอฟต์แวร์จัดการเซิร์ฟเวอร์อื่นๆ อย่างสม่ำเสมอ พร้อมกำหนดกรอบเวลาชัดเจนสำหรับการทดสอบและติดตั้งแพตช์ความปลอดภัยระดับ Critical
2. แยก Subscription และ Workload ที่มีความอ่อนไหวสูงออกจากกัน
สำหรับลูกค้าที่มีความต้องการด้านความปลอดภัยสูง ควรพิจารณาแยกไปใช้เซิร์ฟเวอร์เฉพาะ (Dedicated Server) หรือ Container/VM ที่แยกขาดจากกันอย่างสมบูรณ์ แทนการใช้งานแบบ Multi-Tenant ร่วมกับลูกค้ารายอื่น เพื่อลดผลกระทบที่อาจลุกลามข้าม Subscription
3. เสริมการตรวจสอบพฤติกรรมผิดปกติระดับ File System
ควรพิจารณาใช้เครื่องมือตรวจจับพฤติกรรมผิดปกติระดับ File Integrity Monitoring (FIM) เพื่อเฝ้าระวังการเปลี่ยนแปลง Ownership หรือ Permission ของไฟล์ระบบสำคัญแบบ Real-time ซึ่งจะช่วยตรวจจับความพยายามโจมตีลักษณะ Race Condition ได้รวดเร็วขึ้น แม้ในกรณีที่ยังไม่มีแพตช์ครอบคลุมทุกช่องโหว่
4. ทบทวนสถาปัตยกรรมสิทธิ์การเข้าถึงของระบบ Multi-Tenant
องค์กรที่ให้บริการ Hosting ควรทบทวนการออกแบบสถาปัตยกรรมสิทธิ์การเข้าถึง (Privilege Architecture) ของระบบ Multi-Tenant เป็นระยะ เพื่อลดพื้นผิวการโจมตีที่อาจเกิดจากช่องโหว่ประเภท Privilege Escalation ในอนาคต รวมถึงพิจารณาใช้หลัก Least Privilege กับกระบวนการที่ทำงานด้วยสิทธิ์สูงทุกจุดในระบบ
วิเคราะห์ในมุมมองจาก TXEC
ช่องโหว่ CVE-2026-68488 สะท้อนความเสี่ยงคลาสสิกของสถาปัตยกรรม Multi-Tenant ที่ยังคงพบเห็นซ้ำแล้วซ้ำเล่าในซอฟต์แวร์จัดการเซิร์ฟเวอร์ นั่นคือช่องว่างเล็กๆ ระหว่างขั้นตอนตรวจสอบสิทธิ์กับขั้นตอนดำเนินการจริง (Time-of-Check to Time-of-Use หรือ TOCTOU) ซึ่งแม้จะดูเหมือนเป็นรายละเอียดทางเทคนิคเล็กน้อย แต่เมื่อเกิดขึ้นในกระบวนการที่ทำงานด้วยสิทธิ์ Root อย่าง Backup Restore ผลลัพธ์กลับร้ายแรงถึงขั้นยึดครองเซิร์ฟเวอร์ทั้งเครื่องได้ สำหรับผู้ให้บริการ Hosting ในประเทศไทยที่ใช้ Plesk เป็นแพลตฟอร์มจัดการเซิร์ฟเวอร์ให้ลูกค้าจำนวนมาก ความเร่งด่วนในการแพตช์ครั้งนี้ไม่ควรถูกมองข้าม เพราะผลกระทบไม่ได้จำกัดอยู่แค่ Subscription เดียว แต่ลุกลามไปถึงลูกค้าทุกรายที่ใช้เซิร์ฟเวอร์ร่วมกัน องค์กรควรใช้โอกาสนี้ทบทวนไม่เพียงแค่การแพตช์ แต่รวมถึงการออกแบบสถาปัตยกรรมแยกความเสี่ยงระหว่าง Tenant ในระยะยาวด้วย รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า
[ แหล่งอ้างอิง: Cyber Security News ]