ช่องโหว่ NGINX: สาเหตุ การแก้ไข และการตรวจสอบการผลิต

วันที่บทความในอดีต: 2026-10-14 (วันที่เปิดเผยและวันที่เผยแพร่เรื่องความปลอดภัย) ตรวจสอบแหล่งที่มาและข้อมูลเสริมผ่าน 2026-10-27

บทความนี้ถูกเก็บถาวรตามวันที่จัดงาน การอัปเดตเวอร์ชันและการเปิดตัวที่เผยแพร่หลังวันที่ 14 ตุลาคมมีดังต่อไปนี้ ผู้ชม: เว็บไซต์ NGINX Open Source / NGINX Plus และเจ้าหน้าที่ปฏิบัติการและบำรุงรักษา Reverse proxy เจ้าหน้าที่ตอบสนองด้านความปลอดภัย ผู้ดูแลการจัดจำหน่าย รวมถึงวิศวกรที่คอมไพล์ NGINX ด้วยตนเองและบำรุงรักษาโมดูลของบุคคลที่สาม

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

TL; DR: การดำเนินการตามลำดับความสำคัญ

1. จัดลำดับความสำคัญของการอัพเกรดความปลอดภัย สำหรับแพ็คเกจ nginx.org Open Source ให้อัปเดตสาขา Stable 1.30 เป็นอย่างน้อย 1.30.6 และสาขา Mainline 1.31 เป็นอย่างน้อย 1.31.7. ณ วันที่ตรวจสอบ 1.31.8 จะเป็น Mainline รุ่นใหม่ล่าสุด สิ่งเหล่านี้เป็นข้อมูลพื้นฐานสาขาที่แยกจากกัน อย่าเปรียบเทียบตัวเลขข้ามสาขา S1S2
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 ได้รับการแก้ไขแล้ว S13S14S15
3. ตรวจสอบชุดการกำหนดค่าห้าชุด: alias + rewrite + $request_filename, map + regex + การประเมินตัวแปร, aio + ssi + include virtual, HTTP/3 พร้อม proxy_request_buffering on และ ssl_session_cache shared:... พร้อมการหมุนเวียนคีย์ตั๋วเซสชัน TLS อัตโนมัติ การมีอยู่ของคำสั่งเพียงอย่างเดียวไม่ได้สร้างความสามารถในการเอารัดเอาเปรียบ ประเมินเส้นทางคำขอและขอบเขตการกำหนดค่า S1S3S4
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 ขีดจำกัดอัตราและการเปลี่ยนแปลงการกำหนดค่าครอบคลุมเฉพาะเงื่อนไขบางประการเท่านั้น และไม่สามารถแทนที่แพตช์อย่างเป็นทางการได้ S3S4S8S12

1. ภาพรวมช่องโหว่และการตัดสินความเสี่ยง

NGINX เปิดตัว 1.30.6 (Stable) และ 1.31.7 (Mainline) เมื่อวันที่ 14 ตุลาคม 2026 โดยแก้ไขปัญหาด้านความปลอดภัยห้าประการ สามรายการเกี่ยวข้องกับฮีปโอเวอร์โฟลว์หรือการใช้งานหลังเลิกใช้ และได้รับคะแนน F5 CVSS v4.0 ของ 9.2 / Critical อีกสองรายการส่งผลต่อความสมบูรณ์ของคำขอ HTTP/3 และการตรวจสอบใบรับรองไคลเอ็นต์ TLS S1S2S3

แยกแยะระบบการให้คะแนน: nginx.org แสดงรายการปัญหาทั้งห้ารายการเป็น medium ในขณะที่ F5 CVSS v4.0 และหน่วยงานความมั่นคงแห่งชาติบางแห่งจัดประเภทปัญหาหน่วยความจำสามรายการว่าร้ายแรง นี่ไม่ได้หมายความว่าทั้งห้าอนุญาตให้มีการเรียกใช้โค้ดจากระยะไกลโดยไม่มีเงื่อนไข การกำหนดค่า ความสามารถในการเข้าถึงการรับส่งข้อมูล และเงื่อนไขที่อยู่นอกการควบคุมของผู้โจมตี ความเสียหายของหน่วยความจำและ RCE ที่เชื่อถือได้นั้นเป็นหลักฐานในระดับที่แตกต่างกัน S1S3S4

ซีวีอี	ปัญหาทางเทคนิคและเงื่อนไขทริกเกอร์ทั่วไป	ผลกระทบหลัก	การประเมินและการกำจัด
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 ของตัวเองเกรดและการจัดอันดับความรุนแรงของการจัดจำหน่าย S1S3S4

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

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

2. การวิเคราะห์สาเหตุ

2.1 ทำความเข้าใจขอบเขตที่เสี่ยงต่อข้อผิดพลาดสามประการใน NGINX

NGINX worker เป็นกระบวนการที่ขับเคลื่อนด้วยเหตุการณ์ที่มีอายุการใช้งานยาวนาน ซึ่งจะรักษาสถานะคำขอ การดำเนินการแบบอะซิงโครนัส และตัวแยกวิเคราะห์โปรโตคอล ช่องโหว่นี้รวบรวมข้อจำกัดในระดับวิศวกรรมสามระดับ:

1. การประเมินตัวแปรและขนาดหน่วยความจำต้องสอดคล้องกัน: rewrite หลังจากเปลี่ยนคำขอ URI การแมปพาธจะต้องสอดคล้องกับ location ที่มีผลในปัจจุบัน เมื่อตัวแปลสคริปต์คำนวณความยาวตัวแปร พื้นที่เขียนจะต้องครอบคลุมเอาต์พุตจริงและพื้นที่ที่สงวนไว้
2. การดำเนินการแบบอะซิงโครนัสต้องขยายวงจรชีวิตของหน่วยความจำที่ร้องขอ: เมื่อมีการอ่านและเขียนไฟล์ การรอแคช หรืองานเธรดที่ยังไม่เสร็จ พูลหน่วยความจำคำขอที่เกี่ยวข้องจะไม่สามารถเผยแพร่ล่วงหน้าได้
3. สถานะโปรโตคอลและสถานะความปลอดภัยไม่สามารถผสมหรือละเว้นได้: HTTP/3 ความยาวของการข้ามเฟรมที่ไม่รู้จักไม่สามารถถือเป็นความยาวเนื้อหาคำขอ DATA; TLS ช่องคีย์ทั้งหมดที่เข้าร่วมในการตรวจสอบลายเซ็นจะต้องเริ่มต้นและซิงโครไนซ์อย่างถูกต้องในระหว่างการหมุนเวียนตั๋วเซสชัน

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

