ยังใช้ Node.js 20 อยู่หรือเปล่า? อัปเดตความปลอดภัย 11 พฤศจิกายนนี้ คุณจะไม่ได้รับแพตช์

Node.js 20 จะไม่ได้รับแพตช์อัปเดตใด ๆ ในวันที่ 11 พฤศจิกายน 2026 โดยการอัปเดตความปลอดภัยรอบนี้จะครอบคลุมเฉพาะเวอร์ชัน 26.x, 24.x และ 22.x เท่านั้น เนื่องจาก Node.js 20 ได้สิ้นสุดระยะเวลาการสนับสนุน (End-of-Life) ไปแล้วตั้งแต่วันที่ 30 เมษายน 2026 แพตช์ล่าสุดที่คุณได้รับคือเวอร์ชัน 20.20.2 ซึ่งบิลด์ขึ้นเมื่อวันที่ 24 มีนาคม และนับตั้งแต่นั้นมา มีการเผยแพร่ช่องโหว่ความปลอดภัยไปแล้วถึง 33 CVE โดยไม่มีบิลด์สำหรับ 20.x อีกเลย จึงควรอัปเกรดไปใช้เวอร์ชัน 24 หรือ 26 ภายในสัปดาห์นี้

CVE ทั้ง 33 รายการดังกล่าวถูกปล่อยออกมาในการอัปเดตความปลอดภัย 3 รอบที่ไม่มี Node.js 20 รวมอยู่ด้วย และการอัปเดตรอบที่ 4 ก็กำลังจะมาถึงในอีกไม่กี่วันนี้ ซึ่งในประกาศล่วงหน้าได้ระบุว่าช่องโหว่ที่ร้ายแรงที่สุดถูกจัดอยู่ในระดับ HIGH สำหรับทุกเวอร์ชันที่ยังได้รับการสนับสนุน

วันที่ 11 พฤศจิกายนมีความสำคัญอย่างไร และเหตุใด Node.js 20 จึงถูกตัดออก

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

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

นอกจากนี้ ในประกาศแจ้งเตือนยังมีอีกหนึ่งประโยคสำคัญที่เกี่ยวข้องกับคุณโดยตรง: “เวอร์ชันที่สิ้นสุดระยะเวลาการสนับสนุน (End-of-Life) ย่อมได้รับผลกระทบเสมอเมื่อมีการอัปเดตความปลอดภัยเกิดขึ้น”

ช่องโหว่ความปลอดภัยที่ Node.js 20 พลาดไปแล้วมีอะไรบ้าง

มีการปล่อยอัปเดตความปลอดภัยออกมาแล้ว 3 รอบนับตั้งแต่เวอร์ชัน 20 สิ้นสุดระยะเวลาการสนับสนุน และไม่มีรอบใดเลยที่มีบิลด์สำหรับ 20.x

โค้ดที่ได้รับการแก้ไขเหล่านี้เป็นโค้ดส่วนสำคัญที่เซิร์ฟเวอร์ API ต้องทำงานอยู่ตลอดเวลา:

• การตรวจสอบ TLS hostname: ทั้งในรอบเดือนมิถุนายนและตุลาคม มีการแก้ไขช่องโหว่ที่ทำให้ใบรับรอง (certificate) ถูกยอมรับแม้โฮสต์จะไม่ถูกต้อง
• HTTP/2: การแก้ไขระดับความร้ายแรงสูงในรอบเดือนกรกฎาคมครอบคลุมทั้งบั๊ก heap use-after-free และบั๊ก remote memory exhaustion
• DNS: ในรอบเดือนตุลาคม มีการแก้ไขปัญหา dns.resolve*() ตัดทอนชื่อโฮสต์ตรง NUL byte ซึ่งอาจทำให้ระบบตรวจสอบ allowlist ทำงานผิดพลาด
• การบีบอัดข้อมูล (Compression): ในรอบเดือนตุลาคม มีการแก้ไขข้อผิดพลาด out-of-bounds write ในตัวถอดรหัส Brotli ซึ่งอาจนำไปสู่การรันโค้ดจากระยะไกล (remote code execution) ได้ โดยเราได้อธิบายรายละเอียดไว้ในบทความ ตรวจสอบช่องโหว่ Brotli RCE

