Node.js, 원격 코드 실행 취약점 등을 고친 보안 수정판 공개

웹 서비스에서 Node.js가 쓰이는 자리는 크게 둘입니다. 서버에서 API 요청에 답하거나, 배포 전에 웹사이트 파일을 만드는 빌드 도구로 돕니다. 가상의 안내 사이트를 예로 들면, 개발자가 Node.js로 페이지를 HTML 파일로 미리 만들고 배포 서버는 완성된 파일만 보냅니다. 방문자가 페이지를 열 때는 Node.js가 돌지 않지만, 파일을 만드는 빌드 환경에는 Node.js가 있습니다.

날씨를 보여 주는 가상의 서비스를 생각해 봅시다. 내 Node.js 서버가 외부 날씨 제공 서버에 자료를 요청하고, 돌아온 압축 자료를 풀어 기온을 화면에 표시합니다. Brotli는 웹에서 데이터를 작게 보내려고 쓰는 압축 형식이고, 받은 자료를 다시 읽을 수 있게 푸는 기능도 Node.js에 들어 있습니다. Node.js 공식 문서에도 외부 HTTP 응답을 받아 Brotli로 푸는 예제가 나옵니다. 공식 압축 응답 처리 예제

평소에는 기온 자료가 들어옵니다. 그런데 공격자가 그 응답의 내용을 조작할 수 있고, 조작한 자료가 수정 전 Node.js의 취약한 압축 해제 처리까지 도달한다면 공격의 입구가 생깁니다. 여기서 공격자가 보내는 것은 처음부터 정상적으로 실행해 달라고 맡긴 프로그램이 아니라, 앱이 읽으려던 자료입니다.

어떤 서비스가 이 경로를 갖는지는 구현에 따라 다릅니다. 올린 파일을 Brotli로 푸는 기능, 외부의 압축된 응답을 읽는 기능, 빌드 중 외부 자료를 받아 푸는 작업을 찾아보는 이유입니다. 모든 파일 업로드나 모든 HTTP 요청이 곧바로 이 결함을 실행하는 것은 아닙니다.

메모리는 프로그램이 일하는 동안 자료를 잠깐 놓아 두는 공간입니다. 압축을 푸는 코드는 정해진 칸 안에 결과를 써야 하는데, 이번 결함은 그 칸 밖에까지 쓰는 문제입니다. 이를 범위 밖 쓰기라고 합니다. Node.js 공지는 CVE-2026-111497이 원격 코드 실행(RCE)으로 이어질 수 있다고 명시했습니다. 공식 보안 공지

작업대에 ‘받은 자료를 정리하는 칸’과 ‘작업에 필요한 다른 메모’가 있다고 생각해 보세요. 자료를 자기 칸에만 적으면 문제가 없지만, 옆 칸까지 덮어쓰면 그 메모를 믿고 일하던 프로그램도 잘못 움직일 수 있습니다. 실제 메모리에는 데이터뿐 아니라 실행을 이어 가는 데 쓰이는 정보도 있고, 그런 정보의 손상이 특정 조건에서 공격자가 원하는 코드 실행으로 이어질 수 있습니다. MITRE의 범위 밖 쓰기 설명

그래서 위험은 ‘날씨 숫자가 틀리게 보인다’에서 끝나지 않을 수 있습니다. 원래 맡긴 일은 자료 읽기인데, 결함을 악용하면 그 프로그램이 공격자가 원하는 다른 일까지 하게 될 수 있다는 뜻입니다. 단순히 큰 자료를 받거나 메모리가 부족해지는 모든 상황이 RCE가 되는 것은 아니며, 이 글은 실제 공격 입력이나 성공 조건을 재현하지 않았습니다.

RCE가 성립하면 공격 코드는 보통 뚫린 프로그램의 권한으로 움직입니다. Node.js가 읽을 수 있는 파일·비밀 정보, 쓸 수 있는 파일, 접속할 수 있는 데이터베이스가 피해 범위를 좌우합니다. 서버의 최고 관리자 권한이나 같은 회사의 다른 서버 권한까지 자동으로 얻는다는 뜻은 아닙니다.

아래는 가능한 피해를 이해하기 위한 시나리오입니다. 이번 취약점으로 특정 서비스에서 이런 피해가 발생했다는 보도나 실험 결과가 아닙니다.

가상의 서버 A가 v24.22.0을 쓴다고 해 봅시다. 계열은 24.x로 같아도 이번 수정판은 24.22.1이라서, 서버 A는 아직 수정 전입니다.

리눅스 배포판이나 관리형 호스팅은 수정 내용을 자기 패키지에 옮겨 담기도 합니다. 이를 백포트라고 합니다. 이 경우 버전 번호만으로는 판단이 어려우니, 공급자의 패키지 개정 번호와 보안 수정 이력을 함께 봅니다.

npm은 앱이 가져다 쓰는 패키지를 관리하는 도구입니다. 이번 수정은 Node.js 본체와 그 안에 든 부품에 있어서, npm update로 앱의 패키지를 올려도 해결되지 않습니다. Node.js 실행 파일이나 그것을 담은 컨테이너 이미지를 바꿔야 합니다.

• Node.js가 도는 서버·컨테이너·빌드 환경을 목록으로 적습니다.
• 각 환경의 수정 패키지를 구하고 앱 호환성을 시험합니다.
• 실행 파일이나 이미지를 교체하고 필요한 재시작·재배포를 합니다.
• 실행 중인 버전과 실제 주요 기능을 다시 대조합니다.

마지막 점검에서는 로그인, API 응답, 외부 HTTPS 통신, 압축된 응답 처리처럼 이번 수정과 맞닿은 기능을 한 번씩 돌려 봅니다.