2.2 CVE-2026-15176: การแมปพาธระหว่าง alias และ URI ที่เขียนใหม่ไม่ถูกต้อง

ใน NGINX location ที่ตรงกันและ alias จะกำหนดพาธของไฟล์ rewrite สามารถเปลี่ยนคำขอปัจจุบัน URI ได้ หลังจากเขียนใหม่ สมมติฐานที่ใช้โดยการแมป location ดั้งเดิมอาจไม่คงอยู่อีกต่อไป

เส้นทางการประมวลผลที่ได้รับผลกระทบไม่ได้ตรวจสอบอย่างเพียงพอว่าคำขอถูกเขียนใหม่หรือไม่เมื่อตรวจสอบสถานะ alias ใน ngx_http_map_uri_to_path() เมื่อการกำหนดค่ายังคงประเมิน $request_filename หลังจากเขียนใหม่ เส้นทางอาจถูกสร้างขึ้นด้วยสมมติฐานที่ไม่สอดคล้องกับสถานะ URI ปัจจุบัน ซึ่งท้ายที่สุดจะทริกเกอร์การเขียนนอกขอบเขตไปยังหน่วยความจำฮีป S5

การรวมกันโดยทั่วไป (ใช้เป็นตัวอย่างแย้งสำหรับการตรวจสอบการกำหนดค่าเท่านั้น ไม่แนะนำให้ปรับใช้):

# 仅用于识别风险模式：不是修复配置
location /foo/ {
    alias /srv/alias-root/;
    rewrite ^/foo/.*$ /new-path;
    return 200 $request_filename;
}

อันตรายไม่ได้จำกัดอยู่เพียง return: set, if, add_header, log_format ฯลฯ ยังต้องได้รับการตรวจสอบด้วยหากการประเมิน $request_filename ถูกทริกเกอร์ในกระบวนการร้องขอเดียวกัน return ในตัวอย่างทำให้มองเห็นพาธสถานะนี้ได้ง่ายเท่านั้น ไม่สามารถใช้อนุมานได้ว่าการกำหนดค่าการผลิตทั้งหมดจะทำให้เกิดโอเวอร์โฟลว์ S5S10

ผลที่ตามมาจากการโจมตี: การสร้างคำขออาจทำให้ Worker รีสตาร์ทหรือบริการหยุดชะงัก ภายใต้เงื่อนไขเช่น ASLR ที่ถูกปิดหรือสามารถข้ามได้ ก็มีความเป็นไปได้ที่ RCE แกนหลักของแพตช์อัปสตรีมคือการปฏิเสธที่จะดำเนินการแมปพาธ URI ที่เขียนใหม่ให้เสร็จสิ้นในบริบท alias ที่ไม่ถูกต้องอีกต่อไป แทนที่จะขยายบัฟเฟอร์บางตัว S5S10

2.3 CVE-2026-93479: ไม่ตรงกันระหว่าง “พื้นที่สงวน” และความยาวตัวแปรจริงในการประเมินสคริปต์

โมดูล HTTP และ Stream ของ NGINX มีตัวประเมินสคริปต์ที่เชื่อมสตริงตัวอักษรและค่าตัวแปรเข้ากับสตริงผลลัพธ์ ตัวอย่างแอปพลิเคชันประกอบด้วยเส้นทางเอกสาร HTTP root เส้นทางบันทึกการเข้าถึง และนิพจน์ตัวแปรใน Stream

การกำหนดค่าบางอย่างของ map + นิพจน์ทั่วไปทำให้ค่าที่บันทึกไว้สามารถอ่านได้โดยนิพจน์อื่น ก่อนที่จะประเมินตัวแปรผลลัพธ์ map เมื่อรวมกับวิธีการดำเนินการสคริปต์ที่มีความยาวที่สงวนไว้ การใช้งานแบบเก่าจะนับพื้นที่ที่สงวนไว้ len ลงในตัวสะสมความยาวที่ประเมินล่วงหน้า เพื่อให้การคำนวณตัวชี้การเขียนในภายหลังไม่สอดคล้องกับขอบเขตบัฟเฟอร์อีกต่อไป ในลำดับการประเมินตัวแปรเฉพาะ การเขียนสตริงที่ตามมาอาจเขียนทับพื้นที่ที่สงวนไว้ ทำให้เกิดฮีปโอเวอร์โฟลว์ S6

องค์ประกอบการมีส่วนร่วม	เหตุใดจึงควรให้ความสนใจ
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 ของเดือนตุลาคมแล้ว ควรตรวจสอบห่วงโซ่การรักษาความปลอดภัยทั้งหมด S6S14S17

ความเสี่ยงของ RCE ที่อาจเกิดขึ้นที่นี่เกี่ยวข้องกับสภาพแวดล้อมการป้องกันหน่วยความจำ และไม่ควรอ้างว่า map regex เพียงอย่างเดียวจะสามารถถูกโจมตีโดยผู้โจมตีที่ไม่ระบุชื่อได้ S11

2.4 CVE-2026-97205: AIO การนับจำนวนการดำเนินการที่ยังไม่เสร็จทำให้เกิดการใช้งานหลังเลิกใช้งาน

ช่องโหว่นี้ไม่ใช่แค่ “เปิด SSI แล้วคุณจะได้รับ UAF” คีย์อยู่ที่จำนวนการอ้างอิงการดำเนินการแบบอะซิงโครนัสที่ถือโดยคำขอหลัก

