สรุปสั้น

บริษัท F5 ปล่อยแพตช์แก้ช่องโหว่ระดับวิกฤตใน NGINX ที่เปิดทางให้ผู้โจมตีจากระยะไกลซึ่งไม่ต้องยืนยันตัวตนใดๆ ส่งคำขอ HTTP ที่สร้างขึ้นพิเศษจนเกิด heap buffer overflow ในโปรเซส worker ช่องโหว่นี้ถูกติดตามในรหัส CVE-2026-42533 และได้รับการแก้ไขเมื่อวันที่ 15 กรกฎาคม 2569 ใน nginx เวอร์ชัน 1.30.4 สายเสถียร และ 1.31.3 สาย mainline รวมถึง NGINX Plus 37.0.3.1 ใครที่ยังใช้รุ่นเก่ากว่านี้ควรอัปเกรดทันที ผลกระทบเบื้องต้นคือทำให้โปรเซส worker ล่มหรือรีสตาร์ตจนเกิดภาวะปฏิเสธการให้บริการ (Denial of Service) แต่ในกรณีที่ระบบปิดกลไก ASLR หรือผู้โจมตีข้ามกลไกนี้ได้ F5 ระบุว่าอาจนำไปสู่การรันโค้ดจากระยะไกลได้ด้วย

สิ่งที่ทำให้ช่องโหว่นี้น่ากังวลเป็นพิเศษคือช่วงเวอร์ชันที่กระทบกว้างมาก ครอบคลุมทุกเวอร์ชันตั้งแต่ 0.9.6 จนถึง 1.31.2 ซึ่งย้อนกลับไปถึงปี 2554 ปีที่ไดเรกทีฟ map เริ่มรองรับ regular expression อย่างไรก็ตาม เซิร์ฟเวอร์ NGINX ไม่ได้ได้รับผลกระทบทุกเครื่อง เพราะการเกิดช่องโหว่ขึ้นอยู่กับรูปแบบการตั้งค่าไม่ใช่แค่หมายเลขเวอร์ชัน F5 ให้คะแนน CVSS v4 ที่ 9.2 และ CVSS v3.1 ที่ 8.1 พร้อมประเมินความซับซ้อนของการโจมตีไว้ในระดับสูง ณ วันที่ 20 กรกฎาคม 2569 ช่องโหว่นี้ยังไม่เข้าแคตตาล็อก KEV ของ CISA และยังไม่มีโค้ดโจมตีสาธารณะปรากฏ แต่หนึ่งในผู้รายงานประกาศว่าจะเผยแพร่ตัวอย่างการโจมตี (PoC) หลังออกแพตช์ครบ 21 วัน

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

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 20 กรกฎาคม 2569 ว่าบริษัท F5 ได้ออกแพตช์แก้ช่องโหว่วิกฤตใน NGINX เว็บเซิร์ฟเวอร์และรีเวิร์สพร็อกซีที่ถูกใช้งานแพร่หลายที่สุดตัวหนึ่งของโลก โดยช่องโหว่ CVE-2026-42533 ถูกรายงานเข้ามายัง F5 โดยนักวิจัยอิสระมากกว่าสิบรายพร้อมกัน ซึ่งทาง F5 ได้ขอบคุณที่ “ต่างฝ่ายต่างนำประเด็นนี้มาแจ้งให้ทราบอย่างเป็นอิสระต่อกัน” ขณะที่บันทึกการเปลี่ยนแปลงของ nginx เองให้เครดิตการแก้ไขแก่นาย Mufeed VH จาก Winfunc Research และนาย Maxim Dounin ผู้ดูแลโครงการ

