Node.js RCE 긴급 패치, 라인별 올릴 버전 정리
Node.js가 2026년 10월 21일 보안 릴리스로 Brotli 디코더 원격 코드 실행(CVE-2026-111497)을 포함한 10개 취약점을 수정했고, 22.x·24.x·26.x 전 활성 라인이 영향을 받는다. 설정으로 막을 우회책은 없고 패치가 유일한 대응이며, 현재 쓰는 메이저 라인을 유지한 채 각각 22.23.4, 24.22.1, 26.12.1로만 올리면 호환성 부담 없이 적용된다. 서버·컨테이너·CI의 node -v를 각각 확인하고, EOL 버전이거나 의존성 영향이 걱정되면 nodejs.org 공식 공지로 자기 라인의 정확한 패치 버전을 확인해야 한다.
먼저 내 서버 버전을 확인한다
2026년 10월 21일 Node.js가 보안 릴리스를 냈다. 가장 심각한 것은 Brotli 디코더의 경계 밖 쓰기 결함(CVE-2026-111497)으로, 원격 코드 실행까지 이어질 수 있는 고위험 취약점이다. 같은 릴리스에서 10개 CVE가 함께 수정됐다. 가장 먼저 할 일은 지금 돌아가는 Node 버전을 아는 것이다.
터미널에서 node -v를 실행한다. 중요한 점은 확인 대상이 한 곳이 아니라는 것이다. 개발 PC, 실제 운영 서버, 그리고 컨테이너 안의 Node는 각각 버전이 다를 수 있다. CI 파이프라인에서 쓰는 러너 버전도 따로 봐야 한다. 특히 도커를 쓴다면 컨테이너를 새로 빌드하기 전까지는 호스트에서 node -v를 아무리 쳐봐도 실제 배포본 버전이 바뀌지 않는다.
영향 범위를 오해하지 않기
Photo by Ilnur on Unsplash
이번 취약점은 특정 웹 프레임워크의 문제가 아니라 Node.js 본체의 문제다. 현재 지원되는 22.x, 24.x, 26.x 세 라인이 모두 영향을 받는다. 수명이 끝난(EOL) 구버전도 영향권이며, 이 경우 단순 패치가 아니라 지원 라인으로의 메이저 업그레이드가 필요하다.
Brotli 결함 외에 고위험으로 분류된 것이 세 개 더 있는데, 하나는 dns.resolve가 NUL 문자가 든 이름을 잘라내는 문제(CVE-2026-105482)이고, 둘은 TLS 인증서의 호스트네임 검증을 우회할 수 있는 결함(CVE-2026-105483, CVE-2026-106069)이다. 즉 코드 실행뿐 아니라 이름 해석과 TLS 신뢰 판단에도 영향이 걸쳐 있다. 공식 공지는 설정으로 막는 우회책이 없다고 밝혔다. 패치가 유일한 대응이다.
라인을 유지한 채 패치만 올린다
업데이트의 핵심 원칙은 메이저 버전을 바꾸지 않는 것이다. 지금 쓰는 라인을 그대로 두고 아래 패치 버전으로만 올리면 호환성 부담 없이 적용된다.
| 현재 라인 | 올려야 할 버전 |
|---|---|
| 22.x | 22.23.4 |
| 24.x | 24.22.1 |
| 26.x | 26.12.1 |
적용 순서는 환경에 따라 다르다. nvm으로 관리한다면 해당 버전을 설치하고 기본값으로 바꾼 뒤 재기동한다. 도커라면 베이스 이미지 태그를 패치 버전으로 고정해 이미지를 다시 빌드하고 재배포해야 한다. 2026년 10월 21일 이전에 빌드한 이미지는 태그가 그대로여도 취약한 Node가 들어 있다. 어느 경우든 운영에 바로 넣지 말고 스테이징에서 먼저 올린 뒤, 운영은 롤링이나 블루-그린 방식으로 교체하는 편이 안전하다.
배포 후 검증할 것
올렸다고 끝이 아니다. 교체된 환경에서 node -v로 버전이 실제로 바뀌었는지 확인한다. 그다음 애플리케이션이 정상 기동하는지 보고, 이번 수정과 직접 맞닿은 경로를 점검한다. 응답을 Brotli(br)로 압축하는 구간, 외부 서비스로의 TLS 연결, DNS 조회가 평소처럼 동작하는지 확인하면 된다. 이번 릴리스에는 OpenSSL, Undici, c-ares 같은 의존성 업데이트도 포함돼 있어, HTTPS 요청이나 HTTP 클라이언트 동작에서 미묘한 차이가 없는지 로그를 함께 살피는 것이 좋다.
공식 공지로 직접 확인할 부분
마지막으로, 다음 세 가지는 2차 보도가 아니라 nodejs.org의 공식 보안 공지에서 직접 확인하는 것이 안전하다. 첫째, 자기 라인에 맞는 정확한 패치 버전 번호다. 둘째, 지금 쓰는 버전이 이미 EOL인지 여부, 그리고 EOL이라면 어느 지원 라인으로 올려야 하는지다. 셋째, 함께 갱신된 의존성 목록이다. 현재까지 실제 환경에서의 악용 사례는 보고되지 않았지만, 원격 코드 실행이 가능한 결함인 만큼 보고가 없다는 사실에 기대어 적용을 미룰 이유는 되지 못한다.