ประตูตู้นิรภัยเหล็กที่มีรูกุญแจทองเหลืองสามรู รอยร้าวสีอำพันแผ่ออกจากทุกรู แผ่นปะสีเขียวยึดน็อตไว้บนประตู และปฏิทินกระดาษเก่าแขวนอยู่ข้าง ๆ
newssecuritymariadbdatabasepatchcve

NVD ประกาศ 7 ช่องโหว่ MariaDB คะแนนพุ่ง 9.9 แต่แพตช์เงียบปล่อยมาแล้วตั้งแต่สิงหาคม

น้องกายEngineering

เมื่อวันศุกร์ที่ 16 ตุลาคม 2026 ฐานข้อมูลช่องโหว่ความปลอดภัยระดับชาติของสหรัฐฯ หรือ NVD ได้เผยแพร่รายการช่องโหว่ความปลอดภัยของระบบฐานข้อมูล MariaDB Server พร้อมกันถึง 7 รายการ โดยในจำนวนนี้มีถึง 3 รายการที่ได้รับคะแนนความรุนแรงตามเกณฑ์มาตรฐาน CVSS 3.1 สูงถึง 9.9 คะแนน ซึ่งถือเป็นระดับวิกฤต (Critical) เกือบแตะเพดานสูงสุดที่ 10.0 คะแนนเต็ม (Severity Daily)

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

แต่สิ่งที่กลายเป็นประเด็นสำคัญที่น่าตกใจยิ่งกว่าตัวเลขคะแนน 9.9 คือโค้ดเวอร์ชันที่ได้รับการแก้ไขเพื่ออุดช่องโหว่เหล่านี้ ทางโครงการ MariaDB ได้ปล่อยตัวอัปเดตออกมาให้ดาวน์โหลดกันเรียบร้อยแล้วตั้งแต่ช่วงเดือนสิงหาคมและกันยายน 2026 ที่ผ่านมา (Severity Daily) ทว่าในเอกสารประกาศการอัปเดตรอบดังกล่าว กลับไม่มีการระบุเตือนหรือพูดถึงประเด็นด้านความปลอดภัยเลยแม้แต่น้อย เพิ่งจะมีการเผยแพร่รหัสช่องโหว่และคะแนนความรุนแรงอย่างเป็นทางการใน NVD จนทำให้ระบบสแกนความปลอดภัยทั่วโลกตรวจพบเมื่อวันศุกร์ที่ผ่านมานี่เองครับ

สรุป 30 วินาที

เมื่อช่วงบ่ายวันศุกร์ที่ 16 ตุลาคม 2026 เวลา 17:17 น. ตามเวลาสากล UTC ซึ่งตรงกับเวลา 00:17 น. คืนเข้าสู่วันเสาร์ที่ 17 ตุลาคม ตามเวลาประเทศไทย ฐานข้อมูล NVD ได้เปิดเผยบันทึกรายการช่องโหว่ความปลอดภัยชุดใหม่ของ MariaDB Server จำนวน 7 รายการพร้อมกัน (Severity Daily)

ในบรรดารายการที่ประกาศออกมา มีช่องโหว่ระดับวิกฤตคะแนน CVSS 3.1 สูงถึง 9.9 อยู่จำนวน 3 ตัว ได้แก่:

  1. CVE-2026-85746: บั๊กการเขียนข้อมูลเกินพื้นที่บัฟเฟอร์หน่วยความจำที่จัดสรรไว้ (Out-of-bounds Write) ในฟังก์ชันจัดการข้อมูลพิกัดภูมิศาสตร์ ST_AsText เมื่อประมวลผลข้อมูลเรขาคณิตแบบซ้อนกันหลายชั้น (CVE-2026-85746 Record)
  2. CVE-2026-85748: บั๊กการจัดการหน่วยความจำที่คืนพื้นที่ไปแล้ว (Use-after-free) ในตัวแปรเคอร์เซอร์ SYS_REFCURSOR ซึ่งส่งผลกระทบเฉพาะเวอร์ชันในสาย 12.3 และ 13.0 เท่านั้น (CVE-2026-85748 Record)
  3. CVE-2026-92262: บั๊กการข้ามขั้นตอนเข้ารหัสชื่อไฟล์ตารางของระบบไฟล์ผ่านคำนำหน้าแบบดั้งเดิม #mysql50# ทำให้อาจเข้าถึงไฟล์ระบบเก่าและนำไปสู่ความเสียหายต่อระบบได้ (CVE-2026-92262 Record)