NGINX ใช้ r->main->blocked เพื่อติดตามการประมวลผลแบบอะซิงโครนัสที่ยังไม่เสร็จสมบูรณ์ ในการใช้งานแบบเก่านั้นมีจำนวน 8 บิต บางเส้นทางไม่ได้ทำการตรวจสอบขีดจำกัดบนก่อนที่จะเพิ่มจำนวน เมื่อคำขอหลักเดียวกันสะสมการดำเนินการคงค้าง 256 รายการ การนับอาจวนจาก 255 เป็น 0 กระบวนการต่อมาจะเข้าใจผิดว่าไม่มีการดำเนินการแบบอะซิงโครนัสที่ขัดขวางไม่ให้มีการเผยแพร่คำขอ ดังนั้นจึงปล่อยพูลหน่วยความจำคำขอที่ยังคงอ้างอิงโดยงาน S7

กระบวนการล้มเหลวสามารถแบ่งออกเป็น:

1. เมื่อเปิดใช้งาน I/O/เส้นทางเธรดแบบอะซิงโครนัสที่เกี่ยวข้อง หน้า SSI จะแนะนำคำขอย่อยหลายรายการหรือการดำเนินการอ่านผ่าน include virtual
2. การดำเนินการคงค้างของคำขอหลักบางรายการจะสะสมจนถึงขีดจำกัดบนที่แสดงโดยฟิลด์การนับ
3. การนับแบบ 8 บิตวนเวียน แสดงอย่างไม่ถูกต้องว่า “ไม่มีการดำเนินการที่รอดำเนินการ”
4. พูลหน่วยความจำคำร้องขอจะถูกปล่อยออกมา ในขณะที่การอ่านไฟล์ การรอแคช หรือการเรียกกลับของงานเธรดยังคงรักษาการอ้างอิงไว้
5. การเรียกกลับเสร็จสิ้นแบบอะซิงโครนัสตามมาจะเข้าถึงหน่วยความจำที่ปล่อยออกมา ส่งผลให้ UAF, Worker หยุดทำงานหรือหน่วยความจำเสียหาย

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

การตัดสินการบังคับใช้: จะต้องได้รับการประเมินว่า SSI, AIO, การรวมเสมือน, คำขอย่อย และการดำเนินการอะซิงโครนัสที่เกี่ยวข้องสามารถเกิดขึ้นร่วมกันในห่วงโซ่คำขอเดียวกันได้หรือไม่ โดยปกติแล้วสิ่งเหล่านี้จะไม่ใช่การกำหนดค่าพร็อกซีคงที่แบบธรรมดาที่เป็นค่าเริ่มต้น aio off; หรือ ssi off; สามารถลบองค์ประกอบทริกเกอร์เฉพาะได้ แต่ควรยืนยันการขึ้นต่อกันของฟังก์ชันธุรกิจก่อน S4S7S25

2.5 CVE-2026-95101: เฟรมที่ไม่รู้จัก HTTP/3 สับสนกับสถานะของเนื้อหาคำขอ DATA

ตัวแยกวิเคราะห์เฟรม HTTP/3 ต้องแยกแยะระหว่างเฟรม DATA (ซึ่งจำเป็นต้องส่งผ่านไปยังการประมวลผลเนื้อหาคำขอ HTTP) และเฟรมที่ไม่รู้จักซึ่งควรข้ามไป ความยาวของเฟรมที่ไม่รู้จักจะต้องได้รับการเก็บรักษาไว้อย่างถูกต้องเมื่อแยกส่วนในบัฟเฟอร์เครือข่าย

การใช้งาน ngx_http_v3_parse_data() แบบเก่าใช้ฟิลด์ st->length เพื่อบันทึก “จำนวนไบต์ที่เหลือที่จะข้าม” เมื่อข้ามเฟรมที่ไม่รู้จัก ในขณะที่ตัวกรองเนื้อหาคำขอตีความฟิลด์เดียวกันกับ “ความยาวเพย์โหลด DATA ที่เหลืออยู่” หากเฟรมที่ไม่รู้จักเกิดขึ้นเพื่อขยายการเรียกแยกวิเคราะห์หลายครั้ง ชุดไบต์ถัดไปหลังจากการแยกวิเคราะห์ถูกขัดจังหวะอาจถูกเข้าใจผิดว่าเป็นส่วนหนึ่งของเนื้อหาคำขอ S8

ความเสี่ยงเกิดขึ้นสองประเภท:

• ขอการฉีดเนื้อหา: เพย์โหลดเฟรมที่ไม่ใช่ 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; ไม่ได้ถูกเขียนไว้อย่างชัดเจน S8S18

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

2.6 CVE-2026-97629: TLS การหมุนเวียนตั๋วพลาดช่องคีย์ที่สาม

ในการกำหนดค่าที่ได้รับผลกระทบ NGINX สามารถสร้างและหมุนคีย์ตั๋วเซสชัน TLS โดยอัตโนมัติผ่านแคชหน่วยความจำที่ใช้ร่วมกัน ทำให้ Worker หลายตัวสามารถประมวลผลตั๋วชุดเดียวกันได้

ตรรกะการซิงโครไนซ์ที่เกี่ยวข้องจะจัดสรรสล็อตคีย์ 3 ช่องสำหรับแต่ละ Worker และการเรียกกลับเพื่อถอดรหัสจะสำรวจช่องเหล่านี้ด้วย แต่การใช้งานแบบเก่าจะคัดลอกช่องคีย์เพียง 2 ช่องจากหน่วยความจำที่ใช้ร่วมกันในแต่ละครั้ง ส่งผลให้ชื่อคีย์ คีย์ HMAC และ AES ของช่องที่สาม คีย์อาจยังไม่ได้เตรียมใช้งาน หากตัวระบุคีย์ของตั๋วตรงกับสถานะนี้ วัสดุคีย์ที่ยังไม่ได้เตรียมใช้งานอาจถูกนำมาใช้สำหรับการตรวจสอบลายเซ็นและการถอดรหัส ซึ่งจะสร้างเส้นทางเพื่อสร้างเซสชัน TLS S9

โดยทั่วไปชุดค่าผสมการปรับใช้งานที่มีความเสี่ยงสูงมีดังนี้:

# 仅为排查触发条件所示：共享缓存本身不是恶意配置
ssl_session_cache shared:SSL:10m;
# 未显式配置 ssl_session_ticket_key 文件，使用自动轮换机制

