สรุปสั้น

บริษัท Cisco ออกแพตช์ปิดช่องโหว่ด้านความปลอดภัยระดับวิกฤตที่กระทบสวิตช์ Nexus 9000 ซึ่งใช้ชิป Silicon One จำนวน 10 รุ่น โดยช่องโหว่นี้เปิดทางให้ผู้โจมตีจากระยะไกลที่ไม่ต้องยืนยันตัวตนรันโค้ดด้วยสิทธิ์ root บนอุปกรณ์ได้ พร้อมกันนั้นบริษัทยังออกชุดแพตช์เสริมความแข็งแกร่งของระบบปฏิบัติการ IOS XR ที่รวม 7 CVE แบบร่ม โดยสองรายการในนั้นมีคะแนนความรุนแรงสูงสุดที่ 9.8 และไม่มีวิธีบรรเทาชั่วคราวสำหรับ IOS XR เวอร์ชันใดเลย

ช่องโหว่บน Nexus ที่ติดตามในรหัส CVE-2026-20212 ซึ่งมีคะแนน CVSS 9.8 เกิดจากการผูกบริการเข้ากับที่อยู่ไอพีแบบไม่จำกัด ทำให้พอร์ต TCP หมายเลข 43210 และ 43211 เข้าถึงได้ในอินสแตนซ์ VRF ชั้น 3 ที่เป็นค่าเริ่มต้น ผู้โจมตีที่เข้าถึงที่อยู่ของสวิตช์บนพอร์ตใดพอร์ตหนึ่งได้จึงเชื่อมต่อเข้าบริการนั้นได้โดยตรง และข้อมูลนำเข้าที่ปั้นขึ้นมาเป็นพิเศษจะถูกรันเป็นโค้ดด้วยสิทธิ์สูงสุด ส่วนความพยายามโจมตีที่ไม่สำเร็จก็ยังทำให้โพรเซส S1HAL ล่มและอุปกรณ์รีโหลดตัวเองได้

จุดที่ผู้ดูแลระบบควรให้ความสนใจเป็นพิเศษคือ Cisco ยังไม่ได้เผยแพร่ตารางเวอร์ชันที่แก้ไขแล้วสำหรับ Nexus 9000 แต่ชี้ให้ลูกค้าไปตรวจกับเครื่องมือ Software Checker ของบริษัทเอง โดยเสนอการใช้บัญชีควบคุมการเข้าถึงระดับโครงสร้างพื้นฐานเพื่อปิดสองพอร์ตดังกล่าว และการเปิดโล่ Live Protect ชั่วคราวเป็นมาตรการประคองไปก่อน ส่วนช่องโหว่ในฝั่ง IOS XR นั้นบริษัทระบุว่ากระทบทุกเวอร์ชันไม่ว่าอุปกรณ์จะตั้งค่าอย่างไร ทั้งนี้ ณ วันเปิดเผยเมื่อ 2 กันยายน 2569 Cisco ยังไม่พบการนำช่องโหว่ Nexus ไปใช้โจมตีจริง

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

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 3 กันยายน 2569 ว่า Cisco เปิดเผยชุดคำแนะนำด้านความปลอดภัยเมื่อวันที่ 2 กันยายน ซึ่งครอบคลุมทั้งช่องโหว่วิกฤตบนสวิตช์ Nexus 9000 และชุดแพตช์เสริมความแข็งแกร่งของ IOS XR โดยการปล่อยชุดแพตช์รอบนี้เป็นครั้งที่สามในรอบ 30 วัน ต่อจากชุดแรกเมื่อวันที่ 5 สิงหาคมที่ออกแพตช์ให้ IOS XE กับ Catalyst SD-WAN และอีกสองสัปดาห์ถัดมาที่ออกแพตช์ระดับ CVSS 10.0 ให้ Crosswork และ Secure Workload