เงื่อนไขสำคัญคือ ผู้โจมตีจำเป็นต้องมีสิทธิ์ล็อกอินเข้าสู่ระบบฐานข้อมูลด้วยบัญชีผู้ใช้ระดับสิทธิ์ต่ำ (Low Privileges) จึงทำให้คะแนนหยุดอยู่ที่ 9.9 ไม่ถึง 10.0 เต็ม แต่คะแนนพุ่งสูงเพราะมีการข้ามขอบเขตความปลอดภัย (Scope Changed) ออกไปนอกระบบฐานข้อมูล (Severity Daily) อย่างไรก็ตาม แพตช์ที่แก้ไขช่องโหว่เหล่านี้ถูกรวมอยู่ในรุ่นอัปเดตบำรุงรักษาปกติ ได้แก่ 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3 และ 13.0.2 ซึ่งทยอยปล่อยออกมาตั้งแต่เดือนสิงหาคมและกันยายน 2026 เรียบร้อยแล้ว โดยหน้าเอกสารทางการของ MariaDB มีการระบุหมายเหตุไว้ว่า รหัส CVE อาจถูกนำมาเพิ่มย้อนหลังให้กับเวอร์ชันที่เผยแพร่ไปแล้วได้ตามกระบวนการของหน่วยงานผู้ออกรหัส (MariaDB Documentation)

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

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

กลุ่มผู้ที่มีความเกี่ยวข้องและจำเป็นต้องตรวจสอบระบบของตนเอง ได้แก่:

  • เจ้าของเว็บไซต์และธุรกิจขนาดเล็ก (SMEs): โดยเฉพาะธุรกิจที่เช่าบริการเว็บโฮสติงแบบใช้ทรัพยากรร่วมกัน (Shared Hosting) หรือระบบคลาวด์แบบใช้งานร่วมกันหลายผู้เช่า (Multi-tenant) เนื่องจากในสภาพแวดล้อมลักษณะนี้ ผู้เช่าหรือผู้ใช้งานรายอื่นอาจมีสิทธิ์ล็อกอินเข้าสู่ระบบฐานข้อมูลบนเครื่องเดียวกันอยู่แล้ว ซึ่งสอดคล้องกับเงื่อนไขการโจมตีของช่องโหว่ระดับ 9.9 เหล่านี้อย่างพอดิบพอดี (Orbitaley)
  • นักพัฒนาซอฟต์แวร์และผู้ดูแลระบบ (DevOps & SysAdmins): ระบบที่เคยสร้างบัญชีฐานข้อมูลเอาไว้สำหรับแอปพลิเคชัน บัญชีบริการหลังบ้าน หรือบัญชีทดสอบ หากข้อมูลประจำตัว (Credentials) เกิดรั่วไหล หรือไม่มีการหมุนเวียนรหัสผ่าน ผู้ไม่หวังดีอาจใช้บัญชีระดับล่างดังกล่าวเป็นบันไดในการยกระดับหรือสร้างผลกระทบต่อเซิร์ฟเวอร์ทั้งเครื่องได้
  • ผู้ใช้งานระบบที่ยังคงใช้ MariaDB ในสาย 10.6: กิ่ง 10.6 นี้ได้สิ้นสุดระยะเวลาการสนับสนุนอย่างเป็นทางการ (End of Life หรือ EOL) ไปแล้วตั้งแต่วันที่ 6 กรกฎาคม 2026 โดยมีเวอร์ชัน 10.6.28 เป็นอัปเดตรุ่นสุดท้ายจริง ๆ หากองค์กรใดยังไม่ได้อัปเกรดเป็นเวอร์ชันดังกล่าว ระบบของคุณจะไม่ได้รับการแก้ไขและจะคงค้างอยู่กับช่องโหว่นี้ไปตลอดครับ (Severity Daily)

ทำงานยังไง

เพื่อให้เข้าใจสถานการณ์และธรรมชาติของปัญหาในครั้งนี้ น้องกายขอเปรียบเทียบกับภาพในชีวิตประจำวันง่าย ๆ ครับ

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

