Node.js: ช่องโหว่ HTTP/2 และ HTTPS ทำให้ไคลเอนต์ทำเซิร์ฟเวอร์ล่มและอ่านข้อมูลของผู้ใช้อื่นได้

เกิดอะไรขึ้น

เมื่อวันที่ 11 พฤศจิกายน 2026 โครงการ Node.js เผยแพร่เวอร์ชันความปลอดภัยสำหรับสายรุ่นที่ยังได้รับการสนับสนุนทั้งสามสาย เวอร์ชันที่แก้ไขแล้วคือ 22.23.5, 24.22.3 และ 26.13.1 เวอร์ชันเหล่านี้แก้ไขช่องโหว่ 16 รายการใน Node.js เอง โดยเจ็ดรายการมีระดับความรุนแรงสูง นอกจากนี้ยังมีการอัปเดตไลบรารีที่มาพร้อมกันได้แก่ llhttp (22.x, 24.x, 26.x), undici (24.x, 26.x) และ sqlite (22.x, 24.x)

ปัญหาสำคัญอยู่ในโค้ดฝั่งเซิร์ฟเวอร์ที่ Node.js จัดเตรียมไว้สำหรับ HTTP/2, HTTPS และ TLS:

• เซิร์ฟเวอร์ HTTP/2 ล่ม (24.x และ 26.x): ไคลเอนต์ที่ไม่ได้ยืนยันตัวตนสามารถทำให้โปรเซส Node.js หยุดทำงานได้ เซิร์ฟเวอร์ต้องใช้เพียงการตั้งค่า HTTP/2 เริ่มต้นและตัวจัดการที่ตอบกลับก่อนที่เนื้อหาคำขอจะถูกส่งมาครบ โครงการระบุว่าพฤติกรรมนี้เป็นเรื่องปกติ การโจมตีทำงานได้ทั้งผ่าน TLS และการเชื่อมต่อแบบไม่เข้ารหัส
• การเปิดเผยหน่วยความจำของ HTTP/2 (ทั้งสามสาย): เซิร์ฟเวอร์อาจส่งส่วนของหน่วยความจำให้ไคลเอนต์ รวมถึงการตอบกลับที่ตั้งใจส่งให้การเชื่อมต่ออื่น ตั้งแต่ 24.22.0 และ 26.9.0 เป็นต้นไป ไคลเอนต์สามารถกระตุ้นเหตุการณ์นี้ได้ด้วยตนเอง ส่วน 22.x และบิลด์ 24.x และ 26.x รุ่นเก่ากว่า อาจเกิดขึ้นเมื่อเซิร์ฟเวอร์ปิดสตรีมกลางคันระหว่างการตอบกลับ เช่น หลังจากหมดเวลาที่ไม่มีการใช้งาน
• การเปิดเผยหน่วยความจำของ HTTPS (ทั้งสามสาย): ไคลเอนต์ที่ไม่ได้ยืนยันตัวตนสามารถอ่านหน่วยความจำจากการเชื่อมต่ออื่นได้ "รวมถึงคีย์ TLS ส่วนตัวและคำขอของผู้ใช้รายอื่น" ตามที่โครงการระบุ ช่องโหว่นี้ต้องอาศัยตัวจัดการที่เรียก res.flushHeaders() ก่อนที่เนื้อหาคำขอจะจบ และต่อมาเรียก res.end() พร้อมข้อมูล นอกจากนี้ ผู้โจมตียังต้องมีเส้นทาง (route) ที่ส่งเนื้อหาคำขอกลับหรือจัดเก็บไว้ เพื่ออ่านหน่วยความจำที่รั่วออกมา
• การใช้ทรัพยากรของ HTTP/2 จนหมด (ทั้งสามสาย): ไคลเอนต์สามารถทำให้เซิร์ฟเวอร์ HTTP/2 ที่ใช้ค่าเริ่มต้นใดก็ได้ถือครองหน่วยความจำและตัวอธิบายไฟล์ (file descriptor) ไว้อย่างถาวร
• การให้บริการไฟล์ของ HTTP/2 (24.x และ 26.x): ไคลเอนต์สามารถทำให้หน่วยความจำของเซิร์ฟเวอร์เสียหายได้เมื่อเซิร์ฟเวอร์ให้บริการไฟล์ด้วย stream.respondWithFile() หรือ stream.respondWithFD() ในทั้งสามสาย การยกเลิกการดาวน์โหลดลักษณะนี้ก็อาจทำให้เซิร์ฟเวอร์ล่มได้ (ระดับปานกลาง)
• เซิร์ฟเวอร์ TLS ล่ม (24.x และ 26.x): ไคลเอนต์สามารถทำให้เซิร์ฟเวอร์ TLS ที่ใช้ตัวเชื่อม SNICallback, OCSPRequest, newSession หรือ resumeSession หรือ server.addContext() ล่มได้
• การข้ามการตรวจใบรับรองไคลเอนต์ของ TLS (ทั้งสามสาย): เซิร์ฟเวอร์บางแห่งใช้กฎใบรับรองไคลเอนต์ที่เข้มงวดกว่ากับชื่อโฮสต์บางชื่อ ในเซิร์ฟเวอร์เหล่านั้น ไคลเอนต์ที่ได้รับอนุญาตสำหรับชื่อโฮสต์อื่นสามารถเปลี่ยนไปใช้ชื่อโฮสต์ที่เข้มงวดกว่าระหว่างการเจรจา TLS 1.2 ใหม่ได้ โดยไม่ต้องผ่านกฎของชื่อโฮสต์นั้น

