Drupal อุดช่องโหว่ Critical ใน Field UI: เว็บที่ใช้ Drupal 8.9 ขึ้นไปต้องเช็กเวอร์ชันวันนี้

ตามเว็บของโปรเจกต์ Drupal มีเว็บไซต์มากกว่า 1 ล้านแห่งที่ใช้ Drupal อยู่ ไม่ใช่ทุกเว็บจะโดนเรื่องนี้ แต่เว็บที่อยู่ในช่วงเวอร์ชันที่ได้รับผลกระทบควรรีบเช็ก หลังจากมีการเปิดเผยช่องโหว่ระดับวิกฤต (Critical) ซึ่งเปิดทางให้ผู้ไม่หวังดีสามารถสั่งรันโค้ดอันตรายบนเครื่องเซิร์ฟเวอร์ปลายทางได้จากระยะไกล ตามข้อมูลจากรายงานข่าวของ BleepingComputer

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

สรุป 30 วินาที

เมื่อวันที่ 14 ตุลาคม 2026 ทีมงานความปลอดภัยของ Drupal ได้ออกประกาศเตือนภัยความปลอดภัยระดับ Critical ภายใต้รหัส SA-CORE-2026-014 เพื่อแจ้งการค้นพบช่องโหว่ประเภท Remote Code Execution (RCE) ในโมดูลหลักของระบบที่มีชื่อว่า Field UI โดยได้รับรหัสระบุช่องโหว่สากลคือ CVE-2026-108097 พร้อมค่าประเมินความเสี่ยงสูงถึง 19 เต็ม 25 คะแนน

นอกจากช่องโหว่ในส่วนหลักดังกล่าวแล้ว ยังมีการเปิดเผยช่องโหว่ความรุนแรงระดับ Critical อีกหนึ่งตัวในโมดูลเสริมที่มีชื่อว่า Entity List ภายใต้รหัส CVE-2026-108099 ซึ่งเปิดทางให้เกิดการรันโค้ดจากระยะไกลได้ในลักษณะเดียวกัน โดยทีมความปลอดภัยของ Drupal ได้แจ้งเตือนล่วงหน้าตั้งแต่วันที่ 12 ตุลาคม 2026 และย้ำเตือนผู้ดูแลระบบอย่างจริงจังว่า บรรดาแฮกเกอร์อาจพัฒนาโค้ดโจมตีขึ้นมาได้ภายในเวลาเพียงไม่กี่ชั่วโมงหรือหลักวันหลังการเปิดเผยข้อมูล (BleepingComputer, The Hacker News)

ปัจจุบัน ผู้พัฒนาได้ปล่อยแพตช์อัปเดตออกมาเพื่อแก้ไขช่องโหว่นี้แล้ว ได้แก่ Drupal เวอร์ชัน 11.4.10, 11.3.19 และ 10.6.19 รวมถึงเวอร์ชันทดสอบ Drupal 12.0.0-beta2 และโมดูล Entity List เวอร์ชัน 3.0.10 (SA-CORE-2026-014, BleepingComputer) ส่วนเว็บไซต์ที่ใช้ระบบเวอร์ชันเก่ากว่านั้นซึ่งสิ้นสุดระยะเวลาการสนับสนุน (End-of-Life หรือ EOL) ไปแล้ว จะไม่ได้รับแพตช์แก้ไขความปลอดภัยนี้

ทำไมเรื่องนี้เกี่ยวกับคุณ

Drupal เป็นระบบบริหารจัดการเนื้อหาเว็บไซต์แบบโอเพนซอร์ส (Open-source Content Management System หรือ CMS) ที่เปิดให้ใช้งานได้ฟรี และได้รับความนิยมอย่างแพร่หลายในกลุ่มหน่วยงานภาครัฐ สถาบันการศึกษา มหาวิทยาลัย และองค์กรไม่แสวงหากำไรทั่วโลก (BleepingComputer)

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

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

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

ทำงานยังไง

เพื่อให้เข้าใจกลไกของปัญหานี้ ผมขอยกตัวอย่างเปรียบเทียบกับภาพที่เห็นได้ง่ายอย่าง อาคารสำนักงานขนาดใหญ่ ครับ