ลองพิจารณารายการด้านบนอย่างละเอียด โปรเจกต์ Node.js จะไม่ประเมินความเสี่ยงให้กับเวอร์ชันที่สิ้นสุดการสนับสนุนแล้ว ดังนั้นประกาศแจ้งเตือนจึงระบุเฉพาะเวอร์ชันที่ยังได้รับการดูแลเท่านั้น ช่องโหว่บางตัวอาจอยู่ในโค้ดที่เวอร์ชัน 20 ไม่มี เช่น CVE รายการหนึ่งในเดือนตุลาคมเป็นบั๊กถดถอย (regression) ที่ส่งผลเฉพาะ 26.x และ 24.x เท่านั้น ดังนั้นสถานะที่แท้จริงของแต่ละ CVE บน Node.js 20 จึงถือว่ายังไม่ได้รับการแพตช์และไม่ได้รับการประเมิน โดยไม่มีใครยืนยันว่าคุณปลอดภัย และไม่มีใครจะเข้ามาตรวจสอบให้คุณด้วย

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

“แต่ระบบมันก็ยังทำงานได้ตามปกตินี่นา”

มันยังทำงานได้จริง และนั่นแหละคือปัญหา

สภาพแวดล้อมรันไทม์ที่สิ้นสุดการสนับสนุนไม่ได้พังลงทันที คำสั่ง node -v ยังคงแสดงเวอร์ชันเดิม ชุดทดสอบยังผ่าน และแดชบอร์ดของคุณยังคงเป็นสีเขียว แต่ความเสี่ยงที่แท้จริงจะแฝงอยู่ในจุดที่คุณไม่ได้เฝ้าระวัง:

• ตัวแพตช์เองคือแผนที่บอกทาง: การแก้ไข, ประกาศแจ้งเตือน และคอมมิตโค้ดจะถูกเปิดเผยต่อสาธารณะพร้อมกัน ทำให้ใครก็ตามสามารถเข้าไปดูได้ว่าเวอร์ชันที่ได้รับการสนับสนุนมีการเปลี่ยนแปลงอะไรบ้าง และโค้ดเดิมที่มีปัญหานั้นยังมีอยู่ในเวอร์ชัน 20 หรือไม่
• แพลตฟอร์มของคุณอาจยังยอมให้ปรับใช้ต่อไปได้: AWS Lambda ทำเครื่องหมายว่า nodejs20.x เลิกใช้แล้ว (deprecated) ตั้งแต่วันที่ 30 เมษายน 2026 แต่จะยังไม่บล็อกการสร้างฟังก์ชันใหม่จนถึงวันที่ 29 กรกฎาคม 2027 หรือบล็อกการอัปเดตฟังก์ชันจนถึงวันที่ 31 สิงหาคม 2027
• แพ็กเกจและการตรวจสอบความปลอดภัย (Audits) ก้าวหน้าไปเรื่อย ๆ: โปรเจกต์ Node.js เตือนว่าแพ็กเกจยอดนิยมจะค่อย ๆ ยกเลิกการสนับสนุนเวอร์ชันที่สิ้นสุดอายุขัยไปตามกาลเวลา และมาตรฐานการตรวจสอบในอุตสาหกรรมจำนวนมากก็ไม่อนุญาตให้ใช้งานรันไทม์ที่ไม่มีการบำรุงรักษาอีกต่อไป

เลือกเวอร์ชันเป้าหมาย: Node.js 24 หรือ 26 ไม่ใช่ 22

ย้ายไปใช้เวอร์ชัน 24 ในสัปดาห์นี้หากคุณต้องการเส้นทางที่สั้นและง่ายที่สุด หรือเลือกเวอร์ชัน 26 หากคุณพร้อมรับมือกับการเปลี่ยนแปลงและการตัดฟีเจอร์ออก และต้องการระยะเวลาการสนับสนุนที่ยาวนานที่สุด ควรมองข้ามเวอร์ชัน 22 ไปได้เลย แม้ว่าเวอร์ชันนี้จะได้รับแพตช์เดือนพฤศจิกายน แต่การสนับสนุนจะสิ้นสุดในวันที่ 30 เมษายน 2027 ซึ่งเหลือเวลาไม่ถึง 6 เดือน ทำให้คุณต้องกลับมาทำโปรเจกต์ย้ายระบบแบบนี้ซ้ำอีกครั้งในไม่ช้า

