쇼핑몰이나 회사 웹사이트가 멀쩡하게 열리더라도, 뒤에서 돌아가는 Node.js가 오래된 버전이라면 지금은 서버를 살펴볼 때입니다. 2026년 10월 발견된 Node.js 보안 취약점은 공격자가 조작한 압축 데이터를 서버가 처리할 때 메모리 손상이나 원격 코드 실행으로 이어질 수 있습니다. 다만 Node.js를 사용한다는 이유만으로 모든 사이트가 곧바로 뚫리는 상황은 아니죠. 실제 실행 버전과 압축 해제 경로를 확인하고 패치된 런타임으로 다시 배포하는 게 먼저입니다.
Node.js 보안 취약점이 웹사이트에 위험한 이유
Node.js 프로젝트는 2026년 10월 21일 보안 공지에서 CVE-2026-111497을 공개했습니다. Node.js에 포함된 Brotli 압축 해제기에서 잘못된 압축 입력이 내부 메모리 경계를 넘어 쓰이는 문제가 발견된 겁니다. Brotli는 데이터를 작게 압축해 주고받을 때 사용하는 기술인데, 이번에는 압축을 푸는 과정이 공격 경로가 될 수 있다고 합니다.
악의적으로 만든 Brotli 데이터가 애플리케이션의 node:zlib 압축 해제 기능에 전달되면 서버 프로세스가 비정상 종료되거나 메모리 정보가 노출되고, 조건에 따라 원격 코드가 실행될 수 있습니다. 공식 프로젝트는 심각도를 ‘높음’으로 분류했으며, 싱가포르 사이버보안청은 CVSS 9.8점을 안내했어요. Node.js 공식 보안 공지에 기술적 조건이 명시돼 있습니다.
저는 ‘인증 없이 서버를 장악할 수 있다’는 문구보다 어떤 데이터가 어디서 풀리는지가 더 눈에 들어왔습니다. 외부인이 직접 업로드한 압축 데이터뿐 아니라, 서버가 외부에서 가져온 압축 응답을 처리하는 흐름도 점검해야 하거든요. 오늘 바로 점검할 항목을 고르면 사이트 첫 화면보다는 실제 서비스 프로세스와 데이터 흐름입니다.
영향받는 Node.js 버전과 안전한 패치 버전
보안 수정판은 2026년 10월 21일 공개됐습니다. 공식 지원 계열인 22.x, 24.x, 26.x에서 아래 버전보다 낮은 릴리스를 쓰고 있다면 보안 업데이트 대상입니다. 숫자가 비슷해 보여도 마지막 패치 번호 하나가 달라지는 경우가 있어 정확히 비교해야 합니다.
| 사용 중인 계열 | 영향받는 버전 | 수정된 버전 |
|---|---|---|
| Node.js 22.x | 22.23.4 미만 | 22.23.4 이상 |
| Node.js 24.x | 24.22.1 미만 | 24.22.1 이상 |
| Node.js 26.x | 26.12.1 미만 | 26.12.1 이상 |
22·24·26이 아닌 오래된 지원 종료 계열은 ‘표에 없으니 안전하다’고 판단하면 곤란해요. Node.js 프로젝트는 지원 종료 버전을 보안 릴리스 때 위험 대상으로 간주하라고 안내합니다. 특히 20.x를 계속 유지하는 환경은 지원되는 LTS 계열로 이전을 계획해야 합니다.
이번 릴리스에는 Brotli 문제 외에도 DNS 호스트명 처리, TLS 인증서 검증 등의 수정이 함께 포함됐습니다. 그러니 임시 설정 하나로 Brotli 위험만 줄인 뒤 업데이트를 미루는 선택은 아쉽습니다. 설치 파일과 지원 계열은 Node.js 공식 다운로드 페이지에서 선택할 수 있습니다.
우리 웹사이트가 실제 공격 대상인지 구별하는 기준
영향받는 Node.js 버전을 쓴다고 해서 외부에서 보내는 모든 요청이 자동으로 공격에 성공하는 것은 아닙니다. 중요한 조건은 공격자가 제어하는 Brotli 압축 데이터가 해당 애플리케이션이나 의존 라이브러리에서 실제로 해제되는지입니다. 예를 들어 압축된 요청 본문을 받아 푸는 처리, 신뢰할 수 없는 주소의 파일이나 API 응답을 가져와 푸는 처리가 점검 대상이에요.
다음 항목을 코드와 서비스 구성도에서 함께 살펴보면 좋겠습니다. 요청을 거르는 웹 방화벽이 있어도 서버가 외부 API에서 내려받은 압축 응답까지 검사해 주지는 않으니까요. 이 부분은 겉보기에는 정상인 서비스에서도 빠뜨리기 쉬운 지점입니다.
- 외부 파일 업로드 또는 요청 본문에서 Brotli 데이터를 해제하는 코드가 있는가
zlib.brotliDecompress와 관련 스트림 함수, 이를 감싼 라이브러리를 사용하는가- 서버가 이용자 지정 URL이나 외부 API로 요청한 뒤 압축된 응답을 받아 처리하는가
- 개발용 Node.js와 실제 트래픽을 받는 프로덕션 런타임의 버전이 다른가
이 점검은 패치 우선순위를 정하는 데 유용하지만, 코드에서 특정 함수가 발견되지 않았다고 안전 판정을 내리기는 어렵습니다. 의존 패키지나 실행환경 내부의 처리 경로가 남아 있을 수 있거든요. 노출 여부를 완전히 분석하기 전이라도 지원되는 보안 버전 적용이 기본 대응입니다.
Node.js 서버 버전 확인과 긴급 업데이트 순서
Node.js 보안 취약점 대응에서 가장 먼저 할 일은 배포 서버에서 실제 실행 중인 버전을 확인하는 겁니다. 터미널에서 node -v를 입력하면 설치된 실행 파일 버전이 보이고, process.version은 현재 Node.js 프로세스의 버전을 알려 줍니다. 개발자 개인 노트북에서 나온 숫자로 운영 서버까지 안전하다고 생각하는 실수가 꽤 걱정스럽네요.
- 운영 중인 모든 인스턴스와 서버리스 함수, 컨테이너의 런타임 버전을 목록으로 적습니다.
- 배포 설정과 백업을 확보하고 지원되는 22.23.4, 24.22.1, 26.12.1 또는 그 이후 보안 릴리스를 선택합니다.
- 검증 환경에서 의존 패키지 호환성, 로그인, 결제, 업로드, 외부 API 연결을 확인합니다.
- 새 버전으로 재시작하거나 새 이미지를 재배포하고, 실제 요청을 받는 프로세스의 버전을 다시 읽습니다.
- 오류율과 서버 로그를 비교해 정상 동작을 확인하고 문제 발생 시 복구할 절차를 준비합니다.
npm audit를 실행해 취약한 패키지를 찾는 일도 좋습니다. 하지만 이번 문제는 Node.js 실행환경에 포함된 구성 요소의 결함이므로, 패키지 감사 결과가 깨끗해도 런타임 교체를 대신해 주지 못해요. 운영자가 바쁜 날일수록 ‘점검 완료’ 체크보다 배포된 실행 파일 확인이 더 믿음직합니다.
Docker와 Next.js 및 Vercel에서 놓치는 재배포
Docker로 운영한다면 호스트에 새 Node.js를 설치하는 것만으로 기존 컨테이너 안의 런타임이 바뀌지는 않습니다. 수정된 Node.js 기반 이미지를 선택해 이미지를 다시 빌드하고 배포해야 하죠. 기존 컨테이너를 단순 재시작한 뒤 패치했다고 생각하면 위험이 그대로 남을 수 있습니다.
Next.js를 직접 서버에 올린 경우에도 사용 중인 Node.js 런타임을 먼저 교체하는 게 핵심입니다. 프레임워크나 npm 패키지만 업데이트하고 실제 실행 서버 버전을 그대로 두는 사례는 피하고 싶습니다. 빌드 서버, 배포 서버, 백그라운드 작업자처럼 서로 다른 환경도 함께 목록에 넣으세요.
Vercel의 2026년 10월 보안 안내에는 관리형 22.x·24.x 런타임의 패치 버전을 플랫폼이 관리하지만, 20.x 프로젝트는 지원 계열로 변경 후 재배포해야 한다고 설명돼 있습니다. 외부에 별도로 운영하는 백엔드나 직접 만든 컨테이너 이미지는 운영자가 업데이트해야 합니다. 웹 방화벽은 알려진 요청 패턴을 막는 데 도움을 주지만, 서버가 직접 가져오는 외부 응답에는 같은 보호가 적용되지 않을 수 있습니다. 자세한 환경별 범위는 Vercel 보안 안내에 나와 있습니다.
보안 패치 뒤에도 필요한 로그 점검과 임시 방어
이미 취약한 버전으로 서비스를 운영했다면 패치가 곧 과거 공격 흔적을 지워 주는 것은 아닙니다. 저는 여기서 한 번 더 확인하는 편을 권합니다. 예상하지 못한 프로세스 종료, 비정상적인 압축 데이터 요청, 갑작스러운 외부 통신, 서버 계정이나 환경 변수 접근 흔적을 점검해 보세요.
업데이트 전에는 신뢰할 수 없는 Brotli 압축 데이터를 해제하는 경로를 일시 제한하고, 필요하다면 관련 기능을 임시 중단하는 대응을 검토할 수 있습니다. 압축 처리량과 입력 크기를 제한하고 외부 접근을 축소하는 조치도 피해 범위를 낮추는 보조 수단입니다. 다만 이런 우회 조치가 메모리 손상 결함을 수정하는 패치와 같지는 않아요.
- 패치 시각과 이전 실행 버전, 배포 이력을 남겨 둡니다.
- 의심스러운 로그가 있다면 삭제하지 말고 보존해 침해 여부를 조사합니다.
- 이상 징후가 확인되면 서버를 격리하고 자격 증명 교체 및 침해 대응 절차를 검토합니다.
- 관련 보안 공지를 추적하며 향후 보안 업데이트를 운영 일정에 반영합니다.
한국인터넷진흥원도 2026년 10월 23일 Node.js 제품의 보안 업데이트를 권고했습니다. 운영자가 신고나 상담이 필요할 때는 보호나라의 118 안내를 이용할 수 있어요. 속보 제목에 놀라기보다 내 서비스가 실제 어떤 버전과 어떤 데이터 경로로 움직이는지 파악하는 것이 결국 가장 빠른 대응이라고 생각합니다.
자주 묻는 질문
Q. Node.js를 사용한 웹사이트는 모두 해킹된 건가요?
아닙니다. 취약한 버전과 공격자가 제어하는 Brotli 데이터의 압축 해제 조건이 맞아야 문제가 발생할 수 있습니다. 취약점 공개 자체는 침해 사고 발생의 증거가 아니지만 업데이트 우선순위는 높습니다.
Q. Node.js 20.x라면 어떻게 하나요?
20.x는 지원이 종료된 계열입니다. 지원 중인 LTS 계열로 이전하고 애플리케이션 호환성을 검사한 뒤 재배포하는 쪽이 안전합니다.
Q. npm audit 결과가 깨끗하면 패치를 생략해도 되나요?
아니요. 이번 Brotli 결함은 Node.js 런타임에 포함된 구성 요소와 관련돼 있어 패키지 감사만으로 해결 여부를 알 수 없습니다. 실제 프로세스의 Node.js 버전을 확인해야 합니다.
Q. 방화벽이나 CDN을 이용하면 충분할까요?
알려진 공격 요청을 차단하는 데 도움은 되지만 서버가 외부에서 받은 응답을 압축 해제하는 경로까지 모두 보호하지는 못합니다. 방화벽은 추가 방어 수단으로 쓰고 패치와 재배포를 우선하는 편이 좋겠습니다.
출처와 참고한 곳
- Node.js 프로젝트 공식 보안 공지 — 2026년 10월 취약점 원인, 영향 범위, 수정 릴리스 확인
- KISA 보호나라 — 국내 보안 업데이트 권고와 상담 안내 확인
- 싱가포르 사이버보안청 — CVE-2026-111497 평가 점수와 악용 조건 확인
- Vercel 보안 공지 — 관리형 런타임과 컨테이너·외부 백엔드 대응 차이 확인
함께 읽으면 좋은 글
- VoiceStudio 무료 음성 복제 설치와 일레븐랩스 구독료 비교
- 스레드 자동화툴 사기 전, 에고·어사이드·업리카 비교
- AI 영상 제작 도구 20선, 코딩·3D·애니메이션 상황별 조합
