Microsoft ออกแพตช์ความปลอดภัยนอกรอบให้ .NET วันที่ 25 ตุลาคม 2026 ครอบคลุมทั้ง .NET 8.0.33, 9.0.22, 10.0.14 และ .NET 11 Release Candidate 3 โดยรอบนี้ไม่ได้มีแค่การอุดช่องโหว่ใหม่เท่านั้น แต่ยังรวมแพตช์แก้ของเดิมอีกสองรายการที่รอบ 13 ตุลาคมยังเก็บไม่เรียบร้อยดีด้วย ทีมไหนที่เพิ่งกดอัปเดตไปช่วงกลางเดือนจึงต้องกลับมาเช็กระบบกันใหม่อีกรอบ
เกิดอะไรขึ้น
อัปเดตรอบนี้มีช่องโหว่สำคัญที่ต้องโฟกัสทั้งหมด 4 รายการ ซึ่งแต่ละตัวส่งผลกระทบกับกลุ่มผู้ใช้งานต่างกัน:
| CVE | เกิดที่ไหน | ระดับตาม advisory | กระทบใคร |
|---|---|---|---|
| CVE-2026-111497 | ตัว decompress Brotli | High, CVSS 8.1 | ทุกแพลตฟอร์ม เมื่อแอป decompress Brotli จากข้อมูลที่ผู้โจมตีควบคุมได้ |
| CVE-2026-114148 | เจ้าของไฟล์ใน tarball บน Linux | High, CVSS 7.8 | การติดตั้งจาก tarball ที่เข้าข่าย และงาน source-build |
| CVE-2026-70197 | SocketAsyncEventArgs | High, CVSS 8.1 | Windows, ออก advisory ซ้ำเพราะรอบ 13 ตุลาคมยังไม่มีการแก้ |
| CVE-2026-102870 | ตัว debug ของ Blazor WebAssembly | High, CVSS 8.8 | .NET 10 และ 11, เครื่องนักพัฒนาที่ประเมินค่าระหว่าง debug |
สำหรับช่องโหว่ Brotli เกิดจากการเขียนข้อมูลลงหน่วยความจำเกินขอบเขต (out-of-bounds write) โดย Microsoft ระบุว่าผู้โจมตีที่ไม่ได้ยืนยันตัวตนอาจอ่านข้อมูลหรือทำให้หน่วยความจำของ process เสียหาย จนนำไปสู่ปัญหาข้อมูลรั่วไหล บริการล่ม หรือถูกยกระดับสิทธิ์ได้ ส่วนเคส tarball เกิดจากการกำหนดเจ้าของไฟล์ไม่ถูกต้อง ทำให้บัญชีผู้ใช้ทั่วไปในเครื่องที่มีสิทธิ์แก้ไฟล์ดังกล่าวสามารถใช้ช่องนี้ยกระดับสิทธิ์ตัวเองขึ้นมาได้
ใครได้รับผล
จุดแรกที่ต้องแยกให้ออกก่อนคือ การใช้แพ็กเกจเวอร์ชันเก่าอยู่ ไม่ได้แปลว่าระบบจะเปิดรับช่องโหว่ Brotli เสมอไป เพราะ advisory ระบุ ชัดเจนว่าทั้งฟังก์ชัน request decompression ใน ASP.NET Core และ automatic decompression ของ HttpClient ไม่ได้เปิดทำงานเป็นค่าเริ่มต้น แอปจะเข้าข่ายมีช่องโหว่ก็ต่อเมื่อมีการทำสิ่งเหล่านี้กับข้อมูลที่ผู้โจมตีควบคุมได้:
- เปิดใช้งาน request decompression ใน ASP.NET Core โดยรองรับ
br - ตั้งค่า
AutomaticDecompressionให้รวมDecompressionMethods.BrotliหรือDecompressionMethods.All - เรียกใช้
BrotliStreamหรือBrotliDecoderในSystem.IO.Compressionโดยตรง
ช่องโหว่ตัวนี้ไม่ส่งผลกระทบต่อ .NET Framework
ส่วนกลุ่มที่ใช้ tarball ต้องพิจารณาจากวิธีการติดตั้งเป็นหลักมากกว่าดูแค่เลขเวอร์ชัน โดยใน .NET 8 และ 9 ทาง Microsoft ระบุว่า เฉพาะ tarball ของ ASP.NET Core runtime และ targeting pack เท่านั้นที่เข้าข่าย ขณะที่ .NET 10 และ 11 จะกระทบเฉพาะ tarball ที่มาจาก source-build เท่านั้น ปัญหานี้จะเกิดขึ้นก็ต่อเมื่อการแตกไฟล์ยังคงรักษา numeric ownership จาก archive เอาไว้ เช่น แตกไฟล์ด้วยสิทธิ์ระดับสูง หรือ import archive เข้า container โดยคงสิทธิ์เจ้าของเดิมไว้ หากเป็นการ restore แพ็กเกจจาก NuGet ตามปกติจะไม่ทำให้เกิดปัญหานี้
ควรทำอะไร
แนะนำให้เริ่มจากตรวจสอบรูปแบบ runtime ที่ระบบใช้งานอยู่ เพราะ วิธีอัปเดตต่างกัน:
- แอปแบบ framework-dependent: ติดตั้ง runtime เวอร์ชันล่าสุดตามสายที่แอปใช้งานอยู่ จากนั้นรีสตาร์ตแอป โดยสามารถรัน
dotnet --list-runtimesเพื่อเช็กเวอร์ชันที่มีอยู่ในเครื่องได้ - แอปแบบ self-contained: ต้อง build และ publish ใหม่เท่านั้น เนื่องจากการติดตั้ง runtime ใหม่บนเครื่องไม่ได้เข้าไปเปลี่ยน runtime ที่ถูกแพ็กฝังไว้กับตัวแอป
- Container: build image ใหม่โดยดึงตัวอัปเดตจาก .NET container images แล้วทำการ deploy ใหม่อีกครั้ง
- .NET 11 RC2: อัปเดตขยับไปใช้ RC3 เพื่อรับตัวแก้ไขทั้งหมดของรอบนี้
- Blazor WebAssembly บน .NET 10 หรือ 11: ตรวจสอบแพ็กเกจ
Microsoft.AspNetCore.Components.WebAssembly.ServerและMicrosoft.AspNetCore.Components.WebAssembly.DevServerในโปรเจกต์ให้เป็นเวอร์ชันที่แพตช์แล้ว
หากเคยติดตั้งระบบจาก tarball ที่เข้าข่าย การแตกไฟล์ใหม่ทับที่เดิมหรือการแก้เวอร์ชัน NuGet reference ยังไม่เพียงพอ โดย advisory แนะนำ ให้หยุดการทำงานของบริการ, ตรวจสอบ checksum, ติดตั้งลงในไดเรกทอรีใหม่ที่ว่างอยู่ และแตกไฟล์โดยตัดการจำสิทธิ์เจ้าของเดิม เช่น ใช้แฟล็ก --no-same-owner จากนั้นชี้บริการไปยังไดเรกทอรีใหม่ พร้อมตรวจสอบ runtime ที่ตัวแอปโหลดใช้งานจริง ไม่ใช่ดูแค่คำสั่ง dotnet ตัวแรกที่เจอใน PATH สำหรับ image ที่สร้างขึ้นเองก็ต้องสั่ง build ใหม่เช่นกัน เนื่องจากการเข้าไปแก้ใน container ที่กำลังรันอยู่จะไม่ส่งผลถึง image ที่จะถูกนำไปสร้าง container รอบต่อไป
หากยังไม่สามารถอัปเดตได้ทันทีและระบบจำเป็นต้องใช้ Brotli ทาง advisory แนะนำให้บรรเทาความเสี่ยงชั่วคราวด้วยการถอด br ออกจากการตั้งค่า decompression เดิม หรือเอา DecompressionMethods.Brotli ออกจาก handler แต่มีข้อควรระวังสำคัญคือ ห้ามเพิ่มโค้ดส่วนนี้เข้าไปเด็ดขาดหากแอปไม่ได้เปิดใช้ decompression อยู่ก่อนแล้ว เพราะการเปิดใช้งานขึ้นมาเองอาจเพิ่มความเสี่ยงทำให้บริการล่มแทน และควรทดสอบระบบก่อนขึ้น deploy จริงเสมอ เนื่องจากอาจส่งผลต่อการรับส่งข้อมูลปกติของระบบได้
ข้อจำกัด
เนื้อหาทั้งหมดสรุปจากประกาศและ advisory ทางการของ Microsoft โดยไม่ได้มีการทดสอบเจาะช่องโหว่ด้วยตัวเอง สำหรับคะแนน CVSS เป็นเพียงตัวเลขประเมินเบื้องต้นตาม advisory ซึ่งอาจไม่ได้สะท้อนระดับความเสี่ยงที่แท้จริงของทุกระบบ แต่ละทีมจึงต้องวิเคราะห์ร่วมกับบริบทจริงว่าแอปเปิดรับข้อมูลภายนอกผ่านช่องทางไหน และติดตั้ง .NET ไว้อย่างไร
เลขเวอร์ชันในตารางอ้างอิงตามประกาศรอบวันที่ 25 ตุลาคม 2026 ดังนั้นก่อนเริ่มดำเนินการจริง ควรเปิดดู หน้าดาวน์โหลด .NET และ advisory แต่ละรายการประกอบด้วย เพราะมีรายละเอียดแพ็กเกจย่อยที่ได้รับผลกระทบอีกหลายตัว และหากพบปัญหาแปลกๆ หลังการอัปเดต สามารถแจ้งทีมงาน Microsoft ได้โดยตรงผ่าน dotnet/core