รายชื่อรหัสผลิตภัณฑ์ที่ได้รับผลกระทบซึ่งตรวจสอบได้จากผลลัพธ์ของคำสั่ง show module ประกอบด้วย N9324C-SE1U และ N9348Y2C6D-SE1U ที่เป็น Nexus Smart Switch, N9364E-SG2-O, N9364E-SG2-Q, N9396T12C-SE1, N9348Y12C-SE1, N9396Y12C-SE1, N9336C-SE1, N9K-C9804 และ N9K-C9808 ส่วนรุ่นอื่นของ Nexus 9000 สวิตช์แฟบริก Nexus 9000 ที่ทำงานในโหมด Application Centric Infrastructure และสายผลิตภัณฑ์ Nexus 3000 กับ 7000 ไม่ได้รับผลกระทบ

The Hacker News ยืนยันผ่านบันทึกของโครงการ CVE เมื่อวันที่ 3 กันยายนว่า Cisco ระบุเวอร์ชัน NX-OS ที่ได้รับผลกระทบไว้ถึง 45 เวอร์ชัน ตั้งแต่ 10.3(1) จนถึง 10.6(3s) ซึ่งเป็นช่วงที่ตัวคำแนะนำเองไม่ได้ระบุไว้แต่โยนให้ไปตรวจกับ Software Checker แทน ความต่างตรงนี้มีผลในทางปฏิบัติ เพราะทีมที่ต้องประเมินความเสี่ยงของอุปกรณ์จำนวนมากไม่สามารถเทียบเวอร์ชันจากเอกสารคำแนะนำได้โดยตรง แต่ต้องไล่ป้อนเวอร์ชันเข้าเครื่องมือทีละรายการ

สำหรับมาตรการที่ใช้ได้ก่อนอัปเกรด Cisco เสนอสามทางเลือก ทางแรกคืออัปเกรดไปยังเวอร์ชันที่ Software Checker ระบุ โดยหมายเหตุประกอบระบุว่าโหมดการทำงานของโล่จะเปลี่ยนเป็น N/A เมื่ออัปเกรดไปยัง NX-OS 10.6(4) ขึ้นไป ทางที่สองคือกำหนดบัญชีควบคุมการเข้าถึงระดับโครงสร้างพื้นฐานให้อนุญาตเฉพาะทราฟฟิกการจัดการและระนาบควบคุมที่จำเป็น หรือปฏิเสธแพ็กเก็ต TCP ที่ส่งไปยังที่อยู่ไอพีที่กำหนดไว้ในเครื่องบนพอร์ตปลายทาง 43210 หรือ 43211 อย่างชัดเจน ซึ่งควรทดสอบในสภาพแวดล้อมทดสอบก่อน และทางที่สามคือโล่ Live Protect รหัส lp00031 ซึ่งเป็นการบรรเทาชั่วคราวที่รองรับเฉพาะ NX-OS 10.6(3) และรองรับบน 10.6(3s) ผ่านแพ็กเกจโล่อีกชุดสำหรับ Smart Switch สองรุ่นเท่านั้น โดยไม่รองรับ Nexus 9804 และ 9808 และยังต้องการการเข้าถึงผ่าน SSH, Telnet หรือ NX-API

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

ในฝั่ง IOS XR ชุดแพตช์รอบนี้ใช้วิธีกำหนดหนึ่ง CVE ต่อหนึ่งหมวดของจุดอ่อนตามระบบ Common Weakness Enumeration ของบั๊กที่ถูกแก้ แล้วให้คะแนนตามข้อบกพร่องที่รุนแรงที่สุดในหมวดนั้น ตามกฎที่ระบุไว้ในเอกสารคำถามพบบ่อยเรื่องการเปิดเผยตามความเสี่ยงของบริษัท โดย CVE-2026-20274 ครอบคลุมบั๊กด้านความปลอดภัยของหน่วยความจำและวงจรชีวิตของทรัพยากร ส่วน CVE-2026-20279 ครอบคลุมบั๊กด้านการควบคุมการเข้าถึงซึ่งรวมถึงการไม่มีการยืนยันตัวตนสำหรับฟังก์ชันสำคัญและการตรวจสอบใบรับรองที่ไม่ถูกต้อง ทั้งสองรายการมีเพดานคะแนนที่ 9.8 ขณะที่อีกห้ารายการคือ CVE-2026-20275 ถึง CVE-2026-20278 และ CVE-2026-20280 มีคะแนนสูงสุดอยู่ระหว่าง 8.2 ถึง 8.8

