Node.js 2026년 10월 보안 업데이트: Brotli·TLS 취약점과 수정 버전

현재 쓰는 계열의 수정 버전을 먼저 맞춥니다

Node.js 프로젝트는 2026-10-21 보안 릴리스로 22.23.4, 24.22.1, 26.12.1을 공개했습니다. 아래는 이 공지에 대응하는 계열별 수정 버전입니다. 확인일 이후 릴리스가 나올 수 있으므로 배포할 때 공식 공지를 다시 확인하세요.

처음부터 메이저 버전을 바꾸는 계획과 현재 계열의 보안 수정을 적용하는 계획을 섞지 않는 편이 변경 범위를 파악하기 쉽습니다. 이미 쓰는 계열, 배포판, 네이티브 모듈과 지원 조건을 적고 적용할 버전을 정하세요. 이 표는 모든 미래 취약점에 대한 안전 판정표가 아닙니다.

외부 입력이 취약 기능에 닿는지 확인합니다

Brotli의 CVE-2026-111497은 공격자가 제공한 압축 데이터를 애플리케이션이 node:zlib로 해제하는 경로에서 메모리 손상과 원격 코드 실행 가능성을 다룹니다. Node.js HTTP 서버라는 이유만으로 모든 요청이 곧바로 이 조건에 해당한다고 단정하지 않습니다.

아래는 공식 공지에서 골라 줄인 입력 경로 점검표입니다. 자신의 코드와 사용하는 라이브러리에서 그 경로를 찾는 질문으로 쓰며, 해당 경로를 아직 찾지 못했다는 이유로 런타임 갱신을 생략하지 않습니다.

호스트·CI·컨테이너의 버전을 따로 기록합니다

개발 PC의 Node.js를 바꿨다고 CI나 실행 컨테이너도 바뀌지는 않습니다. 아래 읽기 전용 명령을 각각의 실행 환경에서 확인하고 결과 옆에 환경 이름을 붙이세요. process.versions는 Node.js와 포함된 구성 요소의 버전을 보여주며, 이 정보만으로 특정 입력 경로의 안전성을 판정하지는 않습니다.

이 명령은 지금 실행한 CLI의 버전입니다. 컨테이너 안에서 새 Node 명령을 실행해도 기존 앱 프로세스가 교체됐다는 증거는 별도입니다. 실제 앱의 새 시작 기록, 실행한 이미지와 프로세스 교체 시점을 함께 확인해야 합니다. 환경변수 전체나 비밀값을 출력할 필요는 없습니다.

node --version
node -p "JSON.stringify({node:process.version,openssl:process.versions.openssl,brotli:process.versions.brotli,ares:process.versions.ares,undici:process.versions.undici},null,2)"

npm 의존성 감사와 런타임 패치를 나눕니다

npm audit는 패키지 의존성의 알려진 취약점을 확인하는 절차입니다. 감사 결과가 0건이거나 npm 패키지를 업데이트했다는 사실만으로 Node 실행 파일까지 바뀌었다고 보지 마세요. 패키지 lockfile, Node 버전, 배포 이미지 기록을 별도 항목으로 남깁니다.

예를 들어 저장소의 의존성 감사가 성공했는데 실행 컨테이너의 Node 버전은 이전 값일 수 있습니다. 이 경우 감사 결과를 고치는 대신 런타임이 어느 빌드·이미지에서 오는지 추적해야 합니다. 감사 경고를 숨기거나 검사를 끄는 것은 런타임 교체의 증거가 되지 않습니다.

• 패키지 감사 결과: 어느 lockfile과 커밋을 검사했는가?
• 런타임 결과: 어느 실행 환경에서 어떤 Node 버전을 읽었는가?
• 배포 결과: 그 런타임을 포함한 이미지가 실제 앱에 적용됐는가?

이미지를 재빌드한 뒤 실제 프로세스를 교체합니다

