Node.js 11월 보안 패치 출시: HTTP/2·TLS 영향 조건과 실행 버전 확인

서버 런타임의 보안 패치와 적용 확인을 표현한 생성형 개념 이미지다. 실제 제품 화면이나 네트워크 구성도는 아니다.

Node.js의 11월 보안 업데이트가 실제로 공개됐다. 이제는 예고 일정에 맞춰 목록을 만드는 단계를 넘어, 운영 중인 런타임에 수정 버전을 배포하고 HTTP/2·TLS 경로를 확인할 때다.

이번 글은 앞서 다룬 릴리스 예고의 후속 안내다. 새로 공개된 패치 버전과 취약점의 영향 조건을 바탕으로, 무엇을 먼저 확인하고 어떤 증거를 남길지 정리한다.

1. 같은 계열의 수정 버전부터 확인한다

공식 릴리스 날짜는 November 11, 2026이다. 세 버전 모두 보안 릴리스로 공개됐다.

Node.js 22.x: 22.23.5. 22.23.5 릴리스

Node.js 24.x: 24.22.3. 24.22.3 릴리스

Node.js 26.x: 26.13.1. 26.13.1 릴리스

공식 보안 공지도 업데이트가 제공된 상태로 바뀌었다. 전체 취약점 목록과 영향 계열은 11월 보안 공지에서 확인할 수 있다.

보안 대응과 메이저 버전 이전을 꼭 한 번에 묶을 필요는 없다. 예를 들어 24.x 서비스를 관리한다면 먼저 해당 계열의 수정 릴리스로 검증하는 계획을 세울 수 있다. 배포판이 자체 백포트를 제공하거나 플랫폼이 런타임을 관리한다면 공급자의 패키지 빌드·보안 공지도 함께 확인한다.

2. 우선순위를 정할 세 가지 경로

아래는 전체 CVE 목록이 아니라 운영 점검의 출발점이다. 취약점마다 조건과 영향 계열이 다르므로 “Node.js를 쓴다”는 사실만으로 같은 노출 상태라고 판단하지 않는다.

Node.js가 직접 HTTPS 요청을 처리하는 경로

CVE-2026-123864는 HTTPS 요청 파서의 재진입으로 메모리가 유출될 수 있는 HIGH 취약점이다. 공지는 요청 본문이 끝나기 전 res.flushHeaders()를 호출하고 이후 비어 있지 않은 청크로 res.end()를 호출하는 처리 패턴 등을 조건으로 설명한다. 평문 node:http에는 이 특정 취약점이 적용되지 않는다.

Node.js가 HTTP/2 세션·스트림을 처리하는 경로

연결 종료 과정의 메모리·파일 디스크립터 누수(CVE-2026-123865), 응답 메모리 유출(CVE-2026-123866), 파일 전송 취소 시 프로세스 종료(CVE-2026-123875)가 포함됐다. 일부 문제는 TLS뿐 아니라 평문 HTTP/2에도 해당한다. 파일 응답과 스트림 종료를 사용하는 서비스는 함께 살펴봐야 한다.

호스트마다 다른 mTLS 정책을 적용하는 경로

CVE-2026-123872는 TLS 1.2 재협상에서 서버 이름을 바꿔 클라이언트 인증 정책을 우회하는 문제다. CVE-2026-123867은 인증서 없이 CA만 지정한 SNI 컨텍스트에서 기본 CA로 되돌아가는 문제다. 호스트별 허용 인증서를 구분하는 서비스라면 특히 중요한 점검 대상이다.

위 조건과 심각도는 Node.js 공식 취약점 설명에 근거한다. 특정 CVE가 한 계열의 영향 목록에 없더라도 그 계열의 다른 수정까지 불필요해지는 것은 아니다.

3. 프록시 앞뒤를 나눠서 점검한다

다음은 위 영향 조건을 실제 서비스에 연결하기 위한 운영상 권고다.

TLS 종료 위치를 적는다. 외부 로드밸런서에서 끝나는지, Node.js까지 암호화 연결을 유지하는지 확인한다.

백엔드 프로토콜도 적는다. 브라우저와 프록시 사이의 HTTP/2 여부만 확인하지 말고, 프록시와 애플리케이션 사이의 HTTP/1.1·HTTP/2 설정을 따로 확인한다.

인증 경계를 표시한다. mTLS를 처리하는 구성요소와 호스트별 CA 정책의 소유자를 찾는다.

외부에서 우회 접근할 수 있는 원본 경로를 확인한다. 프록시가 있다는 이유만으로 Node.js에 직접 도달하는 경로가 없다고 가정하지 않는다.

이 목록은 패치 순서를 정하는 데 쓴다. 프록시나 WAF의 존재만으로 이번 패치가 적용됐다고 기록하면 안 된다. 반대로 영향 조건을 모른다는 이유로 운영 환경에서 취약점 재현 코드를 실행할 필요도 없다.

4. 버전 확인을 세 가지 결과로 남긴다

다음 코드는 파일과 설정을 바꾸지 않고 지금 실행한 프로세스의 런타임 정보를 출력한다. process.versions.node는 Node.js 버전이고 process.execPath는 현재 프로세스를 시작한 실행 파일 경로다. Node.js process 문서

check-release.cjs로 저장한 뒤 node check-release.cjs로 실행하면 된다.

below-nov11-baseline: 이 글에 기록한 계열별 수정 버전보다 낮다.

meets-nov11-baseline: 해당 계열에서 이번 수정 버전 이상이다. 전체 보안 상태가 안전하다는 판정은 아니다.

manual-check: 다른 메이저 계열, 프리릴리스, 공급자 접미사 등이 있어 이 비교기로 판단하지 않았다.

고정된 날짜의 기준을 비교하는 예제이므로 이후 보안 릴리스까지 자동으로 추적하지 않는다. 공급자 백포트의 적용 여부도 판정하지 않는다.

로컬 Linux x64·Node.js 24.22.1에서 경계값 바로 아래와 같은 값, 두 자릿수 패치, 상위 마이너, 프리릴리스·공급자 접미사 등 12개 입력 검사를 통과했다. 실제 로컬 런타임은 below-nov11-baseline으로 출력됐다. 이는 비교 로직 검증이며 보안 패치나 취약점 검증 결과가 아니다.

5. 배포 완료 조건은 실행 중인 프로세스까지 잡는다

컨테이너를 사용한다면 최종 실행 이미지에 수정 런타임이 들어 있는지 확인한다. 빌드 단계만 바꾼 경우를 놓치기 쉽다. Docker의 --pull은 베이스 이미지 갱신을 확인하고, --no-cache는 빌드 캐시를 사용하지 않게 한다. 이미지를 digest로 고정했다면 새 digest를 명시적으로 검토해야 한다. Docker 이미지 재빌드·버전 고정 안내

배포 승인 기록에는 다음을 남기는 편이 좋다.