สิ่งที่ทำให้ชุดนี้ต่างจากแพตช์ทั่วไปคือคำแนะนำระบุว่าช่องโหว่กระทบทุกเวอร์ชันโดยไม่ขึ้นกับการตั้งค่าของอุปกรณ์ และไม่มีวิธีบรรเทาชั่วคราวให้ใช้ระหว่างรอ ทางเดียวคือการอัปเกรดไปยังเวอร์ชันที่มีชุดปรับปรุงซอฟต์แวร์แบบเลือกจุด หรือ SMU แล้วจึงติดตั้ง SMU เหล่านั้น โดยแพลตฟอร์ม XR7 ซึ่งรวมถึง Cisco 8000 Series, NCS 1010, NCS 540L และ NCS 5700 Series มี SMU เฉพาะที่ใช้ได้กับทุกเวอร์ชันคือ CSCwv19790

Cisco ระบุว่าอาจมี “SMU ราว 16 ชุดสำหรับแต่ละเวอร์ชัน” และเวอร์ชัน 26.2.2 กับ 26.3.1 ในอนาคตจะเป็นเวอร์ชันแรกที่แก้ไขเรียบร้อยโดยไม่ต้องติดตั้ง SMU เพิ่ม ส่วนลูกค้าที่ใช้เวอร์ชันนอกตารางให้เปิดเคสกับศูนย์ช่วยเหลือทางเทคนิค ปัจจุบัน SMU พร้อมใช้งานสำหรับเวอร์ชัน 6.9.2, 7.3.2, 7.9.2, 7.9.21, 7.10.2, 7.11.2, 7.11.21, 24.2.2, 24.2.21, 24.4.2, 25.2.21, 25.4.1, 25.4.2, 26.1.2 และ 26.2.1 ขณะที่เวอร์ชัน 24.1.2, 24.3.2, 25.1.2 และ 25.2.2 ยังอยู่ในสถานะรอ SMU ในอนาคต โดย SMU ถูกแยกตามพื้นที่การทำงาน เช่น BGP ใช้ CSCwu14807, crypto-ike ใช้ CSCwv19170, gRPC ใช้ CSCwt41683, IP-SLA ใช้ CSCwv19173, IS-IS ใช้ CSCwv45645 และ CSCwv19171, MPLS และ MPLS-TE ใช้ CSCwv40753 กับ CSCwu14825, มัลติแคสต์ใช้ CSCwv19180 กับ CSCwu08799, OSPF ใช้ CSCwv40741 กับ CSCwv19171, การกำหนดเส้นทางแบบเซกเมนต์และ TCP Authentication Option มีรหัสแยกตามสถาปัตยกรรม และ Zero Touch Provisioning ใช้ CSCwu36622

ตัวเลขที่สะท้อนภาระงานจริงได้ดีที่สุดมาจากการที่ The Hacker News ตรวจเทียบบันทึก CVE ทั้งเจ็ดรายการกับเอกสารคำแนะนำเมื่อวันที่ 3 กันยายน แล้วพบว่าในบรรดา 111 เวอร์ชันของ IOS XR ที่ Cisco ระบุว่าได้รับผลกระทบนั้น มีเพียง 14 เวอร์ชันที่มี SMU ให้ใช้ได้ในวันนี้ อีก 4 เวอร์ชันยังรอ SMU และอีก 93 เวอร์ชันต้องอัปเกรดก่อนจึงจะติดตั้งการแก้ไขได้ กล่าวคือผู้ใช้ส่วนใหญ่ไม่สามารถแพตช์ได้ทันทีแม้ต้องการ แต่ต้องวางแผนอัปเกรดระบบปฏิบัติการของอุปกรณ์แกนหลักก่อน ซึ่งเป็นงานที่ต้องหยุดให้บริการและใช้เวลาเป็นสัปดาห์ในเครือข่ายขนาดใหญ่