컨테이너를 사용한다면 builder와 runtime 단계의 베이스 이미지를 함께 확인합니다. 같은 태그 문자열이라도 빌드가 어떤 베이스 이미지와 캐시를 사용했는지 확인하고, 갱신된 기반으로 결과 이미지를 다시 만드세요. 이미지는 생성 후 바뀌지 않으므로 이전 실행 컨테이너가 자동으로 새 런타임을 쓰지는 않습니다.

이 글의 운영 순서는 새 이미지 검증 → 승인된 배포 절차로 교체 → 실행 상태 확인입니다. 이미지 빌드 성공에서 작업을 끝내지 말고 실제 요청을 받는 앱과 별도 워커가 새 프로세스로 실행되는지 확인하세요. 사용하는 배포 체계에 맞춰 직전 이미지와 복구 절차도 준비합니다.

• 적용할 수정 계열과 버전을 기록합니다.
• 베이스 이미지 갱신 여부와 builder/runtime의 버전을 확인합니다.
• 새 결과 이미지의 digest와 테스트 결과를 남깁니다.
• 승인된 절차로 앱·워커를 교체하고 새 시작 기록을 확인합니다.
• 여러 인스턴스 중 이전 이미지가 남아 있는지 확인합니다.

TLS와 HTTP 동작은 검증을 유지한 채 확인합니다

패치 뒤 연결이 실패한다면 인증서 검증을 꺼서 통과시키지 마세요. 의도한 호스트 표기, 인증서의 대상과 신뢰 체인, 프록시 경로를 확인하고 원인을 고칩니다. 기존에 잘못 허용되던 연결을 유지하는 것이 회귀 시험의 목표는 아닙니다.

다음은 승인된 시험 환경에서 사용할 점검 설계이며, 이 글에서 실행한 보안 재현 결과가 아닙니다. 소유한 정상 자료와 테스트용 인증서를 사용하고 운영 시스템이나 제삼자 주소에 공격 입력을 보내지 않습니다.

HLB Studio에서 이번에 확인한 범위

2026-10-23 운영 블로그의 두 SSR replica 컨테이너 안에서 Node 버전을 읽기 전용으로 조회했고 모두 v22.23.4로 확인했습니다. 이 값은 위 22.x 수정 릴리스와 일치합니다. 당시 desired·ready·updated·available 수는 각각 2였으며, 배포 이미지와 앞단 Caddy 설정은 전후 동일했습니다.

이번 확인은 기존 배포에서 컨테이너 안의 Node 실행 파일 버전과 준비 상태를 읽은 범위입니다. 기존 앱 PID의 메모리나 모든 실행 경로를 검사한 것이 아니며 이 작업으로 런타임을 업데이트하거나 프로세스를 재시작하지 않았습니다. 공격 재현·전체 제품 보안 감사·실제 침해가 없었다는 검증과 구분합니다.

패치 완료 기록은 명령 한 줄보다 넓게 남깁니다

운영 기록에는 대상 서비스, 변경 전후 Node 버전, 이미지 digest, 프로세스 교체 시각, 정상 기능과 TLS/HTTP 시험 결과, 남은 예외를 묶습니다. 자신이 확인하지 않은 워커나 다른 서버까지 패치 완료로 넓혀 적지 않습니다.

아래 항목을 작업 기록에 복사해 실제 값으로 채울 수 있습니다. 확인일의 공식 수정 릴리스를 반영했더라도 이후 공지와 사용하는 배포판의 보안 안내는 계속 확인해야 합니다. 이 기록은 침해가 없었다는 증명서나 향후 안전 보장이 아닙니다.

• 대상 서비스 / 담당자 / 확인 시각:
• 영향 입력 경로와 아직 확인하지 못한 경로:
• 변경 전후 Node 버전 / builder와 runtime 버전:
• 커밋 / CI 실행 / 새 이미지 digest:
• 앱·워커의 교체 시점과 새 시작 확인:
• TLS·HTTP·일반 기능의 시험 결과:
• 남은 예외 / 다음 조치 / 복구 대상 이미지: