Node.js HTTP client cắt ngắn header có thể gây request smuggling trong forwarding proxy

Một lỗi trong Node.js HTTP client có thể gây ra request desynchronization đối với các Node.js-based forwarding proxies xây dựng lại outbound headers từ các IncomingMessage headers hiển thị trong khi pipe original body qua một reused backend connection.

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

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

• Node.js 26: các phiên bản đến và bao gồm 26.5.0 được ghi nhận là affected. Bản phát hành sửa lỗi tương ứng là 26.5.1.
• Node.js 24: các phiên bản đến và bao gồm 24.18.0 được ghi nhận là affected. Bản phát hành sửa lỗi tương ứng là 24.18.1.
• Node.js 22: các phiên bản đến và bao gồm 22.23.1 được ghi nhận là affected. Bản phát hành sửa lỗi tương ứng là 22.23.2.

CNA record đặt trạng thái mặc định là unaffected ngoài các mục affected đã liệt kê. Node.js advisory xác nhận cả ba active release line nêu trên đều bị ảnh hưởng.

Lỗi nằm trong cơ chế xử lý header của Node.js HTTP client và thuộc nhóm CWE-444 HTTP Request Smuggling. Khi request có số lượng header vượt quá maxHeadersCount hoặc maxHeaderPairs, Node.js có thể loại bỏ một số header khỏi req.headers, req.rawHeaders và req.headersDistinct, nhưng vẫn dùng các header đó internally để xác định framing của HTTP message. Vì vậy, Content-Length có thể không xuất hiện trong dữ liệu mà userland nhìn thấy, trong khi request body vẫn được chuyển đến ứng dụng. Rủi ro phát sinh khi một forwarding proxy xây dựng lại outbound headers từ các header hiển thị rồi pipe body ban đầu qua một backend connection được tái sử dụng. Trong điều kiện đó, proxy và backend có thể diễn giải ranh giới request khác nhau. Evidence hiện có không nêu chi tiết cụ thể về parser branch hoặc payload cần thiết để kích hoạt tình huống này.

Lỗ hổng có thể được tiếp cận qua mạng và theo bản ghi không yêu cầu quyền xác thực hoặc user interaction. Attack complexity được đánh giá là cao, vì điều kiện khai thác phụ thuộc vào việc triển khai forwarding proxy có xây dựng lại header từ IncomingMessage trong khi chuyển tiếp body qua backend connection được tái sử dụng. Bản ghi được cung cấp đánh dấu public_exploit là false và known_exploited là null. Do đó, evidence hiện có không xác nhận exploit công khai hoặc việc khai thác thực tế, và cũng không nên diễn giải sự im lặng của bản ghi là bằng chứng rằng chưa từng có khai thác.

• Một remote client có thể tác động đến cách forwarding proxy và backend diễn giải request nếu proxy dùng tập header đã bị cắt ngắn để xây dựng lại request nhưng vẫn chuyển tiếp body ban đầu.
• Kết quả kỹ thuật có thể là request desynchronization hoặc request smuggling trên backend connection được tái sử dụng.
• Bản ghi cho thấy điều kiện khai thác không cần quyền xác thực hoặc user interaction, nhưng complexity cao và phụ thuộc vào kiến trúc proxy cụ thể.
• Tác động chính được hỗ trợ bởi evidence là đối với integrity của request. Không có evidence xác nhận việc đọc dữ liệu, chiếm quyền, gián đoạn dịch vụ hoặc thay đổi scope bảo mật.

Lỗi có thể làm forwarding proxy và backend diễn giải khác nhau về ranh giới hoặc nội dung của request được chuyển tiếp. Điều này có thể làm sai lệch request đến dịch vụ phía sau và ảnh hưởng đến integrity của hoạt động xử lý, định tuyến hoặc kiểm tra request. Evidence không xác định một vụ sửa đổi dữ liệu, tiết lộ thông tin, gián đoạn dịch vụ, nạn nhân hoặc breach cụ thể nào. Mức độ phơi nhiễm phụ thuộc đáng kể vào việc tổ chức có dùng Node.js cho forwarding proxy với backend connection reuse và header reconstruction hay không.

1. Nâng cấp Node.js 26 lên 26.5.1, Node.js 24 lên 24.18.1, hoặc Node.js 22 lên 22.23.2, tùy release branch đang vận hành. Đây là các bản phát hành upstream có thay đổi http: reject requests exceeding max header count liên quan đến lỗi này.
2. Redeploy hoặc restart các tiến trình, container và worker để chắc chắn chúng thực sự nạp runtime đã sửa; không chỉ cập nhật package trong filesystem.
3. Kiểm tra các forwarding proxy sau khi nâng cấp, đặc biệt những proxy xây dựng lại header từ IncomingMessage trong khi pipe body qua backend connection được tái sử dụng.
4. Nếu chưa thể nâng cấp, giảm phơi nhiễm bằng cách tạm dừng hoặc cô lập proxy path bị ảnh hưởng khi khả thi về vận hành. Evidence được cung cấp không nêu một workaround cụ thể đã được Node.js xác nhận, vì vậy biện pháp này chỉ nên xem là risk reduction tạm thời, không phải bản sửa lỗi.

• Kiểm kê các tiến trình và container chạy Node.js, sau đó đối chiếu runtime với các bản phát hành đã sửa trong phần remediation.
• Xác định các forwarding proxy dựa trên Node.js có xây dựng outbound headers từ req.headers, req.rawHeaders hoặc req.headersDistinct rồi pipe trực tiếp request body.
• Rà soát việc sử dụng hoặc cấu hình maxHeadersCount và maxHeaderPairs, đặc biệt trên các endpoint có thể nhận request từ mạng không tin cậy.
• Kiểm tra code path xử lý Content-Length và các header framing khác để bảo đảm proxy không suy luận framing chỉ từ tập header hiển thị trong userland.
• Nếu có telemetry về request desynchronization, backend connection reuse hoặc sai lệch request boundary, hãy xem đó là tín hiệu điều tra bổ sung chứ không phải IOC đã được Node.js xác nhận. Việc không thấy log phù hợp không chứng minh hệ thống an toàn.