นอกจากนี้ในคำแนะนำชุดเดียวกันยังมีช่องโหว่ที่ถูกเปิดเผยต่อสาธารณะสองรายการเกี่ยวกับการถอดรหัส S/MIME ในผลิตภัณฑ์ Secure Email คือ CVE-2026-20354 และ CVE-2026-20355 ซึ่งมีคะแนน 5.9 เปิดทางให้ผู้โจมตีที่แทรกตัวอยู่ตรงกลางกู้ข้อความต้นฉบับจากอีเมลที่วิ่งระหว่างเกตเวย์ที่ใช้ AsyncOS 16.5.0 หรือเก่ากว่าและตั้งค่า S/MIME ไว้ โดยเวอร์ชันที่แก้แล้วของทั้งคู่ถูกระบุไว้เฉพาะในบันทึกบั๊กเท่านั้น และยังมีช่องโหว่ทำให้โทรศัพท์หยุดให้บริการคือ CVE-2026-20281 คะแนน 7.5 ที่กระทบ Desk Phone 9800, IP Phone 7800 และ 8800 รวมถึง Video Phone 8875 ที่ลงทะเบียนกับ Unified Communications Manager และเปิดใช้งาน Web Access ซึ่งเป็นค่าที่ปิดอยู่โดยค่าเริ่มต้น

ผลกระทบ

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

ประเด็นที่หนักกว่าตัวช่องโหว่คือสภาพของการแพตช์เอง ในฝั่ง IOS XR ที่ 93 จาก 111 เวอร์ชันต้องอัปเกรดก่อนจึงจะติดตั้งการแก้ไขได้ องค์กรจำนวนมากจึงอยู่ในสถานะที่รู้ว่ามีช่องโหว่คะแนน 9.8 อยู่ในระบบแต่ยังลงมือแก้ไม่ได้ในทันที และเนื่องจากคำแนะนำระบุว่าไม่มีวิธีบรรเทาชั่วคราวสำหรับ IOS XR องค์กรจึงต้องพึ่งการควบคุมการเข้าถึงรอบนอกและการเฝ้าระวังเป็นหลักในช่วงระหว่างนี้ ส่วนฝั่ง Nexus นั้นมาตรการชั่วคราวอย่างโล่ Live Protect ก็ไม่ได้ครอบคลุมทุกรุ่น โดยเฉพาะ Nexus 9804 และ 9808 ที่ไม่รองรับเลย

ในระดับกระบวนการ ชุดแพตช์รอบนี้ยังสะท้อนผลของโมเดลการเปิดเผยแบบใหม่ที่ Cisco ประกาศเมื่อเดือนมิถุนายน ซึ่งรวมบั๊กที่ทีมภายในค้นพบเข้าเป็น CVE แบบร่มแล้วปล่อยเป็นรอบทุกครึ่งเดือน โดยนาย Russ Smoak รองประธานฝ่ายความปลอดภัยสารสนเทศของ Cisco ให้เหตุผลไว้ในบล็อกเดือนมิถุนายนว่า “ในเวลาเดียวกัน ช่องว่างระหว่างการเปิดเผยกับการถูกนำไปใช้โจมตีได้ปิดลงแล้วอย่างแท้จริง” ผลข้างเคียงคือทีมปฏิบัติการต้องรับมือชุดแพตช์ที่ถี่ขึ้นและมีขนาดใหญ่ขึ้น โดยที่รายละเอียดของบั๊กแต่ละตัวถูกยุบรวมอยู่ใน CVE เดียว ทำให้การประเมินความเสี่ยงรายรายการทำได้ยากกว่าเดิม

