Node.js của nodejs: request desynchronization do header framing bị ẩn

Một lỗi trong HTTP client của Node.js có thể gây ra request desynchronization đối với các forwarding proxy dựa trên Node.js, khi chúng dựng lại outbound headers từ các IncomingMessage headers hiển thị nhưng vẫn pipe body gốc tới một backend connection được reuse.

Node.js có thể bỏ qua các header vượt quá maxHeadersCount / maxHeaderPairs khỏi req.headers, req.rawHeaders và req.headersDistinct, trong khi vẫn sử dụng các header bị bỏ qua đó ở nội bộ cho việc framing HTTP message. Cụ thể, Content-Length có thể bị ẩn khỏi userland trong khi request body vẫn được chuyển tới.

Lỗ hổng này ảnh hưởng đến tất cả các release line còn được hỗ trợ: Node.js 22, Node.js 24 và Node.js 26.

Theo affected data của CNA, vendor nodejs và product Node.js có các nhánh sau:

• Node.js 22: các phiên bản nhỏ hơn hoặc bằng 22.22.3 được đánh dấu affected.
• Node.js 24: các phiên bản nhỏ hơn hoặc bằng 24.16.0 được đánh dấu affected.
• Node.js 26: các phiên bản nhỏ hơn hoặc bằng 26.3.0 được đánh dấu affected.

Default status của product là unaffected ngoài các phạm vi được nêu. Red Hat VEX bổ sung trạng thái riêng cho Red Hat Hardened Images: nodejs20.src và nodejs25.src được liệt kê là known affected với trạng thái no fix planned, trong khi các package thuộc các nhánh Node.js 22, Node.js 24 và Node.js 26 của Red Hat được liệt kê là fixed ở các build cụ thể. Trạng thái Red Hat này không nên được suy rộng thành ranh giới upstream cho mọi bản phân phối Node.js.

Lỗi nằm trong HTTP client của Node.js và thuộc CWE-444, xảy ra khi các giới hạn maxHeadersCount hoặc maxHeaderPairs khiến một số header bị loại khỏi các tập header mà ứng dụng nhìn thấy. Input do attacker kiểm soát là HTTP request có các header vượt quá giới hạn, trong đó header dùng cho framing như Content-Length có thể bị ẩn khỏi userland nhưng vẫn được Node.js sử dụng nội bộ để xác định cách xử lý body. Điều kiện khai thác quan trọng là forwarding proxy phải dựng lại header outbound từ req.headers, req.rawHeaders hoặc req.headersDistinct, đồng thời pipe body gốc tới một backend connection được reuse. Khi proxy nhìn thấy một bộ header không đầy đủ nhưng backend vẫn nhận body theo framing khác, cách diễn giải request giữa proxy và backend có thể bị lệch. Network reachability được hỗ trợ và không yêu cầu authentication theo dữ liệu đánh giá trong record, nhưng exploit cần request được tạo có chủ đích và phụ thuộc vào kiến trúc proxy cụ thể. Public record không mô tả chi tiết implementation thấp hơn gây ra việc loại bỏ header hoặc một payload khai thác cụ thể.

Lỗi có thể bị kích hoạt từ xa qua network khi attacker gửi HTTP request tới một Node.js-based forwarding proxy phù hợp. Không yêu cầu quyền xác thực hoặc user interaction theo record, nhưng attack complexity cao vì cần vượt qua giới hạn header và đồng thời đáp ứng cách proxy chuyển tiếp body tới backend connection được reuse. CISA ADP ghi nhận exploitation là none và automatable là no trong đánh giá được công bố cho record này. Record cũng không xác định public exploit; trạng thái đó không chứng minh rằng việc khai thác là không thể trong mọi môi trường.

Kết quả kỹ thuật chính là proxy và backend có thể diễn giải không nhất quán cùng một HTTP request vì proxy thấy bộ header đã bị thiếu trong khi Node.js vẫn xử lý body theo framing nội bộ. Hậu quả thực tế có thể là ảnh hưởng toàn vẹn dữ liệu hoặc xử lý sai request ở backend, nhưng record không xác định một kết quả payload cụ thể. Không có bằng chứng trong record cho thấy mọi deployment đều bị lộ dữ liệu hoặc mất khả dụng. Tác động thực tế phụ thuộc vào reachability của proxy, việc reuse backend connection và logic rebuild headers của ứng dụng.

Các deployment làm forwarding proxy có thể chuyển tiếp một request với header mà proxy không nhìn thấy đầy đủ, trong khi backend vẫn xử lý body theo framing nội bộ của Node.js. Sự không nhất quán này có thể gây request desynchronization và dẫn tới vấn đề toàn vẹn dữ liệu hoặc xử lý request không đúng dự kiến ở backend. Mức độ ảnh hưởng phụ thuộc vào việc proxy có rebuild headers hay không, backend connection có được reuse hay không và các request nào có thể đi qua đường dẫn đó. Record không xác lập việc lộ dữ liệu hoặc gián đoạn dịch vụ cho mọi deployment Node.js.

1. Ưu tiên nâng cấp từng nhánh Node.js bị ảnh hưởng theo bản sửa chính thức của nhà cung cấp. Record đánh dấu patch available nhưng không cung cấp một fixed release upstream tổng quát, vì vậy không nên suy ra rằng một bản sửa của nhánh này tự động áp dụng cho nhánh khác.
2. Đối với Red Hat Hardened Images, sử dụng các fixed package builds được Red Hat liệt kê: Node.js 22 với 22.23.2-2.3.2.hum1, Node.js 24 với 24.18.1-0.2.2.hum1, và Node.js 26 với 26.7.0-1.5.2.hum1.
3. Rà soát thiết kế của forwarding proxy để không chỉ dựa vào các collection header có thể bị giới hạn khi dựng lại request outbound. Đặc biệt, cần xác minh sự nhất quán giữa header dùng để framing và body được pipe tới backend connection.
4. Nếu chưa thể nâng cấp ngay, cô lập các proxy có pattern xử lý nêu trên và đánh giá việc tạm ngừng đường dẫn forwarding bị ảnh hưởng. Đây là biện pháp giảm rủi ro theo kiến trúc, không phải workaround được CNA xác nhận.
5. Sau khi cập nhật, khởi động lại các process hoặc image chứa Node.js và kiểm tra lại inventory để bảo đảm runtime thực tế đã dùng build đã sửa.

1. Kiểm kê các service, container và image sử dụng Node.js để làm forwarding proxy hoặc HTTP gateway, sau đó đối chiếu từng runtime với các ranh giới bị ảnh hưởng trong record.
2. Rà soát code proxy có đọc req.headers, req.rawHeaders hoặc req.headersDistinct để tạo outbound headers hay không, đặc biệt khi body gốc được pipe tới backend connection được reuse.
3. Kiểm tra cấu hình và behavior tại các giới hạn maxHeadersCount và maxHeaderPairs, đồng thời xác minh rằng các header framing quan trọng không bị coi là tùy chọn khi proxy dựng request mới.
4. Với Red Hat Hardened Images, kiểm tra package identity và build đang triển khai so với các fixed package builds được nhà cung cấp nêu trong affected và remediation data.
5. Có thể dùng môi trường kiểm thử không production để xác minh rằng proxy và backend duy trì cùng cách diễn giải request boundary khi đạt giới hạn header. Việc không thấy log bất thường không chứng minh hệ thống an toàn, vì record không nêu một indicator cụ thể.