LX 통합 웹 보안 서비스(WAF)

PHP2Shell · Node2Shell 노출 점검 도구를 공개합니다

2026년 10월, 웹을 떠받치는 두 런타임에서 인증 없이 원격 코드 실행으로 이어질 수 있는 취약점이 연달아 공개됐습니다.

PHP의 PHP2Shell(CVE-2026-109618, CVE-2026-109619)과 Node.js의 Node2Shell(CVE-2026-111497)입니다.

URL만 넣으면 해당 서버가 조치 대상인지 1차로 분류해 드립니다.

무엇이 문제인가

PHP2Shell (CVE-2026-109618, CVE-2026-109619)

두 건 모두 CVSS v4.0 기준 9.2(심각)로 평가됐고, PHP 보안 권고는 두 건을 하나의 코어 수정으로 함께 처리했습니다.

• CVE-2026-109618 — 요청 데이터가 일부만 초기화된 상태에서 메모리가 부족해지면, 요청 정리 과정이 잘못된 데이터를 정상으로 취급할 수 있습니다.
• CVE-2026-109619 — 한 요청이 쓰던 전역 상태가 해제된 뒤에도 워커에 남아, 같은 워커가 처리하는 다음 요청이 그것을 다시 쓰게 됩니다. 기본값으로 켜져 있는 session.upload_progress가 확인된 경로 중 하나입니다.

가장 위험한 구성은 Apache mod_php입니다. 애플리케이션 코드가 실행되기도 전에 공격이 성립할 수 있습니다. PHP-FPM, php-cgi를 비롯해 웹 요청을 처리하는 모든 설치본이 영향 범위에 들어갑니다.

Node2Shell (CVE-2026-111497)

Node.js의 Brotli 디코더에서 발생하는 경계 밖 쓰기입니다. Node.js 공식 권고는 이 결함이 원격 코드 실행을 허용한다고 명시하고 있으며, 심각도는 High로 평가됐습니다.

압축 해제 대상이 외부에서 들어온 데이터라면 영향권입니다. 인바운드 요청 본문을 Brotli로 받는 경우뿐 아니라, 애플리케이션이 외부 응답을 압축 해제하는 경로도 함께 살펴야 합니다.

공식 수정 버전

PHP 8.1 이하와 Node.js 20 이하는 공식 수정 릴리스가 없습니다. PHP의 경우 8.1·8.0·7.4에 대해 소스 백포트가 공개됐고 일부 배포판이 자체 패키지를 제공합니다. 그 외에는 지원되는 버전으로 올리는 것이 유일한 해결책입니다.

점검 도구는 어떻게 동작하나

판단에 쓰는 신호는 이렇습니다.

• X-Powered-By, Server 헤더에 적힌 런타임과 버전
• PHPSESSID, connect.sid, JSESSIONID 같은 세션 쿠키
• Express가 기본으로 내보내는 404 응답 본문
• 노출된 phpinfo() 페이지의 버전 표기

루트 응답에 버전이 없으면 /index.php와 존재하지 않는 경로를 한 번씩만 더 확인합니다. 404 오류 페이지에 런타임 배너가 남아 있는 경우가 흔하기 때문입니다.

판정은 다섯 가지

"확인필요"를 따로 둔 이유

Debian, Ubuntu, RHEL 같은 배포판은 업스트림 버전 번호를 그대로 둔 채 보안 수정만 반영합니다. 그래서 PHP 8.2.26을 쓰는 서버가 이미 패치된 상태일 수 있습니다. 버전만 보고 "취약"이라고 단정하면 멀쩡한 서버를 취약하다고 말하게 됩니다.

도구는 응답의 Server: Apache/2.4.62 (Debian) 같은 배포판 표기나 PHP/8.2.26-1~deb12u1 같은 패키지 접미사를 읽어, 이런 경우를 "취약"이 아니라 "확인필요"로 분리합니다. 다만 지원 종료 브랜치는 백포트가 있어도 업그레이드 대상이므로 "취약"을 유지합니다.

원격으로 확정할 수 없을 때 — 서버에서 확정 확인

원격 점검에는 넘을 수 없는 선이 있습니다. Node.js는 버전을 응답에 싣지 않고, 배포판 백포트는 버전 번호로 구분되지 않습니다. 이것을 알아내려고 비정상 요청을 보내는 것은 공격이므로 하지 않습니다.

대신 서버에 작은 파일 하나를 올리는 방식을 준비했습니다. 점검 페이지에서 대상 주소를 넣으면 그 호스트에만 유효한 토큰과 명령 한 줄을 줍니다.

