Tuxcare Errata System 0.0.1 5.10 2026-09-08T13:10:49 Community Enterprise Operating System 6 - Extend the ALTNJS-278 bundled-zlib build to el6. The guard added in 14.21.3-30 only excluded el7, so CL6 kept getting --shared-zlib and linked the base OS zlib 1.2.3, which is older than the 1.2.7 that made npm fail on CL7. npm install against registry.npmjs.org fails there with "Z_STREAM_ERROR: Invalid response body ...: Zlib error" on both x86_64 and i686. Building against node's bundled deps/zlib (>= 1.2.11) fixes it, as it did on el7. No other platform changes: el8+ still links the system zlib. Critical TuxCare License Agreement CVE-2023-30589 CVE-2023-38552 CVE-2023-32002 CVE-2026-48934 CVE-2023-30590 CVE-2023-30581 CVE-2024-22019 CVE-2026-21717 CVE-2023-32559 CVE-2026-48933 CVE-2026-48937 CVE-2023-46809 CVE-2025-55131 CVE-2023-32006 CVE-2026-48928 CVE-2023-39333 CVE-2026-48930 CVE-2026-21637 CVE-2026-48931 CVE-2026-21714 CVE-2024-27983 CVE-2024-27982 CVE-2026-48618 CVE-2025-59466 CVE-2025-23085 CVE-2023-44487 cpe:/o:centos:linux:6:GA Community Enterprise Operating System 6 - Extend the ALTNJS-278 bundled-zlib build to el6. The guard added in 12.22.12-27 only excluded el7, so CL6 kept getting --shared-zlib and linked the base OS zlib 1.2.3, which is older than the 1.2.7 that made npm fail on CL7. npm install against registry.npmjs.org fails there with "Z_STREAM_ERROR: Invalid response body ...: Zlib error". Building against node's bundled deps/zlib (>= 1.2.11) fixes it, as it did on el7. No other platform changes: el8+ still links the system zlib. - Build el6 against alt-python27. el6's base python is 2.6.6 and Node.js 12 requires 2.7, so ./configure aborted with "Please use Python 2.7". el6 now BuildRequires alt-python27 (2.7.18, from the alt-python flavour repo) and puts it on PATH, as alt-nodejs14 already does. This also fixes the shebang rewrites in %prep, which emitted a literal "%{__python2}" on el6 because el6's rpm does not define that macro. - Fix the i686 build of the now-bundled deps/zlib. zlib.gyp compiles the SSE2 paths without adding -msse2, which only works where SSE2 is in the baseline ABI; on i686 gcc rejects the always_inline intrinsics with "target specific option mismatch". Backport the one-line-per-file sse2 target pragma that node 14's bundled zlib already carries (chunkcopy.h, fill_window_sse.c); a no-op on x86_64. Critical TuxCare License Agreement CVE-2024-22025 CVE-2023-30589 CVE-2022-32213 CVE-2023-38552 CVE-2023-32002 CVE-2025-59465 CVE-2026-48934 CVE-2023-30590 CVE-2024-22019 CVE-2026-21717 CVE-2023-32559 CVE-2023-23918 CVE-2026-48933 CVE-2026-48937 CVE-2023-46809 CVE-2025-55131 CVE-2026-48928 CVE-2026-48930 CVE-2026-21637 CVE-2026-48931 CVE-2026-21714 CVE-2024-27982 CVE-2026-48618 CVE-2025-59466 CVE-2025-23085 CVE-2023-44487 cpe:/o:centos:linux:6:GA Community Enterprise Operating System 6 - CVE-2022-43548: harden the inspector IsIPAddress() to parse IPv4 and bracketed IPv6 hosts with uv_inet_pton(), rejecting octal, hexadecimal and leading-zero octet formats and treating 0.0.0.0/8 and ::/128 as non-routable, closing the --inspect DNS-rebinding host allow-list bypass - Folded in upstream follow-up 73fa9ab7a5, which keeps the IPv6 string terminator inside the INET6_ADDRSTRLEN buffer Important TuxCare License Agreement CVE-2022-43548 cpe:/o:centos:linux:6:GA Community Enterprise Operating System 6 - CVE-2026-56846: keep HTTP/2 header blocks charged against maxSessionMemory while the JS objects built from them can still keep them alive. A new Http2Stream::retained_headers_length_ accumulates what Http2Session::HandleHeadersFrame() used to un-charge the moment it handed the headers up to JS, and Http2Session::RemoveStream() drains both counters when the stream leaves the session, so a peer can no longer hold unbounded header memory alive across many stalled streams while the credit-based limit reads as near zero (backport of nodejs/node f14d78b9e0). Node 12's RemoveStream() takes the stream as a parameter instead of looking it up by id, and its now-redundant un-charge in Http2Stream::~Http2Stream() is removed so the counter is not decremented twice - CVE-2026-56848: stop Http2Stream::SubmitRstStream() from force-purging the session's pending outbound data for a refused stream. Resetting a stream that nghttp2 refused after a GOAWAY happens from inside a receive callback, where session_->SendPendingData() re-enters nghttp2_session_mem_send() while nghttp2_session_mem_recv() is still on the stack and can free streams the active receive is still using. Such a reset now goes out through FlushRstStream() alone, extending the deferral that already covered NGHTTP2_CANCEL to NGHTTP2_REFUSED_STREAM (backport of nodejs/node daa6d25e3d) Important TuxCare License Agreement CVE-2026-56846 CVE-2026-56848 cpe:/o:centos:linux:6:GA Community Enterprise Operating System 6 - CVE-2026-56846: http2: retain header memory in session accounting -- HandleHeadersFrame() un-charged the decoded header block from maxSessionMemory as soon as it handed it to JS, even though the JS objects can keep the block alive for the whole lifetime of the stream, so a peer that opens many streams with large header blocks and never lets them complete keeps unbounded header memory alive while the credit-based limit reads as near zero and never rejects a new stream. The amount is now moved into a new per-stream counter, Http2Stream::retained_headers_length_, and RemoveStream() drains both counters when the stream is erased (backport of nodejs/node@f14d78b9, the v22.x release-line commit shipped in v22.23.2, carrying the upstream regression test with two deviations. The header block is built as an object with a multi-valued cookie field because 14.21.3's Http2Session#request() rejects the flat array upstream passes; that one is required, or the test throws ERR_INVALID_ARG_TYPE before it ever reaches the fix. The server also raises maxHeaderListPairs to 4096, which is hardening: it puts the pair-count branch of AddHeader() structurally out of reach, leaving the session-memory branch as the only thing the test can be measuring. The wire shape still matches upstream's -- 120 cookie fields plus four pseudo-headers, 124 entries. The three doc/api/http2.md hunks are deliberately omitted, so the -docs sub-package keeps describing maxSessionMemory without the "header blocks retained by open streams" clause) - CVE-2026-56848: http2: defer rst stream while in scope -- SubmitRstStream() force-purged pending session data via SendPendingData() for every error code except NGHTTP2_CANCEL, so a RST_STREAM submitted for a refused stream from inside an nghttp2 receive callback re-entered nghttp2_session_mem_send() while nghttp2_session_mem_recv() was still on the stack, and the send path could free streams the active receive was still using (heap use-after-free, reachable by sending GOAWAY with last_stream_id 0 immediately followed by HEADERS for further streams). NGHTTP2_REFUSED_STREAM now takes the same deferred path, flushing the RST_STREAM and leaving the pending data for the enclosing Http2Scope (backport of nodejs/node@daa6d25e, the v22.x release-line commit shipped in v22.23.2, carrying the upstream regression test verbatim; the cosmetic re-indent of the pre-existing AddPendingRstStream block is not carried) Important TuxCare License Agreement CVE-2026-56846 CVE-2026-56848 cpe:/o:centos:linux:6:GA alt-nodejs14-nodejs alt-nodejs14-nodejs-devel alt-nodejs14-nodejs-docs alt-nodejs14-npm alt-nodejs12-nodejs alt-nodejs12-nodejs-devel alt-nodejs12-nodejs-docs alt-nodejs12-npm x86_64 0:14.21.3-32.el6 d07bf2a08d50eb66 0:14.21.3-32.el6 x86_64 1:6.14.18-14.21.3.32.el6 x86_64 0:12.22.12-29.el6 0:12.22.12-29.el6 x86_64 1:6.14.16-12.22.12.29.el6 x86_64 0:12.22.12-31.el6 0:12.22.12-31.el6 x86_64 1:6.14.16-12.22.12.31.el6 x86_64 0:12.22.12-32.el6 0:12.22.12-32.el6 x86_64 1:6.14.16-12.22.12.32.el6 x86_64 0:14.21.3-34.el6 0:14.21.3-34.el6 x86_64 1:6.14.18-14.21.3.34.el6