ลองจินตนาการว่า Drupal Core คือตัวอาคารหลักที่มีระบบรักษาความปลอดภัยแน่นหนา ประตูหน้ามีเจ้าหน้าที่รักษาความปลอดภัยตรวจบัตรอย่างเข้มงวด ใครจะเดินเข้าไปยังห้องเครื่องส่วนกลาง (Server) ได้ ต้องผ่านการยืนยันตัวตนอย่างถูกต้อง แต่ในอาคารแห่งนี้ มีบางแผนกที่ไปว่าจ้างผู้รับเหมาภายนอกมาต่อเติมห้องทำงานและสร้างประตูบานเล็กๆ เสริมไว้ด้านข้าง (เปรียบเหมือน Contributed Modules หรือโมดูลเสริมต่างๆ ที่เจ้าของเว็บติดตั้งเพิ่มเติม)

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

ในเชิงเทคนิค ตามที่ระบุไว้ในประกาศเตือนภัย SA-CORE-2026-014 ช่องโหว่ CVE-2026-108097 ฝังตัวอยู่ในโมดูล Field UI ซึ่งเป็นโมดูลหลักของ Drupal สำหรับจัดการโครงสร้างฟิลด์ข้อมูลและการแสดงผล ตัวโค้ดส่วนนี้ลำพังเพียงตัวมันเอง (Drupal core alone) ไม่สามารถถูกโจมตีได้โดยตรงจากภายนอก

ทว่า เมื่อมีการนำไปใช้งานร่วมกับโมดูลเสริมภายนอก (Contributed Modules) จะเกิดเส้นทางการโจมตีที่รุนแรงหลายรูปแบบ โดยที่สำคัญที่สุดคือ มีอย่างน้อยหนึ่งเส้นทางที่พบแล้วว่า ผู้โจมตีไม่จำเป็นต้องมีการล็อกอินหรือผ่านการยืนยันตัวตนใดๆ เลย (Unauthenticated RCE) นอกจากนี้ การเขียนโค้ดปรับแต่งเฉพาะ (Custom Code) ของแต่ละเว็บไซต์ก็อาจเปิดช่องให้ฟังก์ชันที่มีปัญหานี้ถูกเรียกใช้งานได้เช่นเดียวกัน (SA-CORE-2026-014, BleepingComputer)

ทาง The Hacker News ได้อธิบายรายละเอียดการทำงานว่า โมดูล Field UI สร้างตารางจัดการข้อมูลผ่านโครงสร้างอาร์เรย์ของภาษา PHP ที่ใช้แปลงเป็นหน้าเว็บ HTML ก่อนที่จะมีการแก้ไข โค้ดในขั้นตอนก่อนแสดงผลตารางได้เปิดให้มีการประมวลผลฟังก์ชันเรียกกลับ (Callback) ที่แนบมากับแถวของตารางโดยตรง โดยไม่มีการตรวจสอบอย่างรัดกุมว่าฟังก์ชันนั้นเป็นคำสั่งที่ปลอดภัยหรือไม่ แม้ว่าระบบแสดงผลของ Drupal จะมีกลไกปฏิเสธการรันคำสั่งที่ไม่น่าเชื่อถือมาตั้งแต่เวอร์ชัน 8.8 ในปี 2019 แต่เนื่องจากระบบมองว่าตารางนี้เป็นส่วนประกอบภายในที่เชื่อถือได้ กลไกการตรวจสอบเดิมจึงถูกข้ามไป และโค้ดลักษณะนี้มีอยู่ในระบบมาตั้งแต่ Drupal 8.9.0 เมื่อปี 2020 แล้ว (The Hacker News)

ในส่วนของช่องโหว่ตัวที่สองคือ CVE-2026-108099 บนโมดูล Entity List ซึ่งเป็นโมดูลเสริมสำหรับสร้างรายการข้อมูลเอนทิตีโดยไม่ผ่าน Views ก็มีลักษณะการทำงานและข้อบกพร่องที่คล้ายคลึงกัน โดยมีเส้นทางการโจมตีที่ผู้ไม่หวังดีไม่ต้องล็อกอินเข้าสู่ระบบเช่นกัน (BleepingComputer, The Hacker News)

จุดหักมุม

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