ในเชิงเทคนิค กลไกของช่องโหว่ระดับวิกฤต 9.9 ทั้ง 3 รายการมีรายละเอียดดังต่อไปนี้:

1. บั๊กเขียนข้อมูลทะลุบัฟเฟอร์ในฟังก์ชันพิกัดเชิงพื้นที่ (CVE-2026-85746)

ช่องโหว่นี้เกิดขึ้นกับฟังก์ชัน ST_AsText ซึ่งทำหน้าที่แปลงข้อมูลพิกัดเชิงพื้นที่ (GIS) ให้ออกมาเป็นรูปแบบข้อความ Well-Known Text (WKT) แต่เมื่อระบบต้องประมวลผลข้อมูลโครงสร้างแบบซ้อนกันลึก ๆ (Deeply nested GeometryCollections) กระบวนการแปลงข้อมูลแบบเรียกซ้ำ (Recursive) ไม่ได้คำนวณจำนวนไบต์ที่ใช้จริงอย่างถูกต้อง และไม่ได้กันพื้นที่บัฟเฟอร์หน่วยความจำสำหรับผลลัพธ์ไว้อย่างเพียงพอ ทำให้เกิดข้อผิดพลาดในการเขียนข้อมูลเกินขอบเขตบัฟเฟอร์ (Out-of-bounds Write / CWE-787) ผู้โจมตีที่มีสิทธิ์เข้าสู่ระบบฐานข้อมูลระดับต่ำสามารถส่งอ็อบเจกต์พิกัดที่ถูกสร้างขึ้นเป็นพิเศษ เพื่อทำให้หน่วยความจำเสียหาย เซิร์ฟเวอร์หยุดทำงานหรือล่ม และอาจนำไปสู่การรันโค้ดแปลกปลอมได้หากถูกนำไปประกอบร่วมกับช่องโหว่อื่น (CVE-2026-85746 Record)

2. บั๊กหน่วยความจำค้างในระบบเคอร์เซอร์ (CVE-2026-85748)

ปัญหานี้เกิดขึ้นเฉพาะกับ MariaDB ในสายเวอร์ชัน 12.3 และ 13.0 เท่านั้น โดยเกี่ยวข้องกับกลไกการจัดการตัวแปรเคอร์เซอร์ SYS_REFCURSOR เมื่อระบบทำการจัดสรรพื้นที่หน่วยความจำสำหรับอาร์เรย์เคอร์เซอร์ใหม่ (Cursor-array reallocation) กลับทิ้งจุดอ้างอิงที่เลิกใช้งานแล้วตกค้างไว้ในบริบทของรูทีน ส่งผลให้เกิดภาวะการใช้งานหน่วยความจำหลังจากคืนพื้นที่ไปแล้ว (Use-after-free / CWE-416) ผู้โจมตีที่มีสิทธิ์ล็อกอินระดับต่ำสามารถเปิดตัวแปรเคอร์เซอร์จำนวนมาก แล้วสั่งดึงข้อมูลตัวหนึ่งขึ้นมาเพื่อกระตุ้นข้อผิดพลาดนี้ ซึ่งหากนำไปผสานร่วมกับช่องโหว่อื่น ก็อาจเปิดทางให้เกิดการรันโค้ดจากระยะไกลได้เช่นกัน (CVE-2026-85748 Record)

3. บั๊กการข้ามการแปลงรหัสชื่อไฟล์ตารางด้วยคำนำหน้ายุคเก่า (CVE-2026-92262)

ตามกลไกปกติ MariaDB จะต้องมีการแปลงรหัสชื่อตารางในฐานข้อมูลก่อนที่จะนำไปเชื่อมโยงกับชื่อไฟล์จริงบนระบบไฟล์ของระบบปฏิบัติการ แต่ระบบยังคงมีคำนำหน้ารองรับความเข้ากันได้แบบดั้งเดิมคือ #mysql50# ซึ่งทำให้ตัวจัดการชื่อตารางมองข้ามขั้นตอนการแปลงรหัสชื่อไฟล์ตามระบบไฟล์ปกติไป (CWE-706) ผู้โจมตีที่มีสิทธิ์ในระบบสามารถระบุชื่อตารางโดยใช้คำนำหน้าดังกล่าวเพื่อเข้าถึงไฟล์ภายใต้ชื่อเดิมที่ไม่ได้ผ่านการเข้ารหัส ส่งผลให้เซิร์ฟเวอร์หยุดทำงาน ข้อมูลเสียหาย เกิดการรั่วไหลของข้อมูล หรืออาจนำไปสู่การรันโค้ดสั่งการจากระยะไกลได้ครับ (CVE-2026-92262 Record)