กำหนดการต่าง ๆ อ้างอิงจาก ตารางการปล่อยเวอร์ชันของ Node.js (Node.js release schedule) อย่าลืมตรวจสอบแพลตฟอร์มของคุณก่อนตัดสินใจ ตัวอย่างเช่น บน Lambda รันไทม์ Node.js 26 ยังคงอยู่ในช่วง Public Preview และยังไม่ครอบคลุมใน Lambda SLA ดังนั้นเวอร์ชัน 24 จึงเป็นตัวเลือกเป้าหมายที่ปลอดภัยกว่าสำหรับการใช้งานจริงใน Production บนแพลตฟอร์มดังกล่าวในขณะนี้

ขั้นตอนการย้ายระบบและจุดที่อาจส่งผลกระทบให้โค้ดทำงานไม่ได้

ข้อมูลทั้งหมดในตารางนี้รวบรวมมาจากบันทึกประจำรุ่น (Release Notes) ทางการของเวอร์ชัน 22.0.0, 24.0.0, 25.0.0 และ 26.0.0 รวมถึงคู่มือการย้ายระบบจาก v22 ไป v24 ซึ่งสรุปเฉพาะประเด็นสำคัญสำหรับบริการ API โดยไม่ใช่รายการบันทึกการเปลี่ยนแปลงทั้งหมด

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

ให้แยกไปทำใน branch ใหม่ โดยอัปเดต .nvmrc, ฟิลด์ engines, Dockerfile และ CI ให้ตรงกับเวอร์ชันเป้าหมาย (หากต้องการตั้งค่าเครื่องใหม่ตั้งแต่ต้น สามารถดูได้ที่ คู่มือการติดตั้ง Node.js) จากนั้นทำการติดตั้งแพ็กเกจใหม่เพื่อให้ native modules บิลด์ใหม่ สแกนหา API ที่ถูกลบออก รัน codemod ทางการ และเริ่มสตาร์ตเซอร์วิสพร้อมเปิดใช้งานการติดตามข้อความแจ้งเตือน deprecation:

nvm install 24 && nvm use 24
rm -rf node_modules && npm ci

grep -rnE "assert \{ *type|createCipher\(|createDecipher\(|url\.parse\(|fs\.[FRWX]_OK|SlowBuffer|createSecurePair|_stream_[a-z]+|module\.register\(" \
  --include="*.js" --include="*.mjs" --include="*.ts" --exclude-dir=node_modules .

npx codemod run @nodejs/import-assertions-to-attributes
npx codemod run @nodejs/crypto-createcipheriv-migration
npx codemod run @nodejs/tls-create-secure-pair-to-tls-socket
npx codemod run @nodejs/fs-access-mode-constants

NODE_OPTIONS="--trace-deprecation" npm start

ตรวจสอบผลลัพธ์จากการรัน codemod ด้วยตนเองอีกครั้ง โดยเฉพาะส่วนของ createCipher ที่มีข้อจำกัดชัดเจนว่า โค้ดที่สร้างขึ้นใหม่จะไม่สามารถถอดรหัสข้อมูลที่เคยเข้ารหัสด้วย API แบบเก่าได้ ดังนั้นควรวางแผนย้ายข้อมูล (data migration) ล่วงหน้าหากคุณมีการใช้งานอยู่

เว็บไซต์ของ Node.js ยังไม่มีคู่มือสำหรับการย้ายจากเวอร์ชัน 24 ไป 26 โดยเฉพาะ ดังนั้นโปรดดูบันทึกประจำรุ่นของ 25.0.0 และ 26.0.0 ประกอบสำหรับการข้ามเวอร์ชันดังกล่าว

ทดสอบยืนยันว่า API ยังคงทำงานเหมือนเดิมบนเวอร์ชันใหม่