หลายคนอาจเข้าใจผิดว่า หากแกนหลักของระบบไม่สามารถถูกโจมตีแบบเดี่ยวๆ ได้ เว็บไซต์ก็น่าจะยังปลอดภัย แต่ความจริงในโลกการพัฒนาเว็บนั้น แทบไม่มีเว็บไซต์ไหนเลยที่ติดตั้งเฉพาะแกนหลักโดยไม่ลงโมดูลเสริมหรือเขียนโค้ดเพิ่มเติม ยิ่งไปกว่านั้น โมดูล Field UI ยังเป็นโมดูลที่ถูกเปิดใช้งานโดยอัตโนมัติตั้งแต่เริ่มต้น ผ่านรูปแบบการติดตั้งแบบมาตรฐาน (Standard install profile) ของ Drupal (The Hacker News) นั่นแปลว่า เว็บไซต์ส่วนใหญ่ติดตั้งส่วนประกอบที่มีความเสี่ยงนี้ทิ้งไว้ในระบบตั้งแต่แรกสร้างเว็บ

จุดหักมุมนี้กลายเป็นกับดักสำคัญ เพราะเมื่อมีโมดูลเสริมหรือโค้ดปรับแต่งเปิดทางให้เข้าถึงได้ ผู้โจมตีก็สามารถกระตุ้นข้อบกพร่องในแกนหลักได้ทันทีโดยไม่ต้องล็อกอิน และการกดอัปเดตเฉพาะแกนหลักของ Drupal ก็ไม่ได้ครอบคลุมไปถึงการแก้ไขโมดูล Entity List ผู้ดูแลระบบจำเป็นต้องอัปเดตโมดูลเสริมแยกต่างหาก (BleepingComputer, The Hacker News) หากอัปเดตไม่ครบทุกจุด ประตูลับก็ยังคงเปิดทิ้งไว้ให้ผู้ไม่หวังดีบุกรุกเข้ามาได้อยู่ดีครับ

เรื่องเงิน

ในมุมของงบประมาณและค่าใช้จ่าย การจัดการกับช่องโหว่ความปลอดภัยระดับวิกฤตเช่นนี้มักสร้างภาระทางการเงินที่องค์กรไม่ได้ตั้งรับไว้ล่วงหน้า

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

นอกจากนี้ ทั้ง Drupal 11.3.x และ 10.6.x เองก็จะสิ้นสุดระยะเวลาการดูแลความปลอดภัย (Lose security coverage) ในเดือนธันวาคม 2026 นี้เช่นกัน (The Hacker News) นั่นแปลว่า องค์กรที่เพิ่งอัปเดตแพตช์เฉพาะหน้าในรอบนี้ จำเป็นต้องเตรียมงบประมาณล่วงหน้าสำหรับโครงการอัปเกรดระบบไปยังเวอร์ชันที่สูงกว่าอย่าง 11.4 ขึ้นไปทันทีในอีกไม่กี่เดือนข้างหน้า

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

ผลกระทบ

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

จากข้อมูลสถิติที่รายงานต่อ drupal.org ในช่วงสัปดาห์เริ่มต้นวันที่ 4 ตุลาคม 2026 พบว่า มีเว็บไซต์จำนวนถึง 151,442 แห่ง จากทั้งหมด 531,499 แห่งที่รายงานเวอร์ชันเข้ามา (คิดเป็นสัดส่วนสูงถึง 28.5%) ที่ใช้งาน Drupal สาขาที่ได้รับผลกระทบจากช่องโหว่นี้ แต่กลับเป็นเวอร์ชันที่ ไม่ได้รับแพตช์แก้ไขความปลอดภัย เนื่องจากระบบหมดอายุการสนับสนุน (End-of-Life) ไปแล้ว (The Hacker News)

กลุ่มเวอร์ชันที่ไม่ได้รับแพตช์แก้ไขความปลอดภัย ได้แก่:

• Drupal เวอร์ชัน 11.2.x และรุ่นที่ต่ำกว่าทั้งหมด
• Drupal เวอร์ชัน 10.5.x และรุ่นที่ต่ำกว่าทั้งหมด
• Drupal เวอร์ชัน 8 และ Drupal เวอร์ชัน 9 ทั้งหมด (SA-CORE-2026-014, BleepingComputer)

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