ผลลัพธ์ทางธุรกิจที่ร้ายแรงที่สุดของช่องโหว่นี้คือในบริการที่ใช้การรับรองความถูกต้องใบรับรองไคลเอ็นต์ (mTLS) ใน ssl_verify_client on; และวิธีอื่น ๆ เซสชันการกู้คืนที่ปลอมแปลงอาจข้ามการตรวจสอบใบรับรองไคลเอ็นต์ ความสำเร็จของการโจมตีนั้นขึ้นอยู่กับเงื่อนไขที่ไม่สามารถควบคุมได้เช่นกัน ไซต์ที่ใช้เฉพาะใบรับรอง HTTPS ฝั่งเซิร์ฟเวอร์ปกติและไม่มีการตรวจสอบสิทธิ์ใบรับรองไคลเอ็นต์ไม่ควรมีลักษณะผิดเนื่องจาก “ผู้โจมตีสามารถข้ามการเข้าสู่ระบบเว็บไซต์ทั้งหมดได้” S9S12

นี่เป็นปัญหาสถานะการตรวจสอบสิทธิ์เซสชัน TLS และไม่มีส่วนเกี่ยวข้องกับคีย์ส่วนตัว TLS ของเซิร์ฟเวอร์ถูกถอดรหัสหรือไม่ หรือใบรับรอง CA root สาธารณะได้รับผลกระทบหรือไม่ S24

2.7 วิธีทำความเข้าใจ DoS, RCE, การเลี่ยงการรับรองความถูกต้องและช่องโหว่ที่รู้จัก

• DoS: ข้อผิดพลาดของหน่วยความจำทำให้ Worker หยุดทำงานหรือรีบูตจำนวนมาก ไม่ว่าสาเหตุนั้นจะทำให้เกิดความไม่พร้อมใช้งานโดยรวมหรือไม่นั้นจะขึ้นอยู่กับความกดดันด้านการรับส่งข้อมูล ความสามารถในการรีสตาร์ทกระบวนการ เวลาในการบำรุงรักษาการเชื่อมต่อ และสถาปัตยกรรมที่มีความพร้อมใช้งานสูง
• ศักยภาพของ RCE: การประกาศบางอย่างระบุว่ามีความเป็นไปได้ที่จะมีการเรียกใช้โค้ดเมื่อ ASLR ถูกปิดหรือข้าม นี่ไม่ได้หมายความว่ามีการเปิดเผยห่วงโซ่การโจมตีสาธารณะที่สามารถดำเนินการคำสั่งได้อย่างเสถียรและเป็นสากล S4
• ขอบายพาสการแทรก/การรับรองความถูกต้อง: อาจเปลี่ยนสถานะธุรกิจที่ได้รับการคุ้มครองหรือเนื้อหาคำขอโดยตรง และไม่สามารถเพิกเฉยได้เพียงเพราะมันไม่ได้รับเชลล์โดยตรง
• ได้ค้นพบความพยายามในการโจมตี: CVE-2026-42945 ในเดือนพฤษภาคม 2569 มีรายงานกิจกรรมการแสวงหาผลประโยชน์ในป่า ไม่ควรสรุปข้อเท็จจริงทางประวัติศาสตร์นี้โดยตรงเพื่อหมายความว่า CVE ทั้งห้ารายการในเดือนตุลาคมได้ถูกนำไปใช้ประโยชน์ในวงกว้างอย่างประสบความสำเร็จ S23

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 S1S2

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

3.3 Ubuntu: แบ็กพอร์ตการแจกจ่าย (USN-8955-1)

Canonical USN-8955-1 วันที่ 26 ตุลาคม 2026 มีการอัปเดตความปลอดภัยสำหรับรุ่น Ubuntu สี่รุ่น: S13

เวอร์ชัน 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

3.4 Debian: ต้องตรวจสอบความแตกต่างระหว่างเวอร์ชันแยกต่างหาก

ที่ปรึกษา Debian DSA-6575-1 (2026-10-21) ครอบคลุม CVE ห้ารายการเหล่านี้ และระบุแพ็คเกจ nginx แบบคงที่สำหรับ Debian 13 / trixie เป็น:

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 S14S15S16

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
njs / ngx_http_js_module	2026-10-14 เปิดตัว njs 1.0.2 และแก้ไข CVE-2026-101019 และ CVE-2026-101025 หากคุณใช้ njs คุณต้องตรวจสอบความเข้ากันได้ของโมดูลกับ NGINX ด้วย S20
F5 NGINX ตัวควบคุมทางเข้า / ผ้าเกตเวย์	แกน NGINX เป็นเครือข่ายการจัดจำหน่ายซอฟต์แวร์ที่เกี่ยวข้องแต่เป็นอิสระ แก้ไขช่องโหว่ที่เกี่ยวข้องด้วยตัวควบคุม รูปภาพ และบันทึกประจำรุ่นที่เกี่ยวข้อง คุณไม่สามารถแทนที่ไบนารี NGINX ใน Pod ได้
ชุมชน Kubernetes kubernetes/ingress-nginx	โครงการนี้เลิกใช้งานในเดือนมีนาคม 2026 และจะไม่มีการบำรุงรักษาความปลอดภัยใหม่อีกต่อไป คุณควรวางแผนที่จะย้ายไปยังคอนโทรลเลอร์ที่ได้รับการบำรุงรักษาหรือ Gateway API แทนที่จะเข้าใจผิดหมายเลขรุ่นสำหรับ F5 NGINX Ingress Controller S21

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 ตรวจสอบเวอร์ชันและข้อมูลการคอมไพล์

# 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 และการอนุญาตไฟล์ส่วนตัว และอย่าโพสต์ไฟล์ต้นฉบับในคำสั่งงานสาธารณะ:

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 (พื้นที่เก็บข้อมูลการจัดจำหน่ายอย่างเป็นทางการ):

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 หากแพ็คเกจที่อัปเกรดแล้วยังคงถือว่ามีช่องโหว่จากระบบติดตามความปลอดภัย จำเป็นต้องมีมาตรการซ่อมแซม การแยก หรือการย้ายผู้จำหน่ายเพิ่มเติม S13S14S15

แพคเกจอย่างเป็นทางการ nginx.org:

# 先确认仓库来自 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 เก่า

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

