Node.js 취약점 CVE-2026-111497의 수정이 포함된 최소 버전은 22.23.4·24.22.1·26.12.1이에요. 업데이트 여부를 판단할 때는 실제 서비스를 실행하는 Node.js를 확인해야 해요. 터미널의 버전, 서버 프로세스의 버전, 컨테이너 안의 버전이 서로 다를 수 있어요.
2026년 10월 27일 확인한 공식 공지를 기준으로 위험 버전과 환경별 점검 방법을 정리했어요. “npm 패키지를 갱신했는데 끝난 걸까?”, “Docker 이미지를 바꿨는데 서비스도 바뀌었을까?”를 확인할 때 사용할 수 있는 안내예요.
Node.js 위험 버전과 수정 버전 비교
10월 21일 Node.js 보안 릴리스에 Brotli 압축 해제 취약점 수정이 포함됐어요. 아래 표는 당시 공식 지원 중인 세 계열의 기준이에요. 운영 환경에서는 이 최소 버전뿐 아니라 이후에 나온 보안 업데이트도 확인해야 해요.
화면이 좁으면 표를 좌우로 밀어 나머지 열을 확인할 수 있어요.
| 계열 | 최소 수정 버전 | 수정 대상 |
|---|---|---|
| Node.js 22 | 22.23.4 | 22.23.4 미만의 22.x |
| Node.js 24 | 24.22.1 | 24.22.1 미만의 24.x |
| Node.js 26 | 26.12.1 | 26.12.1 미만의 26.x |
각 수정 내역은 22.23.4 릴리스, 24.22.1 릴리스, 26.12.1 릴리스에 명시돼 있어요. Linux 배포판이나 별도 지원 업체가 보안 수정을 적용한 패키지는 표의 숫자만으로 판정하지 말고 CVE 적용 내역을 함께 확인해야 해요.
20 이하와 21·23·25는 공식 지원이 끝난 계열이에요. 구버전은 취약한 Brotli 포함 여부와 공급사 패치 내역을 별도로 확인하고, 지원 계열로 옮길 계획을 세워야 해요.
확인일 기준 22·24는 LTS, 26은 Current로 표시돼 있어요. Node.js는 운영용 앱에 Active LTS 또는 Maintenance LTS 사용을 권고해요. 숫자가 가장 높은 계열로 무조건 바꾸기보다 공식 지원 상태와 앱의 호환성을 함께 확인하세요.
Node2Shell은 어떤 환경에서 문제가 되나요?
Node2Shell로 불리는 이번 문제의 CVE 번호는 CVE-2026-111497이에요. Node.js에 포함된 Brotli 디코더가 잘못된 압축 데이터를 처리하면서 메모리를 손상시킬 수 있고, 그 결과 프로세스 종료·메모리 정보 노출·원격 코드 실행으로 이어질 수 있어요. Node.js 공식 심각도는 High예요.
원격 공격 가능성을 판단하려면 패치되지 않은 디코더와 공격자가 조작한 압축 데이터가 그 디코더에 도달하는 경로를 함께 확인해야 해요. Node.js 설치 사실만으로 침해가 발생했다고 판단할 수는 없어요. 영향과 원인은 Node.js 10월 공식 보안 공지에서 확인할 수 있어요.
들어오는 웹 요청뿐 아니라 외부 서버의 응답을 자동으로 압축 해제하는 HTTP 클라이언트도 점검 대상이 될 수 있어요. 실제 분석을 공개한 Theori/Xint의 대응 안내는 이런 경로와 환경별 예외를 설명해요. 요청 한 종류를 차단했다고 모든 경로가 해결됐다고 보기는 어려워요.
터미널과 실제 서비스의 버전을 구분해서 확인해요
터미널에서 현재 선택된 Node.js 버전은 다음 명령으로 확인할 수 있어요. 공식 CLI 문서에 정의된 버전 출력 명령이에요.
node --version이 결과는 해당 명령으로 새로 실행한 Node.js의 버전이에요. PM2·systemd로 이미 실행 중인 앱이나 다른 컨테이너까지 같은 버전을 쓴다는 증거는 아니에요. 서비스 설정의 실행 파일 경로와 새로 시작한 프로세스의 버전을 함께 확인해야 해요.
개발 담당자는 서버 앱의 시작 로그에서 다음 두 값을 확인할 수 있어요. process.version은 그 프로세스의 Node.js 버전, process.execPath는 사용 중인 실행 파일 경로예요.
console.info({
nodeVersion: process.version,
executable: process.execPath
});이 코드는 서버에서 실행되는 앱에 맞춰 사용하는 내부 확인 예시예요. Node.js process 문서의 값을 이용하며, 결과는 관리자가 확인할 수 있는 로그에 남기세요. 진단용 공개 페이지를 만들 필요는 없어요.
서버·Docker·관리형 서비스는 확인 위치가 달라요
| 환경 | 확인할 대상 | 조치 후 확인할 근거 |
|---|---|---|
| 직접 관리하는 서버 | 서비스가 실행하는 Node.js 경로 | 패치 적용 뒤 다시 시작한 앱의 버전과 실행 파일 경로 |
| Docker | 현재 요청을 처리하는 컨테이너 | 수정된 기반 이미지로 재빌드·재배포한 기록과 컨테이너 내부 버전 |
| 관리형 배포 서비스 | 배포에 쓰인 런타임(실행 환경)과 현재 실행 중인 버전 | 공급사 CVE 공지, 새 배포 식별 정보, 실제 런타임 확인 결과 |
| 로컬 개발·빌드 환경 | 프로젝트와 자동 빌드 작업의 Node.js | 개발 도구·CI가 선택한 버전과 다음 빌드의 실행 기록 |
Docker 호스트에 설치한 Node.js를 바꿔도 컨테이너 안의 Node.js가 바뀌는 것은 아니에요. node:22-alpine처럼 태그 이름이 같더라도 실제 이미지가 달라질 수 있으므로, 수정된 기반 이미지로 다시 빌드하고 새 컨테이너를 배포한 뒤 내부 버전을 확인하세요. Docker의 이미지 빌드 권장 사항도 이미지 갱신과 재빌드를 구분해 설명해요.
같은 앱을 여러 서버나 컨테이너에서 운영한다면 한 곳의 결과로 전체 완료를 판단하지 마세요. 방문자 요청을 받는 모든 서버·컨테이너와 별도로 실행되는 작업용 프로세스도 같은 기준으로 확인해야 해요.
Brotli 버전 문자열만 보고 취약하다고 단정하지 마세요
Node.js 보안 릴리스는 Brotli 수정 코드를 반영하면서 기존 라이브러리 버전 문자열을 유지할 수 있어요. Theori/Xint가 확인한 공식 배포 예시에서는 수정된 Node.js 22.23.4의 Brotli 값이 1.1.0, 24.22.1·26.12.1의 값이 1.2.0으로 남아 있어요. 따라서 process.versions.brotli 숫자 하나만으로 패치 실패를 판단하면 안 돼요.
반대로 운영체제의 공유 Brotli 라이브러리를 사용하는 배포판 빌드는 Node.js 실행 파일만 확인해서는 부족해요. 담당자는 실제로 불러오는 디코더 패키지와 공급사의 보안 수정 기록까지 확인해야 해요. 이런 경우에는 “Node.js 버전이 높다”보다 “이 실행 환경에 CVE-2026-111497 수정이 포함됐다”는 근거가 필요해요.
업데이트 완료 기록에는 무엇을 남기면 좋을까요?
설치 명령이 성공한 기록과 실제 서비스에 반영된 기록을 함께 남기면, 빠뜨린 환경을 찾기 쉬워요. 다음 항목은 공식 버전 정보와 운영 상태를 연결하기 위한 점검용 목록이에요.
- 영향 범위: 해당 Node.js를 사용하는 서비스·서버·컨테이너·작업 프로세스 목록
- 수정 근거: Node.js 릴리스 또는 공급사 패키지의 CVE 적용 내역
- 배포 근거: 변경 시각과 실행 파일·이미지·배포 식별 정보
- 실행 확인: 다시 시작한 각 앱의 Node.js 버전과 실행 경로
- 기능 확인: 로그인, API, 외부 HTTP 연동, 예약 작업 등 실제 서비스 기능의 결과
백업과 테스트를 준비하고 서비스의 배포 절차에 맞춰 업데이트하세요. 침해 흔적이 의심된다면 일반적인 재시작 순서와 구분해 보안 담당자와 격리·증거 보존을 먼저 협의해야 해요.
업데이트할 때 자주 헷갈리는 질문
npm update를 실행하면 Node.js도 바뀌나요?
npm update는 프로젝트의 패키지를 갱신하는 명령이에요. Node.js 런타임의 보안 업데이트는 사용하는 설치·배포 방식에 따라 별도로 진행해야 해요. 패키지 동작 범위는 npm 공식 문서에서 확인할 수 있어요.
직접 Brotli 압축 해제 코드를 쓰지 않으면 괜찮나요?
앱에 포함된 라이브러리가 자동으로 압축을 해제할 수 있어요. 코드에서 Brotli라는 단어가 보이지 않더라도 실제 요청·응답 처리 경로와 디코더의 패치 여부를 함께 확인하세요.
표의 버전으로 올리면 이번 보안 점검은 끝인가요?
해당 취약점의 수정 포함 여부와 서비스 반영까지 확인해야 해요. 같은 10월 보안 릴리스에는 DNS·TLS 등 다른 문제의 수정도 포함돼 있으므로 전체 릴리스 내용을 확인하고, 이후 보안 공지도 이어서 점검하세요.
출처와 확인일
원문 확인일: 2026년 10월 27일. 위험 버전과 지원 상태는 본문에 연결한 공식 자료를 기준으로 정리했으며, 실제 배포 전에는 후속 수정이 나왔는지 다시 확인해야 해요.