Unit test ไม่สามารถบอกได้ว่า TLS stack และ HTTP client ตัวใหม่จะส่งผลอย่างไรต่อทราฟฟิกจริง การข้ามเวอร์ชันหลักไปถึง 2 หรือ 3 เวอร์ชัน จำเป็นต้องมีการเปรียบเทียบพฤติกรรมการทำงานของเซอร์วิสทั้งก่อนและหลังการย้ายระบบ ซึ่งถือเป็นงานที่เหมาะมากสำหรับ coding agent ของคุณ

Apidog CLI ช่วยให้ Claude Code, Codex หรือ Cursor สามารถรันชุดทดสอบ Apidog ได้โดยตรงจากเทอร์มินัล โดยตั้งค่าเพียงครั้งเดียวดังนี้:

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 ของคุณ:

My service runs on Node.js 20 in staging. Run Apidog test suite <suiteId> in project
<projectId> against environment <envId> and save reports to reports/node20. When I
redeploy on Node.js 24, run the same suite into reports/node24. List every request
whose status, body, or TLS behavior changed. Then read the service logs for deprecation
warnings and check each failure against the 22, 24, and 25 release notes: removed APIs,
changed defaults, stricter fetch and AbortSignal handling, OpenSSL key size rejections.

agent จะรันชุดทดสอบเดียวกันนี้ทั้งก่อนและหลังการย้ายเวอร์ชัน:

apidog run --test-suite <suiteId> --project <projectId> -e <envId> \
  -r cli,junit --out-dir reports/node20

# redeploy the service on the target line, restart it

apidog run --test-suite <suiteId> --project <projectId> -e <envId> \
  -r cli,junit --out-dir reports/node24

สิ่งสำคัญสองประการที่จะช่วยให้ผลการเปรียบเทียบถูกต้องและเชื่อถือได้:

• ห้ามใส่แฟล็ก -k โดยเด็ดขาด: เพราะแฟล็กนี้จะปิดการตรวจสอบความถูกต้องของ SSL ซึ่งจะบดบังข้อผิดพลาดของ TLS ที่คุณกำลังตามหาอยู่
• รวมคำขอที่เซอร์วิสของคุณเรียกต่อไปยังระบบ Upstream ด้วย: การปฏิเสธการเชื่อมต่อของ OpenSSL จะปรากฏเป็นข้อผิดพลาดของ API บนเอนด์พอยต์ที่ต้องติดต่อกับระบบพาร์ตเนอร์รุ่นเก่า ดังนั้นควรทดสอบเส้นทางเหล่านั้นด้วย ไม่ใช่เพียงแค่ทดสอบ /health เท่านั้น

เมื่อผ่านการทดสอบการย้ายระบบเรียบร้อยแล้ว ให้ใส่กระบวนการนี้ไว้ใน CI/CD pipeline ของคุณอย่างต่อเนื่อง โดยสามารถดูเวิร์กโฟลว์ได้จาก คู่มือการใช้ Apidog CLI ใน CI/CD และดูวิธีการตั้งค่า agent ได้จาก คู่มือการใช้งานร่วมกับ Claude Code

หากคุณยังไม่สามารถย้ายระบบได้ภายในสัปดาห์นี้

ซื้อบิลด์ที่ได้รับการแพตช์: หน้า Node.js End-of-Life ได้ระบุพาร์ตเนอร์ 3 รายผ่านโปรแกรม OpenJS Ecosystem Sustainability Program โดย HeroDevs ให้บริการ Never-Ending Support พร้อมแพตช์ความปลอดภัย, TuxCare ให้บริการ Endless Lifecycle Support ที่พอร์ตแพตช์ย้อนหลัง (backport) ให้กับเวอร์ชันที่สิ้นสุดการสนับสนุนแล้ว และ NodeSource ให้บริการประเมินการอัปเกรดพร้อมทีมสนับสนุน ซึ่งทางโปรเจกต์ระบุว่านี่เป็นเพียงทางออกชั่วคราวเท่านั้น และมันก็เป็นเช่นนั้นจริง ๆ