ในส่วนของโมดูล Entity List แม้ว่าจะมีรายงานผู้ใช้งานบนหน้าเว็บ drupal.org ในสัปดาห์ตั้งแต่วันที่ 4 ตุลาคม 2026 เพียง 90 แห่ง แต่หากเว็บไซต์เหล่านั้นเป็นเว็บขององค์กรขนาดใหญ่หรือหน่วยงานสำคัญ ความเสียหายจากการถูกรันโค้ดระยะไกลย่อมมีความรุนแรงไม่แพ้กัน (The Hacker News)

นอกจากช่องโหว่ RCE สองตัวนี้แล้ว ในการอัปเดตรอบเดียวกันนี้ Drupal ยังได้แก้ไขช่องโหว่ประเภท Cross-Site Scripting (XSS) ระดับปานกลาง (Moderately critical) อีก 2 จุด ได้แก่ ช่องโหว่บน Link module (CVE-2026-108515) และ Navigation module (CVE-2026-108514) ซึ่งการจะโจมตีช่องโหว่สองตัวหลังนี้ได้ ผู้โจมตีต้องล็อกอินเข้าสู่ระบบก่อนอย่างน้อยหนึ่งระดับ (The Hacker News)

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

ในการติดตามสถานการณ์ด้านความปลอดภัย มีประเด็นสำคัญที่ควรพิจารณาข้อเท็จจริงอย่างรอบคอบดังนี้ครับ:

1. รายชื่อโมดูลเสริมภายนอกที่เปิดช่องโหว่: ในประกาศเตือนภัยของ Drupal (SA-CORE-2026-014) ไม่ได้ระบุรายชื่อโมดูลเสริมภายนอกทั้งหมดที่สามารถถูกใช้เปิดทางเจาะระบบได้ ระบุไว้เพียงว่ามีหลายเส้นทางและมีอย่างน้อยหนึ่งเส้นทางที่ไม่ต้องล็อกอิน ผู้ดูแลระบบจึงไม่สามารถตรวจสอบความปลอดภัยโดยอิงจากชื่อโมดูลได้ ยกเว้นโมดูล Entity List ที่มีประกาศแยกออกมาต่างหาก (BleepingComputer, The Hacker News)
2. สถานะการโจมตีจริง: ตามข้อมูลในประกาศเตือนภัยระบุว่า ในช่วงเวลาที่เผยแพร่แพตช์ยังไม่มีโค้ดโจมตีถูกปล่อยสู่สาธารณะ และจนถึงวันที่ 15 ตุลาคม 2026 ก็ยังไม่มีรายงานการโจมตีจริงเกิดขึ้นในวงกว้าง (The Hacker News) อย่างไรก็ดี ทีมความปลอดภัยเตือนว่าแฮกเกอร์อาจพัฒนาเครื่องมือเจาะระบบได้ในเวลาไม่กี่ชั่วโมงหรือหลักวัน
3. การสนับสนุนสำหรับ Drupal 7: ตามข้อมูลทางการของ drupal.org ระบุว่า Drupal 7 สิ้นสุดระยะเวลาสนับสนุน (EOL) ไปแล้วตั้งแต่เดือนมกราคม 2025 แต่บริษัท Pantheon ร่วมกับ Tag1 Consulting ได้ปล่อยแพตช์พิเศษ Drupal 7.107 ออกมาเพื่อดูแลลูกค้าระยะยาว (Long-term support) ของตนเองโดยเฉพาะ (The Hacker News) ซึ่งไม่ใช่แพตช์สาธารณะจากทีมงานหลักของ Drupal
4. ผลกระทบเฉพาะเจาะจงในแต่ละประเทศ: แหล่งข่าวทั้งหมดไม่ได้ระบุสถิติแยกตามรายประเทศ รายงานเพียงภาพรวมว่าเว็บไซต์มากกว่า 1 ล้านแห่งทั่วโลกใช้งาน Drupal โดยเน้นไปที่หน่วยงานรัฐ มหาวิทยาลัย และองค์กรไม่แสวงหากำไร (BleepingComputer)

แล้วเราควรทำอะไร

เพื่อป้องกันความเสี่ยงอย่างเป็นรูปธรรม ผมขอแบ่งแนวทางปฏิบัติออกเป็น 3 กลุ่มตามบทบาทหน้าที่ดังนี้ครับ:

สำหรับประชาชนและผู้ใช้งานทั่วไป

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

1. สังเกตความผิดปกติของหน้าเว็บ: หากเข้าใช้งานเว็บไซต์หน่วยงานรัฐหรือสถาบันการศึกษา แล้วพบการเปลี่ยนเส้นทาง (Redirect) ไปยังหน้าเว็บที่ไม่คุ้นเคย หรือมีข้อความแจ้งเตือนแปลกๆ ให้ปิดหน้าต่างนั้นทันที
2. ไม่กรอกรหัสผ่านซ้ำบนหน้าที่ดูน่าสงสัย: หากพบหน้าล็อกอินที่มีลักษณะเปลี่ยนไปจากเดิม หรือขอข้อมูลส่วนบุคคลมากผิดปกติ ให้ระงับการกรอกข้อมูลไว้ก่อน และติดต่อสอบถามหน่วยงานผ่านช่องทางที่เป็นทางการ
3. เปิดใช้งานการยืนยันตัวตนสองขั้นตอน (2FA): ในทุกบริการที่รองรับ เพื่อช่วยป้องกันบัญชีของคุณหากรหัสผ่านรั่วไหล

สำหรับเจ้าของเว็บไซต์ ผู้ดูแลระบบไอที และหน่วยงานต่างๆ

หากเว็บไซต์ขององค์กรคุณสร้างขึ้นด้วยระบบ Drupal นี่คือสิ่งที่ต้องเร่งดำเนินการ:

1. ตรวจสอบเวอร์ชันของระบบทันที: สำรวจว่าเว็บไซต์กำลังรันอยู่บนเวอร์ชันใดของ Drupal Core และมีการติดตั้งโมดูล Entity List หรือไม่
2. อัปเดตแพตช์ไปยังเวอร์ชันปลอดภัย:
   • หากใช้ Drupal 11.4.x ให้อัปเดตเป็น 11.4.10
   • หากใช้ Drupal 11.3.x ให้อัปเดตเป็น 11.3.19
   • หากใช้ Drupal 10.6.x ให้อัปเดตเป็น 10.6.19 (SA-CORE-2026-014)
   • หากใช้เวอร์ชันทดสอบ Drupal 12 ให้ปรับเป็น 12.0.0-beta2 (The Hacker News)
   • หากมีการใช้งานโมดูล Entity List ให้อัปเดตเป็นเวอร์ชัน 3.0.10 ทันที (BleepingComputer)
3. ใช้มาตรการบรรเทาผลกระทบหากยังอัปเดตไม่ได้: หากระบบยังไม่พร้อมสำหรับการอัปเดตโค้ดอย่างสมบูรณ์ คำแนะนำอย่างเป็นทางการระบุให้ทำการ ถอนการติดตั้งโมดูล Field UI (field_ui) ออกเป็นการชั่วคราว (SA-CORE-2026-014) ซึ่งจะช่วยป้องกันช่องโหว่นี้ได้ในระหว่างเตรียมการ แม้ว่าจะทำให้หน้าจัดการฟิลด์และการแสดงผลไม่สามารถเข้าถึงได้ชั่วคราวก็ตาม (The Hacker News)
4. อย่าพึ่งพา WAF เพียงอย่างเดียว: สำหรับผู้ที่ใช้บริการไฟร์วอลล์อย่าง Drupal Steward แม้ระบบจะช่วยสกัดกั้นเส้นทางการโจมตีที่รู้จักได้บางส่วน แต่ทีมงานยืนยันว่าไม่ครอบคลุมทุกช่องทาง จึงไม่สามารถใช้แทนการอัปเดตระบบได้ (SA-CORE-2026-014)
5. ประสานงานกับผู้รับเหมาหรือผู้พัฒนา: หากเว็บไซต์ว่าจ้างบริษัทภายนอกเป็นผู้ดูแล ให้รีบสอบถามความคืบหน้าในการอัปเดตระบบไปยังเวอร์ชันที่ปลอดภัยโดยเร็ว

สำหรับนักพัฒนาเว็บไซต์ (Developers)

