Node.js เวอร์ชันที่คุณใช้อยู่เสี่ยงต่อช่องโหว่ Brotli RCE หรือไม่? เช็กได้ใน 2 นาที

รันคำสั่งนี้ทันที หากเวอร์ชันของคุณต่ำกว่าเกณฑ์ขั้นต่ำในตาราง แสดงว่าคุณกำลังได้รับผลกระทบจากช่องโหว่ Node.js Brotli RCE (CVE-2026-111497) และมีผู้ไม่ประสงค์ดีเริ่มโจมตีช่องโหว่นี้แล้วในขณะนี้

ลองใช้ Apidog วันนี้

node -v 

หากต้องการตรวจสอบอีกทางเพื่อความมั่นใจ ให้สอบถามตัวไบนารีโดยตรง:

node -p "require('node:zlib').constants.BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH" 

แพตช์แก้ไขได้เพิ่มค่าคงที่นี้เข้ามา เราได้ทดสอบรันบนบิลด์ทางการของ macOS ทั้งหมดเก้าบิลด์จากทั้งสามสายเวอร์ชันที่ยังได้รับการสนับสนุน พบว่าทุกบิลด์ที่ได้รับการแก้ไขแล้วจะแสดงผลเป็น -17 ส่วนบิลด์ที่เก่ากว่าจะแสดงผลเป็น undefined ทั้งนี้ ควรยึดผลจาก node -v เป็นหลักก่อน เนื่องจาก Linux distro ที่ทำการ backport แพตช์อาจไม่ได้เพิ่มค่าคงที่นี้เข้ามา

ไม่ต้องตรวจสอบผ่าน process.versions.brotli เพราะค่าที่ได้แสดงเป็น 1.2.0 ทั้งใน 24.21.0 และ 24.22.1 รวมถึงแสดงเป็น 1.1.0 ทั้งใน 22.23.3 และ 22.23.4 เนื่องจากทาง Node.js ได้ cherry-pick ตัวแก้ไขมาโดยไม่ได้เปลี่ยนเลขเวอร์ชันที่รายงาน ดังนั้นค่านี้จึงไม่สามารถบอกได้ว่าคุณได้รับการแพตช์แล้วหรือไม่

TL;DR

ELLIO ได้รายงานการตรวจพบทราฟฟิกการโจมตี ผ่านเซนเซอร์ตรวจจับเมื่อวันที่ 26 ตุลาคม หรือเพียงห้าวันหลังจากปล่อยแพตช์แก้ไข โดยเพย์โหลดที่ดักจับได้มุ่งเป้าไปที่ Node.js 24.22.0 บนสถาปัตยกรรม x86-64 แม้ว่าขั้นสุดท้ายของเพย์โหลดดังกล่าวจะทำงานไม่สำเร็จในการทดสอบของ ELLIO แต่ทาง ELLIO ก็สามารถยืนยันได้ว่าสามารถรันโค้ดได้จริงบนบิลด์ 24.22.0 มาตรฐาน ทั้งนี้ CISA ได้กำหนดเส้นตายให้หน่วยงานรัฐบาลกลางของสหรัฐฯ ดำเนินการแก้ไขภายในวันที่ 10 พฤศจิกายน และระบุสถานะการใช้งานโดยแรนซัมแวร์ว่าเป็น "Unknown" (ยังไม่ทราบแน่ชัด) นอกจากนี้ ข้อมูลทางไกล (Telemetry) ของ Akamai ยังระบุว่ามีเครือข่ายถึง 61% ที่ยังคงรันเวอร์ชันที่ได้รับผลกระทบ ณ วันที่ 26 ตุลาคม

เจาะลึก Node2Shell: บั๊ก Brotli ทำงานอย่างไรและส่งผลกระทบอะไรบ้าง

Node2Shell คือช่องโหว่ประเภท Out-of-bounds write ในตัวถอดรหัส Brotli ที่ติดตั้งมาพร้อมกับรันไทม์ของ Node.js โดยสตรีมข้อมูลบีบอัดที่ถูกดัดแปลงให้ผิดรูปแบบ (Malformed) จะทำให้ตัวถอดรหัสเขียนข้อมูลเกินขอบเขตของบัฟเฟอร์ภายในขนาด 8 ไบต์ ส่งผลให้หน่วยความจำของโปรเซสเสียหาย (Memory corruption) ซึ่งผลลัพธ์ที่ตามมาอาจทำให้ระบบล่ม ข้อมูลในหน่วยความจำรั่วไหล หรือเปิดทางให้ผู้ไม่ประสงค์ดีเข้ามารันโค้ดบนเซิร์ฟเวอร์ของคุณได้