นอกจากช่องโหว่ระดับวิกฤต 3 รายการข้างต้นแล้ว ยังมีช่องโหว่อีก 4 รายการที่ประกาศออกมาพร้อมกันในวันเดียวกัน โดยมีคะแนนความรุนแรงลดหลั่นกันลงมา ได้แก่:

  • CVE-2026-97380 (คะแนน 8.8): บั๊กคำสั่ง GRANT PROXY ร่วมกับรหัสผ่านที่เว้นว่าง มีการตรวจสอบสิทธิ์ของผู้มอบอำนาจผิดคน (Severity Daily)
  • CVE-2026-86047 (คะแนน 7.7): ปัญหาการไม่ใส่เครื่องหมายคำพูดครอบตัวระบุชื่ออย่างสม่ำเสมอในคำสั่ง SHOW CREATE USER และยูทิลิตี mariadb-dump (Severity Daily)
  • CVE-2026-85985 (คะแนน 5.4): ฟังก์ชันการจัดการไฟล์ของกลไกจัดเก็บข้อมูล CONNECT ข้ามการตรวจสอบการตั้งค่าความปลอดภัย secure_file_priv (Severity Daily)
  • CVE-2026-85745 (คะแนน 4.3): บั๊กการอ่านข้อมูลเกินขอบเขตบัฟเฟอร์ (Buffer Over-read) ในฟังก์ชัน ST_Area (Severity Daily)

จุดหักมุม

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

รายงานเชิงลึกจาก Severity Daily ได้เปิดเผยลำดับเหตุการณ์ว่า ปัญหาของช่องโหว่ ST_AsText ถูกรายงานพร้อมโค้ดทดสอบจำลองบั๊ก (Reproducer) บนระบบติดตามงานสาธารณะ MariaDB Jira ในหมายเลขตั๋ว MDEV-40329 ตั้งแต่วันที่ 9 กรกฎาคม 2026 ซึ่งใครก็ตามสามารถเปิดเข้าไปอ่านเนื้อหาได้โดยไม่ต้องล็อกอิน และได้รับการแก้ไขในโค้ดเสร็จสิ้นไปตั้งแต่วันที่ 22 กรกฎาคม 2026 (Severity Daily)

ต่อมาในวันที่ 13 สิงหาคม 2026 ทางโครงการได้ปล่อยเวอร์ชัน 10.6.28 ออกมา และในวันที่ 24 สิงหาคม 2026 ก็ได้ปล่อยเวอร์ชัน 10.11.19, 11.4.13, 11.8.9 และ 12.3.3 ออกมาพร้อม ๆ กันในเวลาไล่เลี่ยกันไม่กี่นาที ตามมาด้วยเวอร์ชัน 13.0.2 เมื่อวันที่ 15 กันยายน 2026 (Severity Daily) ทว่าในประกาศการเปิดตัวเวอร์ชันบำรุงรักษาประจำไตรมาส 3 ดังกล่าว กลับไม่มีการระบุรหัส CVE หรือกล่าวถึงการแก้ปัญหาช่องโหว่ความปลอดภัยใด ๆ เลย

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

เรื่องเงิน

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

ประการแรกคือ ต้นทุนจากความเสี่ยงของการหยุดชะงักของระบบ (Downtime): ตั๋วงานที่เกี่ยวข้องในระบบของ MariaDB อย่าง MDEV-40329 ถูกจัดระดับความสำคัญไว้สูงสุดในระดับ “Blocker” โดยระบุผลกระทบว่าสามารถทำให้เซิร์ฟเวอร์ค้างหรือล่มได้ทันที (Orbitaley) หากระบบฐานข้อมูลของธุรกิจที่ต้องรองรับธุรกรรมแบบเรียลไทม์ เช่น ร้านค้าออนไลน์หรือระบบการเงิน เกิดข้อผิดพลาดจนเซิร์ฟเวอร์หยุดทำงาน ย่อมทำให้สูญเสียรายได้ทันทีในทุกนาทีที่ระบบใช้งานไม่ได้