F5 ระบุในประกาศว่าช่องโหว่กระทบผลิตภัณฑ์ในเครืออีกหลายตัวนอกเหนือจากตัวเซิร์ฟเวอร์หลักและ NGINX Plus ได้แก่ NGINX Ingress Controller, Gateway Fabric, App Protect WAF และ Instance Manager แต่ ณ เวลาที่ประกาศออกมา F5 ยังไม่ได้ระบุเวอร์ชันที่แก้ไขแล้วสำหรับผลิตภัณฑ์ทั้งสี่ตัวนี้ ซึ่งเป็นจุดที่องค์กรที่ใช้ NGINX ในสภาพแวดล้อมคอนเทนเนอร์และ Kubernetes ต้องติดตามอย่างใกล้ชิด

ประเด็นที่กลายเป็นข้อถกเถียงคือระดับความรุนแรงที่แท้จริง F5 วางเงื่อนไขไว้ว่าการรันโค้ดจะเกิดขึ้นได้ต่อเมื่อ ASLR ถูกปิดหรือถูกข้ามได้ แต่นาย Stan Shaw นักวิจัยที่เผยแพร่ผลงานในชื่อ cyberstan และเป็นหนึ่งในผู้รายงานช่องโหว่ ได้ออกบทวิเคราะห์ที่ลงลึกกว่าประกาศของผู้ผลิต โดยชี้ว่าตัวช่องโหว่เองนั่นแหละที่มอบวิธีข้าม ASLR ให้ผู้โจมตี เขาอธิบายกับ The Hacker News ว่ากลไกการทับข้อมูล capture นั้นทำงานย้อนกลับได้ด้วย กล่าวคือเมื่อ capture ที่ถูกทับมีขนาดเล็กกว่าของเดิม บัฟเฟอร์ที่ใหญ่เกินไปจะคืนข้อมูลใน heap ที่ยังไม่ถูกกำหนดค่ากลับออกมา และบนระบบ Ubuntu 24.04 แบบตั้งค่ามาตรฐาน คำขอ GET เพียงครั้งเดียวโดยไม่ต้องล็อกอินก็สามารถดึงที่อยู่หน่วยความจำที่จำเป็นต่อการสร้างเพย์โหลดออกมาได้

“ผู้ที่อ่านประกาศของ F5 อาจสรุปได้อย่างสมเหตุสมผลว่านี่เป็นแค่ช่องโหว่ DoS บนระบบทั่วไป แต่มันไม่ใช่” นาย Shaw กล่าว พร้อมระบุว่าในการทดสอบของเขาเองได้ผลสำเร็จ 10 จาก 10 ครั้ง อย่างไรก็ตาม เขาเลือกที่จะยังไม่เปิดเผยรายละเอียดการโจมตีและตัวอย่าง PoC ในตอนนี้ ทำให้ยังไม่มีใครตรวจสอบข้อกล่าวอ้างนี้อย่างเป็นอิสระได้

ที่น่าจับตาคือนี่เป็นช่องโหว่ heap overflow ตัวที่สามในโค้ดส่วนประมวลผลนิพจน์ของ nginx ที่ถูกเปิดเผยภายในเวลาราวสองเดือน ต่อจาก Rift (CVE-2026-42945) เมื่อเดือนพฤษภาคม และช่องโหว่ capture ซ้อนทับในโมดูล rewrite (CVE-2026-9256) ที่ตามมาอีกไม่กี่วัน ทั้งสามตัวเป็นช่องโหว่คลาสเดียวกันทั้งหมด คือกลไกสคริปต์สองรอบของ nginx ที่วัดขนาดบัฟเฟอร์ในรอบหนึ่งแล้วเขียนข้อมูลลงไปในอีกรอบหนึ่ง และทุกครั้งการเขียนก็ล้นเกินขนาดที่วัดไว้ ต่างกันแค่ตัวจุดชนวน โดย Rift เกิดจากแฟล็กที่ค้างอยู่ ส่วนบั๊กใน rewrite เกิดจาก capture ที่ซ้อนทับกัน และครั้งนี้เกิดจากสถานะ capture ที่ถูกทับ จุดอ่อนร่วมกันตามที่นักวิจัยตั้งข้อสังเกตคือการออกแบบแบบสองรอบที่ไว้ใจการวัดของตัวเอง

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

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