หากคุณจัดการ NGINX ผ่านซ็อกเก็ต systemd สคริปต์รายการคอนเทนเนอร์ หรือการติดตั้งหลายรายการ คุณควรตรวจสอบเป้าหมายการเปิดใช้งานจริงและเส้นทางกระบวนการ แทนที่จะสันนิษฐานโดยตรงว่า systemctl restart nginx ครอบคลุมอินสแตนซ์ทั้งหมด

4.6 ยอมรับและดำเนินการถดถอยทางธุรกิจจากทางเข้าภายนอกที่แท้จริง

ขอแนะนำให้ดำเนินการอย่างน้อย:

• HTTPS ปกติ เส้นทางที่เขียนใหม่ ทรัพยากรคงที่ และหน้าการแมป alias ถูกต้องหรือไม่
• การแจกแจง map ปกติ, พาธ root แบบแปรผัน, พาธบันทึกการเข้าถึง, การกำหนดเส้นทาง SNI/ใบรับรอง และพร็อกซี Stream ถูกต้องหรือไม่
• การอัปโหลดปกติ การอัปโหลดแบบเป็นกลุ่ม คำขอ API และขีดจำกัดวอลุ่มอัปสตรีมสำหรับ HTTP/3 (เมื่อเปิดใช้งาน) ยังคงเป็นไปตามที่คาดไว้
• mTLS: การร้องขอใบรับรองที่ถูกต้องควรสำเร็จ ใบรับรองที่หายไป หมดอายุหรือไม่ได้รับอนุญาตควรยังคงถูกปฏิเสธ และการเริ่มต้นใหม่/การเชื่อมต่อใหม่ TLS ไม่ควรเปลี่ยนการอนุญาตโดยไม่ได้ตั้งใจ
• การเข้าถึงเพจ SSI และไฟล์แบบอะซิงโครนัสเป็นเรื่องปกติหรือไม่ บันทึกข้อผิดพลาดไม่แสดงคำขอที่ผิดปกติสำหรับการอ้างอิงหน่วยความจำหรือการขัดข้องของ Worker ซ้ำๆ
• หลังจากเปลี่ยนการรับส่งข้อมูล กระบวนการเวอร์ชันเก่าและแบบจำลองรูปภาพเก่าควรจะออกแล้ว

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

5. มาตรการบรรเทาผลกระทบเมื่อไม่สามารถอัพเกรดได้ทันที

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

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

5.3 map/Regex: ลดการผสมสถานะตัวแปรการจับ

ขอแนะนำให้จัดลำดับความสำคัญของการจับภาพที่มีชื่อและจำกัดขอบเขตการเผยแพร่ แทนที่จะปล่อยให้การจับภาพที่ไม่ระบุชื่อ เช่น $1 ถูกนำมาใช้ซ้ำในพาธการประเมิน regex ต่างๆ เมื่อเวลาผ่านไป ตัวอย่างเช่น:

# 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整
map $host $tenant_root {
    default /srv/www/default;
    ~^(?<tenant>[a-z0-9-]+)\.example\.net$ /srv/www/$tenant;
}

ตัวอย่างนี้แสดงให้เห็นเฉพาะโครงสร้างที่ง่ายต่อการตรวจสอบของการเป็นเจ้าของตัวแปรเท่านั้น ไม่ได้หมายความว่าได้รับการพิสูจน์แล้วว่าสามารถกำจัดพาธทริกเกอร์ CVE-2026-93479 ทั้งหมดได้อย่างอิสระ โดยเฉพาะอย่างยิ่ง ตรวจสอบว่าตัวแปรการจับถูกอ้างอิงล่วงหน้าโดย root หรือ log_format อื่นๆ หรือไม่ และมี volatile เส้นทางไดนามิก และห่วงโซ่การประเมินที่พึ่งพาซึ่งกันและกัน F5/CERT ขอแนะนำให้ใช้การบันทึกที่มีชื่อและจำกัดขอบเขตการใช้งานให้สอดคล้องกับการกำหนดค่าการจับคู่ปกติที่เกี่ยวข้อง เพื่อเป็นการบรรเทาระยะสั้น S3S6

5.4 AIO + SSI: ปิดการรวมฟังก์ชันที่ไม่จำเป็น

สำหรับเซิร์ฟเวอร์/พาธที่ไม่ต้องการ SSI หรือ I/O ไฟล์อะซิงโครนัส ให้ใช้:

# 在适当的 http/server/location 上下文中配置
ssi off;
aio off;

จากมุมมองของเงื่อนไขที่ทำให้เกิดช่องโหว่ การปิดหนึ่งในสองรายการมักจะเพียงพอที่จะลบห่วงโซ่เฉพาะที่อธิบายไว้ การปิดบัญชีในเวลาเดียวกันใช้ได้กับสถานการณ์ที่ธุรกิจไม่ได้พึ่งพาความสามารถนี้เท่านั้น ตรวจสอบ include virtual คำขอย่อย แคช และลักษณะการทำงานของเธรดพูล เมื่อโหลดพร็อกซีย้อนกลับสูง การปิดระบบ AIO อาจเปลี่ยนแปลงเวลาแฝงและประสิทธิภาพ I/O S7

5.5 HTTP/3 ขอฉีดร่างกาย: ปิดทางเข้าชั่วคราวหากจำเป็น

ปิดการใช้งาน quic Listener ที่เกี่ยวข้องกับ HTTP/3 ยกเลิกส่วนหัวการตอบสนอง Alt-Svc ที่ประกาศ HTTP/3 และตรวจสอบว่า Edge Layer/Load Balancer ยังคงส่งคำขอ QUIC ไปยัง 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 ที่ได้รับผลกระทบเท่านั้น S8S18

ตั๋วเซสชัน 5.6 TLS: การป้องกันลำดับความสำคัญ mTLS ขอบเขตการตรวจสอบความถูกต้อง

หากไม่สามารถอัปเกรดได้และอินสแตนซ์อาศัยแคชเซสชันที่ใช้ร่วมกัน + การหมุนเวียนคีย์ตั๋วอัตโนมัติ ให้ประเมิน:

# 在 nginx http/server 适当作用域进行配置
ssl_session_tickets off;