สาเหตุหลักเกิดจากการจำแนกประเภทข้อผิดพลาดผิดพลาด (Misclassified error) โดยเมื่อเกิดข้อผิดพลาดในการสลับบล็อกข้อมูลที่ไม่ถูกต้อง (Invalid block switch) ระบบกลับตีความว่าเป็น "ต้องการข้อมูลอินพุตเพิ่มเติม" แทนที่จะระบุว่า "ข้อมูลนี้เสียหาย" ทำให้ตัวถอดรหัสแบบสตรีมยังคงเขียนข้อมูลไบต์ต่อท้ายลงในบัฟเฟอร์ขนาดเล็กนั้นไปเรื่อยๆ

บั๊กนี้แฝงอยู่ในไลบรารี Brotli ของ Google เวอร์ชัน 1.0.3 ถึง 1.2.0 ดังนั้นจึงไม่ได้เป็นปัญหาเฉพาะใน Node.js เท่านั้น ทาง Node.js ได้แก้ไขในส่วนของตนเองด้วยการ cherry-pick คอมมิต 0ed4268a จากต้นน้ำ (Upstream) เข้ามาไว้ในเวอร์ชัน 24.22.1 รวมถึงสายเวอร์ชันอื่นๆ ที่เกี่ยวข้อง โดยผู้ค้นพบและรายงานช่องโหว่นี้คือนักวิจัยด้านความปลอดภัย Khai Tran และ Sylvie Mayer จาก OpenAI Codex Security

เครื่องมือสแกน Dependency ของคุณจะไม่สามารถตรวจพบช่องโหว่นี้ได้ เนื่องจากตัวถอดรหัสนั้นมาพร้อมกับตัวรันไทม์ ไม่ได้อยู่ในรูปของแพ็กเกจ โดยคำสั่ง npm install รายงานช่องโหว่เป็น 0 สำหรับโปรเจกต์ทดสอบ Express 5 ของเรา ทั้งๆ ที่รันอยู่บน Node.js 24.15.0 ซึ่งยังไม่ได้รับการแพตช์

ใครบ้างที่ตกเป็นเป้าหมายและมีความเสี่ยง

การมีรันไทม์ที่มีช่องโหว่เป็นเพียงเงื่อนไขครึ่งเดียว อีกครึ่งหนึ่งคือเส้นทาง (Path) ที่ส่งต่อข้อมูล Brotli จากภายนอกที่ไม่น่าไว้วางใจไปยังตัวถอดรหัส เราได้ทดสอบแต่ละเส้นทางบน Node.js 24.22.1 ด้วยการส่ง Body จำลองที่ไม่มีอันตรายและไม่ถูกต้อง (ข้อความ not-valid-brotli) พร้อมเฮดเดอร์ Content-Encoding: br รวมถึงส่งข้อมูล Brotli ที่ถูกต้องไปยังไคลเอนต์แต่ละตัว

มีผลการทดสอบสองจุดที่น่าจับตามองเป็นพิเศษ ประการแรก fetch() ทำการถอดรหัส Brotli แม้ว่าคำขอจะระบุ Accept-Encoding: identity ก็ตาม เนื่องจากมันจะทำงานตาม Response header ของเซิร์ฟเวอร์ปลายทาง ไม่ได้อิงตามสิ่งที่คุณส่งขอไป ดังนั้น เซิร์ฟเวอร์ใดก็ตามที่แอปของคุณส่งคำขอไปหาจึงสามารถส่งข้อมูลมายังตัวถอดรหัสได้ ทำให้ฟีเจอร์อย่าง Webhook tester, ระบบพรีวิวลิงก์ (Link previewer) หรือระบบนำเข้า URL (URL importer) ตกอยู่ในความเสี่ยง ประการที่สอง การได้รับสถานะ 400 เพียงอย่างเดียวไม่สามารถพิสูจน์อะไรได้ เพราะทั้ง Express 5 และ Fastify แบบปกติ ต่างก็ส่งกลับ 400 ทั้งคู่ แต่มีเพียง Express 5 เท่านั้นที่มีการเรียกใช้ตัวถอดรหัสจริง ดังนั้นโปรดตรวจสอบข้อความแสดงข้อผิดพลาดให้ละเอียด

ตรวจสอบเส้นทางในระบบของคุณได้ด้วยสามคำสั่งนี้:

# Direct decoder use grep -rnE "brotliDecompress|createBrotliDecompress" src/ # Parsers that decode request bodies npm ls express body-parser @koa/bodyparser @fastify/compress # Base images and pinned versions grep -rnE "^FROM .*node" --include='Dockerfile*' . 

