11월 11일, 지원 대상 및 지원 종료 버전에 대한 Node.js 보안 업데이트

주요 내용

• Node.js는 11월 11일 또는 그 직후에 22.x, 24.x, 26.x 버전에 대한 고위험 보안 패치를 적용할 예정입니다.
• Upstream은 지원 종료된 버전을 영향을 받는 버전으로 간주하지만, 이에 대한 수정 사항은 제공하지 않습니다.
• ELS for Runtimes는 지원되는 배포판 전반에 걸쳐 지원 종료된 8개의 Node.js 제품군에 대한 백포트 수정 사항을 준비 중입니다.
• 업데이트 후 모든 Node.js 애플리케이션을 다시 시작하고, 지원 종료된 기능의 역호환 적용 여부는 패키지 릴리스별로 확인해야 하며, node --version.

Node.js는 다음 보안 업데이트를 2026년 11월 11일 수요일 또는 그 직후에 출시할 예정입니다. 22.x, 24.x, 26.x 계열에 새로운 버전이 출시될 예정이며, 프로젝트 측은 각 계열에서 가장 심각한 문제를 ‘높음(High)’ 등급으로 평가하고 있습니다. CVE ID와 기술적 세부 사항은 업데이트가 출시될 때까지 공개되지 않으므로, 특정 공격 방법에 대한 조기 주장은 신중하게 받아들여야 합니다.

Node.js를 통해 실행하는 팀의 경우 alt-nodejs 패키지의 경우, 발표 내용만으로는 전체 이야기의 절반에 불과합니다. 여기에는 CloudLinux 호스팅 서버는 물론, TuxCare의 Node.js용 Endless Lifecycle Support(ELS)가 적용되는 Debian, Ubuntu, Alpine 및 Enterprise Linux 호스트도 포함됩니다. nodejs.org에 게시된 수정 사항만으로는 해당 시스템에서 실행 중인 어떤 것도 패치되지 않습니다. 수정 사항이 적용되려면 업데이트된 패키지를 빌드하고, 배포하고, 설치해야 하며, 실행 중인 애플리케이션을 재시작해야 합니다. 대부분의 준비 작업은 세부 사항이 공개되기 훨씬 전인 지금부터 진행할 수 있습니다.

상류 쪽의 수명 종료 라인은 패치할 수 없습니다

업스트림 릴리스는 22, 24, 26 버전에만 해당됩니다. Node.js 권고문에 따르면, 보안 릴리스가 발표될 때마다 지원 종료된 버전도 항상 영향을 받으며, 이는 업스트림에서 더 이상 해당 버전에 대한 수정 사항을 제공하지 않더라도 마찬가지입니다. 그렇다고 해서 모든 구버전에 새로 수정된 모든 버그가 포함된 것은 아니지만, Node.js 20, 18 또는 그 이전 버전을 실행 중인 시스템은 단순히 해당 버전이 릴리스 목록에 포함되지 않았다는 이유만으로 안전하다고 간주해서는 안 됩니다.

ELS for Runtimes는 바로 이러한 격차를 해소해 줍니다. TuxCare의 ELS 팀은 지원 종료된 8개 제품에 대한 백포트 수정 프로그램을 준비 중입니다. alt-nodejs lines, Node.js 10, 12, 14, 16, 18, 19, 20 및 23을 지원하므로, 구형 런타임에 고정된 애플리케이션도 긴급 마이그레이션 없이 패키지 업데이트를 통해 이번 릴리스의 수정 사항을 적용할 수 있습니다. 백포팅은 실질적인 엔지니어링 작업입니다. 수정 사항을 업스트림에서 더 이상 유지 관리하지 않는 코드에 맞게 조정해야 하기 때문입니다. 하지만 업스트림 릴리스 직후인 11월 11일에 다른 모든 릴리스와 함께 이 빌드들을 출시할 계획입니다. 이 ELS for Runtimes 설명서 각 운영 체제에서 지원되는 Node.js 버전을 나열합니다.

어떤 저장소에 수정된 빌드가 포함되어 있나요?