วิธีนี้สามารถปิดกลไกตั๋วเซสชัน TLS ได้ ซึ่งจะลบเส้นทางการปลอมแปลงตั๋วที่อธิบายไว้ในช่องโหว่นี้ อย่างไรก็ตาม อาจส่งผลต่อประสิทธิภาพในการเริ่มเซสชันใหม่ คุณไม่สามารถปิดการตรวจสอบใบรับรองไคลเอ็นต์ mTLS เพื่อ “หลีกเลี่ยงช่องโหว่” ได้ เนื่องจากจะเป็นการลบขอบเขตการรับรองความถูกต้องเดิมโดยตรง S9S12

ไฟล์ ssl_session_ticket_key ที่ชัดเจนและการหมุนเวียนอย่างปลอดภัยยังสามารถนำมาใช้โดยกระบวนการจัดการ TLS ระดับมืออาชีพ เพื่อหลีกเลี่ยงเงื่อนไขที่สร้างขึ้นโดยอัตโนมัติ แต่การดูแลคีย์ การกระจายโหนดแบบเต็ม การหมุนเวียน และวงจรอายุตั๋วเก่า ล้วนจำเป็นต้องได้รับการตรวจสอบอย่างรอบคอบ ไม่แนะนำให้ฮาร์ดโค้ดคีย์ที่ใช้ซ้ำได้ระยะยาวในการกำหนดค่าเว็บทั่วไปหรือสคริปต์สำหรับกรณีฉุกเฉินชั่วคราว บริการที่สำคัญที่ใช้ mTLS ควรได้รับการตรวจสอบเพิ่มเติมสำหรับพฤติกรรมการเริ่มต้นเซสชัน TLS และการปฏิเสธคำขอโดยไม่มีใบรับรองไคลเอ็นต์ที่ถูกต้อง S12

5.7 บทบาทของระบบปฏิบัติการและการป้องกันชายแดน

# Linux：常见值 2 表示进程地址空间随机化处于完整启用状态
sysctl kernel.randomize_va_space

ASLR, ผู้ปฏิบัติงานที่ไม่ใช่ root, ระบบไฟล์คอนเทนเนอร์แบบอ่านอย่างเดียว, สิทธิ์อนุญาตไฟล์ขั้นต่ำ และการแยกเครือข่ายสามารถลดผลกระทบของ RCE ที่อาจเกิดขึ้นได้ ASLR ไม่ได้แก้ไขฮีปโอเวอร์โฟลว์หรือ UAF และไม่สามารถรับประกันได้ว่าผู้ปฏิบัติงานจะไม่หยุดทำงาน WAF ขีดจำกัดอัตรา และขีดจำกัดขนาดร่างกายของคำขอไม่ได้แก้ไขการซิงโครไนซ์คีย์ตั๋ว TLS S4

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 ตัวอย่างนี้แสดงให้เห็นการเปลี่ยนแปลงของตัวแทนสำหรับการตรวจสอบแพตช์ ยังไม่เสร็จสมบูรณ์ สามารถคอมไพล์ได้อย่างอิสระ สำหรับบิลด์แบบกำหนดเอง ให้ตรวจสอบคอมมิตทั้งหมด โค้ดโดยรอบและการทดสอบ และต้องการรีลีสที่รองรับโดยสมบูรณ์ S5S6S7S8S9

6.1 CVE-2026-15176: URI ถูกเขียนใหม่เพื่อรวมเงื่อนไขการปฏิเสธการแมปพาธ alias

การคอมมิตอัปสตรีมที่แก้ไข ngx_http_map_uri_to_path() ใน src/http/ngx_http_core_module.c:

- if (alias && !r->valid_location) {
+ if (alias && (!r->valid_location || r->uri_changed)) {

จุดเน้นในการตรวจสอบ: ไม่สามารถคำนวณพาธของระบบไฟล์ต่อไปได้เมื่อมีการเปลี่ยนแปลง URI แต่ความหมายตำแหน่งที่สอดคล้องกันของ alias ไม่น่าเชื่อถืออีกต่อไป นี่คือการปรับปรุงข้อจำกัดก่อนรัฐ ไม่ใช่การตรวจสอบง่ายๆ ว่าคำขอ URI มีอักขระที่ผิดกฎหมายหรือไม่ S5

6.2 CVE-2026-93479: แยกความแตกต่างระหว่างความยาวข้อมูลเอาต์พุตและความยาวที่สงวนไว้อย่างถูกต้อง

คอมมิตอัปสตรีมจะอัพเดต src/http/ngx_http_script.c และ src/stream/ngx_stream_script.c ในเวลาเดียวกัน เจตนาหลักสามารถสรุปได้ดังนี้:

- 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

เมื่อทำการตรวจสอบและแบ็คพอร์ต จะต้องครอบคลุมผู้ประเมินที่เกี่ยวข้องของ HTTP/Stream ด้วย การตรวจสอบไฟล์ไวยากรณ์การกำหนดค่าของ map เท่านั้นไม่สามารถพิสูจน์ได้ว่าข้อบกพร่องได้รับการแก้ไขแล้ว

6.3 CVE-2026-97205: ตั้งค่าเกณฑ์ความปลอดภัยสำหรับการนับการดำเนินการแบบอะซิงโครนัส 8 บิต

เพิ่มต้นน้ำที่ src/http/ngx_http_request.h:

#define NGX_HTTP_MAX_BLOCKED 250

และเพิ่มรายการที่คล้ายกันในการอ่านไฟล์แบบอะซิงโครนัส การรอแคช การกรองเอาต์พุต และการทำงานของเธรด:

if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) {
    /* 使用同步路径，或者拒绝新的异步操作 */
}

จุดเน้นในการตรวจสอบ: ต้องครอบคลุมเส้นทางโค้ดจริงทั้งหมดที่จะเพิ่ม r->main->blocked คุณไม่สามารถเขียนค่าคงที่เกณฑ์ในไฟล์ส่วนหัวได้ Backport ยังต้องตรวจสอบการประสานงานที่สมบูรณ์ของทางเลือกแบบซิงโครนัส การเรียกกลับแบบอะซิงโครนัส และการส่งคืนข้อผิดพลาด เพื่อให้แน่ใจว่าการหยุดชะงักหรือการรั่วไหลของการอ้างอิงจะไม่เกิดจากการปฏิเสธงานโดยตรง S7

6.4 CVE-2026-95101: รักษาสถานะ skip แยกต่างหากสำหรับเฟรมที่ไม่รู้จัก

อัปสตรีมจะเพิ่มฟิลด์ skip ในโครงสร้างสถานะตัวแยกวิเคราะห์ HTTP/3 และดำเนินการแยกสถานะ:

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

6.5 CVE-2026-97629: ซิงโครไนซ์อาเรย์สล็อตคีย์ TLS ที่สมบูรณ์

การเปลี่ยนแปลงต้นทางอยู่ที่ src/event/ngx_event_openssl.c:

  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

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 จำนวนมากที่ไม่ได้รับการอัปเดตเป็นเวลานานไม่เพียงได้รับผลกระทบจากปัญหาใหม่ในเดือนตุลาคมเท่านั้น ต่อไปนี้คือโหนดการซ่อมแซมตัวแทนในอนาคตอันใกล้นี้: S1S2

ซีวีอี	การเปิดตัวแก้ไขครั้งแรก	ความเสี่ยงและเงื่อนไขสำคัญที่ต้องตรวจสอบ
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

เหตุใดจึงให้ความสนใจเป็นพิเศษกับ CVE-2026-42945

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

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

การแก้ไข 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
• F5 NGINX Plus / NGINX Ingress Controller: Plus, controller และ Gateway Fabric อาจมีกระดานข่าวด้านความปลอดภัยเพิ่มเติม, เวอร์ชันบรรจุภัณฑ์ที่แตกต่างกัน และช่องโหว่ของนโยบายที่ไม่ซ้ำกัน การอัพเกรดหนึ่งเลเยอร์ไม่ได้หมายถึงการอัปเดตอีกเลเยอร์หนึ่งโดยอัตโนมัติ S19
• ชุมชน Kubernetes ingress-nginx: เจ้าหน้าที่ Kubernetes ได้ประกาศแล้วว่าคอนโทรลเลอร์หยุดการบำรุงรักษาในเดือนมีนาคม 2026 และอย่าสับสนระหว่างคลังสินค้ากับคอนโทรลเลอร์ F5 ธุรกิจที่ได้รับผลกระทบควรวางแผนการโยกย้ายได้อย่างราบรื่น และตรวจสอบคำอธิบายประกอบ Ingress และความแตกต่างทางความหมาย Gateway API แทนที่จะรอเวอร์ชันการรักษาความปลอดภัยใหม่ S21

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 กระดานข่าวความปลอดภัยอย่างเป็นทางการ

• https://nginx.org/en/security_advisories.html

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

S2 — บันทึกการเปิดตัวเวอร์ชันอย่างเป็นทางการของ NGINX

• https://nginx.org/news.html
• https://nginx.org/en/CHANGES-1.30

ยืนยัน 1.30.6 / 1.31.7 ของ 2026-10-14, 1.31.8 ของ 2026-10-21 และเหตุการณ์สำคัญในการเผยแพร่การรักษาความปลอดภัยที่สำคัญตั้งแต่เดือนพฤษภาคมถึงกันยายน

S3 - Cyber Security Agency of Singapore: F5 NGINX ช่องโหว่ที่สำคัญสามรายการ

• https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-150/

คำอธิบายของคะแนน CVSS v4.0 9.2 เงื่อนไขการกำหนดค่าที่จำเป็น และคำแนะนำการลดปัญหาชั่วคราวสำหรับ CVE-2026-15176, CVE-2026-93479 และ CVE-2026-97205

S4 - NHS อังกฤษ: F5 NGINX คำแนะนำที่มีความเสี่ยงสูง

• https://digital.nhs.uk/cyber-alerts/2026/cc-4872

อธิบายผลกระทบ DoS / RCE ที่อาจเกิดขึ้นจากปัญหาด้านความปลอดภัยของหน่วยความจำ และข้อจำกัด เช่น ASLR ที่ถูกปิดหรือข้าม

S5 — แหล่งที่มาอย่างเป็นทางการคอมมิต: CVE-2026-15176

• https://github.com/nginx/nginx/commit/f8a23425bd6840c4c36b4264edf576ba3646156f

สอดคล้องกับการตรวจสอบสถานะของ alias และ r->uri_changed ใน ngx_http_map_uri_to_path()

S6 — แหล่งที่มาอย่างเป็นทางการคอมมิต: CVE-2026-93479

• https://github.com/nginx/nginx/commit/6aa4b3fdd4fdc156153f2981eb4070690624447c

สอดคล้องกับความยาวสคริปต์ HTTP/Stream และตรรกะการจัดสรรบัฟเฟอร์ที่สงวนไว้

S7 - แหล่งที่มาอย่างเป็นทางการคอมมิต: CVE-2026-97205

• https://github.com/nginx/nginx/commit/6adfc05ece48f92446383ec1f145446848694698

สอดคล้องกับขีดจำกัดการนับ r->main->blocked NGX_HTTP_MAX_BLOCKED 250 และเส้นทางสำรองแบบอะซิงโครนัส

S8 — แหล่งที่มาอย่างเป็นทางการคอมมิต: CVE-2026-95101

• https://github.com/nginx/nginx/commit/1c173a2d8767730e678c27446138d7ae5dd6fd64

การแยกสถานะที่สอดคล้องกับความยาวคงเหลือของเฟรมที่ไม่รู้จัก HTTP/3 และความยาวของตัวคำขอ DATA

S9 - แหล่งที่มาอย่างเป็นทางการคอมมิต: CVE-2026-97629

• https://github.com/nginx/nginx/commit/1916f26e6ca49296568633d309777e36527e5bb2

สอดคล้องกับช่องคีย์ทั้งหมดระหว่างการซิงโครไนซ์การหมุนเวียนตั๋วเซสชัน TLS

S10 — F5: ประกาศของผู้จำหน่าย CVE-2026-15176

• https://my.f5.com/manage/s/article/K000162416

แสดงรายการปัจจัยทริกเกอร์ เช่น alias, rewrite, $request_filename และบันทึกการเข้าถึง

S11 — F5: ประกาศผู้ขาย CVE-2026-93479

• https://my.f5.com/manage/s/article/K000162607

แสดงรายการการจับภาพ regex ของแผนที่ เส้นทาง root และเงื่อนไขการประเมินตัวแปรของบันทึก

S12 — เอกสารประกอบโมดูล NGINX อย่างเป็นทางการของ TLS/SSL

• https://nginx.org/en/docs/http/ngx_http_ssl_module.html

คำอธิบาย ssl_session_cache, ssl_session_tickets, ssl_session_ticket_key และการรับรองความถูกต้องใบรับรองไคลเอ็นต์และคำแนะนำอื่น ๆ

S13 — คำแนะนำด้านความปลอดภัย: Ubuntu USN-8955-1 (2026-10-26)

• https://ubuntu.com/security/notices/USN-8955-1

มอบแพ็คเกจซอฟต์แวร์เวอร์ชันคงที่ที่สมบูรณ์และขอบเขตการจำหน่ายของ Ubuntu 22.04 / 24.04 / 26.04 / 26.10.

S14 — คำแนะนำด้านความปลอดภัย: Debian DSA-6575-1 (2026-10-21)

• https://lists.debian.org/debian-security-announce/2026/msg00490.html

ยืนยันแพ็คเกจแก้ไขความปลอดภัย 1.26.3-3+deb13u10 สำหรับ Debian 13 / trixie และบันทึกการเชื่อมโยงแบ็คพอร์ตสำหรับ CVE-2026-93479

S15 — การติดตามช่องโหว่: Debian Security Tracker: CVE-2026-15176

• https://security-tracker.debian.org/tracker/CVE-2026-15176

ใช้เพื่อตรวจสอบสถานะการแก้ไขการกระจายของ Debian 12 / bookworm และ Debian 13 / trixie สถานะนี้อาจเปลี่ยนแปลงเมื่อมีการอัปเดตความปลอดภัยในอนาคต

S16 — การติดตามช่องโหว่: Debian Security Tracker: CVE-2026-95101

• https://security-tracker.debian.org/tracker/CVE-2026-95101

การยืนยันเพิ่มเติมเกี่ยวกับสถานะความปลอดภัยของช่องโหว่ HTTP/3 บนสาขาต่างๆ ของ Debian

S17 — คำแนะนำด้านความปลอดภัย: Red Hat: CVE-2026-93479

• https://access.redhat.com/security/cve/cve-2026-93479

ความเข้าใจเพิ่มเติมเกี่ยวกับความสัมพันธ์ระหว่างช่องโหว่การถดถอยในเดือนตุลาคมและการแก้ไขสำหรับ CVE-2026-42533 เดือนกรกฎาคม

S18 — เอกสารโมดูลพร็อกซีย้อนกลับอย่างเป็นทางการของ NGINX

• https://nginx.org/en/docs/http/ngx_http_proxy_module.html
• https://nginx.org/en/docs/http/ngx_http_core_module.html

ค้นหาความหมายและค่าเริ่มต้นของการกำหนดค่า เช่น proxy_request_buffering, client_max_body_size, alias, aio เป็นต้น

S19 — NGINX Plus บันทึกประจำรุ่นอย่างเป็นทางการ

• https://docs.nginx.com/nginx/releases/

List Plus CR/LTS สาขา เวอร์ชัน แพตช์ และการแจ้งเตือนความเข้ากันได้ของการอัพเกรด

S20 — NGINX JavaScript / njs กระดานข่าวความปลอดภัยอย่างเป็นทางการ

• https://nginx.org/en/docs/njs/security.html
• https://nginx.org/en/docs/njs/changes.html

ประกอบด้วย njs 1.0.2 เดือนตุลาคม 2026 และการตรวจสอบ XML ที่เกี่ยวข้อง ปัญหาหน่วยความจำหมด

S21 — Kubernetes: คำแนะนำการเกษียณอายุอย่างเป็นทางการของชุมชน ingress-nginx

• https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/
• https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/

โปรดทราบว่าโปรเจ็กต์หยุดการเปิดตัวใหม่และการแก้ไขความปลอดภัยในเดือนมีนาคม 2026 และขอแนะนำให้ย้ายตัวควบคุมที่ได้รับการบำรุงรักษาหรือ Gateway API

S22 — การควบคุมบริการอย่างเป็นทางการของ NGINX และคำแนะนำในการอัพเกรดไบนารีออนไลน์

• https://nginx.org/en/docs/control.html

แยกแยะวิธีการรีโหลดการกำหนดค่า การรีสตาร์ท และการอัพเกรดไฟล์ปฏิบัติการแบบออนไลน์สำหรับการยอมรับการสลับกระบวนการ

S23 - ประกาศด้านความปลอดภัยของรัฐบาล: พฤษภาคม 2026 NGINX เขียนช่องโหว่ใหม่

• https://its.ny.gov/2026-051
• https://www.govcert.gov.hk/en/alerts_detail.php?id=1881

ให้ข้อมูลประวัติความเสี่ยงและคำแนะนำในการอัปเดตความปลอดภัยสำหรับ CVE-2026-42945 การตัดสินที่เกี่ยวข้องกับการแสวงประโยชน์ในป่าควรเป็นไปตามประกาศของหน่วยงานในขณะนั้นและหลักฐานเหตุการณ์เพิ่มเติม

S24 — F5: CVE-2026-95101 และ CVE-2026-97629 ประกาศผู้จำหน่าย

• https://my.f5.com/manage/s/article/K000162613
• https://my.f5.com/manage/s/article/K000162606

ครอบคลุมความเสี่ยงของการฉีดตัวถังคำขอ HTTP/3 และการหมุนคีย์ตั๋ว TLS อัตโนมัติตามลำดับ

S25 — F5: ประกาศของผู้จำหน่าย CVE-2026-97205

• https://my.f5.com/manage/s/article/K000162608

คำอธิบาย เงื่อนไขทริกเกอร์ SSI/AIO และความเสี่ยงต่อความเสียหายของหน่วยความจำที่อาจเกิดขึ้น

การอัปเดตความปลอดภัย NGINX: การตรวจสอบการกำหนดค่า การอัพเกรด และการยืนยัน