การเพิ่มการเรียกใช้ fetch() เข้ามาเพียงจุดเดียวก็สามารถเปลี่ยนสถานะเหล่านี้ได้ทันที ดังนั้นแม้ระบบของคุณจะ "ยังเข้าไม่ถึงช่องโหว่" แต่คำตอบที่ดีที่สุดก็คือคุณยังคงต้องอัปเดตแพตช์อยู่ดี

วิธีอัปเดตแพตช์แก้ไข CVE-2026-111497

ให้อัปเกรดเป็นบิลด์ล่าสุดของสายเวอร์ชันที่คุณใช้อยู่ ไม่ใช่แค่เวอร์ชันขั้นต่ำ โดยช่องทางเหล่านี้ล้วนมีบิลด์ที่ได้รับการแก้ไขแล้ว ณ วันที่ 5 พฤศจิกายน:

จากนั้น จัดการช่องโหว่อีกสองจุดที่มักถูกมองข้าม:

• รีสตาร์ตทุกอย่าง: โปรเซสที่กำลังทำงานอยู่จะยังคงเก็บไบนารีตัวเก่าไว้ในหน่วยความจำ ดังนั้นการอัปเกรดบนดิสก์จะไม่มีผลใดๆ จนกว่า pm2, systemd หรือตัว Orchestrator ของคุณจะทำการรีสตาร์ตโปรเซสนั้นใหม่
• บิลด์สิ่งที่ Deploy ไปแล้วใหม่: อิมเมจเดิมจะยังคงใช้รันไทม์เวอร์ชันเก่า และสำหรับอิมเมจที่ล็อกเวอร์ชันด้วย digest นั้นจำเป็นต้องสแกนอิมเมจ เนื่องจาก Tag เพียงอย่างเดียวไม่สามารถบอกความเปลี่ยนแปลงได้

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

curl -s https://nodejs.org/dist/index.json | jq -r '[.[] | select(.security == true and (.version | test("^v(22|24|26)\\.")))] | group_by(.version | split(".")[0]) | .[] | max_by(.date) | "\(.version) \(.date)"' 

หากยังคงใช้เวอร์ชัน 20 หรือ 25 อยู่ จะไม่มีบิลด์ที่ออกแพตช์แก้ไขให้คุณ โปรดอ่านแผนการสิ้นสุดระยะเวลาสนับสนุน (End-of-Life) ของ Node.js 20 และรีบย้ายเวอร์ชันทันที

วิธีบรรเทาช่องโหว่ Node.js Brotli หากคุณยังไม่สามารถอัปเดตแพตช์ได้ในตอนนี้

วิธีเหล่านี้ช่วยซื้อเวลาเท่านั้น แต่ไม่สามารถทดแทนการอัปเกรดระบบได้

1. ปฏิเสธ br ที่ระดับ Edge: บล็อกคำขอที่มี Content-Encoding: br ที่ระดับ Proxy หรือ Load Balancer โดยตรวจสอบแบบไม่แยกตัวพิมพ์เล็ก-พิมพ์ใหญ่ (Case-insensitive) และตรวจสอบในรูปแบบที่เป็นรายการ เช่น gzip, br
2. ปฏิเสธที่ระดับแอปพลิเคชัน: ใส่โค้ดนี้ไว้ก่อนหน้า Middleware ตัวประมวลผล Body (Body parser) ซึ่งจากการทดสอบใน Express 5 ของเราจะส่งคืนสถานะ 415:

app.use((req, res, next) => { const encoding = req.headers['content-encoding'] || ''; if (/\bbr\b/i.test(encoding)) return res.status(415).end(); next(); }); 

1. ปิดการทำงานของ Inflation: การตั้งค่า express.json({ inflate: false }) จะส่งกลับสถานะ 415 สำหรับคำขอเดียวกัน แต่วิธีนี้จะปฏิเสธ Body ที่บีบอัดด้วย gzip ด้วยเช่นกัน ดังนั้นควรตรวจสอบฝั่งไคลเอนต์ของคุณก่อน
2. ควบคุม Response ขาออก: สำหรับ axios สามารถกำหนด decompress: false ได้ ซึ่งจากการทดสอบจะปล่อยให้ข้อมูลคงรูปเป็นไบต์โดยไม่ถอดรหัส ส่วน fetch() นั้นไม่มีสวิตช์ปิดการทำงานแบบมาตรฐาน ดังนั้นจึงควรจำกัด Host ปลายทางที่สามารถเรียกใช้งานได้ด้วย Allowlist และกฎการเชื่อมต่อขาออก (Egress rules)
3. จำกัดขอบเขตความเสียหาย (Blast radius): ทำการแบ่งส่วนระบบ (Segment) ของเซอร์วิส Node.js และจำกัดสิทธิ์ผู้ที่สามารถเข้าถึงไฟล์ Core dump ได้ เนื่องจาก ELLIO ระบุว่าเมื่อระบบล่ม ข้อมูลภายในหน่วยความจำอาจถูกเปิดเผยผ่านไฟล์ดังกล่าวได้