CloudLinux에서 Node.js Selector는 다음 환경에서 실행됩니다. alt-nodejs 패키지들, 그리고 Node.js 버전은 서버나 계정 단위가 아닌 애플리케이션별로 선택됩니다. 이 때문에 한 호스팅 서버에서 더 이상 업스트림에서 지원되지 않는 버전을 포함해 세 개나 네 개의 Node.js 버전이 동시에 실행되는 경우가 종종 있습니다.

마찬가지로 alt-nodejs ELS 고객을 위한 패키지 역시 TuxCare의 저장소를 통해 배포되며, Debian 10부터 13까지, Ubuntu 18.04부터 26.04까지, Alpine 3.23 및 3.24를 지원하며, Enterprise Linux용 TuxCare 서명 빌드도 포함됩니다. 이 패키지들은 다음 경로에 설치됩니다. /opt/alt/, 배포판에 이미 포함된 Node.js와 병행하여 설치하고, 평소와 같은 방법으로 업데이트하십시오. yum, apt또는 apk 워크플로우. Node.js 23 빌드는 Debian 12, Debian 13 및 Alpine에서만 제공됩니다.

업데이트된 패키지는 언제 제공될 예정인가요?

CloudLinux는 Node.js에서 수정 사항을 공개하는 대로 바로 빌드 작업을 시작할 계획이며, 업데이트된 버전을 출시할 것으로 예상하고 있습니다. alt-nodejs 같은 날 늦게 패키지가 배포됩니다. 여기에는 22, 24, 26 버전과 6부터 10까지 모든 CloudLinux 버전의 지원 종료 라인이 포함되며, TuxCare 저장소 빌드도 같은 실행 과정에서 함께 배포됩니다. 이 일정은 업스트림 릴리스 일정에 따라 달라지므로, 고정된 배포 시점이 아닌 목표일 뿐입니다.

CloudLinux 호스팅 서버에는 각각 고유한 업데이트 경로를 가진 두 가지 다른 Node.js 패키지 유형이 있습니다. CloudLinux 8을 실행하는 cPanel 서버에서는, ea-nodejs22 이 패키지도 CloudLinux 저장소에서 제공되지만, cPanel의 패키지를 기반으로 빌드됩니다. 이 문제를 해결하려면 먼저 cPanel에서 업데이트된 버전을 공개하고, 그 후에 CloudLinux에서 이에 맞는 패키지를 제공해야 합니다. 운영 체제의 기본 nodejs 패키지는 다시 별도의 경로를 통해, 일반적인 RHEL 및 AlmaLinux 기반 OS 업데이트를 통해 배포됩니다. 이러한 채널 외부에서 설치된 런타임은 별도로 확인해야 합니다. 왜냐하면 alt-nodejs 업데이트를 해도 그 부분은 건드리지 않습니다.

수요일까지 해두면 좋은 준비 작업

CloudLinux를 사용 중이신 경우, 해당 릴리스에 대한 CloudLinux 상태 페이지를 구독하시기 바랍니다. CloudLinux는 11월 10일 화요일 이른 시간에 예상 출시 시간(ETA)을 공지한 후, 패키지가 제공될 때까지 몇 시간 간격으로 진행 상황을 업데이트할 예정입니다. 다른 배포판을 사용하는 ELS 고객은 TuxCare의 ‘사용 가능한 Node.js 수정 사항’ 목록에서 수정된 빌드를 확인하실 수 있습니다.

다음으로, 설치된 패키지를 확인하세요. 호스트의 패키지 관리자(RPM, DEB 또는 APK)에 맞는 다음 명령어 중 하나를 실행하세요:

rpm -qa 'alt-nodejs*'
dpkg -l 'alt-nodejs*'
apk info | grep alt-nodejs

이는 어떤 버전이 설치되어 있는지만 보여줄 뿐, 어떤 애플리케이션이 해당 버전을 사용하는지는 보여주지 않습니다. CloudLinux에서는 각 애플리케이션에 할당된 버전을 확인하려면 Node.js Selector도 함께 확인하세요. 그 외의 환경에서는 systemd 유닛, PM2 구성 파일, 컨테이너 이미지 등이 각각 다른 바이너리를 가리킬 수 있으므로, 이 부분들도 함께 확인해야 합니다. 업데이트 기간 동안 한 개의 애플리케이션만 놓쳐도, 다른 모든 것이 최신 상태인 것처럼 보이는데도 해당 애플리케이션만 구버전 런타임을 계속 실행할 수 있습니다.

