--- title: "ช่องโหว่ NGINX: สาเหตุ การแก้ไข และการตรวจสอบการผลิต" description: "ตรวจสอบช่องโหว่ NGINX ห้าเดือนตุลาคม 2026 ข้อกำหนดเบื้องต้นในการกำหนดค่า การแก้ไขเฉพาะสาขา แบ็คพอร์ตการจัดจำหน่าย และการตรวจสอบการผลิต" language: "th" url: "https://keendigit.com/th/insights/nginx-remediation-guide" author: "KeenDigit" published: "2026-10-14" updated: "2026-10-27" --- # ช่องโหว่ NGINX: สาเหตุ การแก้ไข และการตรวจสอบการผลิต ตรวจสอบช่องโหว่ NGINX ห้าเดือนตุลาคม 2026 ข้อกำหนดเบื้องต้นในการกำหนดค่า การแก้ไขเฉพาะสาขา แบ็คพอร์ตการจัดจำหน่าย และการตรวจสอบการผลิต วันที่บทความในอดีต: 2026-10-14 (วันที่เปิดเผยและวันที่เผยแพร่เรื่องความปลอดภัย) ตรวจสอบแหล่งที่มาและข้อมูลเสริมผ่าน 2026-10-27 บทความนี้ถูกเก็บถาวรตามวันที่จัดงาน การอัปเดตเวอร์ชันและการเปิดตัวที่เผยแพร่หลังวันที่ 14 ตุลาคมมีดังต่อไปนี้ ผู้ชม: เว็บไซต์ NGINX Open Source / NGINX Plus และเจ้าหน้าที่ปฏิบัติการและบำรุงรักษา Reverse proxy เจ้าหน้าที่ตอบสนองด้านความปลอดภัย ผู้ดูแลการจัดจำหน่าย รวมถึงวิศวกรที่คอมไพล์ NGINX ด้วยตนเองและบำรุงรักษาโมดูลของบุคคลที่สาม บทความนี้มุ่งเน้นไปที่ช่องโหว่หลักทั้งห้าของ NGINX ที่ได้รับการเปิดเผยและแก้ไขอย่างเข้มข้นในวันที่ 14 ตุลาคม 2026 และยังมองย้อนกลับไปที่ความปลอดภัยของหน่วยความจำตัวแทนและขอช่องโหว่ด้านความสมบูรณ์ตั้งแต่เดือนพฤษภาคมถึงกันยายน 2026 เนื้อหาครอบคลุมเงื่อนไขทริกเกอร์ สาเหตุระดับโค้ด ขอบเขตผลกระทบ เวิร์กโฟลว์การแก้ไข มาตรการบรรเทาผลกระทบระยะสั้น การใช้แพตช์อย่างเป็นทางการ การส่งแบ็คพอร์ตไปยังสาขาเก่า และการตรวจสอบการผลิต การอ้างอิง เช่น [S1](https://keendigit.com/th/insights/nginx-remediation-guide#source-1) ลิงก์ไปยังภาคผนวกแหล่งที่มา การกำหนดค่าตัวอย่างใช้เพื่อแสดงแนวคิดการปรับใช้และการตรวจสอบเท่านั้น และควรได้รับการตรวจสอบตามเวอร์ชันจริง การสืบทอดการกำหนดค่า การขึ้นต่อกัน และความจุทางธุรกิจก่อนนำไปใช้ ## TL; DR: การดำเนินการตามลำดับความสำคัญ 1. จัดลำดับความสำคัญของการอัพเกรดความปลอดภัย สำหรับแพ็คเกจ nginx.org Open Source ให้อัปเดตสาขา Stable 1.30 เป็นอย่างน้อย 1.30.6 และสาขา Mainline 1.31 เป็นอย่างน้อย 1.31.7. ณ วันที่ตรวจสอบ 1.31.8 จะเป็น Mainline รุ่นใหม่ล่าสุด สิ่งเหล่านี้เป็นข้อมูลพื้นฐานสาขาที่แยกจากกัน อย่าเปรียบเทียบตัวเลขข้ามสาขา [S1](https://keendigit.com/th/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/th/insights/nginx-remediation-guide#source-2) 2. ตรวจสอบการติดตั้งการแจกจ่ายตามเวอร์ชันแพ็คเกจเต็ม Ubuntu 22.04 / 24.04 / 26.04 / 26.10 มีแบ็คพอร์ตของผู้ขาย Debian 13 (trixie) ต้องมีอย่างน้อย `1.26.3-3+deb13u10` ในการตรวจสอบ แพ็กเกจ Debian 12 (bookworm) `1.22.1-9+deb12u10` ยังคงถูกทำเครื่องหมายว่าได้รับผลกระทบ ตรวจสอบ CVE แต่ละรายการ คำแนะนำ Debian 13 ไม่ได้ระบุว่า Debian 12 ได้รับการแก้ไขแล้ว [S13](https://keendigit.com/th/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/th/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/th/insights/nginx-remediation-guide#source-15) 3. ตรวจสอบชุดการกำหนดค่าห้าชุด: `alias + rewrite + $request_filename`, `map` + regex + การประเมินตัวแปร, `aio + ssi + include virtual`, HTTP/3 พร้อม `proxy_request_buffering on` และ `ssl_session_cache shared:...` พร้อมการหมุนเวียนคีย์ตั๋วเซสชัน TLS อัตโนมัติ การมีอยู่ของคำสั่งเพียงอย่างเดียวไม่ได้สร้างความสามารถในการเอารัดเอาเปรียบ ประเมินเส้นทางคำขอและขอบเขตการกำหนดค่า [S1](https://keendigit.com/th/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/th/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/th/insights/nginx-remediation-guide#source-4) 4. แทนที่กระบวนการและคอนเทนเนอร์เก่าทั้งหมด เรียกใช้ `nginx -t` จากนั้นรีสตาร์ทบริการหรือดำเนินการปรับใช้แบบต่อเนื่องที่มีความพร้อมใช้งานสูง ยืนยันว่ากระบวนการ master/worker เก่าได้ออกจากการทำงานแล้ว `nginx -s reload` เพียงอย่างเดียวไม่ได้พิสูจน์ว่าไบนารีที่รันอยู่มีการเปลี่ยนแปลง 5. ตรวจสอบจุดสิ้นสุดจริง: HTTP/1.1, HTTP/2, HTTP/3 หากเปิดใช้งาน, การอัปโหลดพร็อกซีและเนื้อหาคำขอ API, การตรวจสอบใบรับรอง mTLS, หน้า SSI และบันทึกการเข้าถึง บันทึกที่มาของแพ็กเกจ เวอร์ชัน การสรุปรูปภาพ กระบวนการที่รันอยู่ และผลลัพธ์สำหรับแต่ละตำแหน่งข้อมูล 6. หากการอัพเกรดทันทีเป็นไปไม่ได้ ให้ลบเงื่อนไขทริกเกอร์ที่เกี่ยวข้อง: ปิดการใช้งาน SSI/AIO หรือ HTTP/3 ที่ไม่จำเป็น ตรวจสอบช่องโหว่ `alias`/`rewrite`/`map` การอ้างอิงตัวแปร และประเมิน `ssl_session_tickets off;` ชั่วคราวสำหรับบริการ mTLS ที่ได้รับผลกระทบ WAF, ASLR ขีดจำกัดอัตราและการเปลี่ยนแปลงการกำหนดค่าครอบคลุมเฉพาะเงื่อนไขบางประการเท่านั้น และไม่สามารถแทนที่แพตช์อย่างเป็นทางการได้ [S3](https://keendigit.com/th/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/th/insights/nginx-remediation-guide#source-4)[S8](https://keendigit.com/th/insights/nginx-remediation-guide#source-8)[S12](https://keendigit.com/th/insights/nginx-remediation-guide#source-12) ## 1. ภาพรวมช่องโหว่และการตัดสินความเสี่ยง NGINX เปิดตัว 1.30.6 (Stable) และ 1.31.7 (Mainline) เมื่อวันที่ 14 ตุลาคม 2026 โดยแก้ไขปัญหาด้านความปลอดภัยห้าประการ สามรายการเกี่ยวข้องกับฮีปโอเวอร์โฟลว์หรือการใช้งานหลังเลิกใช้ และได้รับคะแนน F5 CVSS v4.0 ของ 9.2 / Critical อีกสองรายการส่งผลต่อความสมบูรณ์ของคำขอ HTTP/3 และการตรวจสอบใบรับรองไคลเอ็นต์ TLS [S1](https://keendigit.com/th/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/th/insights/nginx-remediation-guide#source-2)[S3](https://keendigit.com/th/insights/nginx-remediation-guide#source-3) แยกแยะระบบการให้คะแนน: nginx.org แสดงรายการปัญหาทั้งห้ารายการเป็น `medium` ในขณะที่ F5 CVSS v4.0 และหน่วยงานความมั่นคงแห่งชาติบางแห่งจัดประเภทปัญหาหน่วยความจำสามรายการว่าร้ายแรง นี่ไม่ได้หมายความว่าทั้งห้าอนุญาตให้มีการเรียกใช้โค้ดจากระยะไกลโดยไม่มีเงื่อนไข การกำหนดค่า ความสามารถในการเข้าถึงการรับส่งข้อมูล และเงื่อนไขที่อยู่นอกการควบคุมของผู้โจมตี ความเสียหายของหน่วยความจำและ RCE ที่เชื่อถือได้นั้นเป็นหลักฐานในระดับที่แตกต่างกัน [S1](https://keendigit.com/th/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/th/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/th/insights/nginx-remediation-guide#source-4) | ซีวีอี | ปัญหาทางเทคนิคและเงื่อนไขทริกเกอร์ทั่วไป | ผลกระทบหลัก | การประเมินและการกำจัด | | -------------- | --------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | CVE-2026-15176 | การแมปเส้นทาง `alias` + เปลี่ยน `rewrite` URI + การประเมินผล `$request_filename` | ฮีปบัฟเฟอร์ล้น, Worker หยุดทำงาน; ศักยภาพของ RCE ภายใต้เงื่อนไขบางประการ | F5 CVSS v4.0 9.2; จัดลำดับความสำคัญในการแก้ไขปัญหา | | CVE-2026-93479 | การประเมินสคริปต์ HTTP/Stream โดยเฉพาะการจับภาพ `map` regex และไดเร็กทอรี root, การอ้างอิงโยงตัวแปรบันทึก | บัฟเฟอร์ที่สงวนไว้ถูกเขียนทับและฮีปล้น ศักยภาพของ RCE ภายใต้เงื่อนไขบางประการ | F5 CVSS v4.0 9.2; คือความเสี่ยงจากการถดถอยหลังจากการซ่อมครั้งก่อน | | CVE-2026-97205 | รวม SSI เสมือนและการดำเนินการ AIO/อะซิงโครนัส นับการดำเนินงานที่โดดเด่นล้น | ใช้งานฟรีหลังเกิดปัญหา Worker หน่วยความจำเสียหาย ศักยภาพ RCE | F5 CVSS v4.0 9.2; ต้องมีการกำหนดค่าที่ไม่ใช่ค่าเริ่มต้น | | CVE-2026-95101 | HTTP/3 เฟรมที่ไม่รู้จักกระจัดกระจายไปทั่วบัฟเฟอร์ เปิดใช้งานการบัฟเฟอร์เนื้อหาคำขอพร็อกซี | การฉีดไบต์ที่ไม่ใช่ DATA เข้าไปในเนื้อหาคำขออัปสตรีมไม่ถูกต้อง ซึ่งอาจข้ามขีดจำกัดขนาดเนื้อหาคำขอ | ช่องโหว่นี้ส่งผลต่อความสมบูรณ์ของคำขอ มันไม่ได้จัดให้มีการเรียกใช้โค้ดระยะไกล (RCE) | | CVE-2026-97629 | แคชเซสชัน TLS ที่ใช้ร่วมกัน การหมุนคีย์อัตโนมัติ และการมิเรอร์คีย์ Worker | การปลอมแปลงตั๋วเซสชั่น; การเลี่ยงผ่านการรับรองความถูกต้องใบรับรองไคลเอ็นต์อาจเกิดขึ้นสำหรับบริการ mTLS ที่ได้รับผลกระทบ | ต้องให้ความสนใจเป็นพิเศษกับผลกระทบทางธุรกิจของประเภทการรับรองความถูกต้องของใบรับรอง API | คะแนน CVSS ข้างต้นกำหนดโดย F5 โดยใช้ v4.0 ช่องโหว่เดียวกันอาจแสดงความรุนแรงที่แตกต่างกันใน CVSS 3.1, nginx.org ของตัวเองเกรดและการจัดอันดับความรุนแรงของการจัดจำหน่าย [S1](https://keendigit.com/th/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/th/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/th/insights/nginx-remediation-guide#source-4) ### 1.1 จัดลำดับความสำคัญของการเปิดรับการใช้งานมากกว่าคะแนน CVE เพียงอย่างเดียว | แบบฟอร์มการติดตั้งใช้งาน | จุดสืบสวนที่สำคัญ | คำแนะนำลำดับความสำคัญในการกำจัด | | ---------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | ----------------------------------------------- | | Reverse proxy เครือข่ายสาธารณะ รวมถึง `rewrite`, `alias` และ `map` ที่ซับซ้อนที่กำหนดเอง | CVE-2026-15176, CVE-2026-93479 และเขียนใหม่/แมปช่องโหว่ตั้งแต่เดือนพฤษภาคมถึงกรกฎาคม | P0: ตรวจสอบและอัปเดตทันที | | API / ระนาบการจัดการที่ใช้ใบรับรองไคลเอ็นต์เป็นการตรวจสอบสิทธิ์ทางเข้าหลักเท่านั้นหรือ | ตั๋วเซสชันและการกำหนดค่าแคชที่ใช้ร่วมกันของ CVE-2026-97629 | P0: ยืนยันขอบเขตการตรวจสอบสิทธิ์และอัปเดตทันที | | ให้การอัปโหลด HTTP/3 ภายนอก, อินเทอร์เฟซการเปลี่ยนสถานะ, คลาสธุรกรรม API | CVE-2026-95101 โดยเฉพาะเนื้อหาคำขอจะพร็อกซีไปที่แบ็กเอนด์ | P0/P1: จัดเรียงตามความสำคัญทางธุรกิจ | | SSI เพจไดนามิกหรือ I/O ไฟล์อะซิงโครนัส | CVE-2026-97205 | P1: ยืนยันเงื่อนไขการรวมและซ่อมแซมโดยเร็วที่สุด | | เฉพาะหน้าคงที่ + พร็อกซีย้อนกลับ HTTP/1.1/2 แบบธรรมดา | ยังคงต้องมีการตรวจสอบการกำหนดค่าและเวอร์ชัน แต่เงื่อนไข CVE บางประการอาจหายไป | P1: รวมอยู่ในหน้าต่างอัปเกรดความปลอดภัยฉุกเฉิน | | ใช้ Kubernetes Community ingress-nginx ที่เลิกใช้แล้ว | โครงการหยุดการบำรุงรักษาด้านความปลอดภัย และความเสี่ยงไม่ได้จำกัดอยู่เพียง CVE ทั้งห้านี้ | จัดทำแผนการโยกย้ายตัวควบคุมส่วนบุคคล | P0/P1 คือคำแนะนำในการกำจัดการดำเนินการและการบำรุงรักษาที่ให้ไว้ในบทความนี้สำหรับการเปิดเผยเครือข่ายสาธารณะและความไวในการรับรอง ไม่ใช่การจัดประเภท CVSS อย่างเป็นทางการ และไม่ควรแทนที่สินทรัพย์ภายในขององค์กรและการประเมินความเสี่ยงจากการเปลี่ยนแปลง ### 1.2 ขอบเขตผลกระทบและการอนุญาตการโจมตี ช่องโหว่หลักในชุดนี้ส่วนใหญ่จะอยู่ในระนาบข้อมูล NGINX: จุดเริ่มต้นการโจมตีคือการเชื่อมต่อไคลเอ็นต์และการร้องขอ และผลกระทบที่แท้จริงมักจะเกิดขึ้นในกระบวนการ Worker หากตรงตามเงื่อนไขที่สามารถหาประโยชน์ได้สำหรับความเสียหายของหน่วยความจำ โดยทั่วไปสิทธิ์ในการเรียกใช้โค้ดจะถูกจำกัดโดยผู้ใช้ที่ทำงานอยู่ ข้อจำกัดของคอนเทนเนอร์ ความสามารถของ Linux การติดตั้ง และการอนุญาตเครือข่ายของ Worker ศักยภาพของ RCE ไม่ได้หมายความถึงสิทธิ์ของ root หรือการบุกรุกโฮสต์โดยอัตโนมัติ [S4](https://keendigit.com/th/insights/nginx-remediation-guide#source-4) แต่แม้ว่ากระบวนการนี้จะไม่มีสิทธิ์พิเศษ แต่ก็อาจยังคงสามารถเข้าถึงข้อมูลรับรองพร็อกซี ไฟล์ที่อ่านได้ซึ่งมีคีย์ส่วนตัวของใบรับรอง โทเค็นบริการอัปสตรีม ไฟล์ชั่วคราว API ภายใน และเครือข่ายที่เข้าถึงได้ สำหรับ mTLS การบายพาสการรับรองความถูกต้องอาจส่งผลร้ายแรงทางธุรกิจ และไม่จำเป็นต้องมาพร้อมกับการเรียกใช้โค้ด ## 2. การวิเคราะห์สาเหตุ ### 2.1 ทำความเข้าใจขอบเขตที่เสี่ยงต่อข้อผิดพลาดสามประการใน NGINX NGINX worker เป็นกระบวนการที่ขับเคลื่อนด้วยเหตุการณ์ที่มีอายุการใช้งานยาวนาน ซึ่งจะรักษาสถานะคำขอ การดำเนินการแบบอะซิงโครนัส และตัวแยกวิเคราะห์โปรโตคอล ช่องโหว่นี้รวบรวมข้อจำกัดในระดับวิศวกรรมสามระดับ: 1. การประเมินตัวแปรและขนาดหน่วยความจำต้องสอดคล้องกัน: `rewrite` หลังจากเปลี่ยนคำขอ URI การแมปพาธจะต้องสอดคล้องกับ `location` ที่มีผลในปัจจุบัน เมื่อตัวแปลสคริปต์คำนวณความยาวตัวแปร พื้นที่เขียนจะต้องครอบคลุมเอาต์พุตจริงและพื้นที่ที่สงวนไว้ 2. การดำเนินการแบบอะซิงโครนัสต้องขยายวงจรชีวิตของหน่วยความจำที่ร้องขอ: เมื่อมีการอ่านและเขียนไฟล์ การรอแคช หรืองานเธรดที่ยังไม่เสร็จ พูลหน่วยความจำคำขอที่เกี่ยวข้องจะไม่สามารถเผยแพร่ล่วงหน้าได้ 3. สถานะโปรโตคอลและสถานะความปลอดภัยไม่สามารถผสมหรือละเว้นได้: HTTP/3 ความยาวของการข้ามเฟรมที่ไม่รู้จักไม่สามารถถือเป็นความยาวเนื้อหาคำขอ DATA; TLS ช่องคีย์ทั้งหมดที่เข้าร่วมในการตรวจสอบลายเซ็นจะต้องเริ่มต้นและซิงโครไนซ์อย่างถูกต้องในระหว่างการหมุนเวียนตั๋วเซสชัน เนื้อหาต่อไปนี้อิงตามคำสั่งแก้ไขต้นน้ำ NGINX และประกาศผู้จัดจำหน่าย เพื่ออธิบายกลไกความล้มเหลวที่สามารถทริกเกอร์ได้ ตัวอย่างแฟรกเมนต์มีไว้สำหรับการวิเคราะห์ ไม่ใช่โค้ดที่สมบูรณ์ที่สามารถใช้เพื่อซ่อมแซมสภาพแวดล้อมการใช้งานจริงได้โดยตรง [S5](https://keendigit.com/th/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/th/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/th/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/th/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/th/insights/nginx-remediation-guide#source-9) ### 2.2 CVE-2026-15176: การแมปพาธระหว่าง `alias` และ URI ที่เขียนใหม่ไม่ถูกต้อง ใน NGINX `location` ที่ตรงกันและ `alias` จะกำหนดพาธของไฟล์ `rewrite` สามารถเปลี่ยนคำขอปัจจุบัน URI ได้ หลังจากเขียนใหม่ สมมติฐานที่ใช้โดยการแมป `location` ดั้งเดิมอาจไม่คงอยู่อีกต่อไป เส้นทางการประมวลผลที่ได้รับผลกระทบไม่ได้ตรวจสอบอย่างเพียงพอว่าคำขอถูกเขียนใหม่หรือไม่เมื่อตรวจสอบสถานะ `alias` ใน `ngx_http_map_uri_to_path()` เมื่อการกำหนดค่ายังคงประเมิน `$request_filename` หลังจากเขียนใหม่ เส้นทางอาจถูกสร้างขึ้นด้วยสมมติฐานที่ไม่สอดคล้องกับสถานะ URI ปัจจุบัน ซึ่งท้ายที่สุดจะทริกเกอร์การเขียนนอกขอบเขตไปยังหน่วยความจำฮีป [S5](https://keendigit.com/th/insights/nginx-remediation-guide#source-5) การรวมกันโดยทั่วไป (ใช้เป็นตัวอย่างแย้งสำหรับการตรวจสอบการกำหนดค่าเท่านั้น ไม่แนะนำให้ปรับใช้): ```nginx # 仅用于识别风险模式：不是修复配置 location /foo/ { alias /srv/alias-root/; rewrite ^/foo/.*$ /new-path; return 200 $request_filename; } ``` อันตรายไม่ได้จำกัดอยู่เพียง `return`: `set`, `if`, `add_header`, `log_format` ฯลฯ ยังต้องได้รับการตรวจสอบด้วยหากการประเมิน `$request_filename` ถูกทริกเกอร์ในกระบวนการร้องขอเดียวกัน `return` ในตัวอย่างทำให้มองเห็นพาธสถานะนี้ได้ง่ายเท่านั้น ไม่สามารถใช้อนุมานได้ว่าการกำหนดค่าการผลิตทั้งหมดจะทำให้เกิดโอเวอร์โฟลว์ [S5](https://keendigit.com/th/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/th/insights/nginx-remediation-guide#source-10) ผลที่ตามมาจากการโจมตี: การสร้างคำขออาจทำให้ Worker รีสตาร์ทหรือบริการหยุดชะงัก ภายใต้เงื่อนไขเช่น ASLR ที่ถูกปิดหรือสามารถข้ามได้ ก็มีความเป็นไปได้ที่ RCE แกนหลักของแพตช์อัปสตรีมคือการปฏิเสธที่จะดำเนินการแมปพาธ URI ที่เขียนใหม่ให้เสร็จสิ้นในบริบท `alias` ที่ไม่ถูกต้องอีกต่อไป แทนที่จะขยายบัฟเฟอร์บางตัว [S5](https://keendigit.com/th/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/th/insights/nginx-remediation-guide#source-10) ### 2.3 CVE-2026-93479: ไม่ตรงกันระหว่าง "พื้นที่สงวน" และความยาวตัวแปรจริงในการประเมินสคริปต์ โมดูล HTTP และ Stream ของ NGINX มีตัวประเมินสคริปต์ที่เชื่อมสตริงตัวอักษรและค่าตัวแปรเข้ากับสตริงผลลัพธ์ ตัวอย่างแอปพลิเคชันประกอบด้วยเส้นทางเอกสาร HTTP root เส้นทางบันทึกการเข้าถึง และนิพจน์ตัวแปรใน Stream การกำหนดค่าบางอย่างของ `map` + นิพจน์ทั่วไปทำให้ค่าที่บันทึกไว้สามารถอ่านได้โดยนิพจน์อื่น ก่อนที่จะประเมินตัวแปรผลลัพธ์ `map` เมื่อรวมกับวิธีการดำเนินการสคริปต์ที่มีความยาวที่สงวนไว้ การใช้งานแบบเก่าจะนับพื้นที่ที่สงวนไว้ `len` ลงในตัวสะสมความยาวที่ประเมินล่วงหน้า เพื่อให้การคำนวณตัวชี้การเขียนในภายหลังไม่สอดคล้องกับขอบเขตบัฟเฟอร์อีกต่อไป ในลำดับการประเมินตัวแปรเฉพาะ การเขียนสตริงที่ตามมาอาจเขียนทับพื้นที่ที่สงวนไว้ ทำให้เกิดฮีปโอเวอร์โฟลว์ [S6](https://keendigit.com/th/insights/nginx-remediation-guide#source-6) | องค์ประกอบการมีส่วนร่วม | เหตุใดจึงควรให้ความสนใจ | | -------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | regex ใน `map` | การประเมินตัวแปรการบันทึกอาจมีวงจรชีวิตที่เป็นอิสระและพฤติกรรมการแคช | | การจับแบบไม่ระบุชื่อ เช่น `$1`, `$2` เป็นต้น | เขียนทับได้อย่างง่ายดายด้วยนิพจน์ทั่วไปหรือนิพจน์ทั่วไป ทำให้ยากต่อการติดตามความเป็นเจ้าของ | | ตัวแปรใน `root` | การเรียกใช้สคริปต์และการสำรองบัฟเฟอร์เมื่อทริกเกอร์การสร้างเส้นทาง | | `log_format`/พาธบันทึกไดนามิก | การประเมินประเภทเดียวกันอาจถูกทริกเกอร์ในภายหลังในคำขอ | | นิพจน์สคริปต์ใน `stream` | การแก้ไขอัปสตรีมยังปรับเปลี่ยน `ngx_stream_script_run()` คุณไม่สามารถตรวจสอบเฉพาะโมดูล HTTP เท่านั้น | ความสัมพันธ์การถดถอยที่สำคัญ: รหัสที่เกี่ยวข้องกับช่องโหว่นี้เกี่ยวข้องกับการเปลี่ยนแปลงก่อนหน้านี้ที่แก้ไข CVE-2026-42533 DSA อย่างเป็นทางการสำหรับ Debian 13 ระบุไว้อย่างชัดเจนว่ามีการแนะนำโค้ดที่ได้รับผลกระทบในแพ็คเกจ trixie ผ่านทาง backport การรักษาความปลอดภัยก่อนหน้านี้ ดังนั้น "การติดตั้งแพตช์ช่องโหว่ `map` เดือนกรกฎาคม" ไม่ได้หมายความว่าครอบคลุม CVE-2026-93479 ของเดือนตุลาคมแล้ว ควรตรวจสอบห่วงโซ่การรักษาความปลอดภัยทั้งหมด [S6](https://keendigit.com/th/insights/nginx-remediation-guide#source-6)[S14](https://keendigit.com/th/insights/nginx-remediation-guide#source-14)[S17](https://keendigit.com/th/insights/nginx-remediation-guide#source-17) ความเสี่ยงของ RCE ที่อาจเกิดขึ้นที่นี่เกี่ยวข้องกับสภาพแวดล้อมการป้องกันหน่วยความจำ และไม่ควรอ้างว่า `map` regex เพียงอย่างเดียวจะสามารถถูกโจมตีโดยผู้โจมตีที่ไม่ระบุชื่อได้ [S11](https://keendigit.com/th/insights/nginx-remediation-guide#source-11) ### 2.4 CVE-2026-97205: AIO การนับจำนวนการดำเนินการที่ยังไม่เสร็จทำให้เกิดการใช้งานหลังเลิกใช้งาน ช่องโหว่นี้ไม่ใช่แค่ "เปิด SSI แล้วคุณจะได้รับ UAF" คีย์อยู่ที่จำนวนการอ้างอิงการดำเนินการแบบอะซิงโครนัสที่ถือโดยคำขอหลัก NGINX ใช้ `r->main->blocked` เพื่อติดตามการประมวลผลแบบอะซิงโครนัสที่ยังไม่เสร็จสมบูรณ์ ในการใช้งานแบบเก่านั้นมีจำนวน 8 บิต บางเส้นทางไม่ได้ทำการตรวจสอบขีดจำกัดบนก่อนที่จะเพิ่มจำนวน เมื่อคำขอหลักเดียวกันสะสมการดำเนินการคงค้าง 256 รายการ การนับอาจวนจาก 255 เป็น 0 กระบวนการต่อมาจะเข้าใจผิดว่าไม่มีการดำเนินการแบบอะซิงโครนัสที่ขัดขวางไม่ให้มีการเผยแพร่คำขอ ดังนั้นจึงปล่อยพูลหน่วยความจำคำขอที่ยังคงอ้างอิงโดยงาน [S7](https://keendigit.com/th/insights/nginx-remediation-guide#source-7) กระบวนการล้มเหลวสามารถแบ่งออกเป็น: 1. เมื่อเปิดใช้งาน I/O/เส้นทางเธรดแบบอะซิงโครนัสที่เกี่ยวข้อง หน้า SSI จะแนะนำคำขอย่อยหลายรายการหรือการดำเนินการอ่านผ่าน `include virtual` 2. การดำเนินการคงค้างของคำขอหลักบางรายการจะสะสมจนถึงขีดจำกัดบนที่แสดงโดยฟิลด์การนับ 3. การนับแบบ 8 บิตวนเวียน แสดงอย่างไม่ถูกต้องว่า "ไม่มีการดำเนินการที่รอดำเนินการ" 4. พูลหน่วยความจำคำร้องขอจะถูกปล่อยออกมา ในขณะที่การอ่านไฟล์ การรอแคช หรือการเรียกกลับของงานเธรดยังคงรักษาการอ้างอิงไว้ 5. การเรียกกลับเสร็จสิ้นแบบอะซิงโครนัสตามมาจะเข้าถึงหน่วยความจำที่ปล่อยออกมา ส่งผลให้ UAF, Worker หยุดทำงานหรือหน่วยความจำเสียหาย การแก้ไขอย่างเป็นทางการจะเพิ่ม `NGX_HTTP_MAX_BLOCKED 250` ลงในไฟล์ส่วนหัวของคำขอ และเพิ่มข้อจำกัดให้กับตัวกรองเอาต์พุต การอ่านแคช และเส้นทางเธรดอัปสตรีม เมื่อถึงเกณฑ์ การดำเนินการกับพาธที่ซิงโครไนซ์จะเสร็จสมบูรณ์พร้อมกัน และหากไม่สามารถประมวลผลได้อย่างปลอดภัย การเพิ่มงานที่ค้างอยู่จะถูกปฏิเสธ [S7](https://keendigit.com/th/insights/nginx-remediation-guide#source-7) การตัดสินการบังคับใช้: จะต้องได้รับการประเมินว่า SSI, AIO, การรวมเสมือน, คำขอย่อย และการดำเนินการอะซิงโครนัสที่เกี่ยวข้องสามารถเกิดขึ้นร่วมกันในห่วงโซ่คำขอเดียวกันได้หรือไม่ โดยปกติแล้วสิ่งเหล่านี้จะไม่ใช่การกำหนดค่าพร็อกซีคงที่แบบธรรมดาที่เป็นค่าเริ่มต้น `aio off;` หรือ `ssi off;` สามารถลบองค์ประกอบทริกเกอร์เฉพาะได้ แต่ควรยืนยันการขึ้นต่อกันของฟังก์ชันธุรกิจก่อน [S4](https://keendigit.com/th/insights/nginx-remediation-guide#source-4)[S7](https://keendigit.com/th/insights/nginx-remediation-guide#source-7)[S25](https://keendigit.com/th/insights/nginx-remediation-guide#source-25) ### 2.5 CVE-2026-95101: เฟรมที่ไม่รู้จัก HTTP/3 สับสนกับสถานะของเนื้อหาคำขอ DATA ตัวแยกวิเคราะห์เฟรม HTTP/3 ต้องแยกแยะระหว่างเฟรม `DATA` (ซึ่งจำเป็นต้องส่งผ่านไปยังการประมวลผลเนื้อหาคำขอ HTTP) และเฟรมที่ไม่รู้จักซึ่งควรข้ามไป ความยาวของเฟรมที่ไม่รู้จักจะต้องได้รับการเก็บรักษาไว้อย่างถูกต้องเมื่อแยกส่วนในบัฟเฟอร์เครือข่าย การใช้งาน `ngx_http_v3_parse_data()` แบบเก่าใช้ฟิลด์ `st->length` เพื่อบันทึก "จำนวนไบต์ที่เหลือที่จะข้าม" เมื่อข้ามเฟรมที่ไม่รู้จัก ในขณะที่ตัวกรองเนื้อหาคำขอตีความฟิลด์เดียวกันกับ "ความยาวเพย์โหลด DATA ที่เหลืออยู่" หากเฟรมที่ไม่รู้จักเกิดขึ้นเพื่อขยายการเรียกแยกวิเคราะห์หลายครั้ง ชุดไบต์ถัดไปหลังจากการแยกวิเคราะห์ถูกขัดจังหวะอาจถูกเข้าใจผิดว่าเป็นส่วนหนึ่งของเนื้อหาคำขอ [S8](https://keendigit.com/th/insights/nginx-remediation-guide#source-8) ความเสี่ยงเกิดขึ้นสองประเภท: - ขอการฉีดเนื้อหา: เพย์โหลดเฟรมที่ไม่ใช่ DATA ที่ไคลเอ็นต์ส่งมาอาจถูกส่งไปยังแอปพลิเคชันอัปสตรีม โดยเปลี่ยนข้อมูลที่ได้รับจริงจากแบ็กเอนด์ - การข้ามขีดจำกัดขนาด: `client_max_body_size` และข้อจำกัดอื่นๆ การตรวจสอบที่คาดหวังจะเน้นไปที่เส้นทาง DATA และเนื้อหาที่แปลงอย่างไม่ถูกต้องอาจข้ามการตรวจสอบที่เกี่ยวข้อง สถานการณ์ทริกเกอร์ทั่วไปที่อธิบายโดยเจ้าหน้าที่คือเมื่อ `ngx_http_v3_module` ได้รับคำขอ HTTP/3 และส่งต่อ `proxy_request_buffering on` การบัฟเฟอร์เนื้อหาคำขอพร็อกซีถูกเปิดใช้งานโดยค่าเริ่มต้นใน `ngx_http_proxy_module` ดังนั้น ควรตรวจสอบพร็อกซีย้อนกลับที่เปิด HTTP/3 ก่อน ไม่เหมาะสมที่จะถือว่าไม่มีเงื่อนไขทริกเกอร์เพียงเพราะว่า `proxy_request_buffering on;` ไม่ได้ถูกเขียนไว้อย่างชัดเจน [S8](https://keendigit.com/th/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/th/insights/nginx-remediation-guide#source-18) ผลที่ตามมาโดยตรงจากช่องโหว่นี้เป็นของความสมบูรณ์ของคำขอแบ็กเอนด์และการเปลี่ยนแปลงขอบเขตความปลอดภัย ซึ่งไม่ใช่นิพจน์ที่เทียบเท่ากับ RCE ที่เสร็จสมบูรณ์โดยตรงในแกน NGINX ผลกระทบทางธุรกิจขั้นสุดท้ายขึ้นอยู่กับวิธีการแยกวิเคราะห์ไบต์เหล่านี้และต้นทางที่เชื่อถือได้ [S24](https://keendigit.com/th/insights/nginx-remediation-guide#source-24) ### 2.6 CVE-2026-97629: TLS การหมุนเวียนตั๋วพลาดช่องคีย์ที่สาม ในการกำหนดค่าที่ได้รับผลกระทบ NGINX สามารถสร้างและหมุนคีย์ตั๋วเซสชัน TLS โดยอัตโนมัติผ่านแคชหน่วยความจำที่ใช้ร่วมกัน ทำให้ Worker หลายตัวสามารถประมวลผลตั๋วชุดเดียวกันได้ ตรรกะการซิงโครไนซ์ที่เกี่ยวข้องจะจัดสรรสล็อตคีย์ 3 ช่องสำหรับแต่ละ Worker และการเรียกกลับเพื่อถอดรหัสจะสำรวจช่องเหล่านี้ด้วย แต่การใช้งานแบบเก่าจะคัดลอกช่องคีย์เพียง 2 ช่องจากหน่วยความจำที่ใช้ร่วมกันในแต่ละครั้ง ส่งผลให้ชื่อคีย์ คีย์ HMAC และ AES ของช่องที่สาม คีย์อาจยังไม่ได้เตรียมใช้งาน หากตัวระบุคีย์ของตั๋วตรงกับสถานะนี้ วัสดุคีย์ที่ยังไม่ได้เตรียมใช้งานอาจถูกนำมาใช้สำหรับการตรวจสอบลายเซ็นและการถอดรหัส ซึ่งจะสร้างเส้นทางเพื่อสร้างเซสชัน TLS [S9](https://keendigit.com/th/insights/nginx-remediation-guide#source-9) โดยทั่วไปชุดค่าผสมการปรับใช้งานที่มีความเสี่ยงสูงมีดังนี้: ```nginx # 仅为排查触发条件所示：共享缓存本身不是恶意配置 ssl_session_cache shared:SSL:10m; # 未显式配置 ssl_session_ticket_key 文件，使用自动轮换机制 ``` ผลลัพธ์ทางธุรกิจที่ร้ายแรงที่สุดของช่องโหว่นี้คือในบริการที่ใช้การรับรองความถูกต้องใบรับรองไคลเอ็นต์ (mTLS) ใน `ssl_verify_client on;` และวิธีอื่น ๆ เซสชันการกู้คืนที่ปลอมแปลงอาจข้ามการตรวจสอบใบรับรองไคลเอ็นต์ ความสำเร็จของการโจมตีนั้นขึ้นอยู่กับเงื่อนไขที่ไม่สามารถควบคุมได้เช่นกัน ไซต์ที่ใช้เฉพาะใบรับรอง HTTPS ฝั่งเซิร์ฟเวอร์ปกติและไม่มีการตรวจสอบสิทธิ์ใบรับรองไคลเอ็นต์ไม่ควรมีลักษณะผิดเนื่องจาก "ผู้โจมตีสามารถข้ามการเข้าสู่ระบบเว็บไซต์ทั้งหมดได้" [S9](https://keendigit.com/th/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/th/insights/nginx-remediation-guide#source-12) นี่เป็นปัญหาสถานะการตรวจสอบสิทธิ์เซสชัน TLS และไม่มีส่วนเกี่ยวข้องกับคีย์ส่วนตัว TLS ของเซิร์ฟเวอร์ถูกถอดรหัสหรือไม่ หรือใบรับรอง CA root สาธารณะได้รับผลกระทบหรือไม่ [S24](https://keendigit.com/th/insights/nginx-remediation-guide#source-24) ### 2.7 วิธีทำความเข้าใจ DoS, RCE, การเลี่ยงการรับรองความถูกต้องและช่องโหว่ที่รู้จัก - DoS: ข้อผิดพลาดของหน่วยความจำทำให้ Worker หยุดทำงานหรือรีบูตจำนวนมาก ไม่ว่าสาเหตุนั้นจะทำให้เกิดความไม่พร้อมใช้งานโดยรวมหรือไม่นั้นจะขึ้นอยู่กับความกดดันด้านการรับส่งข้อมูล ความสามารถในการรีสตาร์ทกระบวนการ เวลาในการบำรุงรักษาการเชื่อมต่อ และสถาปัตยกรรมที่มีความพร้อมใช้งานสูง - ศักยภาพของ RCE: การประกาศบางอย่างระบุว่ามีความเป็นไปได้ที่จะมีการเรียกใช้โค้ดเมื่อ ASLR ถูกปิดหรือข้าม นี่ไม่ได้หมายความว่ามีการเปิดเผยห่วงโซ่การโจมตีสาธารณะที่สามารถดำเนินการคำสั่งได้อย่างเสถียรและเป็นสากล [S4](https://keendigit.com/th/insights/nginx-remediation-guide#source-4) - ขอบายพาสการแทรก/การรับรองความถูกต้อง: อาจเปลี่ยนสถานะธุรกิจที่ได้รับการคุ้มครองหรือเนื้อหาคำขอโดยตรง และไม่สามารถเพิกเฉยได้เพียงเพราะมันไม่ได้รับเชลล์โดยตรง - ได้ค้นพบความพยายามในการโจมตี: CVE-2026-42945 ในเดือนพฤษภาคม 2569 มีรายงานกิจกรรมการแสวงหาผลประโยชน์ในป่า ไม่ควรสรุปข้อเท็จจริงทางประวัติศาสตร์นี้โดยตรงเพื่อหมายความว่า CVE ทั้งห้ารายการในเดือนตุลาคมได้ถูกนำไปใช้ประโยชน์ในวงกว้างอย่างประสบความสำเร็จ [S23](https://keendigit.com/th/insights/nginx-remediation-guide#source-23) ## 3. การเลือกเวอร์ชันการซ่อมแซมและแพตช์ ### 3.1 NGINX Open Source พื้นฐานแพตช์อย่างเป็นทางการ | สาขาต้นน้ำ | เวอร์ชันอย่างเป็นทางการครั้งแรกครอบคลุมช่องโหว่ห้ารายการในเดือนตุลาคม | คำแนะนำ ณ 2026-10-27 | | ---------------------------------- | --------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | Stable 1.30.x | 1.30.6（2026-10-14） | ติดตั้งอย่างน้อย 1.30.6 และติดตามผลด้วยเวอร์ชันความปลอดภัยที่ตามมา | | Mainline 1.31.x | 1.31.7（2026-10-14） | 1.31.8（2026-10-21） | | สาขา NGINX Open Source ก่อนหน้านี้ | ไม่สามารถตัดสินได้จาก "การใช้แพตช์ช่องโหว่เก่า" เท่านั้น | ย้ายไปยังสาขาที่ได้รับการบำรุงรักษาก่อน มิฉะนั้น ผู้จำหน่ายจะต้องแสดงหลักฐานการสนับสนุนอย่างเป็นทางการตาม CVE-by-CVE | สิ่งเหล่านี้คือบทสรุปเวอร์ชันของซอร์สโค้ดอัพสตรีม nginx.org/สาขาอย่างเป็นทางการ และไม่ควรใช้เพื่อปฏิเสธแพ็คเกจความปลอดภัยโดยตรงด้วยการแก้ไขแบ็คพอร์ตที่จัดทำโดยผู้จำหน่ายการจัดจำหน่าย แม้ว่าค่าของ `1.31.6` จะมากกว่า `1.30.6` แต่ก็ยังต่ำกว่าค่าพื้นฐานแพตช์ของสาขา mainline [S1](https://keendigit.com/th/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/th/insights/nginx-remediation-guide#source-2) ### 3.2 ขอบเขตผลกระทบต้นน้ำของ CVE ห้ารายการ ช่วงต่อไปนี้แสดงรายการตามข้อความต้นฉบับของกระดานข่าวความปลอดภัย nginx.org และจำเป็นต้องทำความเข้าใจร่วมกับ "สาขาที่ทำงานอยู่ในปัจจุบัน" และ "เส้นทางการกำหนดค่าจริง": | ซีวีอี | แท็กอัปสตรีมเวอร์ชันที่ได้รับผลกระทบ | เวอร์ชันคงที่ที่มีป้ายกำกับอย่างเป็นทางการ | | -------------- | ------------------------------------ | ----------------------------------------------- | | CVE-2026-15176 | `0.1.29–1.31.6` | `1.30.6+` หรือ `1.31.7+` ภายในสาขาที่เกี่ยวข้อง | | CVE-2026-93479 | `1.30.0–1.30.5`，`1.31.2–1.31.6` | เช่นเดียวกับข้างต้น | | CVE-2026-97205 | `0.8.11–1.31.6` | เช่นเดียวกับข้างต้น | | CVE-2026-95101 | `1.25.0–1.31.6` | เช่นเดียวกับข้างต้น | | CVE-2026-97629 | `1.23.2–1.31.6` | เช่นเดียวกับข้างต้น | CVE-2026-93479 มีขีดจำกัดเวอร์ชันแนะนำเฉพาะ ไม่ใช่ว่า NGINX รุ่นเก่าทุกเวอร์ชันจะได้รับผลกระทบจากการถดถอยนี้ เวอร์ชันเก่าที่อยู่นอกช่วงดังกล่าวอาจยังคงได้รับผลกระทบจากช่องโหว่ regex ของ `map` รุ่นก่อนหน้า CVE-2026-42533 [S1](https://keendigit.com/th/insights/nginx-remediation-guide#source-1) ### 3.3 Ubuntu: แบ็กพอร์ตการแจกจ่าย (USN-8955-1) Canonical USN-8955-1 วันที่ 26 ตุลาคม 2026 มีการอัปเดตความปลอดภัยสำหรับรุ่น Ubuntu สี่รุ่น: [S13](https://keendigit.com/th/insights/nginx-remediation-guide#source-13) | เวอร์ชัน Ubuntu | `nginx` และเวอร์ชันคงที่ของแพ็กเกจซอร์สเดียวกัน | คำอธิบาย | | --------------- | ----------------------------------------------- | ------------------------------------------------------------------ | | 22.04 LTS | `1.18.0-6ubuntu14.22` | มันเป็น backport ของผู้ขาย หมายเลขเวอร์ชันอัปสตรีมยังคงแสดง 1.18.0 | | 24.04 LTS | `1.24.0-2ubuntu7.19` | เช่นเดียวกับข้างต้น | | 26.04 LTS | `1.28.3-2ubuntu1.12` | เช่นเดียวกับข้างต้น | | 26.10 | `1.30.4-7ubuntu1.1` | เช่นเดียวกับข้างต้น | การประกาศประกอบด้วยแพ็คเกจที่คล้ายคลึงกันในเวอร์ชันคงที่ เช่น `nginx-core`, `nginx-extras`, `nginx-full` และ `nginx-light` อย่าสรุปว่าจะแก้ไขจากส่วนอัปสตรีมที่แสดงโดย `nginx -v` เท่านั้นหรือไม่ เช่น Ubuntu 24.04 และ `1.24.0-2ubuntu7.19` ได้รับการแพตช์โดยผู้จำหน่ายรายนี้ แต่ `1.24.0` จากแหล่งใดๆ ก็ไม่ปลอดภัยโดยเนื้อแท้ Ubuntu ระบุไว้อย่างชัดเจนอย่างเป็นทางการว่า CVE-2026-95101 มีผลเฉพาะกับ Ubuntu 26.04 / 26.10 และ CVE-2026-97629 มีผลเฉพาะกับ Ubuntu 24.04 / 26.04 /26.10. ต่อไปนี้เป็นบรรจุภัณฑ์และขอบเขตการทำงานของ Ubuntu ซึ่งไม่สามารถส่งเสริมการจำหน่ายอื่นๆ ได้โดยตรง [S13](https://keendigit.com/th/insights/nginx-remediation-guide#source-13) ### 3.4 Debian: ต้องตรวจสอบความแตกต่างระหว่างเวอร์ชันแยกต่างหาก ที่ปรึกษา Debian DSA-6575-1 (2026-10-21) ครอบคลุม CVE ห้ารายการเหล่านี้ และระบุแพ็คเกจ `nginx` แบบคงที่สำหรับ Debian 13 / trixie เป็น: ```text 1.26.3-3+deb13u10 ``` อย่างไรก็ตาม ในขณะที่ตรวจสอบรายงานนี้ `1.22.1-9+deb12u10` สำหรับ Debian 12 / bookworm ยังคงถูกตั้งค่าสถานะว่ามีช่องโหว่โดย Debian Security Tracker ดังนั้น: - Debian 13 เพียงอัพเดตและยอมรับตาม DSA-6575-1 - Debian 12 ต้องตรวจสอบการแก้ไขด้านความปลอดภัยที่ได้รับจาก Security Tracker หรือผู้จำหน่าย ELTS ปัจจุบันทีละรายการ ก่อนที่การแก้ไขจะได้รับการยืนยันในประกาศ อย่าประกาศว่าทั้งห้ารายการได้รับการแก้ไขตามความสำเร็จของ `apt upgrade` - แพ็คเกจแหล่งที่มา Debian อาจมีชุดแพตช์ที่ไม่ขึ้นอยู่กับหมายเลขเวอร์ชัน nginx.org สำหรับบิลด์แบบกำหนดเอง คุณต้องตรวจสอบชุดฟิกซ์แพ็กเกจซอร์สโค้ดที่สมบูรณ์ และคุณไม่สามารถคัดลอกการคอมมิตอัปสตรีมเพียงรายการเดียวและพิจารณาว่าเสร็จสมบูรณ์แล้ว ความแตกต่างข้างต้นขึ้นอยู่กับบันทึกการติดตามของ DSA และ CVE [S14](https://keendigit.com/th/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/th/insights/nginx-remediation-guide#source-15)[S16](https://keendigit.com/th/insights/nginx-remediation-guide#source-16) ### 3.5 NGINX Plus, njs และตัวควบคุมทางเข้า | สินค้า/ส่วนประกอบ | ประเด็นสำคัญในการเลือกและการตรวจสอบความปลอดภัย | | ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | NGINX Plus (เวอร์ชันเชิงพาณิชย์) | โปรดดูคำแนะนำการประกาศและการอัพเกรดของสาขา Plus ที่สอดคล้องกับ F5 CR ล่าสุด ณ เวลาที่ตรวจสอบคือ `PLS.37.2.0.1` และรุ่นความปลอดภัยของ LTS คือ `PLS.37.0.7.1` เวอร์ชัน Plus และ backport ที่รวมไว้ไม่สามารถแทนที่ได้โดยตรงด้วยเกณฑ์ 1.30/1.31 ของ Open Source [S19](https://keendigit.com/th/insights/nginx-remediation-guide#source-19) | | njs / ngx\_http\_js\_module | 2026-10-14 เปิดตัว `njs 1.0.2` และแก้ไข CVE-2026-101019 และ CVE-2026-101025 หากคุณใช้ njs คุณต้องตรวจสอบความเข้ากันได้ของโมดูลกับ NGINX ด้วย [S20](https://keendigit.com/th/insights/nginx-remediation-guide#source-20) | | F5 NGINX ตัวควบคุมทางเข้า / ผ้าเกตเวย์ | แกน NGINX เป็นเครือข่ายการจัดจำหน่ายซอฟต์แวร์ที่เกี่ยวข้องแต่เป็นอิสระ แก้ไขช่องโหว่ที่เกี่ยวข้องด้วยตัวควบคุม รูปภาพ และบันทึกประจำรุ่นที่เกี่ยวข้อง คุณไม่สามารถแทนที่ไบนารี NGINX ใน Pod ได้ | | ชุมชน Kubernetes `kubernetes/ingress-nginx` | โครงการนี้เลิกใช้งานในเดือนมีนาคม 2026 และจะไม่มีการบำรุงรักษาความปลอดภัยใหม่อีกต่อไป คุณควรวางแผนที่จะย้ายไปยังคอนโทรลเลอร์ที่ได้รับการบำรุงรักษาหรือ Gateway API แทนที่จะเข้าใจผิดหมายเลขรุ่นสำหรับ F5 NGINX Ingress Controller [S21](https://keendigit.com/th/insights/nginx-remediation-guide#source-21) | ### 3.6 คุณควรเลือก Patch ใด? | แบบฟอร์มการติดตั้งใช้งาน | แนวทางปฏิบัติที่แนะนำ | หลักฐานการซ่อม | | ---------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | | แพ็คเกจ DEB/RPM อย่างเป็นทางการของ nginx.org | อัปเกรดเป็นเวอร์ชันคงที่ของสาขาอัปสตรีม | `nginx -v/-V` แหล่งแพ็คเกจ ประกาศความปลอดภัยอย่างเป็นทางการ | | พื้นที่เก็บข้อมูลอย่างเป็นทางการ Ubuntu/Debian | ติดตั้งแพ็คเกจการรักษาความปลอดภัยของผู้ขาย | เวอร์ชันแพ็คเกจเต็ม + สถานะ USN/DSA + CVE ของผู้จัดจำหน่าย | | RHEL/Alma/Rocky/SUSE/การแจกแจงอื่นๆ | อัปเกรดตามกระดานข่าวความปลอดภัยการกระจายเฉพาะและเวอร์ชันแพ็คเกจ | CSAF/ประกาศของผู้จำหน่ายที่เกี่ยวข้อง เวอร์ชัน Ubuntu/Debian ไม่สามารถใช้ได้ | | อิมเมจคอนเทนเนอร์อย่างเป็นทางการหรือแบบกำหนดเอง | สร้างหรือดึงอิมเมจการซ่อมแซมที่ได้รับการตรวจสอบแล้วและแทนที่แบบต่อเนื่อง | การแยกย่อยอิมเมจ, สร้าง SBOM, การรัน ID รูปภาพของพ็อด/คอนเทนเนอร์ | | NGINX, OpenResty, Tengine ที่คอมไพล์เอง หรือเวอร์ชันที่แพตช์ด้วยโมดูลของบริษัทอื่น | จัดลำดับความสำคัญการใช้เวอร์ชันความปลอดภัยเต็มรูปแบบของผู้ดูแล ดำเนินการแบ็คพอร์ตแพตช์ที่ได้รับการตรวจสอบแล้วสำหรับแผนผังต้นทางเป้าหมายเมื่อจำเป็น | การแก้ไขช่องโหว่ 5 รายการ, ความเข้ากันได้ของ ABI/โมดูล, หน่วยและการถดถอยของธุรกิจ | OpenResty และ Tengine เป็นระบบรีลีสที่แตกต่างกัน ตารางนี้อธิบายเฉพาะวิธีการยืนยันเท่านั้น ไม่ได้หมายความว่าทุกเวอร์ชันจะได้รับผลกระทบในเวลาเดียวกันกับ NGINX มาตรฐาน และไม่สามารถใช้แพตช์โค้ดอัปสตรีมได้โดยไม่มีเงื่อนไข ## 4. กระบวนการซ่อมแซมอย่างเป็นทางการ ### 4.1 รายการอินสแตนซ์จริงของการรับทราฟฟิกภายนอก จัดเรียงสำหรับแต่ละรายการอย่างน้อย: - ชื่อโดเมน, โหลดบาลานซ์/CDN/ลิงก์พร็อกซี Edge, วิธีการเปิดเผยไซต์ต้นทาง และโปรโตคอลเครือข่ายที่ใช้ - ผลิตภัณฑ์ NGINX (โอเพ่นซอร์ส, Plus, Ingress ฯลฯ ) เวอร์ชันเต็ม แหล่งเก็บข้อมูลแพ็กเกจ การย่อยรูปภาพ - `nginx -V` จะแสดงโมดูลอาคารและพารามิเตอร์การคอมไพล์ ไม่ว่าจะมี njs, Lua, OpenResty และโมดูลไดนามิกของบริษัทอื่นหรือไม่ - master/worker PID, หน่วยบริการ/คอนเทนเนอร์/พ็อด, เรพลิกาและโหนด Worker ที่กำลังทำงานอยู่จริง - การกำหนดค่า `http`/`stream`, `server`, `location`, `include` ที่มีประสิทธิภาพจริง - ไม่ว่าจะเปิดใช้งาน HTTP/3, mTLS, SSI/AIO, เส้นทางบันทึกแบบไดนามิก, `map` ที่ซับซ้อน และการจับภาพ regex อย่าเพิ่งตรวจสอบ `/etc/nginx/nginx.conf` เริ่มต้น สภาพแวดล้อมการใช้งานจริงมักจะโหลดหลายไซต์ TLS และการกำหนดค่าโมดูลผ่าน `include` อาจมีหลายพาธการติดตั้ง NGINX หรือพร็อกซีหลายชั้น ### 4.2 ตรวจสอบเวอร์ชันและข้อมูลการคอมไพล์ ```bash # NGINX 版本及构建选项 nginx -v nginx -V 2>&1 # Linux：查看实际运行的 NGINX 进程 ps -eo pid,ppid,user,comm,args | grep '[n]ginx' # Debian / Ubuntu：查看完整已安装包版本、来源 apt-cache policy nginx # 兼顾 nginx-core / nginx-full / nginx-extras 等实际已安装包 dpkg-query -W 'nginx*' 2>/dev/null # RPM 系：以实际安装包及仓库公告为准 rpm -qa | grep '^nginx' ``` `nginx -V` รายงานการสร้างไบนารีที่พบในพาธบรรทัดคำสั่ง มันไม่ได้พิสูจน์ว่า worker ที่ทำงานอยู่ได้โหลดมันแล้ว `nginx -v` อาจละเว้นส่วนต่อท้ายแพ็คเกจแบบเต็มของการแจกจ่าย ดังนั้นโปรดตรวจสอบผู้จัดการแพ็คเกจหรือบันทึกห่วงโซ่อุปทานด้วย ### 4.3 ส่งออกการกำหนดค่าที่มีประสิทธิภาพ และดำเนินการคัดกรองแบบคงที่รอบแรก `nginx -T` จะทดสอบการกำหนดค่าและดัมพ์การกำหนดค่าที่รวมเข้าด้วยกัน เอาต์พุตอาจมีข้อมูลที่ละเอียดอ่อน เช่น ข้อมูลรับรองการตรวจสอบ เส้นทางคีย์ ชื่อโฮสต์ภายใน ฯลฯ ขอแนะนำให้บันทึกเทอร์มินัลที่ควบคุมด้วยสิทธิ์ root และการอนุญาตไฟล์ส่วนตัว และอย่าโพสต์ไฟล์ต้นฉบับในคำสั่งงานสาธารณะ: ```bash sudo sh -c 'umask 077; nginx -T > /root/nginx-effective.conf 2> /root/nginx-config-check.log' sudo grep -nE \ 'alias|rewrite|map[[:space:]]|request_filename|aio[[:space:]]|ssi[[:space:]]|quic|http3|proxy_request_buffering|ssl_session_cache|ssl_session_ticket_key|ssl_session_tickets|ssl_verify_client|log_format|root[[:space:]]' \ /root/nginx-effective.conf ``` นี่เป็นเพียงตัวระบุตำแหน่งเส้นทางที่เป็นตัวเลือก ไม่ใช่เครื่องมือกำหนดอัตโนมัติ CVE ที่เชื่อถือได้: 1. `grep` ไม่สามารถระบุได้ว่าตัวแปรอยู่ใน `location` เดียวกันหรือเชนการประเมินคำขอเดียวกัน และไม่สามารถอนุมานความสัมพันธ์ที่สืบทอดการกำหนดค่าได้ 2. `proxy_request_buffering on` การกำหนดค่าแคชและตั๋วบางอย่างมีค่าเริ่มต้น และการไม่เขียนคำสั่งที่เกี่ยวข้องไม่ได้หมายความว่าความเสี่ยงจะหายไป 3. การกำหนดค่าที่สร้างโดย Reverse Proxies, CDN, Sidecar ของคอนเทนเนอร์ หรือตัวควบคุมอาจแตกต่างจากไฟล์ที่ตรวจสอบด้วยตนเอง 4. อาจต้องยืนยันคุณสมบัติของ `NGINX Plus` และโมดูลไดนามิกโดยใช้เครื่องมือการจัดการอย่างเป็นทางการที่เกี่ยวข้อง ### 4.4 ปรับใช้การแก้ไขผ่านช่องทางที่เชื่อถือได้ Debian/Ubuntu (พื้นที่เก็บข้อมูลการจัดจำหน่ายอย่างเป็นทางการ): ```bash sudo apt-get update apt-cache policy nginx # 升级发行版仓库中已经安装的 NGINX 及相关包； # 先确认 Candidate 属于修复版本，再执行升级。 sudo apt-get install --only-upgrade nginx # 对实际安装的 nginx-core / nginx-full / nginx-extras 等包 # 确认它们的版本和依赖一同达到厂商修复要求。 dpkg-query -W 'nginx*' 2>/dev/null ``` ชุดคำสั่งนี้ไม่สามารถสร้างการแก้ไขด้านความปลอดภัยจากภายนอกที่ยังไม่พร้อมใช้งานได้ โดยเฉพาะอย่างยิ่งสำหรับ Debian 12 หากแพ็คเกจที่อัปเกรดแล้วยังคงถือว่ามีช่องโหว่จากระบบติดตามความปลอดภัย จำเป็นต้องมีมาตรการซ่อมแซม การแยก หรือการย้ายผู้จำหน่ายเพิ่มเติม [S13](https://keendigit.com/th/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/th/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/th/insights/nginx-remediation-guide#source-15) แพคเกจอย่างเป็นทางการ nginx.org: ```bash # 先确认仓库来自 nginx.org、目标分支和候选版本 apt-cache policy nginx # 经变更审批后再执行对应仓库的升级命令 sudo apt-get install --only-upgrade nginx ``` หากใช้ OpenResty, Tengine หรือ NGINX Plus ที่คอมไพล์เอง ให้ใช้เวอร์ชันโปรแกรมแก้ไขที่ได้รับการสนับสนุนจากผู้ดูแลที่เกี่ยวข้อง และอย่าผสม nginx.org, การแจกจ่าย และแพ็กเกจพื้นที่เก็บข้อมูลของบริษัทอื่น ไบนารี/อิมเมจดั้งเดิม การกำหนดค่า ลายเซ็น และรายการปรับใช้การย้อนกลับควรได้รับการเก็บรักษาไว้ คอนเทนเนอร์/Kubernetes: อัปเดตอิมเมจที่ไม่เปลี่ยนรูป บันทึกไดเจสต์ และแทนที่เรพลิกาเก่าทั้งหมดด้วยการเปิดตัวแบบทีละขั้น `kubectl rollout status` ยืนยันว่าตัวควบคุมการปรับใช้เสร็จสิ้นแล้วเท่านั้น ยังตรวจสอบการแยกย่อยรูปภาพ การกำหนดเส้นทางขาเข้า และการจำลองที่ไม่มีประสิทธิภาพอีกด้วย ### 4.5 ตรวจสอบการกำหนดค่าและเปลี่ยน Worker เก่า ```bash sudo nginx -t # 按服务实际名称、主机高可用和变更窗口执行重启 sudo systemctl restart nginx sudo systemctl status nginx --no-pager # 核查真正存在的 master / worker ps -eo pid,ppid,user,comm,args | grep '[n]ginx' ``` อย่าถือว่า `nginx -s reload` เป็นข้อพิสูจน์ว่าไบนารีใหม่กำลังทำงานอยู่: การโหลดการกำหนดค่าแบบปกติจะทำให้ master เก่าเริ่มทำงานใหม่โดยไม่ต้องแทนที่ไฟล์ปฏิบัติการ NGINX รองรับกระบวนการอัปเกรดไบนารีออนไลน์โดยเฉพาะ แต่ต้องมีขั้นตอนและการตรวจสอบเพิ่มเติม หากไม่มีขั้นตอนที่กำหนดไว้ ให้ใช้สวิตช์การรับส่งข้อมูลที่มีความพร้อมใช้งานสูงตามด้วยการรีสตาร์ทบริการ หรือเปิดตัวคอนเทนเนอร์ทดแทน [S22](https://keendigit.com/th/insights/nginx-remediation-guide#source-22) หากคุณจัดการ NGINX ผ่านซ็อกเก็ต `systemd` สคริปต์รายการคอนเทนเนอร์ หรือการติดตั้งหลายรายการ คุณควรตรวจสอบเป้าหมายการเปิดใช้งานจริงและเส้นทางกระบวนการ แทนที่จะสันนิษฐานโดยตรงว่า `systemctl restart nginx` ครอบคลุมอินสแตนซ์ทั้งหมด ### 4.6 ยอมรับและดำเนินการถดถอยทางธุรกิจจากทางเข้าภายนอกที่แท้จริง ขอแนะนำให้ดำเนินการอย่างน้อย: - HTTPS ปกติ เส้นทางที่เขียนใหม่ ทรัพยากรคงที่ และหน้าการแมป `alias` ถูกต้องหรือไม่ - การแจกแจง `map` ปกติ, พาธ root แบบแปรผัน, พาธบันทึกการเข้าถึง, การกำหนดเส้นทาง SNI/ใบรับรอง และพร็อกซี Stream ถูกต้องหรือไม่ - การอัปโหลดปกติ การอัปโหลดแบบเป็นกลุ่ม คำขอ API และขีดจำกัดวอลุ่มอัปสตรีมสำหรับ HTTP/3 (เมื่อเปิดใช้งาน) ยังคงเป็นไปตามที่คาดไว้ - mTLS: การร้องขอใบรับรองที่ถูกต้องควรสำเร็จ ใบรับรองที่หายไป หมดอายุหรือไม่ได้รับอนุญาตควรยังคงถูกปฏิเสธ และการเริ่มต้นใหม่/การเชื่อมต่อใหม่ TLS ไม่ควรเปลี่ยนการอนุญาตโดยไม่ได้ตั้งใจ - การเข้าถึงเพจ SSI และไฟล์แบบอะซิงโครนัสเป็นเรื่องปกติหรือไม่ บันทึกข้อผิดพลาดไม่แสดงคำขอที่ผิดปกติสำหรับการอ้างอิงหน่วยความจำหรือการขัดข้องของ Worker ซ้ำๆ - หลังจากเปลี่ยนการรับส่งข้อมูล กระบวนการเวอร์ชันเก่าและแบบจำลองรูปภาพเก่าควรจะออกแล้ว การทดสอบจะต้องดำเนินการในสภาพแวดล้อมของตนเองหรือที่ได้รับอนุญาต การทดสอบควันคำขอปกติไม่สามารถพิสูจน์ได้ว่าช่องโหว่ของหน่วยความจำได้รับการแก้ไขแล้ว ท้ายที่สุดแล้ว เวอร์ชันคงที่ แพตช์ซอร์สโค้ด และการทดสอบรันไทม์ของซัพพลายเออร์จะต้องได้รับการยอมรับร่วมกันเพื่อการยอมรับ ## 5. มาตรการบรรเทาผลกระทบเมื่อไม่สามารถอัพเกรดได้ทันที ส่วนนี้เป็นตัวเลือกในการลดความเสี่ยง ไม่ใช่การเปลี่ยนแพตช์ การเปลี่ยนแปลงการกำหนดค่าชั่วคราวทั้งหมดควรได้รับการสำรองข้อมูล ดำเนินการ `nginx -t` เผยแพร่เป็นชุด และย้อนกลับอย่างรวดเร็วหากจำเป็น [S3](https://keendigit.com/th/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/th/insights/nginx-remediation-guide#source-4) ### 5.1 ควบคุมลำดับความสำคัญของการรับส่งข้อมูลตามความเสี่ยงจากภายนอก จัดลำดับความสำคัญในการลดพื้นที่การโจมตีของบริการที่ไม่สามารถอัปเกรดได้ทันเวลา: บนพื้นผิวการจัดการและ API ภายใน เพิ่มการควบคุมการเข้าถึงแหล่งที่มาที่เชื่อถือได้ การแยกเครือข่ายอัปสตรีม หรือออฟไลน์ระยะสั้น เพิ่มการเชื่อมต่อ ขอเนื้อหา และจำกัดอัตราสำหรับทางเข้าที่มีความเสี่ยงสูง ตรวจสอบให้แน่ใจว่าการตรวจสอบแหล่งที่มาเกิดขึ้นที่ NGINX ที่เกี่ยวข้องกับรายการก่อนห่วงโซ่การประมวลผลคำขอ ควรสังเกตว่าช่องโหว่ส่วนใหญ่อยู่ใน NGINX ภายใน Data Plane กฎ WAF แบบดั้งเดิมอาจไม่สามารถกำหนดเงื่อนไขทริกเกอร์การกำหนดค่าแบบกำหนดเองได้อย่างถูกต้อง ### 5.2 `alias` / `rewrite`: หลีกเลี่ยงการประเมิน `$request_filename` หลังจากเขียนใหม่ ขอแนะนำให้ตรวจสอบและปรับ: - พยายามอย่าดำเนินการ `rewrite` ที่จะเปลี่ยน URI ในเวลาเดียวกันกับ `location` โดยใช้ `alias` - หลีกเลี่ยงการใช้ `$request_filename` เมื่อ URI ถูกเขียนใหม่ แต่การจับคู่ตำแหน่งที่ถูกต้องยังไม่เสร็จสิ้น - ตรวจสอบการอ้างอิงตัวแปรทางอ้อมใน `return`, `set`, `if`, `add_header`, รูปแบบบันทึกการเข้าถึง และรวมไฟล์ต่างๆ - ใช้ clear `root`/`try_files`/อิสระ `location` เมื่อได้รับอนุญาตจากธุรกิจ แต่เปลี่ยนเฉพาะ `alias` เป็น `root` นอกจากนี้ยังอาจเปลี่ยนความหมายของเส้นทางไฟล์ ซึ่งต้องได้รับการตรวจสอบทีละรายการ อย่าคัดลอก "เทมเพลตการเขียนซ้ำอย่างปลอดภัย" ทั่วไปบนอินเทอร์เน็ตโดยตรงเพื่อเขียนทับการกำหนดค่าที่มีอยู่ คำนำหน้า `location` ที่แตกต่างกันและเป้าหมายการเขียนใหม่ส่งผลให้เกิดการต่อเส้นทางที่มีความหมายแตกต่างไปจากเดิมอย่างสิ้นเชิง [S5](https://keendigit.com/th/insights/nginx-remediation-guide#source-5) ### 5.3 `map`/Regex: ลดการผสมสถานะตัวแปรการจับ ขอแนะนำให้จัดลำดับความสำคัญของการจับภาพที่มีชื่อและจำกัดขอบเขตการเผยแพร่ แทนที่จะปล่อยให้การจับภาพที่ไม่ระบุชื่อ เช่น `$1` ถูกนำมาใช้ซ้ำในพาธการประเมิน regex ต่างๆ เมื่อเวลาผ่านไป ตัวอย่างเช่น: ```nginx # 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整 map $host $tenant_root { default /srv/www/default; ~^(?[a-z0-9-]+)\.example\.net$ /srv/www/$tenant; } ``` ตัวอย่างนี้แสดงให้เห็นเฉพาะโครงสร้างที่ง่ายต่อการตรวจสอบของการเป็นเจ้าของตัวแปรเท่านั้น ไม่ได้หมายความว่าได้รับการพิสูจน์แล้วว่าสามารถกำจัดพาธทริกเกอร์ CVE-2026-93479 ทั้งหมดได้อย่างอิสระ โดยเฉพาะอย่างยิ่ง ตรวจสอบว่าตัวแปรการจับถูกอ้างอิงล่วงหน้าโดย `root` หรือ `log_format` อื่นๆ หรือไม่ และมี `volatile` เส้นทางไดนามิก และห่วงโซ่การประเมินที่พึ่งพาซึ่งกันและกัน F5/CERT ขอแนะนำให้ใช้การบันทึกที่มีชื่อและจำกัดขอบเขตการใช้งานให้สอดคล้องกับการกำหนดค่าการจับคู่ปกติที่เกี่ยวข้อง เพื่อเป็นการบรรเทาระยะสั้น [S3](https://keendigit.com/th/insights/nginx-remediation-guide#source-3)[S6](https://keendigit.com/th/insights/nginx-remediation-guide#source-6) ### 5.4 AIO + SSI: ปิดการรวมฟังก์ชันที่ไม่จำเป็น สำหรับเซิร์ฟเวอร์/พาธที่ไม่ต้องการ SSI หรือ I/O ไฟล์อะซิงโครนัส ให้ใช้: ```nginx # 在适当的 http/server/location 上下文中配置 ssi off; aio off; ``` จากมุมมองของเงื่อนไขที่ทำให้เกิดช่องโหว่ การปิดหนึ่งในสองรายการมักจะเพียงพอที่จะลบห่วงโซ่เฉพาะที่อธิบายไว้ การปิดบัญชีในเวลาเดียวกันใช้ได้กับสถานการณ์ที่ธุรกิจไม่ได้พึ่งพาความสามารถนี้เท่านั้น ตรวจสอบ `include virtual` คำขอย่อย แคช และลักษณะการทำงานของเธรดพูล เมื่อโหลดพร็อกซีย้อนกลับสูง การปิดระบบ AIO อาจเปลี่ยนแปลงเวลาแฝงและประสิทธิภาพ I/O [S7](https://keendigit.com/th/insights/nginx-remediation-guide#source-7) ### 5.5 HTTP/3 ขอฉีดร่างกาย: ปิดทางเข้าชั่วคราวหากจำเป็น ปิดการใช้งาน `quic` Listener ที่เกี่ยวข้องกับ HTTP/3 ยกเลิกส่วนหัวการตอบสนอง `Alt-Svc` ที่ประกาศ HTTP/3 และตรวจสอบว่า Edge Layer/Load Balancer ยังคงส่งคำขอ QUIC ไปยัง NGINX ที่ไม่ได้รับการซ่อมแซมโดยตรงหรือไม่: ```nginx # 示意：保留 HTTPS/TCP；暂时移除此前的 QUIC/UDP listen server { listen 443 ssl; # 保留 HTTPS/TCP 入口 # 对支持新版语法的构建，可在此使用 http2 on; # 删除原有的 listen 443 quic reuseport; # 删除原有的 add_header Alt-Svc ...;（仅限宣传 h3 的那项） # 其余证书、server_name、location 等配置保持不变 } ``` ข้อมูลข้างต้นเป็นเพียงคำอธิบายถึงความแตกต่างในการเปลี่ยนแปลง ไม่ใช่การกำหนดค่าเซิร์ฟเวอร์ที่สมบูรณ์ที่สามารถเปิดใช้งานทีละรายการได้ ไวยากรณ์การตั้งค่าของ HTTP/2 เกี่ยวข้องกับเวอร์ชัน NGINX หากคุณต้องการเก็บ HTTP/2 ไว้ คุณควรใช้ `http2 on;` หรือไวยากรณ์ที่ถูกต้องที่มีอยู่ตามเวอร์ชันที่เกี่ยวข้อง และตรวจสอบกับ `nginx -t` ต้องรวมกับการกำหนดค่าเซิร์ฟเวอร์ที่มีอยู่ก่อนที่จะปรับใช้ แทนที่จะแทนที่ส่วนทั้งหมดด้วยส่วนนี้ ยังตรวจสอบไฟร์วอลล์ UDP 443 ตำแหน่งการสิ้นสุด HTTP/3 และเส้นทางสำรองไคลเอ็นต์ของ CDN/พร็อกซีด้านหน้า การบรรเทาระยะสั้นอีกประเภทหนึ่งคือการใช้ `proxy_request_buffering off;` บนเส้นทางพร็อกซีที่ได้รับผลกระทบ แต่จะเปลี่ยนลักษณะการทำงานของการสตรีมเนื้อหาคำขออัปสตรีม การลองใหม่ล้มเหลว และเวิร์กโฟลว์การอัปโหลดบางส่วน ใช้เฉพาะหลังจากการทดสอบและการยืนยันว่าคำสั่งดังกล่าวกระทบกับเส้นทางพร็อกซี HTTP/3 ที่ได้รับผลกระทบเท่านั้น [S8](https://keendigit.com/th/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/th/insights/nginx-remediation-guide#source-18) ### ตั๋วเซสชัน 5.6 TLS: การป้องกันลำดับความสำคัญ mTLS ขอบเขตการตรวจสอบความถูกต้อง หากไม่สามารถอัปเกรดได้และอินสแตนซ์อาศัยแคชเซสชันที่ใช้ร่วมกัน + การหมุนเวียนคีย์ตั๋วอัตโนมัติ ให้ประเมิน: ```nginx # 在 nginx http/server 适当作用域进行配置 ssl_session_tickets off; ``` วิธีนี้สามารถปิดกลไกตั๋วเซสชัน TLS ได้ ซึ่งจะลบเส้นทางการปลอมแปลงตั๋วที่อธิบายไว้ในช่องโหว่นี้ อย่างไรก็ตาม อาจส่งผลต่อประสิทธิภาพในการเริ่มเซสชันใหม่ คุณไม่สามารถปิดการตรวจสอบใบรับรองไคลเอ็นต์ mTLS เพื่อ "หลีกเลี่ยงช่องโหว่" ได้ เนื่องจากจะเป็นการลบขอบเขตการรับรองความถูกต้องเดิมโดยตรง [S9](https://keendigit.com/th/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/th/insights/nginx-remediation-guide#source-12) ไฟล์ `ssl_session_ticket_key` ที่ชัดเจนและการหมุนเวียนอย่างปลอดภัยยังสามารถนำมาใช้โดยกระบวนการจัดการ TLS ระดับมืออาชีพ เพื่อหลีกเลี่ยงเงื่อนไขที่สร้างขึ้นโดยอัตโนมัติ แต่การดูแลคีย์ การกระจายโหนดแบบเต็ม การหมุนเวียน และวงจรอายุตั๋วเก่า ล้วนจำเป็นต้องได้รับการตรวจสอบอย่างรอบคอบ ไม่แนะนำให้ฮาร์ดโค้ดคีย์ที่ใช้ซ้ำได้ระยะยาวในการกำหนดค่าเว็บทั่วไปหรือสคริปต์สำหรับกรณีฉุกเฉินชั่วคราว บริการที่สำคัญที่ใช้ mTLS ควรได้รับการตรวจสอบเพิ่มเติมสำหรับพฤติกรรมการเริ่มต้นเซสชัน TLS และการปฏิเสธคำขอโดยไม่มีใบรับรองไคลเอ็นต์ที่ถูกต้อง [S12](https://keendigit.com/th/insights/nginx-remediation-guide#source-12) ### 5.7 บทบาทของระบบปฏิบัติการและการป้องกันชายแดน ```bash # Linux：常见值 2 表示进程地址空间随机化处于完整启用状态 sysctl kernel.randomize_va_space ``` ASLR, ผู้ปฏิบัติงานที่ไม่ใช่ root, ระบบไฟล์คอนเทนเนอร์แบบอ่านอย่างเดียว, สิทธิ์อนุญาตไฟล์ขั้นต่ำ และการแยกเครือข่ายสามารถลดผลกระทบของ RCE ที่อาจเกิดขึ้นได้ ASLR ไม่ได้แก้ไขฮีปโอเวอร์โฟลว์หรือ UAF และไม่สามารถรับประกันได้ว่าผู้ปฏิบัติงานจะไม่หยุดทำงาน WAF ขีดจำกัดอัตรา และขีดจำกัดขนาดร่างกายของคำขอไม่ได้แก้ไขการซิงโครไนซ์คีย์ตั๋ว TLS [S4](https://keendigit.com/th/insights/nginx-remediation-guide#source-4) ### 5.8 ความเข้าใจผิดที่พบบ่อย: การดำเนินการเหล่านี้ไม่เพียงพอที่จะซ่อมแซมให้เสร็จสิ้น | การดำเนินงานทั่วไป | เหตุใดจึงไม่เพียงพอ? | | ------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | | "nginx -v ดูค่อนข้างใหม่" | สาขาที่เป็นเจ้าของ เวอร์ชันแพ็คเกจแบ็คพอร์ตที่สมบูรณ์ของเวอร์ชันวางจำหน่าย และกระบวนการออนไลน์จะไม่ได้รับการตรวจสอบ | | “มีการอัพเกรดอินทราเน็ตเพียงอันเดียวเท่านั้น” | Worker เก่า/คอนเทนเนอร์เก่า/อินสแตนซ์ต้นทาง CDN เก่ายังคงได้รับคำขอ | | "ไซต์ไม่ได้ใช้แท็ก PHP/ไดนามิก" | ข้อบกพร่องเกิดขึ้นในพาธหลัก NGINX หรือการแยกวิเคราะห์โปรโตคอล และไม่ขึ้นอยู่กับการดำเนินการของ PHP | | "การเปิด WAF/Cloudflare ก็เพียงพอแล้ว" | WAF ไม่สามารถพิสูจน์ได้ว่าบล็อกข้อบกพร่องของหน่วยความจำที่ขึ้นกับการกำหนดค่า NGINX ทั้งหมดหรือข้อบกพร่องในการเริ่มต้นใหม่ TLS | | "เปิด ASLR แล้ว" | เพียงใช้ประโยชน์จากการบรรเทาความยากลำบาก DoS พร้อมการร้องขอการฉีดยังคงเป็นไปได้ | | "HTTP/3 ไม่ได้ถูกเปิดเผยต่อเครือข่ายสาธารณะ ดังนั้นจึงไม่จำเป็นต้องอัปเกรดเลย" | CVE อีกสี่รายการยังคงต้องมีการประเมินโดยอิสระ และอาจมีการเชื่อมโยงโดยตรงกับต้นกำเนิดที่ซ่อนอยู่ | | "ช่องโหว่ `map` เดือนกรกฎาคมได้รับการแก้ไขแล้ว" | CVE-2026-93479 ตุลาคมเกี่ยวข้องกับปัญหาการถดถอยการประเมินสคริปต์ที่ตามมา | | "การปิดใช้งานแคชจะแก้ปัญหาทั้งหมดได้" | มีผลกับแคช TLS หรือสถานการณ์ AIO บางรายการเท่านั้น และไม่ครอบคลุมถึงนามแฝง สคริปต์ HTTP/3 | ## 6. แนวคิดการใช้งานแพทช์อย่างเป็นทางการและประเด็นการตรวจสอบ ส่วนนี้เป็นไปตามการแก้ไขอัพสตรีม NGINX เดือนตุลาคม 2026 ตัวอย่างนี้แสดงให้เห็นการเปลี่ยนแปลงของตัวแทนสำหรับการตรวจสอบแพตช์ ยังไม่เสร็จสมบูรณ์ สามารถคอมไพล์ได้อย่างอิสระ สำหรับบิลด์แบบกำหนดเอง ให้ตรวจสอบคอมมิตทั้งหมด โค้ดโดยรอบและการทดสอบ และต้องการรีลีสที่รองรับโดยสมบูรณ์ [S5](https://keendigit.com/th/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/th/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/th/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/th/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/th/insights/nginx-remediation-guide#source-9) ### 6.1 CVE-2026-15176: URI ถูกเขียนใหม่เพื่อรวมเงื่อนไขการปฏิเสธการแมปพาธ `alias` การคอมมิตอัปสตรีมที่แก้ไข `ngx_http_map_uri_to_path()` ใน `src/http/ngx_http_core_module.c`: ```diff - if (alias && !r->valid_location) { + if (alias && (!r->valid_location || r->uri_changed)) { ``` จุดเน้นในการตรวจสอบ: ไม่สามารถคำนวณพาธของระบบไฟล์ต่อไปได้เมื่อมีการเปลี่ยนแปลง URI แต่ความหมายตำแหน่งที่สอดคล้องกันของ `alias` ไม่น่าเชื่อถืออีกต่อไป นี่คือการปรับปรุงข้อจำกัดก่อนรัฐ ไม่ใช่การตรวจสอบง่ายๆ ว่าคำขอ URI มีอักขระที่ผิดกฎหมายหรือไม่ [S5](https://keendigit.com/th/insights/nginx-remediation-guide#source-5) ### 6.2 CVE-2026-93479: แยกความแตกต่างระหว่างความยาวข้อมูลเอาต์พุตและความยาวที่สงวนไว้อย่างถูกต้อง คอมมิตอัปสตรีมจะอัพเดต `src/http/ngx_http_script.c` และ `src/stream/ngx_stream_script.c` ในเวลาเดียวกัน เจตนาหลักสามารถสรุปได้ดังนี้: ```diff - n = len; + n = 0; /* ...计算实际脚本输出长度... */ - value->len = n; - value->data = ngx_pnalloc(pool, n); + value->len = n + len; + value->data = ngx_pnalloc(pool, n + len); ``` ในที่นี้ `pool` เป็นชื่อพารามิเตอร์ที่แสดงตัวอย่าง: นิพจน์การจัดสรร HTTP และ Stream จริงแตกต่างกัน การเปลี่ยนแปลงจะคำนวณความยาวเอาต์พุตของสคริปต์ก่อน จากนั้นจึงเพิ่มความยาวที่สงวนไว้ในการจัดสรรขั้นสุดท้าย ดังนั้นเอาต์พุตจะไม่เขียนทับพื้นที่ที่สงวนไว้ [S6](https://keendigit.com/th/insights/nginx-remediation-guide#source-6) เมื่อทำการตรวจสอบและแบ็คพอร์ต จะต้องครอบคลุมผู้ประเมินที่เกี่ยวข้องของ HTTP/Stream ด้วย การตรวจสอบไฟล์ไวยากรณ์การกำหนดค่าของ `map` เท่านั้นไม่สามารถพิสูจน์ได้ว่าข้อบกพร่องได้รับการแก้ไขแล้ว ### 6.3 CVE-2026-97205: ตั้งค่าเกณฑ์ความปลอดภัยสำหรับการนับการดำเนินการแบบอะซิงโครนัส 8 บิต เพิ่มต้นน้ำที่ `src/http/ngx_http_request.h`: ```c #define NGX_HTTP_MAX_BLOCKED 250 ``` และเพิ่มรายการที่คล้ายกันในการอ่านไฟล์แบบอะซิงโครนัส การรอแคช การกรองเอาต์พุต และการทำงานของเธรด: ```c if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) { /* 使用同步路径，或者拒绝新的异步操作 */ } ``` จุดเน้นในการตรวจสอบ: ต้องครอบคลุมเส้นทางโค้ดจริงทั้งหมดที่จะเพิ่ม `r->main->blocked` คุณไม่สามารถเขียนค่าคงที่เกณฑ์ในไฟล์ส่วนหัวได้ Backport ยังต้องตรวจสอบการประสานงานที่สมบูรณ์ของทางเลือกแบบซิงโครนัส การเรียกกลับแบบอะซิงโครนัส และการส่งคืนข้อผิดพลาด เพื่อให้แน่ใจว่าการหยุดชะงักหรือการรั่วไหลของการอ้างอิงจะไม่เกิดจากการปฏิเสธงานโดยตรง [S7](https://keendigit.com/th/insights/nginx-remediation-guide#source-7) ### 6.4 CVE-2026-95101: รักษาสถานะ `skip` แยกต่างหากสำหรับเฟรมที่ไม่รู้จัก อัปสตรีมจะเพิ่มฟิลด์ `skip` ในโครงสร้างสถานะตัวแยกวิเคราะห์ HTTP/3 และดำเนินการแยกสถานะ: ```c if (st->type != NGX_HTTP_V3_FRAME_DATA && st->length > 0) { st->skip = st->length; st->length = 0; st->state = sw_skip; } /* ... */ rc = ngx_http_v3_parse_skip(b, &st->skip); ``` สิ่งสำคัญไม่ใช่การ "ปิดการใช้งานเฟรม HTTP/3 ที่ไม่รู้จัก" แต่เพื่อให้แน่ใจว่าในการอ่านหลาย ๆ ครั้ง จำนวนไบต์ที่ข้ามและความยาวของเพย์โหลด DATA จะได้รับการจัดการโดยรัฐอิสระเสมอ บทวิจารณ์ควรมุ่งเน้นไปที่การแบ่งส่วนบัฟเฟอร์ข้ามเฟรมที่ไม่รู้จัก และความสอดคล้องในที่สุดของ `client_max_body_size` [S8](https://keendigit.com/th/insights/nginx-remediation-guide#source-8) ### 6.5 CVE-2026-97629: ซิงโครไนซ์อาเรย์สล็อตคีย์ TLS ที่สมบูรณ์ การเปลี่ยนแปลงต้นทางอยู่ที่ `src/event/ngx_event_openssl.c`: ```diff ngx_memcpy(keys->elts, cache->ticket_keys, - 2 * sizeof(ngx_ssl_ticket_key_t)); + keys->nelts * sizeof(ngx_ssl_ticket_key_t)); ``` รูปภาพต้นฉบับมีช่องหลักสามช่อง แต่คัดลอกเฉพาะสองช่องแรกเท่านั้น ให้ซิงโครไนซ์ตามจำนวนจริงขององค์ประกอบอาร์เรย์เพื่อให้แน่ใจว่าชุดคีย์การลงคะแนนของ Worker สอดคล้องกับหน่วยความจำที่ใช้ร่วมกัน เมื่อตรวจสอบ โปรดยืนยันด้วยว่าการจัดสรรอาร์เรย์ การเริ่มต้น การล็อกที่ใช้ร่วมกัน และลอจิกการหมุนมีความสอดคล้องกัน แทนที่จะตรวจสอบการแก้ไขความยาว `memcpy` เพียงครั้งเดียว [S9](https://keendigit.com/th/insights/nginx-remediation-guide#source-9) ### 6.6 เหตุใดจึงไม่แนะนำให้ใช้เฉพาะชิ้นส่วนแพตช์ที่กระจัดกระจายเท่านั้น การปรับเปลี่ยนทั้งห้านี้ครอบคลุมถึง `src/http`, `src/stream`, `src/http/v3` และ `src/event` ตามลำดับ และเวอร์ชันเก่าอาจมีแบ็คพอร์ตด้านความปลอดภัยและส่วนขยายที่ไม่เป็นทางการ การแบ็คพอร์ตควรสร้างเมทริกซ์ตรวจสอบต่อไปนี้: | ตรวจสอบวัตถุ | สิ่งที่จะต้องได้รับการยืนยัน | | -------------------- | -------------------------------------------------------------------------------------- | | แหล่งแพทช์ | การส่งอย่างเป็นทางการ เวอร์ชันเป้าหมายที่ตรงกัน แพตช์ที่สมบูรณ์และการตรวจสอบลายเซ็น | | ชุดแพทช์เดิม | ไม่ขัดแย้งกับการแก้ไขในอดีต เช่น CVE-2026-42533, แบ็กพอร์ตการแจกจ่าย ฯลฯ | | เส้นทางรหัส | ครอบคลุมสคริปต์ HTTP + Stream, AIO/thread, HTTP/3, OpenSSL | | เรียบเรียงเข้ากันได้ | OpenSSL, PCRE, โมดูล ABI, โมดูลไดนามิกและการพึ่งพาลิงก์มีความสอดคล้องกัน | | การถดถอยเชิงฟังก์ชัน | `alias` เขียนใหม่, บันทึกแบบไดนามิก, SSI/AIO, อัปโหลด HTTP/3, รีสตาร์ทเซสชัน mTLS | | รันไทม์ | Worker/Pod ทั้งหมดใช้งานบิลด์ที่ได้รับการตรวจสอบใหม่ โดยไม่มีอิมเมจแบบเดิมหลงเหลืออยู่ | สำหรับทีมที่ดูแลรักษารุ่นของตนเอง ขอแนะนำให้เก็บ ID แพตช์ที่ตรวจสอบได้ เวอร์ชันแพ็กเกจ บันทึกบิลด์ และรายงานการถดถอยสำหรับ CVE แต่ละรายการ สำหรับการดำเนินงานและการบำรุงรักษาตามปกติ โซลูชันที่ปลอดภัยที่สุดคือการติดตั้งการอัปเดตความปลอดภัยที่สมบูรณ์ของผู้จำหน่าย ## 7. การย้อนรอยช่องโหว่ในอดีต สาขาเก่า และผลิตภัณฑ์อื่นๆ ### ช่องโหว่หลัก 7.1 NGINX คุ้มค่าที่จะได้รับการยืนยันพร้อมกันตั้งแต่เดือนพฤษภาคมถึงกันยายน 2569 อินสแตนซ์ NGINX จำนวนมากที่ไม่ได้รับการอัปเดตเป็นเวลานานไม่เพียงได้รับผลกระทบจากปัญหาใหม่ในเดือนตุลาคมเท่านั้น ต่อไปนี้คือโหนดการซ่อมแซมตัวแทนในอนาคตอันใกล้นี้: [S1](https://keendigit.com/th/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/th/insights/nginx-remediation-guide#source-2) | ซีวีอี | การเปิดตัวแก้ไขครั้งแรก | ความเสี่ยงและเงื่อนไขสำคัญที่ต้องตรวจสอบ | | -------------- | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | CVE-2026-42945 | Stable 1.30.1 / Mainline 1.31.0 13 พ.ค. | `rewrite` การจับภาพ regex แบบไม่ระบุชื่อและตรรกะการแทนที่จะกระตุ้นให้เกิดฮีปล้น ศักยภาพของ RCE มีรายงานสาธารณะเกี่ยวกับความพยายามโจมตีในป่า | | CVE-2026-9256 | Stable 1.30.2 / Mainline 1.31.1 22 พ.ค. | การจับภาพ regex ที่ทับซ้อนกันและการประมาณความยาวใน `rewrite` นำไปสู่การล้น | | CVE-2026-42055 | Stable 1.30.3 / Mainline 1.31.2 วันที่ 17 มิถุนายน | HTTP/2 การกำหนดค่าเฉพาะสำหรับอัปสตรีมหรือ gRPC เงื่อนไขส่วนหัวคำขอขนาดใหญ่ทำให้เกิดบัฟเฟอร์ล้น | | CVE-2026-42530 | Mainline 1.31.2 วันที่ 17 มิถุนายน | HTTP/3 ใช้หลังฟรี; เครื่องหมายอย่างเป็นทางการได้รับผลกระทบช่วง `1.31.0–1.31.1` | | CVE-2026-42533 | Stable 1.30.4 / Mainline 1.31.3, 15 กรกฎาคม | การประเมินตัวแปรการจับ `map` + regex ทำให้เกิดฮีปล้น และแพตช์ต่อมามีความสัมพันธ์แบบถดถอยกับ CVE-2026-93479 ในเดือนตุลาคม | | CVE-2026-60005 | Stable 1.30.4 / Mainline 1.31.3, 15 กรกฎาคม | เนื้อหาหน่วยความจำ `ngx_http_slice_module` รั่วไหลภายใต้ตัวแปรเฉพาะและเงื่อนไขการอัปเดตแคช | | CVE-2026-56434 | Stable 1.30.4 / Mainline 1.31.3, 15 กรกฎาคม | SSI เกี่ยวข้องกับ UAF; ไม่ใช่สาเหตุของ root เดียวกันกับช่องโหว่การนับ AIO ของเดือนตุลาคม | | CVE-2026-90439 | Stable 1.30.5 / Mainline 1.31.6 วันที่ 15 กันยายน | ฮีปโอเวอร์โฟลว์ที่จำกัดของ HTTP/3 + เวอร์ชันเฉพาะของ OpenSSL ส่วนใหญ่แสดงออกมาว่าเป็นความเสียหายของหน่วยความจำที่จำกัด/จำกัด | ช่องโหว่อื่นๆ เช่น NGINX Core, HTTP/2, ชุดอักขระ และ SMTP ที่ประกาศในปี 2569 ควรได้รับการตรวจสอบตามกระดานข่าวความปลอดภัยอย่างเป็นทางการ ตารางนี้จงใจมุ่งเน้นไปที่เหตุการณ์ทั่วไปที่เกี่ยวข้องกับการใช้งานพร็อกซีย้อนกลับแบบสาธารณะของ NGINX ในปัจจุบัน และมีความปลอดภัยของหน่วยความจำหรือคำขอโดยนัยด้านความสมบูรณ์ ไม่ใช่ CVE ทั้งหมดในปี 2026 รายการ [S1](https://keendigit.com/th/insights/nginx-remediation-guide#source-1) #### เหตุใดจึงให้ความสนใจเป็นพิเศษกับ CVE-2026-42945 มีกระดานข่าวด้านความปลอดภัยจากหน่วยงานของรัฐที่บันทึกกิจกรรมการแสวงหาผลประโยชน์ในป่าและข้อมูลโค้ดการหาประโยชน์สาธารณะสำหรับช่องโหว่ `rewrite` ในเดือนพฤษภาคม ดังนั้น สำหรับอินสแตนซ์ที่ไม่ได้รับการติดตั้งเป็นเวลานานตั้งแต่เดือนพฤษภาคมถึงปัจจุบันและมีการเขียนนิพจน์ทั่วไปที่ซับซ้อนแบบเปิดบนเครือข่ายสาธารณะ นอกเหนือจากการซ่อมแซมให้เสร็จสิ้นแล้ว ข้อขัดข้องที่ผิดปกติของ Worker บันทึกการเข้าถึง และการเปลี่ยนแปลงที่น่าสงสัยในขณะนั้นควรได้รับการตรวจสอบเพิ่มเติม [S23](https://keendigit.com/th/insights/nginx-remediation-guide#source-23) "ความพยายามในการโจมตีเกิดขึ้น" ไม่ได้พิสูจน์โดยอัตโนมัติว่าผู้โจมตีได้ดำเนินการคำสั่งอย่างน่าเชื่อถือกับทุกเป้าหมาย เมื่อเกี่ยวข้องกับการตอบสนองต่อเหตุการณ์ ตัวบ่งชี้การประนีประนอมและความล้มเหลวของกระบวนการควรได้รับการตรวจสอบแยกต่างหากจากหลักฐานที่แท้จริงของการยกระดับสิทธิพิเศษหรือการคงอยู่ ### การแก้ไข 7.2 สำหรับเวอร์ชันเก่าและแบ็กพอร์ตการแจกจ่าย NGINX สาขาต่างๆ มีวงจรการสนับสนุนของตัวเองและเวลาในการแนะนำช่องโหว่ที่แตกต่างกัน แพทช์ใหม่ทั้งห้าไม่สามารถเผยแพร่ไปยังแผนผังต้นทางทั้งหมดได้หากไม่มีการตรวจสอบ | ฉาก | กลยุทธ์ที่แนะนำ | | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | เวอร์ชันวางจำหน่ายได้ประกาศแพตช์ความปลอดภัยที่สมบูรณ์แล้ว | ใช้แพ็คเกจของผู้จำหน่ายและจัดทำเอกสารเวอร์ชันแพ็คเกจที่สมบูรณ์ หลีกเลี่ยงการแทนที่ด้วยไบนารีเปลือยอัพสตรีมที่เข้ากันไม่ได้ | | Debian 12 และรุ่นอื่นๆ ที่ได้รับผลกระทบซึ่งยังไม่ครอบคลุมโดย CVE ทั้งหมดในชุดนี้ | ส่งคำสั่งงานที่มีความเสี่ยง จำกัดการสัมผัสจากภายนอก และตรวจสอบสถานะซัพพลายเออร์/ELTS ย้ายหรือใช้สายการปลดการบำรุงรักษาที่ตรวจสอบได้เมื่อจำเป็น | | สาขาประวัติศาสตร์ที่สิ้นสุดการสนับสนุนต้นน้ำ | จัดลำดับความสำคัญของการโยกย้ายไปยังเวอร์ชันที่รองรับ หากจำเป็นต้องมีการแบ็คพอร์ตในระยะสั้น ผู้ดูแลจะประเมินการขึ้นต่อกันและความเข้ากันได้ของแพตช์ และเขียนการทดสอบที่สมบูรณ์ | | มาพร้อมกับส้อม NGINX (OpenResty, Tengine, เกตเวย์แบบกำหนดเอง) | ขั้นแรกให้ตรวจสอบว่าเส้นทางรหัสที่เกี่ยวข้องถูกรวมอยู่หรือไม่ แล้วใช้คำชี้แจงความปลอดภัยของผู้ดูแลทางแยก ไม่สามารถเทียบเท่ากับเวอร์ชันอัปสตรีมได้โดยตรง | | แพทช์รักษาความปลอดภัยนำไปสู่การเปลี่ยนแปลงในฟังก์ชันทางธุรกิจ | ใช้การเปิดตัวแบบทีละขั้น การสลับการรับส่งข้อมูลระหว่างเวอร์ชัน และการปรับการกำหนดค่า ไม่เหมาะสมที่จะกู้คืนเครือข่ายสาธารณะเวอร์ชันที่ไม่ได้แก้ไขโดยไม่มีการแยกส่วน | ### 7.3 แยกการแก้ไขสำหรับ njs, Ingress และ NGINX Core - njs: นอกจากโปรแกรมหลัก NGINX แล้ว คุณยังต้องตรวจสอบเวอร์ชันของโมดูล NGINX JavaScript ด้วย `njs 1.0.2` แก้ไขปัญหาหน่วยความจำแยกวิเคราะห์ XML เดือนตุลาคม 2569 และปัญหาความไม่สอดคล้องกันในการตรวจสอบ XML ด้วยแอตทริบิวต์การอ้างอิงเอนทิตี สำหรับการปรับใช้ที่เกี่ยวข้องกับการตรวจสอบลายเซ็น XML โดยใช้ `nginx-saml` คุณควรอ่านคำแนะนำอย่างเป็นทางการของ njs สำหรับสถานการณ์ปลั๊กอินเพิ่มเติม [S20](https://keendigit.com/th/insights/nginx-remediation-guide#source-20) - F5 NGINX Plus / NGINX Ingress Controller: Plus, controller และ Gateway Fabric อาจมีกระดานข่าวด้านความปลอดภัยเพิ่มเติม, เวอร์ชันบรรจุภัณฑ์ที่แตกต่างกัน และช่องโหว่ของนโยบายที่ไม่ซ้ำกัน การอัพเกรดหนึ่งเลเยอร์ไม่ได้หมายถึงการอัปเดตอีกเลเยอร์หนึ่งโดยอัตโนมัติ [S19](https://keendigit.com/th/insights/nginx-remediation-guide#source-19) - ชุมชน Kubernetes ingress-nginx: เจ้าหน้าที่ Kubernetes ได้ประกาศแล้วว่าคอนโทรลเลอร์หยุดการบำรุงรักษาในเดือนมีนาคม 2026 และอย่าสับสนระหว่างคลังสินค้ากับคอนโทรลเลอร์ F5 ธุรกิจที่ได้รับผลกระทบควรวางแผนการโยกย้ายได้อย่างราบรื่น และตรวจสอบคำอธิบายประกอบ Ingress และความแตกต่างทางความหมาย Gateway API แทนที่จะรอเวอร์ชันการรักษาความปลอดภัยใหม่ [S21](https://keendigit.com/th/insights/nginx-remediation-guide#source-21) ## 8. เกณฑ์การยอมรับและการตรวจสอบติดตามผล ขอแนะนำให้ใช้รายการต่อไปนี้เป็นเงื่อนไขการยอมรับสำหรับการเปลี่ยนแปลงใบสั่งงาน: | โครงการ | มาตรฐานคุณสมบัติ | หลักฐานที่สามารถเก็บรักษาได้ | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------- | | ความครอบคลุมของสินทรัพย์และพอร์ทัล | อินสแตนซ์ภายนอกและอินสแตนซ์ที่เชื่อมต่อโดยตรงทั้งหมดที่สามารถเลี่ยงผ่าน CDN ได้ถูกสร้างขึ้นแล้ว | ชื่อโดเมน, LB, IP, รายการพ็อด/คอนเทนเนอร์ | | แหล่งบรรจุภัณฑ์และขอบเขตการซ่อมแซม | ใช้เวอร์ชันที่ได้รับการยืนยันว่าครอบคลุม CVE ที่เกี่ยวข้องทั้งหมด | คำแนะนำด้านความปลอดภัยขั้นต้น, USN/DSA, เวอร์ชันแพ็คเกจ, การแยกย่อยอิมเมจ | | กระบวนการเก่าออก | master/worker/คอนเทนเนอร์เก่าทั้งหมดถูกเปลี่ยนแล้ว | PID/เวลาเริ่มต้น สถานะการปรับใช้งานแบบต่อเนื่อง อิมเมจที่กำลังรัน | | การตรวจสอบการกำหนดค่า | ชุดค่าผสมที่มีความเสี่ยงสูงถูกกำจัดหรือครอบคลุมโดยแพตช์ และความสัมพันธ์ในการสืบทอดได้รับการตรวจสอบแล้ว | ปรับปรุงข้อมูลสรุปและบันทึกการตรวจสอบของ `nginx -T` | | TLS/mTLS | ใบรับรองที่เชื่อถือได้ผ่าน ใบรับรองที่ไม่ถูกต้องหรือหายไปจะถูกปฏิเสธ การเริ่มต้นเซสชันใหม่ไม่ได้ข้ามการรับรองความถูกต้อง | การทดสอบการอนุญาตเชิงลบ/บวก ควบคุมผลการทดสอบ TLS | | เนื้อหาคำขอ HTTP/3 | เปิดใช้งานเส้นทางที่แก้ไข; เนื้อหาคำขออัปสตรีมและการควบคุมปริมาณทำงานอย่างถูกต้อง | HTTP/3, การอัปโหลดพร็อกซี, การทดสอบการถดถอยขีดจำกัดปริมาณ | | SSI/AIO | ฟังก์ชันนี้ตรงตามข้อกำหนด Worker ไม่มีการยกเลิกที่ผิดปกติ | การตรวจสอบการถดถอยทางธุรกิจ ความผิดพลาด และอัตราข้อผิดพลาด | | การตรวจสอบการทำงานและการบำรุงรักษา | ไม่มีข้อยกเว้นที่ชัดเจน 5xx, SIGSEGV กระบวนการออกจากการทำงานซ้ำๆ | ตัวบ่งชี้การบริการและบันทึกก่อนและหลังการเปลี่ยนแปลง | | กลยุทธ์การย้อนกลับ | หากจำเป็นต้องย้อนกลับ ให้จำกัดการเปิดเผยและรักษาขอบเขตความปลอดภัยก่อน | เปลี่ยนคำสั่ง การดำเนินการฉุกเฉิน และแผนการกักกัน | | วงจรชีวิตต่อมา | กำหนดการสมัครรับข่าวสารด้านความปลอดภัย ความถี่ในการอัปเดตคอนเทนเนอร์ และแผนการย้ายสาขา | อัปเกรดบัญชีแยกประเภท ผู้รับผิดชอบ และวันตรวจสอบครั้งต่อไป | ### 8.1 คุณควรเน้นที่สิ่งใดในบันทึกและสถานะการทำงาน แก้ไขปัญหาความผิดปกติบนเซิร์ฟเวอร์ที่ถูกเปิดเผยเป็นเวลานาน `worker process exited on signal` 、 `SIGSEGV` ความล้มเหลวของคำขอที่เพิ่มขึ้นอย่างรวดเร็ว การรวมการเข้าถึงแหล่งที่มาที่ผิดปกติ การเริ่มต้นเซสชันใหม่/การรับรองความถูกต้อง TLS ที่ไม่คาดคิด ความสำเร็จและพฤติกรรมของเนื้อหาคำขอแบ็กเอนด์ที่ผิดปกติ ตัวบ่งชี้เหล่านี้สามารถใช้เป็นเบาะแสในการสืบสวนเท่านั้น และไม่ใช่หลักฐานเพียงพอที่จะพิสูจน์โดยตรงว่า CVE บางตัวถูกนำไปใช้ประโยชน์ ;การขาดบันทึกที่เกี่ยวข้องไม่ได้พิสูจน์ว่าไม่มีการโจมตี ### 8.2 ข้อความสรุปความเสี่ยงขั้นสุดท้ายที่แนะนำ รายงานการยอมรับสำหรับสภาพแวดล้อมการผลิตควรใช้นิพจน์ที่แม่นยำต่อไปนี้: > NGINX ทางเข้าบริการภายนอกและแหล่งที่มาของแพ็คเกจซอฟต์แวร์ได้รับการระบุแล้ว อินสแตนซ์ที่เกี่ยวข้องทั้งหมดได้รับการอัปเกรดเป็นเวอร์ชันการรักษาความปลอดภัยอัปสตรีมอย่างเป็นทางการ หรือแบ็คพอร์ตที่ยืนยันโดยผู้จัดจำหน่ายที่เผยแพร่เสร็จสมบูรณ์แล้ว Worker เก่าและคอนเทนเนอร์เก่าได้ถูกเปลี่ยนแล้ว นามแฝง/เขียนใหม่/แมป เนื้อหาคำขอ AIO/SSI, HTTP/3 และเนื้อหาคำขอ TLS Session Ticket/mTLS ได้รับการตรวจสอบและผ่านการทดสอบการทำงาน การรับรองความถูกต้อง และการถดถอยความสมบูรณ์ของคำขอ สำหรับกรณีที่ยังอัปเกรดไม่เสร็จสมบูรณ์ ให้ลงทะเบียนพื้นที่เสี่ยง มาตรการชดเชย ผู้รับผิดชอบ และกำหนดเวลาดำเนินการให้เสร็จสิ้นเพิ่มเติม หากแพทช์สำหรับ Debian 12 หรือรุ่นอื่น ๆ ยังคงไม่สมบูรณ์ ไม่เหมาะสมที่จะตัดสินแบบฟอร์มการยอมรับทั้งหมดว่า "เสร็จสมบูรณ์" CVE ที่ยังไม่ได้รับการแก้ไข ไม่ว่าจะมีการกำหนดค่าทริกเกอร์ที่สอดคล้องกัน สถานะการแยก และเส้นทางการอัพเกรดขั้นสุดท้ายควรได้รับการบันทึกไว้อย่างชัดเจน *** ## ภาคผนวก: แหล่งอ้างอิงและลิงก์ คำอธิบาย: หมายเลข `[Sx]` ในข้อความสอดคล้องกับส่วนนี้อย่างสม่ำเสมอ ข้อมูลต่อไปนี้ให้ความสำคัญกับการประกาศความปลอดภัยของโครงการขั้นต้น การประกาศใช้รหัส ประกาศเปิดตัวซัพพลายเออร์ และข้อมูลหน่วยงานความมั่นคงแห่งชาติ ความรุนแรงของช่องโหว่ที่อ้างถึงนั้นอธิบายไว้ตามเกณฑ์การจัดอันดับของแต่ละองค์กรที่ออก วันที่ตรวจสอบข้อมูลคือวันที่ 27 ตุลาคม 2026 ### S1 — NGINX Open Source กระดานข่าวความปลอดภัยอย่างเป็นทางการ - ประกอบด้วยเวอร์ชันอัปสตรีมที่ได้รับผลกระทบ สาขาการแก้ไข และระดับความรุนแรงอย่างเป็นทางการของ CVE ห้าเดือนตุลาคม และยังครอบคลุมช่องโหว่ในอดีตจนถึงปี 2026 ### S2 — บันทึกการเปิดตัวเวอร์ชันอย่างเป็นทางการของ NGINX - - ยืนยัน 1.30.6 / 1.31.7 ของ 2026-10-14, 1.31.8 ของ 2026-10-21 และเหตุการณ์สำคัญในการเผยแพร่การรักษาความปลอดภัยที่สำคัญตั้งแต่เดือนพฤษภาคมถึงกันยายน ### S3 - Cyber Security Agency of Singapore: F5 NGINX ช่องโหว่ที่สำคัญสามรายการ - คำอธิบายของคะแนน CVSS v4.0 9.2 เงื่อนไขการกำหนดค่าที่จำเป็น และคำแนะนำการลดปัญหาชั่วคราวสำหรับ CVE-2026-15176, CVE-2026-93479 และ CVE-2026-97205 ### S4 - NHS อังกฤษ: F5 NGINX คำแนะนำที่มีความเสี่ยงสูง - อธิบายผลกระทบ DoS / RCE ที่อาจเกิดขึ้นจากปัญหาด้านความปลอดภัยของหน่วยความจำ และข้อจำกัด เช่น ASLR ที่ถูกปิดหรือข้าม ### S5 — แหล่งที่มาอย่างเป็นทางการคอมมิต: CVE-2026-15176 - สอดคล้องกับการตรวจสอบสถานะของ `alias` และ `r->uri_changed` ใน `ngx_http_map_uri_to_path()` ### S6 — แหล่งที่มาอย่างเป็นทางการคอมมิต: CVE-2026-93479 - สอดคล้องกับความยาวสคริปต์ HTTP/Stream และตรรกะการจัดสรรบัฟเฟอร์ที่สงวนไว้ ### S7 - แหล่งที่มาอย่างเป็นทางการคอมมิต: CVE-2026-97205 - สอดคล้องกับขีดจำกัดการนับ `r->main->blocked` `NGX_HTTP_MAX_BLOCKED 250` และเส้นทางสำรองแบบอะซิงโครนัส ### S8 — แหล่งที่มาอย่างเป็นทางการคอมมิต: CVE-2026-95101 - การแยกสถานะที่สอดคล้องกับความยาวคงเหลือของเฟรมที่ไม่รู้จัก HTTP/3 และความยาวของตัวคำขอ DATA ### S9 - แหล่งที่มาอย่างเป็นทางการคอมมิต: CVE-2026-97629 - สอดคล้องกับช่องคีย์ทั้งหมดระหว่างการซิงโครไนซ์การหมุนเวียนตั๋วเซสชัน TLS ### S10 — F5: ประกาศของผู้จำหน่าย CVE-2026-15176 - แสดงรายการปัจจัยทริกเกอร์ เช่น `alias`, `rewrite`, `$request_filename` และบันทึกการเข้าถึง ### S11 — F5: ประกาศผู้ขาย CVE-2026-93479 - แสดงรายการการจับภาพ regex ของแผนที่ เส้นทาง root และเงื่อนไขการประเมินตัวแปรของบันทึก ### S12 — เอกสารประกอบโมดูล NGINX อย่างเป็นทางการของ TLS/SSL - คำอธิบาย `ssl_session_cache`, `ssl_session_tickets`, `ssl_session_ticket_key` และการรับรองความถูกต้องใบรับรองไคลเอ็นต์และคำแนะนำอื่น ๆ ### S13 — คำแนะนำด้านความปลอดภัย: Ubuntu USN-8955-1 (2026-10-26) - มอบแพ็คเกจซอฟต์แวร์เวอร์ชันคงที่ที่สมบูรณ์และขอบเขตการจำหน่ายของ Ubuntu 22.04 / 24.04 / 26.04 / 26.10. ### S14 — คำแนะนำด้านความปลอดภัย: Debian DSA-6575-1 (2026-10-21) - ยืนยันแพ็คเกจแก้ไขความปลอดภัย `1.26.3-3+deb13u10` สำหรับ Debian 13 / trixie และบันทึกการเชื่อมโยงแบ็คพอร์ตสำหรับ CVE-2026-93479 ### S15 — การติดตามช่องโหว่: Debian Security Tracker: CVE-2026-15176 - ใช้เพื่อตรวจสอบสถานะการแก้ไขการกระจายของ Debian 12 / bookworm และ Debian 13 / trixie สถานะนี้อาจเปลี่ยนแปลงเมื่อมีการอัปเดตความปลอดภัยในอนาคต ### S16 — การติดตามช่องโหว่: Debian Security Tracker: CVE-2026-95101 - การยืนยันเพิ่มเติมเกี่ยวกับสถานะความปลอดภัยของช่องโหว่ HTTP/3 บนสาขาต่างๆ ของ Debian ### S17 — คำแนะนำด้านความปลอดภัย: Red Hat: CVE-2026-93479 - ความเข้าใจเพิ่มเติมเกี่ยวกับความสัมพันธ์ระหว่างช่องโหว่การถดถอยในเดือนตุลาคมและการแก้ไขสำหรับ CVE-2026-42533 เดือนกรกฎาคม ### S18 — เอกสารโมดูลพร็อกซีย้อนกลับอย่างเป็นทางการของ NGINX - - ค้นหาความหมายและค่าเริ่มต้นของการกำหนดค่า เช่น `proxy_request_buffering`, `client_max_body_size`, `alias`, `aio` เป็นต้น ### S19 — NGINX Plus บันทึกประจำรุ่นอย่างเป็นทางการ - List Plus CR/LTS สาขา เวอร์ชัน แพตช์ และการแจ้งเตือนความเข้ากันได้ของการอัพเกรด ### S20 — NGINX JavaScript / njs กระดานข่าวความปลอดภัยอย่างเป็นทางการ - - ประกอบด้วย njs 1.0.2 เดือนตุลาคม 2026 และการตรวจสอบ XML ที่เกี่ยวข้อง ปัญหาหน่วยความจำหมด ### S21 — Kubernetes: คำแนะนำการเกษียณอายุอย่างเป็นทางการของชุมชน ingress-nginx - - โปรดทราบว่าโปรเจ็กต์หยุดการเปิดตัวใหม่และการแก้ไขความปลอดภัยในเดือนมีนาคม 2026 และขอแนะนำให้ย้ายตัวควบคุมที่ได้รับการบำรุงรักษาหรือ Gateway API ### S22 — การควบคุมบริการอย่างเป็นทางการของ NGINX และคำแนะนำในการอัพเกรดไบนารีออนไลน์ - แยกแยะวิธีการรีโหลดการกำหนดค่า การรีสตาร์ท และการอัพเกรดไฟล์ปฏิบัติการแบบออนไลน์สำหรับการยอมรับการสลับกระบวนการ ### S23 - ประกาศด้านความปลอดภัยของรัฐบาล: พฤษภาคม 2026 NGINX เขียนช่องโหว่ใหม่ - - ให้ข้อมูลประวัติความเสี่ยงและคำแนะนำในการอัปเดตความปลอดภัยสำหรับ CVE-2026-42945 การตัดสินที่เกี่ยวข้องกับการแสวงประโยชน์ในป่าควรเป็นไปตามประกาศของหน่วยงานในขณะนั้นและหลักฐานเหตุการณ์เพิ่มเติม ### S24 — F5: CVE-2026-95101 และ CVE-2026-97629 ประกาศผู้จำหน่าย - - ครอบคลุมความเสี่ยงของการฉีดตัวถังคำขอ HTTP/3 และการหมุนคีย์ตั๋ว TLS อัตโนมัติตามลำดับ ### S25 — F5: ประกาศของผู้จำหน่าย CVE-2026-97205 - คำอธิบาย เงื่อนไขทริกเกอร์ SSI/AIO และความเสี่ยงต่อความเสียหายของหน่วยความจำที่อาจเกิดขึ้น [การอัปเดตความปลอดภัย NGINX: การตรวจสอบการกำหนดค่า การอัพเกรด และการยืนยัน](https://keendigit.com/th/news/nginx-security-update) ## ให้คำปรึกษาด้านการรักษาความปลอดภัย ไม่แน่ใจว่าการเปลี่ยนแปลงความน่าเชื่อถือของใบรับรองส่งผลต่อระบบของคุณอย่างไร เราสามารถช่วยประเมินลูกค้าที่ได้รับผลกระทบและวางแผนการอัปเดตความปลอดภัยได้ [หารือเกี่ยวกับการอัปเดตความปลอดภัย]() [หน้าเดิม]() · [ดัชนีเนื้อหา]() KeenDigit LLC · รหัสการยื่นไวโอมิง: 2026-002106155 [ตรวจสอบกับรัฐมนตรีต่างประเทศไวโอมิง]() © 2026 KeenDigit LLC · เชอริแดน ไวโอมิง สหรัฐอเมริกา · สงวนลิขสิทธิ์.