ประการที่สองคือ ต้นทุนด้านแรงงานและการบริหารจัดการของทีมไอที: การที่รหัส CVE ระดับวิกฤต 9.9 เพิ่งปรากฏบนฐานข้อมูล NVD ทำให้ระบบตรวจสอบความปลอดภัยของหลายองค์กรแจ้งเตือนข้อผิดพลาดระดับร้ายแรงพร้อมกัน ทีมงานไอทีและฝ่ายความปลอดภัยต้องเร่งระดมกำลังเพื่อตรวจสอบรายการเซิร์ฟเวอร์ทั้งหมดในความดูแล หากพบว่าเครื่องใดยังไม่ได้อัปเกรดตามรอบสิงหาคม ก็จำเป็นต้องวางแผนขอเปิดหน้าต่างเวลาบำรุงรักษาฉุกเฉิน (Maintenance Window) เพื่อทำการอัปเกรด ซึ่งมีทั้งต้นทุนแรงงานนอกเวลาและความเสี่ยงต่อความพร้อมใช้งานของระบบที่ต้องหยุดให้บริการชั่วคราวครับ (Severity Daily)

ผลกระทบ

ผลกระทบทางเทคนิคและความปลอดภัยของระบบจากช่องโหว่ชุดนี้สามารถสรุปได้เป็น 3 ด้านหลัก:

  1. ความเสียหายของข้อมูลและการรั่วไหล (Data Corruption & Exfiltration): ช่องโหว่ CVE-2026-92262 ที่เกิดจากคำนำหน้า #mysql50# เปิดช่องให้ผู้โจมตีเข้าถึงไฟล์ระบบเก่าที่ไม่มีการแปลงรหัสชื่อไฟล์ ซึ่งสามารถนำไปสู่ความเสียหายของไฟล์ข้อมูล การขโมยข้อมูลสำคัญ หรือทำให้เซิร์ฟเวอร์หยุดทำงานอย่างกะทันหัน (CVE-2026-92262 Record)

  2. การล่มสลายของกระบวนการทำงานในหน่วยความจำ (Memory Corruption): ช่องโหว่ CVE-2026-85746 ทำให้เกิดการเขียนข้อมูลล้นพื้นที่บัฟเฟอร์ และช่องโหว่ CVE-2026-85748 ทำให้เกิดการอ้างอิงหน่วยความจำที่ถูกปลดปล่อยไปแล้ว ทั้งสองกรณีส่งผลโดยตรงต่อเสถียรภาพของกระบวนการทำงานของฐานข้อมูล ทำให้ระบบหยุดตอบสนองหรือแครชได้โดยตรง (CVE-2026-85746 Record, CVE-2026-85748 Record)

  3. ความเสี่ยงในสภาพแวดล้อมที่ใช้งานร่วมกัน (Multi-tenant Risks): เนื่องจากช่องโหว่เหล่านี้ต้องการเพียงสิทธิ์การใช้งานระดับต่ำ ทำให้ระบบโฮสติงที่มีผู้เช่าหลายรายใช้งานเครื่องแม่ข่ายฐานข้อมูลร่วมกันมีความเปราะบางเป็นพิเศษ เพราะผู้เช่ารายหนึ่งอาจใช้ช่องโหว่นี้เพื่อส่งผลกระทบต่อทรัพยากรส่วนกลางหรือผู้เช่ารายอื่นบนระบบเดียวกันได้ (Orbitaley)

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

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

  • สถานะคะแนน 9.9 ยังคงเป็นคะแนน Secondary: ข้อมูลจาก Severity Daily ยืนยันว่า คะแนน CVSS ทั้งหมดถูกประเมินโดย GitHub Security Advisory ในฐานะผู้ให้ข้อมูลรอง (Secondary) ขณะที่ทาง NVD ยังไม่ได้ทำการวิเคราะห์และให้คะแนนหลัก (Primary) อย่างเป็นทางการ โดยสถานะของช่องโหว่วิกฤตเหล่านี้ใน NVD ยังคงอยู่ในสถานะ “Awaiting Analysis” ดังนั้นตัวเลขคะแนนและเวกเตอร์อาจมีการเปลี่ยนแปลงได้หลังจากที่ NVD วิเคราะห์เสร็จสิ้น (Severity Daily)
  • ความเป็นไปได้ในการสั่งรันโค้ดควบคุมระบบ (RCE): ในเอกสารคำอธิบายทางการของทั้ง CVE-2026-85746 และ CVE-2026-85748 ระบุตรงกันว่า การจะนำช่องโหว่ไปใช้เพื่อสั่งรันโค้ดได้นั้น จำเป็นต้อง “นำไปใช้ร่วมกับช่องโหว่อื่นอีกช่องโหว่หนึ่ง” (when combined with another vulnerability) (CVE-2026-85746 Record, CVE-2026-85748 Record) นอกจากนี้ การประเมินตามกรอบ SSVC โดยผู้ประสานงานของหน่วยงาน CISA สำหรับช่องโหว่ 85746 ยังระบุว่า การถูกนำไปใช้ประโยชน์ (Exploitation) ยังอยู่ในระดับ “None” (ยังไม่มี) และไม่สามารถทำงานแบบอัตโนมัติได้ (Automatable: No) รวมถึงยังไม่มีช่องโหว่ใดในชุดนี้ถูกจัดอยู่ในแค็ตตาล็อก KEV ของ CISA จึงยังไม่มีหลักฐานการโจมตีจริงในปัจจุบัน (Severity Daily, Orbitaley)
  • ความไม่สอดคล้องของเวอร์ชันที่ได้รับผลกระทบใน CVE-2026-85748: ในบันทึกของ NVD และ cve.org ระบุว่าช่องโหว่นี้กระทบเฉพาะกิ่ง 12.3 และ 13.0 เท่านั้น (CVE-2026-85748 Record) แต่ในตั๋วงาน Jira หมายเลข MDEV-40396 กลับระบุรุ่นที่ทำการแก้ไขว่ามีเวอร์ชัน 13.1.1 และ 13.3.1 รวมอยู่ด้วย ซึ่งยังคงเป็นคำถามที่ไม่มีเอกสารอธิบายชัดเจนว่ากิ่ง 13.1 และ 13.3 ได้รับผลกระทบด้วยหรือไม่ (Severity Daily)
  • รายละเอียดในบันทึกการเปลี่ยนแปลง (Changelogs): แหล่งข่าว Severity Daily ระบุว่าไม่สามารถเข้าถึงหน้าบันทึกการเปลี่ยนแปลงรายเวอร์ชันได้ จึงไม่สามารถยืนยันได้ว่าภายในบันทึกย่อย ๆ มีการกล่าวถึงประเด็นความปลอดภัยไว้หรือไม่ แม้ว่าในหน้าประกาศเปิดตัวภาพรวมจะไม่มีการเอ่ยถึงเลยก็ตาม (Severity Daily)

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