ให้เฝ้าระวังพฤติกรรมในลักษณะเดียวกับที่ ELLIO พบเห็นเป็นกลุ่มแรก นั่นคือปริมาณ Request body ที่เข้ารหัสด้วย Brotli พุ่งสูงขึ้นอย่างผิดปกติ เพื่อทำการสแกนหาว่าโฮสต์ใดบ้างที่มีการถอดรหัสข้อมูลดังกล่าว หากพบทราฟฟิก Content-Encoding: br ที่น่าสงสัยบน JSON API หรือพบอัตราการล่มของ Worker process เพิ่มสูงขึ้นอย่างกะทันหัน ควรรีบเข้าตรวจสอบทันที

ตรวจสอบความถูกต้องของ API หลังการอัปเกรด: ให้ AI Agent ช่วยจัดการ

การอัปเกรดข้ามเวอร์ชันของรันไทม์อาจส่งผลต่อพฤติกรรมการทำงานของ TLS, DNS และ HTTP ซึ่งการอัปเดตรอบเดือนตุลาคมที่ผ่านมาได้ส่งผลกระทบต่อทั้งสามส่วนนี้ อย่าเสียเวลาเปรียบเทียบการเปลี่ยนแปลงด้วยตัวเอง ให้ Coding Agent ของคุณรัน Apidog CLI ทั้งก่อนและหลังการอัปเกรด เพื่อสรุปรายงานความเปลี่ยนแปลงที่เกิดขึ้น

npm install -g apidog-cli@latest apidog login --with-token <YOUR_TOKEN> npx -y skills add https://apidog.com # pick your agent when prompted 

ป้อนพรอมต์ต่อไปนี้ให้กับ Agent ของคุณ:

Run Apidog test suite <id> in project <id> against staging and save the results to reports/before. After I upgrade Node.js, add a test case for POST /orders that sends the plain text "not-valid-brotli" with Content-Encoding: br, asserts a 4xx status, then checks GET /health returns 200. Rerun the suite to reports/after and list every request whose result changed. 

Agent จะรันคำสั่งเหล่านี้:

apidog run --test-suite <id> --project <id> -e <envId> -r cli,junit --out-dir reports/before apidog cli-schema get test-case-create apidog cli-schema validate test-case-create --file case.json apidog test-case create --project <id> --file case.json apidog run --test-case <caseId> --project <id> -e <envId> -r cli,json apidog run --test-suite <id> --project <id> -e <envId> -r cli,junit --out-dir reports/after 

เคสทดสอบเพิ่มเติมนั้นทำหน้าที่เป็น Health check ไม่ใช่การโจมตี (Exploit) โดยข้อมูล Body เป็นเพียงข้อความธรรมดา และจากการทดสอบของเราก็ล้มเหลวด้วยข้อผิดพลาดเรื่อง Padding แบบเดียวกันทั้งในบิลด์ที่มีช่องโหว่และบิลด์ที่แก้ไขแล้ว อย่างไรก็ตาม เคสนี้ช่วยตรวจจับปัญหาจริงได้ เนื่องจากในการทดสอบ Koa ของเรา ระบบตอบกลับเป็นสถานะ 500 เพราะไม่มีการจัดการข้อผิดพลาดจากการถอดรหัส ซึ่งในความเป็นจริงแล้ว Public API ควรตอบกลับด้วยรหัสสถานะ 4xx ทั้งนี้ ขอแนะนำให้รันทดสอบบนสภาพแวดล้อม Staging เท่านั้น

สามารถดูรายละเอียดแฟล็กทั้งหมดได้จากเอกสารอ้างอิงคำสั่ง run และดูคู่มือ CI/CD เพื่อผสานการทดสอบ JUnit เดียวกันนี้เข้ากับไปป์ไลน์ของคุณ ทั้งนี้ แผนบริการฟรีของ Apidog รองรับการใช้งานสูงสุด 4 คน

ทำไมวันที่ 11 พฤศจิกายนจึงเป็นกำหนดการสำคัญถัดไป