ช่องโหว่อยู่ในส่วนที่เรียกว่า script engine ของ nginx ซึ่งเป็นโค้ดที่ทำหน้าที่ประกอบสตริงจากไดเรกทีฟต่างๆ ในขณะที่มีคำขอเข้ามา และจะปรากฏขึ้นเฉพาะกับการตั้งค่ารูปแบบหนึ่งเท่านั้น นั่นคือเมื่อมี map ที่ใช้ regular expression และตัวแปรผลลัพธ์ของ map นั้นถูกอ้างอิงในนิพจน์สตริงที่อยู่หลังการ capture จากการจับคู่ regular expression ก่อนหน้า

ภายใต้รูปแบบดังกล่าว การประเมินผลแบบสองรอบของ engine จะแตกกระจาย รอบแรกทำหน้าที่วัดว่าผลลัพธ์ต้องใช้พื้นที่กี่ไบต์แล้วจองบัฟเฟอร์ให้พอดี ส่วนรอบที่สองเขียนข้อมูลจริงลงไป ปัญหาคือทั้งสองรอบอ่านสถานะ capture ชุดเดียวกัน และการประเมิน regular expression ของ map ที่เกิดขึ้นคั่นกลางระหว่างสองรอบนั้นไปเขียนทับสถานะดังกล่าว

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

รูปแบบการตั้งค่าที่ต้องไล่ตรวจจึงค่อนข้างแคบและเฉพาะเจาะจง คือ map ที่อิงกับ regular expression ซึ่งตัวแปรของมันปรากฏอยู่ในนิพจน์สตริงร่วมกับ capture แบบตัวเลข ($1, $2) จากการจับคู่ก่อนหน้า โดยที่ capture ถูกเขียนไว้ก่อนตัวแปรของ map ทั้งนี้ นาย Shaw ได้พัฒนาสแกนเนอร์ที่ตรวจเงื่อนไขนี้ให้อัตโนมัติทั่วทั้งไฟล์ตั้งค่า ตามไฟล์ที่ถูก include เข้ามา และแจ้งเตือนเฉพาะลำดับที่โจมตีได้จริง โดยเครื่องมือนี้ไม่ได้โจมตีอะไรทั้งสิ้น แต่ก็ต้องเข้าใจว่าเป็นเครื่องมือของผู้รายงานช่องโหว่ ไม่ใช่ผลิตภัณฑ์ที่ผู้ผลิตรับรอง

ผลกระทบต่อไทย

NGINX เป็นเว็บเซิร์ฟเวอร์และรีเวิร์สพร็อกซีที่องค์กรไทยใช้กันอย่างกว้างขวาง ทั้งในเว็บไซต์หน่วยงานรัฐ ระบบธนาคาร แพลตฟอร์มอีคอมเมิร์ซ ไปจนถึงเป็น Ingress Controller ในคลัสเตอร์ Kubernetes ของผู้ให้บริการคลาวด์ในประเทศ เมื่อช่องโหว่กระทบเวอร์ชันย้อนหลังไปถึงปี 2554 ระบบที่ตั้งไว้นานแล้วและไม่เคยอัปเกรดจึงมีโอกาสอยู่ในช่วงที่ได้รับผลกระทบสูงมาก

ข่าวดีคือช่องโหว่นี้ไม่ได้กระทบทุกเครื่องที่รัน NGINX แต่ขึ้นอยู่กับรูปแบบการตั้งค่าที่ค่อนข้างเฉพาะ ทีมงานจึงควรเริ่มจากการไล่ตรวจไฟล์ตั้งค่าเพื่อประเมินความเสี่ยงจริงก่อน แทนที่จะตื่นตระหนกจากคะแนน CVSS 9.2 เพียงอย่างเดียว อย่างไรก็ตาม องค์กรที่ใช้เทมเพลตตั้งค่าสำเร็จรูปจากอินเทอร์เน็ตหรือจากผู้รับเหมาภายนอกควรตรวจสอบเป็นพิเศษ เพราะรูปแบบ map กับ regular expression มักถูกคัดลอกต่อกันมาโดยไม่มีใครทบทวน