ประกาศของโครงการไม่พบการโจมตีที่ใช้ช่องโหว่เหล่านี้

ใครได้รับผลกระทบ

• เซิร์ฟเวอร์ที่รัน Node.js 22.x ก่อน 22.23.5, 24.x ก่อน 24.22.3 หรือ 26.x ก่อน 26.13.1
• สายที่หมดอายุการสนับสนุน รวมถึง 20.x และ 25.x จะไม่ได้รับการแก้ไขในรอบนี้ โครงการระบุว่าเวอร์ชันเหล่านี้ได้รับผลกระทบเสมอ
• ปัญหาฝั่งเซิร์ฟเวอร์ที่ร้ายแรงจะเกี่ยวข้องก็ต่อเมื่อ โปรเซส Node.js รับการเชื่อมต่อ HTTP/2, HTTPS หรือ TLS ด้วยตัวเอง ตัวอย่างได้แก่โมดูล node:http2, node:https หรือ node:tls ที่มาพร้อมระบบ หรือเฟรมเวิร์กที่ใช้โมดูลเหล่านี้ในการสิ้นสุด TLS หรือ HTTP/2
• เซิร์ฟเวอร์ HTTP ธรรมดาที่สร้างด้วย node:http ไม่ได้รับผลกระทบ จากการเปิดเผยหน่วยความจำของ HTTPS
• การล่มของ HTTP/2 มีผลกับสาย 24.x และ 26.x เท่านั้น ไม่รวม 22.x

ความเสี่ยงของคุณลดลงมากหากมี reverse proxy เช่น nginx, Apache, HAProxy หรือ load balancer เป็นผู้สิ้นสุด TLS และ HTTP/2 และ Node.js รับเฉพาะ HTTP/1.1 ธรรมดาจากตัวกลางนั้น อย่างไรก็ตาม คุณควรอัปเดตอยู่ดี เพราะรอบนี้ยังมีการแก้ไขอื่นและการอัปเดตไลบรารีด้วย

สิ่งที่ควรทำตอนนี้

