PHP 이어 노드.js에서도 고위험 취약점 발견…보안업계 대응 분주

웹사이트와 서버 개발에 널리 쓰이는 소프트웨어에서 고위험 보안 취약점이 잇따라 발견되면서 국내외 보안기업들이 대응에 나서고 있다. 프로그래밍 언어 PHP에서는 두 건의 취약점의 긴급 보안 패치가 배포된 지 이틀 만에 세 번째 원격코드실행(RCE) 취약점이 또 확인됐다. 자바스크립트 실행 환경인 노드.js(Node.js)에서도 서버에서 임의의 코드를 실행할 수 있는 ‘Node2Shell’ 취약점이 발견돼 긴급 패치가 배포됐다.

보안업계는 기업이 운영하는 서버와 내부 시스템에서 취약한 소프트웨어를 찾아내고, 공식 보안 패치를 적용하는 것이 중요하다고 강조한다. 이를 위해 국내 보안기업들은 취약점 진단 도구와 공격 차단 규칙 등을 공개하고 있다. 패치를 즉시 적용하기 어려운 경우에는 취약한 기능을 비활성화하거나 악성 요청을 차단하는 임시 조치를 적용하고, 이후 취약점이 해결됐는지 점검해야 한다는 설명이다.

PHP, 긴급 패치 이틀 만에 세 번째 취약점 발견 

PHP 개발팀은 지난 23일 새로운 원격코드실행 취약점 ‘CVE-2026-115560’을 공개했다. 이번 취약점은 웹사이트 이용자의 로그인 상태 등을 유지하는 세션 데이터를 처리하는 과정에서 발생한다.

앞서 PHP는 21일 ‘PHP2Shell’로 불리는 취약점 2건(CVE-2026-109618·CVE-2026-109619)을 수정하기 위해 긴급 보안 업데이트를 배포했다. 두 취약점은 공통 취약점 평가체계(CVSS) 4.0 기준 각각 9.2점으로, 최고 위험 등급인 ‘치명적(Critical)’으로 분류됐다.

PHP는 당시 취약점을 수정한 8.5.12, 8.4.27, 8.3.36, 8.2.35 버전을 배포했다. 그러나 추가로 확인된 세 번째 취약점은 기존 긴급 패치로 해결되지 않는다.

다만 실제 공격이 가능한 조건은 제한적이다. PHP가 세션 데이터를 저장하는 방식을 ‘php_binary’ 또는 ‘php_serialize’로 설정한 뒤 프로그램 실행 과정에서 ‘php’ 방식으로 변경해야 한다. 여기에 파일 업로드 진행 상태를 관리하는 기능도 활성화돼 있어야 한다.

PHP 개발팀은 이러한 설정 조합이 실제 운영 환경에서 드물다고 판단했다. 이에 별도의 긴급 패치 대신 차기 정기 업데이트에서 취약점을 수정하기로 했다.

패치가 배포되기 전까지는 ‘session.upload_progress.enabled’ 값을 ‘0’으로 변경해 파일 업로드 진행 상태 관리 기능을 비활성화하도록 권고했다. 앞서 PHP2Shell 대응 과정에서 해당 설정을 적용하고 유지했다면 추가 조치는 필요하지 않다.

노드.js도 원격코드실행 취약점 발견, 21일 보안 패치

노드.js에서도 원격코드실행 취약점 ‘Node2Shell(CVE-2026-111497)’이 확인됐다. 노드.js는 자바스크립트를 웹브라우저 밖에서 실행하도록 지원하는 환경이다. 웹서버와 온라인 서비스의 뒷단 시스템을 개발하는 데 사용한다.

노드.js(Node.js) 측에 따르면, 이번 취약점은 데이터를 압축하고 해제하는 ‘브로틀리(Brotli)’ 모듈에서 발생한다. 브로틀리는 웹서비스에서 주고받는 데이터의 크기를 줄여 전송 효율을 높이는 압축 기술이다.

공격자가 조작한 브로틀리 압축 데이터를 서버에 전달하면 압축 해제 과정에서 메모리의 허용 범위를 벗어난 영역에 데이터가 기록될 수 있다. 이로 인해 서버가 비정상 종료되거나 메모리 정보가 노출될 수 있다. 특정 조건에서는 원격코드실행으로 이어질 가능성도 있다.

개발자가 직접 압축 해제 기능을 구현하지 않았더라도 취약점에 노출될 수 있다. 서버가 사용하는 외부 라이브러리나 웹 개발 도구가 공격자의 브로틀리 압축 데이터를 자동으로 해제하는 경우다.

노드.js 프로젝트는 지난 21일 취약점을 수정한 22.23.4, 24.22.1, 26.12.1 버전을 배포했다. 공식 보안 공지는 이번 취약점의 위험도를 ‘높음(High)’으로 분류했다. 기업과 기관은 운영 중인 노드.js 버전과 압축 데이터 처리 경로를 확인하고 보안 업데이트를 적용해야 한다.

취약 자산 파악부터 공격 차단까지, 보안업계 대응 확대

국내 보안기업들은 PHP와 노드.js 취약점에 대응하기 위한 진단 도구와 공격 차단 방안을 잇달아 공개하고 있다. 주요 대응 방법은 기업이 운영하는 취약 시스템을 찾아내고 실제 공격 가능성을 점검한 뒤 보안 패치나 임시 차단 조치를 적용하는 것이다.

우선은 기업이 운영하는 PHP와 노드.js 기반 시스템을 먼저 파악해야 한다. 외부에 공개된 웹사이트 뿐 아니라 사내 업무시스템과 관리용 서버도 점검 대상이다. 직접 개발하지 않은 소프트웨어나 외부 라이브러리에 취약한 기능이 포함돼 있는지도 확인해야 한다.

이러한 점검을 위해 엔키화이트햇과 파이오링크, 스틸리언 등 보안 기업들은 PHP2Shell 취약 여부를 확인하는 진단 도구와 서비스를 공개하고 나섰다. 로그프레소는 기존 보안관제 플랫폼에서 외부 웹사이트와 내부망의 PHP 기반 시스템을 점검하고 패치 이후에도 취약점 조치 여부를 재확인할 수 있도록 지원한다.

취약한 시스템을 발견했다면 공격에 노출될 가능성을 확인하고 보안 패치도 적용해야 한다. 다만 운영 중인 서비스는 업데이트 과정에서 호환성 문제가 발생하거나 일시적인 중단이 필요할 수 있다. 패치를 즉시 적용하기 어려운 경우에는 공격에 악용될 수 있는 기능을 비활성화하거나 외부에서 전달되는 악성 요청을 차단하는 임시 조치를 검토해야 한다.

에버스핀은 PHP2Shell 공격을 차단하는 보안 규칙을 고객사에 적용했다. 해외에서는 클라우드플레어도 웹방화벽(WAF)을 통한 공격 차단 규칙을 배포했다.

노드.js 취약점과 관련해서는 티오리가 Node2Shell의 공격 가능성을 재현하고 압축 데이터가 처리되는 경로를 점검하도록 권고했다. 패치가 어려운 기업을 위한 임시 차단 방안과 온라인 점검 서비스도 공개했다.

다만 대응 방법은 취약점별로 적용 범위가 다르다. 기존 PHP2Shell 취약점 2건을 대상으로 개발한 진단 도구나 차단 규칙이 새로 발견된 세 번째 취약점까지 대응하는지는 별도로 확인이 필요하다. 클라우드플레어는 세 번째 취약점에 대해서도 기존 웹방화벽 규칙이 알려진 공격 시도를 차단할 수 있다고 설명했지만, PHP의 기본 파일 업로드 진행 상태 매개변수 이름을 변경한 경우에는 해당 규칙이 적용되지 않는다고 밝혔다.

기업은 공식 보안 패치를 우선 적용하고 업데이트 이후에도 취약점이 남아 있는지 재점검해야 한다. 공격 차단 규칙이나 임시 설정 변경만으로 모든 위험이 사라지는 것은 아니다. 기존에 공격이 발생했는지 확인하려면 서버 접속 기록과 이상 징후 등을 추가로 분석해야 한다.

글. 바이라인네트워크
<곽중희 기자>god8889@byline.network