จุดที่ควรกังวลเพิ่มเติมสำหรับองค์กรไทยคือ F5 ยังไม่ประกาศเวอร์ชันที่แก้ไขแล้วสำหรับ NGINX Ingress Controller, Gateway Fabric, App Protect WAF และ Instance Manager ซึ่งหมายความว่าองค์กรที่ใช้ผลิตภัณฑ์เหล่านี้ในสภาพแวดล้อมคอนเทนเนอร์อาจยังไม่มีทางแก้ที่สมบูรณ์ในตอนนี้ และต้องพึ่งมาตรการชั่วคราวไปก่อน ประกอบกับที่ผู้รายงานประกาศชัดว่าจะปล่อย PoC หลังแพตช์ 21 วัน ซึ่งหมายถึงต้นเดือนสิงหาคม 2569 กรอบเวลาในการอัปเกรดจึงค่อนข้างจำกัด

คำแนะนำ

วิธีแก้ที่สมบูรณ์คืออัปเกรดเป็น nginx 1.30.4 หรือ 1.31.3 หรือ NGINX Plus 37.0.3.1 ตามสายที่ใช้อยู่ ซึ่งควรทำโดยเร็วที่สุดก่อนที่โค้ดโจมตีสาธารณะจะออกมา

สำหรับผู้ที่ยังอัปเกรดทันทีไม่ได้ มาตรการชั่วคราวที่ F5 แนะนำคือเปลี่ยน map ที่ใช้ regular expression ให้ใช้ named capture แทน ซึ่งนาย Shaw ยืนยันว่าปิดเส้นทางโจมตีหลักและครอบคลุมการตั้งค่าส่วนใหญ่ได้จริง แต่เขาก็เตือนว่ามาตรการนี้ยังเหลือช่องแคบๆ ไว้ กล่าวคือ map ที่นิยาม named group ชื่อเดียวกับที่ใช้ใน regular expression ของ location จะไปถึงจุดล้นเดียวกันได้ผ่านเส้นทางโค้ดอีกทางหนึ่ง ซึ่งเขายืนยันด้วยเครื่องมือ AddressSanitizer แล้ว และประกาศของ F5 ไม่ได้กล่าวถึงประเด็นนี้ เขาจึงย้ำว่า “การอัปเกรดเป็น 1.30.4 หรือ 1.31.3 เป็นทางแก้ที่สมบูรณ์เพียงทางเดียว”

ทีมผู้ดูแลระบบควรไล่ตรวจไฟล์ตั้งค่าทั้งหมดรวมถึงไฟล์ที่ถูก include เข้ามา เพื่อหารูปแบบเสี่ยงคือ map แบบ regular expression ที่ตัวแปรถูกใช้ในนิพจน์สตริงร่วมกับ capture แบบตัวเลขจากการจับคู่ก่อนหน้า และควรจัดลำดับความสำคัญให้เซิร์ฟเวอร์ที่เปิดสู่อินเทอร์เน็ตก่อน

องค์กรที่ใช้ NGINX Ingress Controller, Gateway Fabric, App Protect WAF หรือ Instance Manager ควรติดตามประกาศของ F5 อย่างต่อเนื่องจนกว่าจะมีเวอร์ชันแก้ไขออกมา และในระหว่างนี้ควรใช้มาตรการเปลี่ยนไปใช้ named capture ควบคู่กับการเฝ้าระวังการล่มหรือรีสตาร์ตของโปรเซส worker ที่ผิดปกติ ซึ่งอาจเป็นสัญญาณของการทดลองโจมตี

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