1. ตรวจสอบโค้ดปรับแต่งเฉพาะ (Custom Code): ทบทวนโค้ดส่วนขยายที่มีการโต้ตอบกับตารางของ Field UI โดยเฉพาะโค้ดที่มีการเรียกใช้ฟังก์ชันเรียกกลับของแถวตาราง เนื่องจากโค้ดเวอร์ชันใหม่จะยกเลิกการเรียกใช้คำสั่งเหล่านี้ และอาจส่งผลกระทบต่อการทำงานเดิมได้ (The Hacker News)
2. ทดสอบระบบอย่างละเอียดหลังอัปเดต: ให้เข้าไปตรวจสอบหน้าจัดการฟิลด์ (Manage fields) และหน้าจัดการแสดงผล (Manage display) เพื่อยืนยันว่าการทำงานของระบบยังคงเป็นปกติ (The Hacker News)
3. ติดตามแนวทางการตรวจจับความผิดปกติ: ผู้ดูแลระบบควรติดตามข้อมูลสัญญาณบ่งชี้ความผิดปกติ (IOCs) จากหน้าประกาศทางการของผู้พัฒนาอย่างต่อเนื่อง

ผมมองว่า…

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

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

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

ปิดท้าย: สิ่งที่ต้องจับตา

หลังจากนี้ มี 2 ประเด็นหลักที่ทีมงานความปลอดภัยและผู้ดูแลเว็บไซต์ต้องเฝ้าระวังอย่างใกล้ชิด:

• การปรากฏของโค้ดโจมตี (Exploit): ในอดีตเมื่อเดือนพฤษภาคม Drupal เคยมีกรณีช่องโหว่ SQL Injection บน PostgreSQL ที่พบความพยายามโจมตีหลังจากออกประกาศเพียง 2 วัน จนกระทั่งหน่วยงาน CISA ต้องบรรจุเข้าสู่บัญชีรายการช่องโหว่ที่ถูกโจมตีจริง (The Hacker News) ในครั้งนี้จึงต้องจับตาดูว่าจะมีผู้พัฒนาโค้ดโจมตีออกมาเผยแพร่ในลักษณะเดียวกันหรือไม่
• การหมดอายุของเวอร์ชัน 10.6 และ 11.3: ทั้งสองเวอร์ชันนี้จะสิ้นสุดการดูแลความปลอดภัยในเดือนธันวาคม 2026 (The Hacker News) ผู้ดูแลระบบที่ติดตั้งแพตช์ในรอบนี้จึงต้องเริ่มวางแผนอัปเกรดระบบข้ามสายการพัฒนาล่วงหน้า เพื่อไม่ให้เกิดภาวะขาดการสนับสนุนความปลอดภัยในช่วงสิ้นปีครับ

Recap

• เช็กว่าเว็บของคุณใช้ Drupal เวอร์ชันไหน ถ้าอยู่ในช่วง 8.9.0 ขึ้นไปและต่ำกว่าเวอร์ชันแก้ไข ถือว่าโดน CVE-2026-108097 (ความเสี่ยง Critical 19/25)
• ถ้าใช้โมดูล Entity List ให้อัปเดตเป็น 3.0.10 แยกต่างหาก (CVE-2026-108099)
• ไล่ดูโมดูลเสริมและโค้ดที่เขียนเอง เพราะ core อย่างเดียวโจมตีตรงๆ ไม่ได้ แต่มีเส้นทางผ่านโมดูลเสริมอย่างน้อยหนึ่งทางที่ไม่ต้องล็อกอิน
• อัปเดตเป็น Drupal 11.4.10, 11.3.19 หรือ 10.6.19 ตามสายที่ใช้อยู่
• ถ้ายังอยู่บน 11.2 ลงไป, 10.5 ลงไป, Drupal 8 หรือ 9 วางแผนย้ายขึ้นสายที่ยังได้รับแพตช์ เพราะสายเหล่านี้หมดอายุแล้ว
• ถ้ายังอัปเดตไม่ได้ ถอนการติดตั้งโมดูล Field UI (field_ui) ไว้ก่อนชั่วคราว
• ใช้ Drupal Steward อยู่ก็ยังต้องลงแพตช์ เพราะมันกันได้แค่บางเส้นทาง
• ผู้ใช้ทั่วไป: ถ้าเว็บที่ใช้ประจำมีหน้าตาหรือพฤติกรรมแปลกไป อย่ากรอกข้อมูล ให้แจ้งหน่วยงานนั้น