Node.js: HTTP/2 및 HTTPS 결함으로 클라이언트가 서버를 중단시키고 다른 사용자의 데이터를 읽을 수 있음

발생 내용

2026년 11월 11일 Node.js 프로젝트는 지원 중인 세 가지 릴리스 라인에 대한 보안 릴리스를 발표했습니다. 수정된 버전은 22.23.5, 24.22.3, 26.13.1입니다. 이번 릴리스에서 Node.js 자체의 취약점 16개를 수정했으며, 그중 7개는 높음으로 평가되었습니다. 또한 번들된 종속 라이브러리인 llhttp(22.x, 24.x, 26.x), undici(24.x, 26.x), sqlite(22.x, 24.x)도 업데이트되었습니다.

가장 중요한 문제는 Node.js가 HTTP/2, HTTPS, TLS를 위해 직접 제공하는 서버 코드에 있습니다:

• HTTP/2 서버 중단(24.x 및 26.x): 인증되지 않은 클라이언트가 Node.js 프로세스를 멈추게 할 수 있습니다. 공격에는 기본 HTTP/2 설정과 요청 본문이 모두 도착하기 전에 응답하는 핸들러만 있으면 됩니다. 프로젝트는 이러한 동작을 일반적인 것으로 설명합니다. 이 공격은 TLS 연결과 평문 연결 모두에서 가능합니다.
• HTTP/2 메모리 노출(세 라인 모두): 서버가 클라이언트에게 자신의 메모리 일부를 보낼 수 있으며, 여기에는 다른 연결을 위한 응답도 포함됩니다. 24.22.0 및 26.9.0 이후 버전에서는 클라이언트가 단독으로 이를 유발할 수 있습니다. 22.x와 그 이전의 24.x, 26.x 빌드에서는 예를 들어 유휴 시간 초과 후처럼 서버가 응답 도중 스트림을 닫을 때 발생할 수 있습니다.
• HTTPS 메모리 노출(세 라인 모두): 프로젝트에 따르면 인증되지 않은 클라이언트가 "TLS 개인 키와 다른 사용자의 요청을 포함한" 다른 연결의 메모리를 읽을 수 있습니다. 이를 위해서는 요청 본문이 끝나기 전에 res.flushHeaders()를 호출하고, 이후 데이터와 함께 res.end()를 호출하는 핸들러가 필요합니다. 유출된 메모리를 읽으려면 공격자에게 요청 본문을 되돌려 보내거나 저장하는 경로도 필요합니다.
• HTTP/2 리소스 고갈(세 라인 모두): 클라이언트가 기본 HTTP/2 서버가 메모리와 파일 디스크립터를 영구적으로 점유하도록 만들 수 있습니다.
• HTTP/2 파일 제공(24.x 및 26.x): 서버가 stream.respondWithFile() 또는 stream.respondWithFD()로 파일을 제공할 때 클라이언트가 서버 메모리를 손상시킬 수 있습니다. 세 라인 모두에서 이러한 다운로드를 취소하면 서버가 중단될 수도 있습니다(중간 등급).
• TLS 서버 중단(24.x 및 26.x): SNICallback, OCSPRequest, newSession, resumeSession 훅 또는 server.addContext()를 사용하는 TLS 서버를 클라이언트가 중단시킬 수 있습니다.
• TLS 클라이언트 인증서 우회(세 라인 모두): 일부 서버는 특정 호스트 이름에 대해 더 엄격한 클라이언트 인증서 규칙을 적용합니다. 이러한 서버에서 다른 호스트 이름에 대해 승인받은 클라이언트는 TLS 1.2 재협상 중에 규칙을 충족하지 않고도 더 엄격한 호스트 이름으로 전환할 수 있습니다.

공지에는 이러한 결함을 이용한 공격 사례가 보고되지 않았습니다.

영향을 받는 대상