그런 다음 재시작을 계획해야 합니다. 패키지 업데이트만으로는 충분하지 않기 때문입니다. 업데이트된 패키지를 설치하면 디스크에 있는 바이너리가 교체되지만, 실행 중인 Node.js 애플리케이션은 패키지 관리자가 어떻게 표시하든 재시작할 때까지 계속해서 이전 버전을 사용합니다.

Node.js Selector를 통해 관리되는 애플리케이션은 해당 인터페이스에서 또는 다음 명령어를 사용하여 계정 이름과 애플리케이션 루트 경로를 지정해 재시작할 수 있습니다:

cloudlinux-selector restart --json --interpreter nodejs --user <user> --app-root <app_root>

Node.js Selector 외부에서 실행 중인 모든 프로세스는 해당 서비스가 일반적으로 관리되는 방식에 따라 다시 시작됩니다. 그 후, 실행 중인 모든 Node.js 프로세스가 시작 시간과 함께 나열되므로, 업데이트 전에 시작된 프로세스는 눈에 띄게 됩니다:

ps -eo pid,lstart,args | grep -E '[n]ode( |$)'

많은 애플리케이션을 호스팅하는 서버의 경우, 사전에 재시작 순서를 정해 두고 가동 중단 시간이 중요한 애플리케이션의 소유자와 협의를 진행해야 합니다. 릴리스 당일 밤에 서둘러 재시작하는 것보다, 계획에 따라 단계적으로 재시작하는 편이 더 낫습니다.

소포가 도착하면 어떻게 해야 할까요?

관련된 alt-nodejs 패키지가 출시되었으니, 평소 사용하는 패키지 관리 절차를 통해 이를 적용한 후 해당 애플리케이션들을 다시 시작하십시오. 그런 다음 각 앱이 정상적으로 다시 실행되었는지, 그리고 업데이트된 런타임을 사용하고 있는지 확인하십시오. 패키지 설치가 성공적으로 완료되었다고 해서 모든 애플리케이션이 수정 사항을 반영한 것은 아닙니다.

생애 주기 말기인 라인에는 한 가지 추가 확인이 필요합니다. 22, 24, 26 패키지는 새로운 업스트림 릴리스로 이동하므로, 예상대로 버전 번호가 변경됩니다. 백포트는 기존 버전 위에 수정 사항을 추가하는 방식으로 작동하므로, 업스트림 Node.js 버전은 그대로 유지되고 패키지 릴리스 번호만 변경됩니다. 해당 라인에서는, node --version 업데이트 전후로 외관상 차이가 없으므로, 설치된 패키지 릴리스를 CloudLinux나 TuxCare에서 공개한 수정된 빌드와 비교해 보시기 바랍니다. 버전 문자열만 비교하는 스캐너는 같은 문제로 인해 오류를 일으켜, 패치된 백포트를 취약점으로 표시할 수 있습니다.

Node.js 보안 권고문에는 해당 취약점에 대한 세부 정보와 수정된 업스트림 버전이 공개되는 대로 게재될 예정입니다. 한편, alt-nodejs 하지만 호스트의 경우, 실질적인 문제는 더 간단합니다. 업데이트된 패키지가 설치되었는지, 그리고 해당 앱이 재시작되었는지 확인하면 됩니다. 업스트림에서 남겨둔 줄들에 대해서는, 런타임용 ELS 지속적으로 수정 사항을 제공하므로, 마이그레이션은 자문 기관이 정한 일정이 아닌 팀이 직접 정한 일정에 따라 진행될 수 있습니다.

런타임용 ELS 다운로드 →

참조

Node.js, “2026년 11월 11일(수) 보안 업데이트”

CloudLinux 상태 페이지, “Node.js 보안 업데이트, 2026년 11월 11일”

TuxCare 문서