Node.js 쓰는 회사라면 오늘 확인할 것, 10월 보안 릴리스 HIGH 4건 Node.js 프로젝트가 10월 21일 보안 릴리스를 배포했다. 26.x, 24.x, 22.x 세 라인이 나란히 새 버전을 받았고 수정 버전은 26.12.1, 24.22.1, 22.23.4다. 이번 릴리스의 최고 심각도는 HIGH로, HIGH 4건에 MEDIUM 3건, LOW 3건을 더해 모두 10건이 한꺼번에 나왔다. 라인 성격도 갈리는데 26.x는 아직 LTS가 아닌 Current 라인이고, 24.x와 22.x는 LTS 라인이다. 왜 급한지부터 짚으면, Brotli 디코더의 경계 밖 쓰기로 원격 코드 실행을 허용할 수 있는 건이 있고, TLS 인증서 호스트명 검증을 우회하는 건이 두 건, dns.resolve가 NUL 문자를 포함한 이름을 중간에서 잘라 버리는 건이 있기 때문이다. 다만 공식 자료에 실제 악용 여부는 명시돼 있지 않다. 확인된 것은 취약점과 영향 조건이지, 실제 침해가 관측됐다는 얘기가 아니다. HIGH 4건도 조건이 제각각이다. CVE-2026-111497(Brotli)은 zlib로 Brotli 압축을 푸는 코드를 직접 쓰는 경우만이 아니다. 서버가 받은 fetch 응답을 br 인코딩으로 디코딩하는 경로도 해당될 수 있다. 요청 헤더의 Accept-Encoding을 손보는 정도로는 해결이 안 되는데, 패치 대상이 애플리케이션 설정이 아니라 디코더 자체이기 때문이다. CVE-2026-105483은 IP를 전각 숫자로 쓰면 TLS 인증서 호스트명 검증을 우회할 수 있는 건으로, 26.x와 24.x만 해당하고, 공식 공지의 이 CVE 영향 라인에는 22.x가 포함되지 않는다. CVE-2026-106069는 호스트가 느슨하게 IP로 해석될 때 같은 검증이 우회되는 건으로 세 라인 공통이다. CVE-2026-105482(DNS 절단)도 세 라인 공통인데, dns.resolve에 외부에서 들어온 이름이 닿는 서비스일수록 먼저 볼 건이다. 나머지도 조건을 달고 봐야 한다. Permission Model 관련 두 건(CVE-2026-106071은 26.x만, CVE-2026-106073은 세 라인)은 그 기능을 실제로 켜서 쓰는 경우의 얘기다. 이 취약점들을 OS 권한 상승으로 설명해서는 안 된다. Node 공식 문서도 Permission Model은 악성 코드를 안전하게 가두기 위한 보안 샌드박스가 아니라고 명시한다. CVE-2026-106074(엔트로피 캐시)는 모든 randomUUID 호출이 같은 값을 뱉는다는 얘기가 아니라, 사용자 startup snapshot이나 SEA에 난수 캐시가 저장돼 재사용되는 조건에서 생기는 문제다. CVE-2026-106070(ZipFile)은 26.x만 해당한다. CVE-2026-105481은 keep-alive 연결에서 요청을 보내기 전에 쓰인 응답을 소켓이 처리할 수 있는 문제라, keep-alive로 외부 서비스와 연결을 오래 유지하는 워크로드에서 볼 건이다. CVE-2026-106072는 비정규 형식의 IPv4 호스트명에서 인증서 검증이 부적절해 DNS SAN으로 IP 엔드포인트가 인증될 수 있는 문제라, IP 주소로 직접 TLS 접속하는 코드가 있으면 확인할 건이다. 엔진 릴리스에는 내장 의존성 업데이트도 함께 실렸는데 c-ares와 Undici, 인증서 묶음(ca-cert, eMudhra 중간 CA 침해 대응)은 세 라인, OpenSSL은 24.x와 22.x, SQLite는 22.x에 포함됐다. 지원 종료 라인 얘기도 빼놓을 수 없다. 지원 종료 버전이 이번 수정판 목록에 없다고 안전한 것은 아니다. 개별 CVE 적용 여부와 공급자 백포트·지원 증빙을 확인하고, 정규 지원 라인으로 이전 계획을 세워야 한다. Node 20은 2026년 4월 30일, Node 18은 2025년 4월 30일에 이미 지원이 끝났고 23과 25도 종료된 라인이다. 아직 많이 쓰이는 라인이 이미 지원 종료인 경우가 실제로 있어서, 점검 목록에 넣어야 한다. 기업 점검은 이 순서로 가면 된다. 1. 실제 서비스 프로세스가 쓰는 런타임부터 확인한다. 셸에서 친 node -v는 그 셸의 버전일 뿐이라, 실행 중인 프로세스의 process.version이나 process.versions.node, process.execPath로 잡아야 한다. 소스의 engines와 .nvmrc, 잠금파일, CI 러너가 쓰는 버전은 따로 적어 둔다. 적어 놓고 보면 서로 다른 경우가 적지 않다. 2. 실행 형태와 설치 경로를 식별한다. 컨테이너인지 서버리스인지 호스팅인지 직접 실행인지, 공식 바이너리인지 OS 패키지인지 버전 매니저로 깔았는지에 따라 업데이트 방식이 갈린다. 3. 컨테이너는 실행 중인 이미지의 digest를 확인하고 새 이미지로 교체한다. docker build --no-cache는 빌드 캐시를 안 쓸 뿐 새 base 이미지를 당겨오는 옵션이 아니라서, --pull로 새 이미지를 받았는지 따로 봐야 한다. 문제가 생겼을 때 돌아갈 롤백 이미지의 digest도 같이 확인해 둔다. 4. 서버리스는 공급자 증빙으로 확인한다. Lambda의 nodejs24.x 같은 런타임 식별자는 메이저 라인만 알려 줄 뿐 패치 버전까지 보장하지 않는다. 공급자가 어떤 버전을 언제부터 순차 배포했는지를 문서와 공지로 대조한다. 5. 데스크톱 앱과 내장 런타임은 별도로 본다. Electron에 내장된 Node는 OS에 설치된 Node를 올려도 바뀌지 않으니, 앱 자체의 업데이트를 확인한다. 6. 지원 종료 라인을 쓰는지 확인한다. 종료된 라인이 이번 수정판 목록에 없다고 안전하다고 보지 말고, 개별 CVE 적용 여부와 공급자 백포트·지원 증빙을 확인하고 정규 지원 라인으로의 이전 계획을 세운다. 7. 의존성 점검은 엔진 점검과 분리한다. npm audit는 설치된 패키지에서 알려진 취약점을 찾는 검사이지, Node 엔진 자체가 안전한지를 보증하지 않는다. 8. 업데이트한 뒤에는 재빌드와 재배포를 마치고, 모든 워크로드가 실제로 재시작됐는지 확인한다. 오래 떠 있는 프로세스는 옛 런타임을 계속 물고 있다. startup snapshot이나 SEA로 산출물을 만드는 프로젝트는 그 산출물의 재생성도 이 단계에서 검토한다. 이번 엔트로피 캐시 건이 바로 그 경로의 문제다. 9. 로그인, 결제, 외부 API로의 TLS 호출 같은 핵심 기능 회귀 테스트로 마친다. 침해가 의심되면 증거 보존·격리 등 사고 대응을 패치와 함께 계획한다. 패치만으로 기존 침해가 제거되는 것은 아니다. 결국 모든 Node 서비스가 같은 피해를 본 것은 아니다. 라인이 무엇인지, 어떤 기능을 실제로 쓰는지, 어디서 어떻게 도는지에 따라 갈린다. 오늘 안에 답할 첫 질문은 "우리 서비스는 어떤 런타임으로, 어디서 돌고 있나"다. 공식 공지: nodejs.org/en/blog/vulnerabi… 참고 원문: 릴리스 v26.12.1 nodejs.org/en/blog/release/v… · v24.22.1 nodejs.org/en/blog/release/v… · v22.23.4 nodejs.org/en/blog/release/v… · 프로세스 확인 nodejs.org/api/process.html · Permission Model nodejs.org/api/permissions.h… · npm audit docs.npmjs.com/cli/commands/… · 지원 일정 github.com/nodejs/Release/bl… · Docker 빌드 docs.docker.com/build/buildi… · Lambda 런타임 docs.aws.amazon.com/lambda/l… · Electron 보안 electronjs.org/docs/latest/t… 나는 퍼즈, AI 알려주는 개구리. 최신 AI 정보가 궁금하면 팔로우.