เนื่องจากทาง MariaDB ไม่ได้มีการเผยแพร่วิธีการตั้งค่าเพื่อเลี่ยงปัญหาชั่วคราว (Workaround) แนวทางแก้ไขเดียวที่มีคือการอัปเกรดฐานข้อมูลไปยังเวอร์ชันที่ได้รับการแก้ไขแล้ว (Orbitaley) น้องกายขอแนะนำขั้นตอนปฏิบัติสำหรับแต่ละกลุ่มดังนี้ครับ:

สำหรับเจ้าของธุรกิจ และผู้ใช้งานทั่วไป (Non-tech / SMEs)

  1. สอบถามผู้ให้บริการโฮสติงหรือคลาวด์ของคุณทันที: ส่งข้อความหรือติดต่อฝ่ายบริการลูกค้าเพื่อสอบถามว่า เซิร์ฟเวอร์ฐานข้อมูล MariaDB ที่ใช้งานอยู่ได้รับการอัปเดตเป็นเวอร์ชันแพตช์ที่ออกตั้งแต่เดือนสิงหาคมหรือกันยายน 2026 หรือยัง
  2. ตรวจสอบสภาพแวดล้อมระบบ: หากใช้งานแชร์โฮสติง ควรถามถึงมาตรการแยกสิทธิ์การเข้าถึงระหว่างผู้ใช้งานบนเซิร์ฟเวอร์เดียวกันเพื่อลดความเสี่ยง
  3. สำรองข้อมูลอย่างสม่ำเสมอ: ดำเนินการสำรองข้อมูล (Backup) ทั้งไฟล์เว็บไซต์และฐานข้อมูลเก็บไว้ในตำแหน่งที่ปลอดภัยนอกเซิร์ฟเวอร์อย่างสม่ำเสมอ

