ช่องโหว่ QPACK ล่มเซิร์ฟเวอร์ HTTP/3 ได้ด้วยการเชื่อมต่อเดียว — ขยายหน่วยความจำได้ถึง 4,000 เท่า พบใน 7 จาก 10 สแตก quic-go, quiche, lsquic แก้แล้ว Bun ยังค้าง CPU 100% ไม่มีแพตช์

สรุปสั้น

บริษัท FoxIO เปิดเผยช่องโหว่กลุ่มหนึ่งใน QPACK ระบบบีบอัด header ของโปรโตคอล HTTP/3 ที่ทำให้ผู้โจมตีจากระยะไกลซึ่งไม่ต้องล็อกอินทำให้เว็บเซิร์ฟเวอร์ HTTP/3 จำนวนมากล่มได้ด้วยการเชื่อมต่อเพียงครั้งเดียว พร้อมปล่อยโค้ด proof-of-concept ที่ใช้ได้จริง ผู้โจมตีส่ง header ที่ถูกบีบอัดชุดเล็ก ๆ ซึ่งคลายออกในหน่วยความจำเป็นชุดที่ใหญ่กว่าหลายเท่า บังคับให้เซิร์ฟเวอร์ใช้หน่วยความจำมากกว่าที่ได้รับหลายพันเท่าจนหน่วยความจำของเซิร์ฟเวอร์ที่ตั้งค่ามาตรฐานหมด

FoxIO พบปัญหาประเภทเดียวกันใน 7 จาก 10 สแตก HTTP/3 ที่ทดสอบ ช่องโหว่ทำได้เพียงการโจมตีแบบปฏิเสธการให้บริการ (DoS) ไม่มีหลักฐานว่านำไปสู่การขโมยข้อมูลหรือรันโค้ด และยังไม่มีรายงานการโจมตีจริง แพตช์ออกแล้วสำหรับ quic-go, Cloudflare quiche, lsquic และ Wireshark แต่ Bun, ไลบรารี h3 ของ Rust และ aioquic ยังไม่มีแพตช์ ณ วันเปิดเผย ผลกระทบกว้างเพราะสแตกเหล่านี้อยู่ใต้ซอฟต์แวร์ยอดนิยมอย่าง Caddy, Traefik, cloudflared และ LiteSpeed Web Server

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

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 22 ตุลาคม 2569 ว่าต้นเหตุร่วมอยู่ที่ QPACK ซึ่ง HTTP/3 ใช้บีบอัด header ของคำขอ เพื่อให้ฟิลด์ที่ซ้ำกันส่งเป็นรหัสสั้น ๆ แทนข้อความเต็ม ตามหลักแล้วเซิร์ฟเวอร์ต้องจำกัดขนาด header หลังคลายออก แต่สแตกที่ได้รับผลกระทบจำกัดเฉพาะขนาดชุดที่ถูกบีบอัดซึ่งมาถึงทางเครือข่าย ไม่ได้จำกัดผลลัพธ์ที่คลายแล้ว หรือจำกัดช้าเกินไป คำขอเดียวจึงขยายเป็น header หลายแสนรายการที่เซิร์ฟเวอร์ต้องเก็บไว้ในหน่วยความจำ

ขอบเขตกว้างเพราะสแตกเหล่านี้อยู่ใต้ซอฟต์แวร์ที่ใช้กันมาก quic-go เป็นไลบรารีภาษา Go ที่อยู่เบื้องหลัง Caddy, Traefik และ cloudflared ส่วน lsquic เป็นไลบรารีของ LiteSpeed ที่ใช้ใน LiteSpeed Web Server และ OpenLiteSpeed และเซิร์ฟเวอร์ HTTP/3 ของ Bun ก็รันบน lsquic ผู้โจมตีไม่ต้องมีบัญชีหรือสิทธิ์พิเศษ และเพราะ HTTP/3 ทำงานบน UDP คำขอจึงไปถึงเซิร์ฟเวอร์ก่อนที่การกรองปกติหลายอย่างจะทำงาน

สถานะของแต่ละสแตก ณ วันที่ 22 ตุลาคม 2569 มีดังนี้

FoxIO ระบุว่า IIS, Envoy, ngtcp2/nghttp3 และ quiche ของ Google ไม่ได้รับผลกระทบ เพราะจำกัดขนาด header ที่คลายแล้วระหว่างถอดรหัส ไม่ใช่หลังถอดรหัสเสร็จ

วิธีการโจมตี

อัตราการขยายต่างกันไปตามสแตก ในการทดสอบของ FoxIO กับค่าตั้งมาตรฐาน ชุดที่ถูกบีบอัดขนาด 1 MB บน quic-go คลายออกเป็น header ราว 160,000 ฟิลด์ และค้างอยู่ในคำขอราว 15 MB หรือประมาณ 17 เท่าของข้อมูลที่ส่ง ส่วน advisory ของ quic-go เองประเมินว่าขยายได้ถึงราว 50 เท่า

วิธีที่สองดันอัตราขยายสูงขึ้นอีกมาก ผู้โจมตีเก็บ header ขนาดราว 4 KB ไว้หนึ่งรายการในตาราง dynamic ของ QPACK แล้วอ้างถึงรายการนั้นหลายพันครั้งด้วยการอ้างอิงขนาด 1 ไบต์ เซิร์ฟเวอร์จะสร้างรายการเต็มขึ้นมาใหม่ทุกครั้งที่ถูกอ้างอิง FoxIO วัดได้ราว 4,000 เท่าบน Bun และระหว่าง 600–1,800 เท่าบน lsquic