PHP 쓰는 회사라면 오늘 확인할 것, 미인증 원격 코드 실행 2건 PHP 프로젝트가 10월 21일 보안 공지를 냈다. 인증 없이 원격에서 코드를 실행할 수 있는 취약점 2건이 한꺼번에 공개됐고, 두 건 모두 CVSS v4.0 기준 9.2다. 수정 버전은 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35. 왜 급한가부터 짚으면, 위험 대상이 웹 요청을 받는 PHP 설치 전반인데다 mod_php 환경에서는 애플리케이션 코드가 실행되기도 전에 공격이 트리거되는 실증이 이미 나왔기 때문이다. 다만 이건 연구 과정에서 확인된 실증이고, 실제 침해가 관측됐다는 얘기와는 구분해서 봐야 한다. 공식 공지에 실제 침해가 관측됐다는 발표는 없다. 두 취약점은 결이 다르다. CVE-2026-109618은 메모리 부족(OOM) 처리 과정에서 생기는 문제다. 요청 데이터가 반쯤 초기화된 상태에서 처리가 중단되면, 정리 과정이 무효한 데이터를 유효한 것으로 취급할 수 있다. 공식 자문 기준으로 완전한 원격 코드 실행이 실증된 환경은 Apache mod_php이고, PHP-FPM은 소스 분석상 취약할 수 있는 것으로 평가되지만 완전한 익스플로잇은 아직 실증되지 않았다. FrankenPHP는 mod_php와 구조가 비슷해 취약 가능성이 거론되고, LiteSpeed(LSAPI)는 미검증 상태다. CVE-2026-109619는 해제된 메모리를 가리키는 전역 상태가 남는 문제다. 같은 워커가 다음 요청을 처리할 때 초기화보다 먼저 그 낡은 상태를 건드릴 수 있다. 이쪽은 세션 업로드 진행률(session upload progress) 경로의 코드 실행이 mod_php와 PHP-FPM 양쪽에서 실증됐고, PHP 8.5의 fatal_error_backtraces 경로는 mod_php에서 실증됐다. 두 요청이 같은 워커에 닿아야 한다는 조건이 붙지만, 워커가 많다고 조건 자체가 사라지지는 않는다. 두 취약점으로 얻는 코드 실행 권한은 PHP를 돌리는 웹 워커 프로세스(Apache·FPM 워커)의 권한이다. 그 자체로 자동적인 root 권한 획득은 아니다. 1차 영향 범위는 그 워커가 읽고 쓸 수 있는 파일과 설정, 세션, 업로드, 접근 가능한 데이터부터 잡아야 하고, 그 이상의 권한 상승 여부는 환경마다 별개로 갈린다. 즉 같은 공지 안에서도 어떤 SAPI로 돌리느냐, 어떤 설정이 켜져 있느냐에 따라 확인된 위험의 수준이 다르다. "PHP니까 전부 똑같이 위험하다"로 뭉뚱그리면 점검이 빗나간다. 기업 점검은 이 순서로 가면 된다. 1. 실제 서비스 중인 웹 런타임 버전부터 확인한다. 서버에 로그인해서 친 php -v는 CLI 버전일 뿐이라, FPM이나 mod_php가 실제로 쓰는 버전과 다를 수 있다. 웹 런타임 기준으로 다시 확인해야 한다. 자산 목록에는 외주 운영 서버와 컨테이너 이미지도 포함한다. 호스트에 PHP가 안 보여도 이미지 안에 런타임이 있을 수 있다. 확인은 OS·SAPI·FPM 풀 단위로 나눠서, 로드된 ini 파일과 설정값, 확장(extension) 버전까지 함께 기록한다. 2. SAPI를 식별한다. PHP-FPM인지, Apache mod_php인지, CGI인지, FrankenPHP나 LiteSpeed인지에 따라 위에서 본 대로 실증 범위와 우선순위가 갈린다. 3. 배포판 패키지를 쓰는 환경이면 벤더 공지를 확인한다. 배포판은 보안 패치를 백포트하는 경우가 많아서, 버전 번호 문자열만 보고 "낮으니 취약하다" 또는 "높으니 안전하다"고 판단하면 틀린다. 판정은 패키지 버전 번호가 아니라 전체 릴리스(릴리스 문자열과 패키지 변경 이력)와 벤더의 CVE 대응 공지를 대조해서 한다. 백포트는 버전을 유지한 채 보안 수정만 이식하는 방식이라 번호만으로는 알 수 없다. 주요 배포판과 LTS 벤더는 패치를 사전 제공받았다고 공지에 명시돼 있다. 참고로 remirepo는 이번 업데이트가 오늘 나오지 않는다고 공지가 못 박았으니, 거기에 의존하는 환경은 배포판 패키지나 소스 빌드 전환을 검토할 차례다. 4. CMS와 플러그인, 의존성 목록을 뽑는다. 본체만 패치하고 방치된 플러그인이 남아 있으면 점검했다고 보기 어렵다. PHP 8.1 이하는 PHP 프로젝트의 정규 보안 지원이 종료된 버전이다. 다만 이번 건에는 예외가 있어서, 보안팀이 7.4·8.0·8.1용 최소 소스 백포트를 따로 제공했다. 배포판과 LTS 벤더마다 이번 CVE를 제공하는 범위와 방식이 다르니, "지원이 끊겼으니 이번 패치가 없다"고 단정하면 틀린다. 쓰는 배포판·벤더가 이번 대응을 제공하는지, 소스 빌드 환경이면 예외 백포트를 적용할 수 있는지를 확인하고, 정규 경로는 지원되는 버전으로 올리는 것으로 잡는다. 8.2도 2026년 12월 31일에 지원이 끝난다는 점은 일정에 넣어둘 만하다. 공개된 phpinfo 페이지가 남아 있지 않은지도 본다. phpinfo는 버전·경로·설정값에 환경변수까지 출력하므로 방치 자체가 정보 노출이다. composer audit는 설치된 패키지의 알려진 취약점 점검이지 PHP 엔진 자체의 안전 보증이 아니니, 엔진 점검과 분리해서 본다. 5. 침해 징후를 본다. 웹 워커 계정으로 도는 낯선 프로세스나 새로 생긴 파일, 워커의 반복적인 비정상 종료 같은 흔적이 점검 대상이다. 다만 공식 자문도 짚듯이, 로그에 오류가 없다고 안전한 것은 아니다. 이상 징후는 확정된 침해 지표가 아니다. 의심이 가면 패치 전에 증거부터 보존하고, 침해 대응은 별도 절차로 분리한다. 패치는 취약점을 막을 뿐, 이미 들어온 침해를 제거하지는 않는다. 6. 패치를 적용한다. 순서는 위에서 확인한 런타임과 SAPI 기준으로, 운영 환경 전체에 빠짐없이. 7. 패치 후에는 PHP-FPM과 Apache 워커를 전부 재시작한다. 바이너리만 교체하고 재시작을 빠뜨리면, 메모리에 올라간 옛 코드가 계속 요청을 받는다. 8. 재시작 뒤에는 런타임 버전과 핵심 설정이 실제로 반영됐는지 다시 확인하고, 로그인·파일 업로드·세션·DB 연결 같은 핵심 기능의 회귀 테스트까지 마친다. 파일만 바뀌고 서비스에 안 붙은 패치는 없는 셈이다. 지금 당장 패치가 어렵다면 임시 완화는 있다. 단, 공식 입장은 분명하다. 완전한 완화책은 없고, 안전한 선택은 업데이트뿐이다. 109618 쪽에서는 memory_limit=-1 설정이 거론되는데, 이건 애플리케이션이 덮을 수 없는 위치, 예를 들어 FPM 풀이나 Apache 설정의 php_admin_value로 걸고, 다른 설정이 유한한 제한을 되살리지 않는지까지 확인했을 때의 얘기다. 메모리를 무제한으로 풀면 그 자체로 가용성 위험이 생기니 컨테이너나 cgroup 제한을 종료 경계로 함께 두는 것이 공식 권고에 가깝고, 그렇더라도 근본적인 할당 실패가 나면 취약 경로에 닿을 수 있다. RLIMIT_AS나 RLIMIT_DATA로 대신하는 것은 오히려 취약한 실패를 유발할 수 있어 금지다. post_max_size를 낮추는 것(업로드가 없으면 8M, 필요하면 32M, upload_max_filesize는 그보다 작게)도 같은 맥락의 임시 조치다. 109619 쪽에서는 session.upload_progress.enabled=0을 php.ini나 FPM 풀처럼 요청 파싱 전에 적용되는 위치에 설정하고 모든 워커를 재시작하는 방법이 있다. ini_set()이나 .user.ini에 기대면 안 되고, 이 조치가 막는 것도 확인된 세션 경로뿐이라 다른 변형까지 막아주지는 않는다. PHP 8.5라면 fatal_error_backtraces=0도 같은 방식으로, 다만 이것도 확인된 경로 하나를 막을 뿐이다. 결국 완화는 시간을 버는 조치일 뿐이고, 결론은 패치 일정부터 잡는 것이다. 우리 회사가 PHP로 뭘 돌리고 있는지, 그 런타임이 정확히 몇 버전 어떤 SAPI인지, 오늘 안에 답할 수 있는지가 첫 번째 점검이다. 공식 공지: php.net/archive/2026.php#202… 나는 퍼즈, AI 알려주는 개구리. 최신 AI 정보가 궁금하면 팔로우.