สำหรับนักพัฒนาและผู้ดูแลระบบ (Developers & System Admins)

  1. ตรวจสอบหมายเลขเวอร์ชันของเซิร์ฟเวอร์ที่ดูแลอยู่: ตรวจเช็กเวอร์ชัน MariaDB ที่ติดตั้งอยู่ โดยแต่ละกิ่งจะต้องเป็นเวอร์ชันดังต่อไปนี้ขึ้นไป:
    • กิ่ง 10.6.x: ต้องเป็นเวอร์ชัน 10.6.28 ขึ้นไป (ข้อควรระวัง: กิ่งนี้หมดอายุการสนับสนุน EOL ไปแล้วตั้งแต่วันที่ 6 กรกฎาคม 2026 โดย 10.6.28 เป็นเวอร์ชันสุดท้าย ควรวางแผนย้ายไปยังกิ่งที่ยังรองรับ) (Severity Daily)
    • กิ่ง 10.11.x: ต้องเป็นเวอร์ชัน 10.11.19 ขึ้นไป
    • กิ่ง 11.4.x: ต้องเป็นเวอร์ชัน 11.4.13 ขึ้นไป
    • กิ่ง 11.8.x: ต้องเป็นเวอร์ชัน 11.8.9 ขึ้นไป
    • กิ่ง 12.3.x: ต้องเป็นเวอร์ชัน 12.3.3 ขึ้นไป (กิ่งนี้ได้รับผลกระทบจากทั้ง 3 ช่องโหว่วิกฤต)
    • กิ่ง 13.0.x: ต้องเป็นเวอร์ชัน 13.0.2 ขึ้นไป (ได้รับผลกระทบจากทั้ง 3 ช่องโหว่วิกฤตเช่นกัน)
  2. อย่าตระหนกหากระบบสแกนเพิ่งแจ้งเตือนสีแดง: ให้ตรวจสอบเวอร์ชันที่ใช้งานจริงก่อน หากเซิร์ฟเวอร์ของคุณได้รับการอัปเดตตามรอบปกติในช่วงปลายเดือนสิงหาคมไปแล้ว ระบบของคุณอาจได้รับการแก้ไขเรียบร้อยแล้ว การแจ้งเตือนที่เพิ่งเกิดขึ้นเป็นเพียงผลจากการอัปเดตข้อมูลของ NVD ที่ล่าช้ากว่าตัวโค้ดไปประมาณ 7 สัปดาห์ (Severity Daily)
  3. ดำเนินมาตรการลดความเสี่ยงระหว่างรอการอัปเกรด:
    • ปิดพอร์ตของบริการ MariaDB ไม่ให้เปิดเชื่อมต่อสู่เครือข่ายอินเทอร์เน็ตสาธารณะโดยตรง และจำกัดการเข้าถึงเฉพาะโฮสต์หรือแอปพลิเคชันที่จำเป็นเท่านั้น (Orbitaley)
    • ทบทวนสิทธิ์ของบัญชีผู้ใช้ฐานข้อมูลทั้งหมด ลบบัญชีที่ไม่จำเป็น และไม่ควรมอบสิทธิ์ FILE ให้แก่บัญชีของแอปพลิเคชันทั่วไป (Severity Daily)
    • ตั้งค่าตัวแปร secure_file_priv ให้รัดกุม เพื่อช่วยจำกัดความเสี่ยงจากช่องโหว่ CVE-2026-85985 ไปพร้อมกัน (Severity Daily)
    • ตรวจสอบบันทึกการทำงาน (Logs) เพื่อเฝ้าระวังกรณีที่เซิร์ฟเวอร์เกิดการแครชผิดปกติ หรือมีการเรียกใช้ชื่อตารางที่มีคำนำหน้า #mysql50# (Orbitaley) โดยสามารถติดตามรายละเอียดตัวบ่งชี้ภัยคุกคาม (IOC) ทางเทคนิคเพิ่มเติมได้จากเอกสารของผู้พัฒนาและนักวิจัยความปลอดภัยครับ