Bun เป็นกรณีที่หนักที่สุด เซิร์ฟเวอร์ HTTP/3 ของ Bun ซึ่งเอกสารเรียกว่ายังอยู่ในขั้นทดลอง ใช้ lsquic แต่แทนที่ส่วนที่จำกัดหน่วยความจำของ header ด้วยโค้ดของตัวเอง ซึ่งตรวจทีละ header แต่ไม่เคยตรวจผลรวม FoxIO พบว่าเมื่อ header ที่คลายแล้วเกิน 2 GB ตัวนับขนาดในโค้ดนั้นจะ overflow กลับเป็นศูนย์ และเซิร์ฟเวอร์ติดอยู่ในลูปที่ไม่มีวันออก stream เดียวที่ส่งข้อมูลราว 516 KB ทำให้เซิร์ฟเวอร์ใช้ CPU ค้าง 100% โดยไม่ฟื้นตัวและไม่รับคำขอใหม่ ส่วน lsquic เองมีเพดาน 64 KB ที่กันไม่ให้ถึงจุดนี้

Wireshark ต่างจากกรณีเซิร์ฟเวอร์ ปัญหาทำให้ dissector ของ HTTP/3 ล่มเมื่อ Wireshark ถอดรหัสทราฟฟิกด้วยไฟล์ key-log หรือเปิดไฟล์ capture ที่มี secret สำหรับถอดรหัสอยู่ข้างใน ไม่ใช่เซิร์ฟเวอร์ที่ผู้โจมตีเข้าถึงทางเครือข่ายได้ และ Wireshark ระบุว่า “ไม่ทราบว่ามีการโจมตีด้วยช่องโหว่นี้” งานวิจัยนี้เริ่มจากงาน “MadeYouReset” ของนาย Gal Bar Nahum ซึ่งเป็นเทคนิค DoS ต่อ HTTP/2 ที่ตั้งคำถามว่าการบีบอัด header ของ HTTP/3 มีจุดอ่อนคล้ายกันหรือไม่

ผลกระทบ

เซิร์ฟเวอร์ที่เปิด HTTP/3 บน quic-go หรือ lsquic เวอร์ชันเก่า รวมถึง reverse proxy อย่าง Caddy, Traefik และ cloudflared หรือเว็บโฮสติ้งที่ใช้ LiteSpeed/OpenLiteSpeed สามารถถูกทำให้ล่มได้จากเครื่องเดียวโดยไม่ต้องใช้บอตเน็ต เพราะการเชื่อมต่อเดียวก็พอให้หน่วยความจำหมด ต้นทุนการโจมตีที่ต่ำมากเมื่อเทียบกับความเสียหายทำให้ช่องโหว่ลักษณะนี้น่าสนใจสำหรับผู้โจมตี โดยเฉพาะเมื่อมี PoC สาธารณะแล้ว

แอปที่เปิดเซิร์ฟเวอร์ HTTP/3 ของ Bun สู่อินเทอร์เน็ตเสี่ยงที่สุด เพราะยังไม่มีแพตช์และอาการคือ CPU ค้างถาวรจนต้องรีสตาร์ต เหตุการณ์นี้ต่อยอดจากความเสี่ยงของ HTTP/3 ที่เคยรายงานไว้ ทั้งช่องโหว่ XRING ใน XQUIC (2026/07/108 ) และการขยายทราฟฟิกจากการแปลงโปรโตคอลของ CDN (2026/08/125 ) ซึ่งสะท้อนว่าการติดตั้ง HTTP/3 หลายตัวยังขาดการป้องกันด้านทรัพยากรที่ HTTP/2 เคยถูกบังคับให้เพิ่มมาก่อน

คำแนะนำ

• อัปเดตเป็นเวอร์ชันที่แก้แล้ว: quic-go 0.57.0, Cloudflare quiche 0.29.3, lsquic 4.9.0, Wireshark 4.6.2 หรือ 4.4.12
• อัปเดต Caddy, Traefik, cloudflared, LiteSpeed Web Server และ OpenLiteSpeed เป็นรุ่นที่ใช้ไลบรารีเวอร์ชันที่แก้แล้ว และตรวจไบนารี Go ที่ build เองว่าใช้ quic-go 0.57.0 ขึ้นไป
• Bun: อย่าเปิดเซิร์ฟเวอร์ HTTP/3 สู่ภายนอกจนกว่าจะมีแพตช์
• mitmproxy: ปิด HTTP/3 ด้วย --set http3=false
• ไลบรารี h3 ของ Rust: ตั้งเพดาน max_field_section_size ให้เหมาะสม
• หากไม่จำเป็นต้องใช้ HTTP/3 ให้พิจารณาปิดชั่วคราวหรือบล็อก UDP 443 แล้วให้ไคลเอนต์ถอยกลับไปใช้ HTTP/2
• เฝ้าระวังการใช้หน่วยความจำและ CPU ของโปรเซสเว็บเซิร์ฟเวอร์ และตั้งการแจ้งเตือนเมื่อพุ่งสูงผิดปกติจากการเชื่อมต่อ QUIC จำนวนน้อย

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

• FoxIO — Header Accordions: QPACK Amplification Attacks Against HTTP/3 Servers
• quic-go — GHSA-g754-hx8w-x2g6
• Cloudflare quiche — GHSA-4fgf-9xrr-88gf
• The Hacker News — New QPACK Flaws Can Crash HTTP/3 Servers, Trigger Up to 4,000-Fold Memory Amplification