1. ค้นหา Node.js ทุกการติดตั้ง อย่าลืมแพ็กเกจของระบบ ตัวจัดการเวอร์ชัน (nvm, n, Volta) อิมเมจ Docker, CI runner และแผงควบคุมการโฮสต์ที่มาพร้อม Node.js ของตัวเอง
2. อัปเดตเป็นเวอร์ชันที่แก้ไขแล้วของสายของคุณ: 22.23.5, 24.22.3 หรือ 26.13.1 หากใช้แพ็กเกจจากดิสโทรหรือผู้จำหน่าย (เช่น NodeSource หรือ Linux distribution ของคุณ) ให้ติดตั้งการอัปเดตทันทีที่แหล่งแพ็กเกจมีเวอร์ชันเหล่านี้
3. ย้ายออกจากเวอร์ชันที่หมดอายุการสนับสนุน หากยังรัน 20.x, 25.x หรือเก่ากว่า ให้อัปเกรดเป็นสายที่ยังได้รับการสนับสนุน ประกาศไม่มีวิธีแก้ชั่วคราวสำหรับเซิร์ฟเวอร์ที่อัปเดตไม่ได้
4. สร้างอิมเมจคอนเทนเนอร์ใหม่ ด้วยอิมเมจพื้นฐานของ Node.js ที่อัปเดตแล้ว และนำไปใช้งานใหม่ การอัปเดตเฉพาะโฮสต์จะไม่เปลี่ยน Node.js ที่อยู่ภายในคอนเทนเนอร์
5. เริ่มโปรเซส Node.js ทั้งหมดใหม่ (systemd units, PM2, คอนเทนเนอร์ Docker ฯลฯ) เพื่อโหลดรันไทม์ใหม่ จากนั้นตรวจสอบว่าแอปพลิเคชันตอบสนองตามปกติ
6. พิจารณาเปลี่ยนความลับหากคุณได้รับผลกระทบ ประกาศไม่ได้ระบุว่าเซิร์ฟเวอร์ที่ตรงตามเงื่อนไขของการเปิดเผยหน่วยความจำของ HTTPS ควรเปลี่ยนคีย์ TLS หรือความลับอื่นหรือไม่ หากเซิร์ฟเวอร์ HTTPS ของ Node.js ของคุณตรงกับเงื่อนไขเหล่านั้นและเข้าถึงได้จากอินเทอร์เน็ต ควรพิจารณาต่ออายุใบรับรอง TLS และคีย์

วิธีตรวจสอบว่าคุณได้รับผลกระทบหรือไม่

• รัน node -v บนแต่ละเซิร์ฟเวอร์ และภายในแต่ละคอนเทนเนอร์ (docker exec <container> node -v) เวอร์ชันที่ต่ำกว่า 22.23.5, 24.22.3 หรือ 26.13.1 ในสายของตน หรือสายที่หมดอายุการสนับสนุนใดก็ตาม เช่น 20.x หรือ 25.x ได้รับผลกระทบ
• ใช้ PM2 โดยรัน pm2 list และ pm2 show <app> เพื่อดูว่าแต่ละแอปใช้ไบนารีและเวอร์ชัน Node.js ใด
• ตรวจสอบว่าแอปพลิเคชันของคุณสิ้นสุด HTTP/2 หรือ TLS ใน Node.js เองหรือไม่ ค้นหาในโค้ดด้วยคำว่า http2.createSecureServer, http2.createServer, https.createServer, tls.createServer, respondWithFile, respondWithFD, SNICallback และ addContext
• ตรวจสอบตัวจัดการโปรเซสและบันทึกของระบบเพื่อหาการรีสตาร์ตหรือการล่มของ Node.js ที่ไม่คาดคิด การยกเลิกการทำงานของเซิร์ฟเวอร์ HTTP/2 ซ้ำ ๆ อาจบ่งชี้ถึงความพยายามกระตุ้นให้เกิดการล่ม

แหล่งข้อมูล

• https://thehackernews.com/2026/11/nodejs-fixes-16-flaws-including-http2.html