โปรเจกต์ Node.js ได้ประกาศล่วงหน้าถึงการปล่อยอัปเดตรอบใหม่สำหรับเวอร์ชัน 26.x, 24.x และ 22.x ในวันที่ 11 พฤศจิกายน 2026 หรือหลังจากนั้นไม่นาน โดยมีระดับความรุนแรงสูงสุดอยู่ที่ HIGH อีกครั้ง ซึ่งในขณะนี้ยังไม่มีการเปิดเผยรายละเอียด CVE สู่สาธารณะ สามารถอ่านวิธีเตรียมตัวรับมือได้ที่คู่มือการอัปเดตรอบเดือนพฤศจิกายนของเรา

ควรอัปเดตแพตช์ Brotli ทันทีโดยไม่ต้องรอคบรวมกับรอบดังกล่าว เนื่องจากช่องโหว่นี้มีรายละเอียดเผยแพร่ออกมาแล้วและพบการโจมตีจริงในปัจจุบัน อีกทั้งการอัปเกรดในสัปดาห์นี้ยังถือเป็นการซักซ้อมสำหรับการอัปเดตรอบถัดไป ไม่ว่าจะเป็นการสำรวจรายการระบบ (Inventory), การบิลด์อิมเมจใหม่ และการรันชุดทดสอบแบบเดียวกัน ซึ่งกรณีของ PHP2Shell และ React2Shell ก็เคยดำเนินไปในรูปแบบเดียวกันนี้

คำถามที่พบบ่อย (FAQ)

ช่องโหว่ CVE-2026-111497 กำลังถูกโจมตีจริงหรือไม่? มีการโจมตีจริง โดย CISA ได้เพิ่มช่องโหว่นี้ลงในแค็ตตาล็อก Known Exploited Vulnerabilities เมื่อวันที่ 27 ตุลาคม 2026 ภายใต้หัวข้อ Google Brotli และทาง ELLIO ได้ตรวจพบทราฟฟิกการโจมตีตั้งแต่เมื่อวันที่ 26 ตุลาคม

ช่องโหว่นี้มีความรุนแรงระดับ High หรือ Critical กันแน่? ทั้งสองระดับเป็นข้อมูลจริง โดยทาง Node.js จัดให้อยู่ในระดับ HIGH ส่วน NVD ให้คะแนน CVSS 3.1 อยู่ที่ 9.8 ระดับ CRITICAL และคะแนน CVSS 4.0 ที่ประเมินโดย Google อยู่ที่ 9.2 ดังนั้นควรกำหนดแผนรับมือโดยยึดตามข้อเท็จจริงที่ว่าช่องโหว่นี้มีการโจมตีเกิดขึ้นจริงแล้ว

หากใช้งาน Express 4 ปลอดภัยหรือไม่? แม้ว่า Request body ในแอปของคุณจะไม่ส่งข้อมูลไปยังตัวถอดรหัส แต่การเรียกใช้ fetch(), axios และคำสั่งใน node:zlib โดยตรงยังคงเข้าถึงตัวถอดรหัสได้ นอกจากนี้ ในอัปเดตรอบเดียวกันยังมีการแก้ไขช่องโหว่ CVE อื่นๆ อีกถึง 9 รายการ ดังนั้นจึงควรอัปเกรดอยู่ดี

Node.js 20 ได้รับผลกระทบหรือไม่? ทางโปรเจกต์ไม่ได้ทำการประเมินสายเวอร์ชันที่สิ้นสุดระยะเวลาสนับสนุน (End-of-Life) แล้ว และจะไม่มีการออกแพตช์แก้ไขให้ ขอให้ถือว่าเวอร์ชัน 20.x และ 25.x มีความเสี่ยงเนื่องจากไม่มีการแพตช์และไม่ได้รับการประเมินความปลอดภัย จากนั้นให้วางแผนย้ายเวอร์ชันทันที

ช่องโหว่นี้ส่งผลกระทบต่อสิ่งอื่นนอกจาก Node.js หรือไม่? มีผลกระทบ โดยประกาศความปลอดภัยของ GitHub ได้ระบุถึงแพ็กเกจ brotli และ brotlicffi บน PyPI รวมถึงผู้พัฒนารายอื่นก็มีการออกแพตช์แก้ไขแล้ว เช่น Bun 1.4.4 และ .NET ทั้งนี้ ต้องอัปเดตตัวถอดรหัสแต่ละตัวแยกกัน เนื่องจากการอัปเกรด Node.js จะครอบคลุมเฉพาะตัวถอดรหัสที่มากับ Node.js เองเท่านั้น