mkdir -p .well-known && node -p "JSON.stringify({token:'<토큰>',node:process.version})" > .well-known/hlml-vulncheck.txt

https://대상/.well-known/hlml-vulncheck.txt 로 열리면 "확인"을 누릅니다. 도구가 그 파일을 읽어 실제 실행 중인 버전으로 확정 판정을 내립니다. 웹 루트에 파일을 쓸 수 있는 사람만 할 수 있는 작업이라 소유권 확인도 겸합니다. 토큰은 24시간 동안 유효하고 발급받은 호스트에서만 통과하므로, 남의 서버를 대신 확인할 수는 없습니다. PHP 서버용 명령도 함께 제공합니다.

한계 — 반드시 함께 읽어 주세요

점검 결과를 그대로 최종 결론으로 쓰면 안 되는 이유가 있습니다.

1. 배포판 백포트는 원격으로 확정할 수 없습니다

"확인필요" 판정으로 오탐은 크게 줄였지만, 배포판이 실제로 패치를 반영했는지는 원격에서 알 수 없습니다. 서버에서 패키지 정보(dpkg -l, rpm -q)와 벤더 보안 공지를 확인하거나, "서버에서 확정 확인"을 쓰세요. 또한 배포판 표기를 숨긴 서버는 이 분리가 적용되지 않아 "취약"으로 나올 수 있습니다.

2. Node.js는 버전을 거의 노출하지 않습니다

PHP는 X-Powered-By에 버전을 적는 경우가 많지만, Node.js와 Express는 버전을 응답에 싣지 않습니다. 그래서 Node 서버는 원격 점검만으로는 대부분 "위험"으로 분류됩니다. 이는 취약하다는 뜻이 아니라 원격에서는 판단할 수 없다는 뜻입니다.

3. 응답 헤더는 중간 장비가 바꿉니다

프록시, WAF, CDN이 헤더를 지우거나 다른 값으로 바꿔 둘 수 있습니다. 도구는 CF-Ray, Via, X-Cache 같은 헤더로 앞단에 CDN이 있다는 사실은 탐지해 판정 근거에 표시하지만, 그 뒤의 원본 서버를 들여다볼 수는 없습니다.

4. 앞단과 뒷단이 다를 수 있습니다

Tomcat 같은 Java 서블릿 컨테이너로 식별되면 이 두 취약점의 직접 대상은 아니라고 표시합니다. 다만 그것이 앞단일 뿐이고 뒤에 PHP나 Node 백엔드가 있을 수 있으니, 해당 경로를 따로 넣어 점검해야 합니다.

5. 악용 가능 여부를 증명하지 않습니다

이 도구는 버전과 설정에 근거한 노출 여부 분류입니다. 실제로 공격이 성립하는지는 확인하지 않습니다.

확실하게 확인하는 방법

원격 점검에서 "위험"이나 "확인불가"가 나왔다면, 서버에서 직접 보는 것이 가장 정확합니다.

# PHP — 웹에서 쓰는 설정까지 보려면 웹 경로의 phpinfo() 출력이 가장 정확합니다
php -v

# Node.js
node -v

컨테이너로 운영 중이라면 호스트가 아니라 실제 서비스가 쓰는 이미지 안에서 확인해야 합니다.

개인정보와 안전장치

• 입력한 주소와 점검 결과를 서버에 저장하지 않습니다.
• 사설·루프백·링크로컬·예약 대역(IPv4·IPv6)은 점검하지 않습니다. 리다이렉트를 따라갈 때마다 다시 검사합니다.
• 점검 권한 확인에 동의해야 실행됩니다. 본인이 관리하거나 점검 권한을 받은 대상만 입력해 주세요.
• 한 번에 최대 10개까지, IP당 요청 빈도를 제한합니다.

지금 해야 할 일

1. 운영 중인 PHP·Node.js 버전을 확인합니다.
2. 수정 버전 미만이면 지원되는 최신 버전으로 갱신합니다.
3. 갱신 후 프로세스를 재시작하고 실행 중인 버전을 다시 확인합니다.
4. 인터넷에 노출된 서버가 공개 이후 상당 기간 미패치 상태였다면, 패치만으로는 이미 설치된 것이 사라지지 않으므로 침해 여부를 별도로 점검하세요.

출처

• PHP 보안 권고: php.net
• Node.js 2026년 10월 보안 릴리스: nodejs.org