สรุปสั้น
Internet Systems Consortium (ISC) ได้ออก BIND 9.20.29 และ 9.21.26 เพื่อแก้ช่องโหว่ด้านความปลอดภัย 14 รายการที่เปิดเผยเมื่อวันที่ 16 กันยายน ในซอฟต์แวร์เซิร์ฟเวอร์ DNS แบบโอเพนซอร์ส BIND 9 หนึ่งในนั้นกระทบทุกเซิร์ฟเวอร์ BIND ที่ให้บริการ DNS-over-HTTPS (DoH) โดยผู้ส่งที่ไม่มีข้อมูลรับรอง (credential) ใด ๆ สามารถทำให้โปรเซส named ของเซิร์ฟเวอร์ล่มได้ด้วยคำขอเพียงรายการเดียวที่มีลายเซ็น SIG(0) ที่ไม่ถูกต้อง หากผู้ส่งปิดการเชื่อมต่อก่อนที่ named จะตรวจสอบลายเซ็นเสร็จ ช่องโหว่นี้คือ CVE-2026-77692 จัดระดับ High ที่คะแนน CVSS 3.1 เท่ากับ 7.5
ISC ระบุในประกาศว่ายังไม่พบว่าช่องโหว่ทั้ง 14 รายการถูกใช้โจมตีจริง และไม่มีรายการใดปรากฏในบัญชี Known Exploited Vulnerabilities (KEV) ของ CISA รุ่นที่ออกในวันเดียวกัน ในจำนวนนี้ ISC จัดระดับ High ไว้ 7 รายการที่คะแนน 7.5 เท่ากันทั้งหมด และอีก 7 รายการเป็นระดับ Medium ตั้งแต่ 5.3 ถึง 6.5 โดย ISC ไม่ได้ระบุวิธีบรรเทา (workaround) สำหรับช่องโหว่ใดเลย ทางแก้เดียวคือการอัปเดตเวอร์ชัน นับเป็นชุดแพตช์ความปลอดภัยที่ใหญ่ที่สุดในบรรดา 5 ครั้งที่ ISC ออกให้ BIND ในปีนี้ หลังจากแก้ 1 รายการในเดือนมกราคม 4 รายการในมีนาคม 6 รายการในพฤษภาคม และ 9 รายการในกรกฎาคม
รายละเอียดข่าว
เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 17 กันยายน 2569 ว่า รุ่นที่แก้ไขแล้วประกอบด้วย BIND 9.20.29 บนสายเสถียร (stable) ปัจจุบันซึ่งแก้ครบทั้ง 14 รายการ, BIND 9.21.26 บนสายพัฒนา (development) ที่แก้ 13 รายการเพราะ CVE-2026-19662 ไม่กระทบสาย 9.21 และ BIND 9.20.29-S1 รุ่น Supported Preview Edition สำหรับลูกค้าที่มีสัญญาสนับสนุนซึ่งแก้ครบทั้ง 14 รายการ ทั้งนี้ช่องโหว่ 12 จาก 14 รายการยังกระทบสาย 9.18 ที่เก่ากว่า ไปจนถึงรุ่น 9.18.50 ซึ่งเป็นรุ่นสุดท้าย โดย ISC ยุติการสนับสนุน 9.18 ไปตั้งแต่ปลายเดือนมิถุนายน และไม่มีรุ่น 9.18 ใดที่แก้ช่องโหว่เหล่านี้ ISC เตือนตั้งแต่เดือนพฤษภาคมว่าผู้ใช้ 9.18 ควรวางแผนอัปเดตไปเป็น 9.20 โดยเร็วที่สุด พร้อมย้ำในตารางช่องโหว่ว่า “ควรถือว่ารุ่นที่หมดอายุแล้ว (EOL) มีความเสี่ยงต่อ CVE ใหม่เสมอ”
แพ็กเกจของระบบปฏิบัติการเป็นอีกเรื่องหนึ่ง โดย Debian 12 มาพร้อมแพ็กเกจที่อิงจาก 9.18.49 และระบบติดตามความปลอดภัยของ Debian ยังไม่ได้ระบุช่องโหว่ทั้ง 14 รายการนี้ ณ เวลา 06:20 UTC ของวันที่ 17 กันยายน ในแง่เงื่อนไขการโจมตี ช่องโหว่ 2 ใน 14 รายการสามารถกระตุ้นได้ด้วยคำขอเพียงอย่างเดียวโดยผู้โจมตีไม่จำเป็นต้องมีเซิร์ฟเวอร์ DNS ของตัวเอง และทั้งคู่กระทบเฉพาะสาย 9.20 และ 9.21 ได้แก่ CVE-2026-77692 (การล่มผ่าน DoH) และ CVE-2026-76163 ที่คำสั่งชนิด TKEY ทำให้ named ล่มได้เมื่อไฟล์ named.conf ไม่มีบล็อก global options ส่วนช่องโหว่การล่มอื่น ๆ ต้องอาศัย recursive resolver รับข้อมูลที่สร้างขึ้นมาเป็นพิเศษจากเซิร์ฟเวอร์ที่ผู้โจมตีควบคุม
รายละเอียดช่องโหว่
ช่องโหว่ส่วนใหญ่ในชุดนี้เป็นการทำให้เซิร์ฟเวอร์ล่มหรือกินทรัพยากร การตอบกลับที่สร้างขึ้นมาเป็นพิเศษเพียงรายการเดียวสามารถทำให้ resolver ที่ตั้งค่าเริ่มต้นล่มได้ (CVE-2026-19667), resolver ที่ใช้ dns64 ร่วมกับ break-dnssec yes (CVE-2026-19666) หรือ validating resolver ที่ได้รับคำตอบแบบ wildcard ที่มีทั้งหลักฐาน NSEC และ NSEC3 (CVE-2026-80274) ส่วนอีก 4 รายการเป็นการทำให้ resolver ใช้ CPU หรือหน่วยความจำจนหมดแทนการล่ม โดย 2 ในนั้นเกิดจากเรคคอร์ด SVCB/HTTPS alias ที่ถูกแคช (CVE-2026-81563 และ CVE-2026-81736)
อีก 4 รายการที่เหลือเกี่ยวกับความสมบูรณ์ของข้อมูล DNS ที่เซิร์ฟเวอร์ให้บริการหรือที่ resolver ยอมรับ ISC จัดทั้งหมดเป็นระดับ Medium สองรายการทำให้ validating resolver ยอมรับหลักฐาน DNSSEC ที่ผิด โดย CVE-2026-19941 ทำให้เรคคอร์ด NSEC ที่มีลายเซ็นจากโซนที่ไม่เกี่ยวข้องผ่านเป็นหลักฐานว่าไม่มี wildcard อยู่ ซึ่ง ISC เรียกว่าการวางยาแคช (cache poisoning) เช่นเดียวกับ CVE-2026-77119 ที่ทำให้การมอบหมายโซนแบบปลอดภัยถูกลดระดับ ส่วน CVE-2026-19033 เกี่ยวกับ secondary server ที่คัดลอกโซนจาก primary อาจเริ่มให้บริการข้อมูลโซนใหม่ก่อนที่ข้อความสุดท้ายซึ่งบรรจุลายเซ็นจะมาถึงระหว่างการถ่ายโอนแบบ IXFR หลายข้อความบน TCP และ CVE-2026-78301 ที่ต้องอาศัยการโหลดโซนที่ผิดรูปแบบเข้าสู่ authoritative server ตารางด้านล่างสรุปช่องโหว่ระดับ High ทั้ง 7 รายการ
| CVE | ระดับ | ผลกระทบ | เงื่อนไข |
|---|---|---|---|
| CVE-2026-77692 | 7.5 High | named ล่ม | เซิร์ฟเวอร์ตอบ DoH · คำขอ SIG(0) ไม่ถูกต้องและปิดการเชื่อมต่อก่อน |
| CVE-2026-76163 | 7.5 High | named ล่ม | คำสั่ง TKEY · named.conf ไม่มีบล็อก global options |
| CVE-2026-19667 | 7.5 High | resolver ล่ม | คำตอบเชิงลบขนาด 65536 ไบต์พอดีจากเซิร์ฟเวอร์ผู้โจมตี · ค่าเริ่มต้น |
| CVE-2026-19666 | 7.5 High | resolver ล่ม | dns64 กับ break-dnssec yes · คำตอบผิดรูปจากแคช |
| CVE-2026-80274 | 7.5 High | resolver ล่ม/ตอบผิด | validating resolver · wildcard ที่มีทั้ง NSEC3 และ NSEC |
| CVE-2026-81563 | 7.5 High | แคชโตเกินขีดจนแก้ชื่อไม่ได้ | ตาม SVCB/HTTPS alias ที่มีเรคคอร์ดเป้าหมายเกิน 13 รายการซ้ำ ๆ |
| CVE-2026-81736 | 7.5 High | CPU หมดบน resolver | ต้นไม้ SVCB/HTTPS alias ในแคช · ไคลเอนต์เปิด recursion + โซนผู้โจมตี |
ผลกระทบ
BIND เป็นซอฟต์แวร์เซิร์ฟเวอร์ DNS ที่ใช้แพร่หลายที่สุดตัวหนึ่งของโลก การที่ named ถูกทำให้ล่มได้โดยไม่ต้องยืนยันตัวตน โดยเฉพาะผ่าน DNS-over-HTTPS ที่กำลังถูกนำมาใช้มากขึ้น หมายความว่าผู้โจมตีสามารถทำให้บริการแปลงชื่อโดเมนของหน่วยงานหยุดทำงานได้ด้วยคำขอเดียว ซึ่งกระทบต่อการเข้าถึงเว็บ อีเมล และบริการภายในทั้งหมดที่พึ่งพา DNS นั้น ยิ่งไปกว่านั้น ช่องโหว่กลุ่มที่ทำให้ยอมรับหลักฐาน DNSSEC ผิดหรือวางยาแคชได้ อาจถูกใช้หลอกให้ resolver ตอบผลลัพธ์ปลอมสำหรับชื่อที่ควรแปลผลถูกต้อง ซึ่งเปิดทางไปสู่การเปลี่ยนเส้นทางผู้ใช้ไปยังปลายทางที่ผู้โจมตีควบคุม
ประเด็นที่ต้องระวังเป็นพิเศษคือรุ่น 9.18 ที่หมดอายุการสนับสนุนไปแล้วได้รับผลกระทบถึง 12 รายการแต่จะไม่มีแพตช์ออกมาให้ ทำให้องค์กรที่ยังใช้ 9.18 หรือใช้แพ็กเกจของระบบปฏิบัติการที่อิงรุ่นเก่า เช่น Debian 12 มีความเสี่ยงค้างไว้จนกว่าจะอัปเกรด แม้ ISC จะยังไม่พบการใช้โจมตีจริง แต่ชุดทดสอบที่จำลองการทำงานของช่องโหว่ถูกเผยแพร่พร้อมซอร์สโค้ด 9.20.29 แล้ว ซึ่งแม้จะเป็นเครื่องมือยืนยันการแก้ไขไม่ใช่เครื่องมือโจมตี แต่ก็ระบุเงื่อนไขการกระตุ้นช่องโหว่ไว้ชัดเจน จึงลดระยะเวลาที่ผู้โจมตีต้องใช้ในการพัฒนาชุดโจมตีของตนเองลง
คำแนะนำ
ผู้ดูแลระบบที่ให้บริการ DNS ด้วย BIND ควรอัปเดตเป็น BIND 9.20.29 หรือ 9.21.26 (หรือ 9.20.29-S1 สำหรับลูกค้าที่มีสัญญาสนับสนุน) โดยเร็วที่สุด เพราะ ISC ไม่ได้ระบุวิธีบรรเทาใด ๆ ทางแก้จึงมีเพียงการอัปเดตเวอร์ชันเท่านั้น ควรให้ความสำคัญเป็นพิเศษกับเซิร์ฟเวอร์ที่เปิดบริการ DNS-over-HTTPS ซึ่งเสี่ยงต่อ CVE-2026-77692 และเซิร์ฟเวอร์ที่ทำหน้าที่ recursive resolver องค์กรที่ยังใช้ BIND 9.18 ที่หมดอายุแล้วควรวางแผนย้ายไปสาย 9.20 โดยด่วน และตรวจสอบว่าแพ็กเกจ DNS ที่มาพร้อมระบบปฏิบัติการ (เช่น Debian) ได้รับการอัปเดตครบถ้วน นอกจากนี้ควรเฝ้าระวังการล่มหรือการรีสตาร์ตผิดปกติของโปรเซส named และจำกัดการเข้าถึงบริการ DNS เฉพาะเครือข่ายที่จำเป็นเพื่อลดพื้นผิวการโจมตี
