Nếu máy chủ của bạn chạy Node.js và phục vụ HTTPS hoặc HTTP/2 trực tiếp, bản vá bảo mật ngày 11/11/2026 là việc nên làm trong tuần này. Dự án Node.js đã phát hành bản sửa cho ba nhánh đang được hỗ trợ, và theo The Hacker News, đợt này xử lý 16 lỗ hổng. Hai nhóm đáng chú ý nhất là lỗi làm sập tiến trình và lỗi khiến máy chủ gửi nhầm dữ liệu của kết nối khác.

Những bản Node.js nào đã có bản vá

Các bản sửa gồm 22.23.5, 24.22.3 và 26.13.1, tương ứng ba nhánh 22.x, 24.x và 26.x. Thông báo gốc của Node.js nêu rõ các bản cập nhật phụ thuộc cũng được nâng: llhttp (22.x, 24.x, 26.x), undici (24.x, 26.x) và sqlite (22.x, 24.x).

Nếu bạn vẫn đang dùng nhánh cũ hơn 22.x, thông báo không liệt kê nhánh đó trong đợt vá. Hãy xem lịch hỗ trợ trong bài Node.js 26 lên LTS và lịch phát hành mới để biết nhánh của mình còn được bảo trì hay không.

Lỗi HTTP/2: một client ẩn danh đủ để sập server

CVE-2026-123863 (mức cao) ảnh hưởng nhánh 24.x và 26.x. Điều kiện kích hoạt chỉ là một máy chủ HTTP/2 mặc định có handler trả lời trước khi nhận hết phần thân yêu cầu. Theo Node.js, đó là cách viết khá phổ biến. Kẻ tấn công không cần đăng nhập, và lỗi hoạt động cả trên TLS lẫn cleartext.

Còn CVE-2026-123865 cho phép client làm rò bộ nhớ và file descriptor vĩnh viễn: kết nối ở trạng thái CLOSE_WAIT, còn trạng thái HTTP/2 vẫn nằm trong bộ nhớ. Máy chủ không sập ngay mà chậm dần rồi hết tài nguyên, nên rất khó nhận ra nếu chỉ nhìn log lỗi.

Ngoài ra còn nhiều lỗi use-after-free và tràn bộ đệm trong HTTP/2, trong đó có trường hợp ứng dụng dùng respondWithFile() hoặc respondWithFD() (CVE-2026-123874) hoặc truyền giá trị từ header :authority vào session.altsvc() (CVE-2026-123828).

Lỗi làm lộ bộ nhớ: nguy cơ với dữ liệu người dùng

Đây là nhóm cần lưu tâm nhất với doanh nghiệp. CVE-2026-123864 (mức cao, ảnh hưởng cả 22.x, 24.x, 26.x) cho phép client không xác thực đọc vùng nhớ thuộc kết nối khác, theo mô tả có thể gồm khoá riêng TLS và yêu cầu của người dùng khác. Điều kiện: handler gọi res.flushHeaders() trước khi thân yêu cầu kết thúc, rồi gọi res.end() với một đoạn dữ liệu không rỗng; việc đọc dữ liệu rò ra cần thêm một route có echo hoặc lưu lại thân yêu cầu. node:http không mã hoá không bị ảnh hưởng.

CVE-2026-123866 cũng có thể khiến server gửi vùng nhớ đã giải phóng, gồm nội dung phản hồi của kết nối khác, tới một peer. Nếu hệ thống của bạn xử lý dữ liệu cá nhân, một sự cố kiểu này vừa là lỗi kỹ thuật vừa là sự cố dữ liệu. Giảm lượng dữ liệu nhạy cảm đi qua tầng ứng dụng, ví dụ bằng việc che thông tin cá nhân từ sớm, giúp thiệt hại nhỏ hơn nếu có sự cố; bạn có thể tham khảo giải pháp AI Masking cho mục đích này.

TLS: xác thực chứng chỉ client có thể bị vượt qua

Hai lỗi liên quan mTLS theo từng hostname:

  • CVE-2026-123872: client đổi servername khi thương lượng lại TLS 1.2 để mang phiên xác thực sang host được bảo vệ chặt hơn.
  • CVE-2026-123867: khi gọi server.addContext(host, { ca }) mà context không có chứng chỉ máy chủ, CA riêng của host không được cài và hệ thống quay về CA mặc định.

Cả hai chỉ ảnh hưởng nếu bạn áp chính sách chứng chỉ client khác nhau giữa các hostname trong cùng một server Node.js. Ngoài ra, CVE-2026-126051 có thể làm sập tiến trình khi server dùng SNICallback, OCSPRequest, newSession, resumeSession hoặc server.addContext().

Lỗi thông tin xác thực proxy lọt vào log

CVE-2026-123871 (mức trung bình) đáng chú ý vì rất đời thường: một số đường báo lỗi ERR_PROXY_INVALID_CONFIG ghi nguyên URL proxy, kèm tên người dùng và mật khẩu, vào thông báo lỗi. Thông báo đó có thể đi tới stderr, log container, hệ thống gom log và dịch vụ báo cáo sự cố. Nếu bạn cấu hình proxy qua biến môi trường, hãy rà log cũ.

Kiểm tra hệ thống của bạn trong một buổi

Bạn có thể làm theo thứ tự sau.

  1. Xác định phiên bản đang chạy. Trên máy chủ và trong container:
node --version
docker exec <ten-container> node --version
  1. So với bản vá. Cần tối thiểu 22.23.5, 24.22.3 hoặc 26.13.1 tuỳ nhánh.
  2. Xem Node.js có đứng trực tiếp ra internet không. Nếu phía trước đã có Nginx hoặc bộ cân bằng tải kết thúc TLS và HTTP/2, bề mặt tấn công thu hẹp đáng kể, nhưng vẫn nên cập nhật.
  3. Tìm đoạn code chạm vào các điểm bị lỗi:
grep -rnE "node:http2|require\('http2'\)|respondWithFile|respondWithFD|altsvc|addContext|SNICallback|flushHeaders" src/
  1. Với container, build lại image. Ghim tag cụ thể, ví dụ nhánh 24 hoặc 26, và build bằng --pull để lấy lớp nền mới. Image cũ chạy lâu ngày sẽ không tự có bản vá.
  2. Rà log. Tìm chuỗi ERR_PROXY_INVALID_CONFIG và xoá hoặc xoay vòng mật khẩu proxy nếu nó từng xuất hiện.
  3. Kiểm thử trước khi đưa lên production. Chạy bộ test, đặc biệt các route upload, streaming và tải file, rồi theo dõi số kết nối CLOSE_WAIT và mức RAM sau khi triển khai.

Ứng dụng Next.js có bị ảnh hưởng không

Next.js chạy trên Node.js, nên cần cập nhật runtime ở máy chủ tự vận hành. Tuy nhiên phần lớn triển khai đặt Nginx hoặc reverse proxy phía trước, không để Node.js phục vụ HTTP/2 trực tiếp, nên mức rủi ro cụ thể phụ thuộc kiến trúc. Dù vậy, cập nhật phiên bản runtime vẫn rẻ hơn nhiều so với việc điều tra sự cố rò rỉ sau này.

Nên làm gì tiếp theo

Hãy lập danh sách các dịch vụ Node.js đang chạy, ghi lại nhánh và phiên bản, rồi xếp lịch nâng cấp theo mức độ lộ ra internet. Nếu bạn cần đội ngũ rà soát hoặc vận hành giúp, xem các dự án Node.js, Next.js đã triển khai tại trang dự án của Besoft.

Nguồn tham khảo