Node.js vá lỗ hổng thực thi mã từ xa trong trình giải nén Brotli đi kèm
Node.js đã phát hành các bản cập nhật bảo mật cho phiên bản 22, 24 và 26 để khắc phục một lỗi ghi ngoài phạm vi (out-of-bounds write) mức độ nghiêm trọng cao trong trình giải nén Brotli, có thể cho phép thực thi mã từ xa.
Được dịch tự động từ bản gốc tiếng Anh.
Node.js đã phát hành các bản cập nhật bảo mật quan trọng vào ngày 21 tháng 10 cho ba dòng phiên bản được hỗ trợ: 22.x, 24.x và 26.x. Bản vá quan trọng nhất xử lý một lỗ hổng trong thư viện giải nén Brotli đi kèm, có khả năng cho phép kẻ tấn công thực thi mã tùy ý trên các hệ thống bị ảnh hưởng. Các nhà phát triển đang chạy những phiên bản đã hết vòng đời (end-of-life) như Node.js 20.x cần nâng cấp ngay lập tức, vì các dòng cũ hơn này sẽ không nhận được bản vá.
Chuyện gì đã xảy ra
Dự án Node.js đã sửa mười lỗi khác nhau trong chu kỳ phát hành này, nhưng mối lo ngại chính là CVE-2026-111497, một lỗ hổng ghi ngoài phạm vi trong trình giải nén Brotli. Lỗi này tồn tại trong bản sao thư viện Brotli của Google mà Node.js đóng gói nội bộ, nghĩa là nó ảnh hưởng đến bất kỳ ứng dụng nào giải nén dữ liệu Brotli, dù thông qua module node:zlib hay tự động qua phản hồi của fetch(). Lỗ hổng được kích hoạt bởi đầu vào nén bị lỗi định dạng, khiến trình giải nén ghi dữ liệu vượt ra ngoài bộ nhớ đệm đã được cấp phát.
Mặc dù dự án đánh giá lỗi này ở mức độ nghiêm trọng cao với khả năng dẫn đến thực thi mã từ xa (RCE), việc khai thác thực tế dường như khá khó khăn. Một bằng chứng khái niệm (proof-of-concept) công bố vào ngày 22 tháng 10 chỉ minh họa việc thực thi mã trên một bản build thử nghiệm cố tình làm suy yếu. Trên các bản build tiêu chuẩn, kỹ thuật khai thác gây ra sự cố sập chương trình và hạn chế đọc bộ nhớ thay vì thực thi mã đầy đủ. Tính đến ngày 22 tháng 10, chưa có báo cáo về việc khai thác tích cực trong môi trường thực tế, và các phiên bản đã vá hiện từ chối đầu vào bị lỗi định dạng được sử dụng trong các bài kiểm tra này.
Ngoài vấn đề với Brotli, bản cập nhật còn xử lý ba lỗ hổng nghiêm trọng cao khác. Hai trong số đó liên quan đến việc kiểm tra chứng chỉ TLS mà kẻ tấn công có thể bỏ qua bằng cách sử dụng các dạng địa chỉ IP không chuẩn hóa hoặc chữ số toàn góc (fullwidth digits), cho phép chứng chỉ khớp với các máy chủ mà chúng không nên khớp. Bản vá nghiêm trọng cao thứ ba ngăn chặn dns.resolve cắt ngắn tên máy chủ chứa các byte null nhúng bên trong. Các bản sửa còn lại bao gồm các vấn đề ở mức độ trung bình và thấp, chẳng hạn như lỗi trong việc tạo số ngẫu nhiên trong snapshot khởi động và việc bỏ qua mô hình phân quyền.
Cơ chế hoạt động
Brotli là một thuật toán nén do Google phát triển, được sử dụng rộng rãi cho nội dung web vì cung cấp tỷ lệ nén tốt hơn gzip. Node.js đóng gói bản sao mã nguồn Brotli riêng thay vì phụ thuộc vào thư viện cấp hệ thống. Khi một ứng dụng nhận dữ liệu nén, trình giải nén nội bộ xử lý luồng bit để tái tạo nội dung gốc. Lỗ hổng xuất hiện do trình giải nén không xác minh đúng cách một số trường hợp biên trong đầu vào bị lỗi định dạng, dẫn đến ghi ngoài phạm vi. Điều này có nghĩa là chương trình ghi dữ liệu vào vị trí bộ nhớ mà nó không được phép truy cập, có thể làm hỏng bộ nhớ hoặc cho phép kẻ tấn công chèn và chạy mã độc hại.
Bản vá bao gồm một patch từ dự án Brotli gốc, được Node.js tích hợp vào mã nguồn của mình. Patch này thêm các bước kiểm tra xác minh chặt chẽ hơn, khiến trình giải nén thất bại sớm và an toàn khi gặp đầu vào không hợp lệ, ngăn ngừa tình trạng hỏng bộ nhớ. Vì nhiều dự án phần mềm khác cũng đóng gói bản sao Brotli riêng, các bản cập nhật tương tự có khả năng cần thiết trên toàn bộ hệ sinh thái rộng lớn hơn. Cùng bản sửa lỗi này đã được phát hành trong các phiên bản Brotli 1.2.1, 1.1.1 và 1.0.10 vào ngày 21 tháng 10.
Chi tiết chính
- Phiên bản đã sửa: Node.js 22.23.4, 24.22.1 và 26.12.1 chứa các bản vá cần thiết.
- Cảnh báo hết vòng đời: Node.js 20.x và các phiên bản trước đó không còn được hỗ trợ và sẽ không nhận được bản sửa lỗi này; bắt buộc phải di chuyển sang phiên bản mới hơn.
- Vector tấn công: Các ứng dụng bị lộ nếu chúng giải nén dữ liệu Brotli từ các nguồn không đáng tin cậy, chẳng hạn như body của request hoặc phản hồi từ API bên ngoài.
- Chặn chứng chỉ: Bản cập nhật cũng chặn tám khóa cơ quan chứng chỉ trung gian (intermediate CA) bị xâm phạm từ eMudhra và loại bỏ ba root emSign.
- Cập nhật phụ thuộc: Các phiên bản đi kèm của undici, c-ares, OpenSSL (trên 22.x và 24.x) và SQLite (trên 22.x) đã được cập nhật để sửa các lỗ hổng đã biết bổ sung.
- Không có biện pháp tạm thời: Không có cách giảm thiểu tạm thời nào trong Node.js cho lỗ hổng Brotli; nâng cấp là giải pháp duy nhất.
Tại sao điều này quan trọng
Đối với các kỹ sư backend và trưởng nhóm kỹ thuật, bản cập nhật này nhấn mạnh những rủi ro vốn có trong việc đóng gói các thư viện của bên thứ ba. Mặc dù mã nguồn không được viết bởi đội ngũ Node.js, trách nhiệm bảo mật nó thuộc về những người bảo trì runtime và cuối cùng là các nhà phát triển triển khai nó. Việc lỗ hổng tồn tại trong các quy trình tự động như fetch() có nghĩa là ngay cả những ứng dụng không sử dụng trực tiếp các thư viện nén vẫn có thể gặp rủi ro nếu chúng tương tác với các dịch vụ bên ngoài trả về dữ liệu nén Brotli.
Việc bao gồm danh sách chặn chứng chỉ eMudhra cũng nhấn mạnh tầm quan trọng của các kho lưu trữ tin cậy (trust stores) trong giao tiếp an toàn. Vì Node.js không thực hiện kiểm tra thu hồi chứng chỉ theo mặc định, các khóa cơ quan chứng chỉ bị xâm phạm có thể vẫn được tin cậy cho đến khi bị chặn rõ ràng. Bản phát hành này là lời nhắc nhở rằng bảo mật không chỉ là sửa lỗi mã mà còn là duy trì tính toàn vẹn của hạ tầng mật mã hỗ trợ các kết nối an toàn.
Bạn có thể làm gì
- Nâng cấp ngay lập tức lên Node.js 22.23.4, 24.22.1 hoặc 26.12.1 tùy thuộc vào dòng phiên bản hiện tại của bạn.
- Di chuyển bất kỳ ứng dụng nào vẫn chạy trên Node.js 20.x hoặc phiên bản cũ hơn sang một phiên bản được hỗ trợ.
- Xem xét các triển khai tùy chỉnh hoặc ứng dụng thực thi đơn lẻ (single-executable applications) để đảm bảo chúng được xây dựng lại với các phiên bản đã vá.
- Giám sát nhật ký để tìm kiếm các sự cố sập bất thường hoặc lỗi bộ nhớ có thể chỉ ra nỗ lực khai thác trước khi áp dụng bản vá.
- Xác minh rằng các pipeline CI/CD của bạn được cấu hình để tải các image cơ sở đã vá mới nhất cho các triển khai container hóa.
- Nếu không thể nâng cấp ngay lập tức, hãy cân nhắc triển khai các quy tắc tường lửa cấp mạng để chặn các yêu cầu inbound đáng ngờ, mặc dù điều này không bảo vệ chống lại các lỗ hổng fetch outbound.