ลดช่องทางที่ทราฟฟิกภายนอกจะเข้าถึงโพรเซสได้โดยตรง: ขั้นตอนเหล่านี้ช่วยลดความเสี่ยงจากช่องโหว่ประเภทต่าง ๆ ข้างต้น แต่ไม่ได้เป็นการแก้ปัญหาที่ต้นเหตุ:

• ทำ TLS and HTTP/2 termination ที่พร็อกซีหรือโหลดบาลานเซอร์ที่ยังได้รับการดูแลรักษา แล้วส่งต่อคำขอด้วย HTTP/1.1 แบบธรรมดาไปยัง Node.js ภายในเครือข่ายส่วนตัว (Private network)
• หยุดแตกไฟล์บีบอัด Brotli จากแหล่งที่มาที่ไม่น่าเชื่อถือ ทั้งในคำขอขาเข้าและข้อมูลภายนอกที่ดึงเข้ามา
• ปฏิเสธชื่อโฮสต์ที่มี NUL byte หรือรูปแบบ IP ที่ไม่ใช่มาตรฐาน (non-canonical) ก่อนที่จะนำไปตรวจ allowlist หรือยิงคำขอออกไปข้างนอก
• แยกเซอร์วิสออกจากระบบอื่น: กำหนดสิทธิ์แบบจำกัดเท่าที่จำเป็น (least-privilege credentials), จำกัดการเชื่อมต่อขาออก (restricted egress) และไม่ใช้คีย์หรือ secret ร่วมกับเซอร์วิสอื่นที่ได้รับการแพตช์แล้ว

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

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

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

Node.js 20 มีช่องโหว่ตามที่พบในบั๊กของวันที่ 11 พฤศจิกายนหรือไม่? ข้อมูล CVE ยังไม่ได้รับการเปิดเผยต่อสาธารณะ จึงยังไม่มีใครระบุได้แน่ชัดว่าช่องโหว่ใดบ้างที่ส่งผลกระทบ แต่ประกาศแจ้งเตือนระบุไว้ชัดเจนว่า เวอร์ชันที่สิ้นสุดระยะเวลาการสนับสนุนย่อมได้รับผลกระทบเสมอเมื่อมีการอัปเดตความปลอดภัย และทีมงานไม่ได้ทำการประเมินความเสี่ยงแยกให้เป็นรายตัว

ควรอัปเกรดเป็น Node.js 22 แทนหรือไม่? ไม่แนะนำ แม้ว่าจะเป็นการเปลี่ยนผ่านที่กระทบน้อยที่สุด แต่เวอร์ชัน 22 จะสิ้นสุดการสนับสนุนในวันที่ 30 เมษายน 2027 การย้ายไปใช้เวอร์ชัน 24 จะช่วยยืดระยะเวลาการสนับสนุนเพิ่มอีกหนึ่งปี และเวอร์ชัน 26 จะได้เพิ่มอีกถึงสองปี

ควรเลือก Node.js 24 หรือ 26 ดี? เลือกเวอร์ชัน 24 หากคุณจำเป็นต้องย้ายระบบให้เสร็จภายในสัปดาห์นี้ หรือแพลตฟอร์มที่คุณใช้ยังไม่รองรับเวอร์ชัน 26 อย่างสมบูรณ์ แต่หากคุณสามารถทดสอบระบบทั้งหมดใหม่ได้ในตอนนี้ ให้เลือกเวอร์ชัน 26 เพราะจะได้รับการสนับสนุนยาวนานจนถึงวันที่ 30 เมษายน 2029

หากกำลังใช้งาน Node.js 25 อยู่ จะได้รับผลกระทบด้วยหรือไม่? ได้รับผลกระทบเช่นกัน เนื่องจาก Node.js 25 สิ้นสุดระยะเวลาการสนับสนุนไปตั้งแต่วันที่ 1 มิถุนายน 2026 โดยมีบิลด์สุดท้ายคือ 25.9.0 จึงไม่ได้รับแพตช์แก้ไขในเดือนพฤศจิกายนนี้ด้วยเช่นกัน และการย้ายไปเวอร์ชัน 26 ก็ห่างกันเพียงเวอร์ชันหลักเดียวเท่านั้น