ที่ควรอ่านประกอบกันคือรายงานของบริษัท Sygnia ที่ออกก่อนหน้านี้หกวัน ซึ่งระบุว่ากลุ่มผู้ก่อภัยคุกคามที่เชื่อมโยงกับจีนในชื่อ Fire Ant รันอิมแพลนต์ที่สร้างขึ้นเฉพาะบนเราเตอร์ IOS XR โดยอิมแพลนต์ดังกล่าวระงับการส่งข้อมูลบันทึก syslog กรองผลลัพธ์ของคำสั่ง show และรองรับอุโมงค์ GRE ที่ซ่อนอยู่ อีกทั้งยังดักจับแพ็กเก็ตจากเราเตอร์แล้วอัปโหลดไปยังเซิร์ฟเวอร์ FTP ภายนอก พร้อมพยายามเชื่อมต่อและสแกนพอร์ตไปยังระบบที่เชื่อมต่ออยู่ซึ่งเกี่ยวข้องกับโครงสร้างพื้นฐานสำคัญ การสืบสวนเริ่มจากการพบอินเทอร์เฟซอุโมงค์ที่ทำงานอยู่บนเราเตอร์โดยไม่มีคอนฟิกที่ทำงานอยู่หรือประวัติการยืนยันการเปลี่ยนแปลงใด ๆ มาอธิบาย ซึ่ง Sygnia ระบุว่าชี้ให้เห็นว่าสถานะการทำงานของอุปกรณ์ “ไม่อาจเชื่อถือได้อีกต่อไปว่าตรงกับคอนฟิกและบันทึกการตรวจสอบ” ทั้งนี้ Sygnia ไม่ได้ระบุว่ากลุ่มดังกล่าวเข้าถึงเราเตอร์ได้อย่างไรตั้งแต่แรกและไม่ได้ระบุชื่อช่องโหว่ใด จึงยังเชื่อมโยงกับ CVE ชุดนี้โดยตรงไม่ได้ เว็บไซต์นี้เคยรายงานเหตุการณ์ดังกล่าวไว้แล้วในโพสต์ 2026/08/175

คำแนะนำ

สำหรับผู้ดูแลสวิตช์ Nexus 9000 ควรเริ่มจากรันคำสั่ง show module เพื่อเทียบรหัสผลิตภัณฑ์กับรายชื่อ 10 รุ่นที่ได้รับผลกระทบ แล้วตรวจเวอร์ชัน NX-OS ที่ใช้อยู่กับเครื่องมือ Software Checker ของ Cisco เนื่องจากเอกสารคำแนะนำไม่ได้ให้ตารางเวอร์ชันที่แก้ไขแล้วไว้โดยตรง

ระหว่างรอการอัปเกรด ควรกำหนดบัญชีควบคุมการเข้าถึงระดับโครงสร้างพื้นฐานให้ปฏิเสธแพ็กเก็ต TCP ไปยังพอร์ตปลายทาง 43210 และ 43211 บนที่อยู่ไอพีของอุปกรณ์ และทดสอบในสภาพแวดล้อมทดสอบก่อนนำขึ้นใช้งานจริง สำหรับรุ่นที่รองรับควรพิจารณาเปิดโล่ Live Protect รหัส lp00031 เป็นมาตรการเสริม โดยเข้าใจว่ามาตรการนี้ไม่รองรับ Nexus 9804 และ 9808

ในฝั่ง IOS XR ควรจัดทำบัญชีเวอร์ชันที่ใช้งานอยู่ทั้งหมดก่อน แล้วแยกเป็นสามกลุ่มคือกลุ่มที่มี SMU พร้อมติดตั้งทันที กลุ่มที่ยังรอ SMU และกลุ่มที่ต้องอัปเกรดเวอร์ชันก่อน จากนั้นจัดลำดับตามความสำคัญของอุปกรณ์และการเปิดสู่ภายนอก สำหรับเวอร์ชันที่อยู่นอกตารางของ Cisco ควรเปิดเคสกับศูนย์ช่วยเหลือทางเทคนิคแทนการรอเงียบ ๆ

องค์กรที่ใช้ Secure Email ควรตรวจว่าเกตเวย์ยังใช้ AsyncOS 16.5.0 หรือเก่ากว่าและเปิด S/MIME อยู่หรือไม่ ส่วนผู้ดูแลระบบโทรศัพท์ควรยืนยันว่าค่า Web Access บนอุปกรณ์รุ่นที่ระบุยังปิดอยู่ตามค่าเริ่มต้น และอัปเดตซอฟต์แวร์ SIP เป็นเวอร์ชัน 5.0(1), 14.4(1)SR3, 14.4(1)SR4 หรือ 11.0(6)SR8 ตามรุ่นของอุปกรณ์

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

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