ผมมองว่า…

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

หากมองในมิติของการพัฒนาโค้ด ทีมงานของโครงการ MariaDB สามารถจัดการกับบั๊กเหล่านี้ได้อย่างรวดเร็วมาก มีการสร้างตั๋วรายงานในเดือนกรกฎาคม และพัฒนาตัวแก้ไขเสร็จสิ้นภายในเดือนเดียวกัน จากนั้นในเดือนสิงหาคม โค้ดที่ปลอดภัยก็ถูกปล่อยออกมาสู่สาธารณะเรียบร้อย ทว่าการปล่อยแพตช์ออกมาภายใต้ชื่อการอัปเดตบำรุงรักษาทั่วไปตามปกติ โดยไม่มีการส่งสัญญาณเตือนว่ามีช่องโหว่ระดับวิกฤตรวมอยู่ด้วย ทำให้ผู้ดูแลระบบจำนวนไม่น้อยเลือกที่จะเลื่อนการอัปเกรดออกไปก่อนเพื่อรอรอบเวลาที่สะดวก

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

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

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

ประเด็นแรกคือ การวิเคราะห์คะแนนอย่างเป็นทางการ (Primary Score) จากทาง NVD ซึ่งปัจจุบันยังคงอยู่ในสถานะรอการวิเคราะห์ (Awaiting Analysis) เนื่องจากช่องโหว่เหล่านี้ต้องการการล็อกอินเข้าสู่ระบบ และการรันโค้ดต้องอาศัยช่องโหว่อื่นมาทำงานร่วมกัน หากนักวิเคราะห์ของ NVD ประเมินขอบเขตผลกระทบต่างออกไป คะแนนความรุนแรงอาจมีการปรับลดลงมาจากระดับ 9.9 หรือไม่ (Severity Daily)

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

Recap

  • NVD เผยแพร่รายงานช่องโหว่ความปลอดภัยของ MariaDB Server จำนวน 7 รายการเมื่อวันศุกร์ที่ 16 ตุลาคม 2026
  • มีช่องโหว่ระดับวิกฤตคะแนน CVSS 3.1 สูงถึง 9.9 จำนวน 3 รายการ ได้แก่ CVE-2026-85746, CVE-2026-85748 และ CVE-2026-92262
  • ทุกช่องโหว่ระดับ 9.9 กำหนดให้ผู้โจมตีต้องมีบัญชีล็อกอินในระบบฐานข้อมูลด้วยสิทธิ์ระดับต่ำก่อน จึงไม่ใช่ช่องโหว่ที่ผู้โจมตีภายนอกเจาะได้โดยตรงแบบไม่ยืนยันตัวตน
  • คำอธิบายของบั๊กวิกฤต 2 ตัวระบุว่า การจะสั่งรันโค้ดควบคุมระบบได้ จำเป็นต้องทำงานร่วมกับช่องโหว่อื่นเพิ่มเติม
  • ปัจจุบันยังไม่มีรายงานการโจมตีจริงในระบบ และยังไม่มีรายการใดถูกจัดเข้าสู่แค็ตตาล็อก KEV ของ CISA
  • แพตช์ที่แก้ไขปัญหา (เวอร์ชัน 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, 13.0.2) ถูกเผยแพร่ออกมาแล้วตั้งแต่ช่วงเดือนสิงหาคมและกันยายน 2026
  • MariaDB กิ่ง 10.6 ได้สิ้นสุดระยะเวลาการสนับสนุน (EOL) ไปแล้ว โดยมีรุ่น 10.6.28 เป็นอัปเดตรุ่นสุดท้าย
  • ไม่มีการเผยแพร่วิธีเลี่ยงปัญหาชั่วคราว ทางออกเดียวคือการตรวจสอบเวอร์ชันและดำเนินการอัปเกรดไปยังรุ่นที่ได้รับการแก้ไขแล้ว