• 22.23.5 이전의 22.x, 24.22.3 이전의 24.x, 또는 26.13.1 이전의 26.x Node.js를 실행하는 서버.
• 20.x와 25.x를 포함한 지원 종료 라인은 이번 릴리스에서 수정되지 않습니다. 프로젝트는 이러한 버전이 항상 영향을 받는다고 설명합니다.
• 서버 측의 심각한 문제는 Node.js 프로세스가 HTTP/2, HTTPS 또는 TLS 연결을 직접 수락하는 경우에만 해당합니다. 예를 들어 내장 모듈 node:http2, node:https, node:tls를 사용하거나, 이들을 이용해 TLS나 HTTP/2를 종료하는 프레임워크를 사용하는 경우입니다.
• node:http로 만든 일반 HTTP 서버는 HTTPS 메모리 노출의 영향을 받지 않습니다.
• HTTP/2 중단은 24.x 및 26.x 라인에만 영향을 주며 22.x에는 영향을 주지 않습니다.

nginx, Apache, HAProxy 또는 로드 밸런서와 같은 리버스 프록시가 TLS와 HTTP/2를 종료하고 Node.js는 일반 HTTP/1.1만 전달받는 경우 노출 위험이 훨씬 낮습니다. 다만 이번 릴리스에는 다른 수정 사항과 종속 라이브러리 업데이트도 포함되어 있으므로 업데이트를 권장합니다.

지금 해야 할 일

1. 모든 Node.js 설치 위치를 찾으십시오. 시스템 패키지, 버전 관리자(nvm, n, Volta), Docker 이미지, CI 러너, 자체 Node.js를 포함하는 호스팅 패널도 확인하십시오.
2. 사용 중인 라인의 수정 버전으로 업데이트하십시오: 22.23.5, 24.22.3 또는 26.13.1. 배포판이나 벤더 패키지(예: NodeSource 또는 Linux 배포판)를 사용하는 경우 패키지 소스에서 해당 버전을 제공하는 즉시 업데이트를 설치하십시오.
3. 지원이 종료된 버전에서 벗어나십시오. 20.x, 25.x 또는 그 이전 버전을 계속 실행 중이라면 지원되는 라인으로 업그레이드하십시오. 업데이트할 수 없는 서버에 대한 우회 방법은 공지에 나와 있지 않습니다.
4. 컨테이너 이미지를 다시 빌드하여 업데이트된 Node.js 기반 이미지로 재배포하십시오. 호스트만 업데이트해서는 컨테이너 내부의 Node.js가 변경되지 않습니다.
5. 모든 Node.js 프로세스를 재시작(systemd 유닛, PM2, Docker 컨테이너 등)하여 새 런타임이 로드되도록 하십시오. 이후 애플리케이션이 정상적으로 응답하는지 확인하십시오.
6. 노출되었다면 비밀 정보 교체를 검토하십시오. 공지는 HTTPS 메모리 노출 조건에 해당한 서버가 TLS 키나 기타 비밀 정보를 교체해야 하는지 명시하지 않습니다. 해당 조건에 맞는 Node.js HTTPS 서버가 인터넷에서 접근 가능했다면 TLS 인증서와 키의 갱신을 검토하십시오.

영향 여부 확인 방법

• 각 서버와 각 컨테이너 내부에서 node -v를 실행하십시오(docker exec <container> node -v). 해당 라인에서 22.23.5, 24.22.3 또는 26.13.1보다 낮은 버전이거나 20.x, 25.x 같은 지원 종료 라인이면 영향을 받습니다.
• PM2를 사용하는 경우 pm2 list와 pm2 show <app>으로 각 앱이 사용하는 Node.js 바이너리와 버전을 확인할 수 있습니다.
• 애플리케이션이 Node.js에서 직접 HTTP/2나 TLS를 종료하는지 확인하십시오. 코드에서 http2.createSecureServer, http2.createServer, https.createServer, tls.createServer, respondWithFile, respondWithFD, SNICallback, addContext를 검색하십시오.
• 프로세스 관리자와 시스템 로그에서 예상치 못한 Node.js 재시작이나 중단이 있는지 확인하십시오. HTTP/2 서버의 반복적인 비정상 종료는 중단을 유발하려는 시도일 수 있습니다.

출처

• https://thehackernews.com/2026/11/nodejs-fixes-16-flaws-including-http2.html