내 서버, PHP2Shell·HTTP2Shell에 안전한가요?
인증 없이 원격 코드 실행이 가능한 두 건의 치명적 취약점입니다 — PHP의 PHP2Shell, Brotli 압축 해제 라이브러리의 HTTP2Shell(Node.js·Python·Bun·Envoy 등). 사이트 주소만 넣으면 공격 요청 없이 어느 쪽에 해당하는지 확인해 드립니다.
PHP2Shell이 뭔가요? — 쉽게 이해하기
2026년 10월, PHP 코어에서 로그인(인증) 없이 누구나 원격으로 서버에 명령을 실행할 수 있는 두 건의 치명적 취약점(CVE-2026-109618·CVE-2026-109619)이 공개됐습니다. 개별 사이트의 코드 문제가 아니라 PHP 자체의 결함이라, PHP로 돌아가는 모든 웹사이트가 대상입니다. KISA와 미국 CISA가 즉시 업데이트를 권고했고, 공개 전부터 실제 공격 시도가 관측됐습니다.
HTTPS가 집으로 오가는 길에 자물쇠를 채워 ‘엿보기’를 막는 보안문이라면, PHP2Shell은 집(서버)을 움직이는 프로그램 자체에 난 구멍입니다. 공격자는 열쇠(로그인) 없이 그 구멍으로 바로 들어와, 집 안의 물건(데이터)을 가져가거나 집을 통째로 조종할 수 있습니다. 보안문이 아무리 튼튼해도, 벽에 구멍이 있으면 소용이 없습니다.
HTTP2Shell이 뭔가요? — Brotli 압축 해제 라이브러리의 결함 (구 Node2Shell)
2026년 10월 공개된 이 취약점은 처음에 Node.js 내장 디코더 문제로 알려져 ‘Node2Shell’로 불렸습니다. 그런데 결함이 Google이 만든 Brotli 압축 해제 라이브러리 자체에 있어, 같은 라이브러리를 쓰는 Bun·Python·Envoy·Istio·curl 등으로 영향이 넓어지면서 지금은 HTTP2Shell로 부릅니다. 별개의 새 취약점이 아니라 같은 CVE입니다.
수정 버전은 아래 05 · 어떤 버전을 써야 안전한가요?에 정리했습니다.
HTTP 를 쓴다는 이유만으로 모두 해당하는 것은 아닙니다. 외부에서 온 데이터를 취약한 디코더로 압축 해제하는지가 판단 기준입니다.
코드에서 brotli 를 직접 설치하거나 불러오지 않아도, 다른 패키지가 함께 설치하면 requests 등이 자동으로 사용합니다. 10월 23일 기준 pip-audit·Dependabot·Safety 가 이 취약점을 잡지 못하는 상태였으므로, 실제 설치된 패키지와 전체 의존성을 확인하세요.
PHP2Shell 이 집을 움직이는 프로그램(PHP)에 난 구멍이라면, HTTP2Shell 은 ‘압축된 소포를 자동으로 뜯는 기계’의 결함입니다. 같은 기계가 Node.js·Python·Envoy 등 여러 회사의 공장에 똑같이 들어가 있어, 바깥에서 온 소포를 뜯기만 해도 어느 공장이든 터질 수 있습니다.
- 들어오는 요청: 압축을 풀기 전 단계(프록시·미들웨어)에서 Content-Encoding: br 요청을 거부합니다.
- 외부 응답: HTTP 클라이언트의 Brotli 자동 해제를 끄거나, 본문을 처리하기 전에 차단합니다.
- 요청의 Accept-Encoding 에서 br 만 빼는 것으로는 부족합니다 — 악성 서버는 이를 무시하고 Brotli 로 응답할 수 있습니다.
- CDN·웹서버의 응답 압축을 끄는 것과 앱의 압축 해제 경로를 막는 것은 별개입니다. gzip·deflate 는 그대로 써도 됩니다.
- 임시 대응은 시간을 버는 것일 뿐입니다 — 영향받는 구성 요소를 반드시 수정 버전으로 올리세요.
서버 내부 라이브러리 버전은 겉으로 거의 드러나지 않아 이 점검기에서는 대개 ‘확인 필요’로 나옵니다. Node.js·Bun 버전이나 Envoy 사용이 응답에서 보이면 함께 표시합니다.
HTTPS가 있으면 괜찮지 않나요? — 보호하는 곳이 다릅니다
HTTPS(자물쇠)는 데이터가 오가는 ‘길’을 암호화해 중간에서 못 엿보게 합니다. PHP2Shell·HTTP2Shell은 데이터가 도착하는 ‘서버 엔진’(PHP·Node.js)의 결함입니다. 보호하는 계층이 서로 달라, HTTPS를 쓰고 있어도 두 취약점 모두 막지 못합니다. 둘 다 갖춰야 합니다.
공격당하면 무슨 일이 생기나요?
공격의 대부분은 사람이 하나씩 고르는 게 아니라, 자동화된 봇이 인터넷 주소를 쉼 없이 훑으며 ‘패치 안 된 버전’을 찾아 무차별로 시도합니다. 규모·업종·유명세와 무관하게, 취약한 상태로 열려 있으면 차례가 옵니다. 공개된 취약점일수록 봇의 표적 목록 맨 앞에 오릅니다 — 공개 시점부터 패치까지의 하루하루가 가장 위험합니다.
진료·건강 정보는 개인정보보호법상 민감정보로 분류돼, 유출 시 피해가 크고 정보주체 통지·관계기관 신고 의무가 따릅니다. 예약·전자차트 같은 서버가 멈추면 진료 자체가 지연되고, 한 번 잃은 환자 신뢰는 되돌리기 어렵습니다. 그래서 의료기관은 ‘해당되면 즉시 패치’가 선택이 아니라 필수입니다.
어떤 버전을 써야 안전한가요?
| PHP 브랜치 | 취약 범위 | 안전한 버전 |
|---|---|---|
| PHP 8.5 | 8.5.12 미만 | 8.5.12 이상 |
| PHP 8.4 | 8.4.27 미만 | 8.4.27 이상 |
| PHP 8.3 | 8.3.36 미만 | 8.3.36 이상 |
| PHP 8.2 | 8.2.35 미만 | 8.2.35 이상 |
| PHP 8.1 이하 | 전부 해당 | 지원 종료 — 상위 버전으로 전환 |
지원이 종료된 PHP 8.1 이하는 패치가 제공되지 않으므로, 지원되는 상위 버전으로 올려야 합니다.
| 대상 | 수정 버전(이상) |
|---|---|
| Node.js | 22.23.4 · 24.22.1 · 26.12.1 (20 이하는 지원 종료 — 현행 LTS로) |
| Bun | 1.4.4 |
| Google Brotli · libbrotli | 1.2.1 (이전 계열 1.0.10 · 1.1.1) |
| Python brotli | 1.2.1 |
| Python brotlicffi | 1.2.1.0 |
| Envoy Proxy | 1.40.0 · 1.39.3 · 1.38.6 · 1.37.8 |
| Istio | 1.30.6 · 1.31.2 |
| curl / libcurl 등 | 연결된 Brotli 라이브러리 또는 배포판 보안 패키지 업데이트 |
Envoy 1.36.12·Istio 1.29.9 에도 수정이 들어갔지만 지원 종료 계열입니다. Linux 배포판은 버전 번호를 그대로 둔 채 수정만 넣을 수 있으니 배포판 보안 공지를 확인하고, 라이브러리를 내장하거나 정적으로 연결한 프로그램·컨테이너는 다시 빌드해야 합니다.
PHP 프레임워크·게시판이 지원 종료됐다면? (심화 진단)
PHP 버전을 숨겨도 안심할 수 없습니다. 쓰고 있는 PHP 프레임워크·게시판이 더 이상 유지보수되지 않으면, 보통 옛 PHP에서만 돌고 새 보안 패치를 받지 못합니다. 그래서 이 점검기는 겉으로 드러난 흔적으로 기반 기술을 찾아, 지원이 끝난 것이면 위험으로 표시합니다.
PHP 버전이 보이지 않아도, 위 ‘지원 종료’에 해당하는 프레임워크·게시판이 발견되면 점검 결과를 위험 높음으로 표시합니다. 버전은 겉으로 드러난 흔적 기준이므로, 정확한 버전과 패치 여부는 서버에서 확인하세요.
보안 패치 방법 (상세)
패치가 유일한 완전 해결책입니다. 운영 환경에 맞는 방법으로 지원되는 최신 버전으로 올리세요. 서버를 직접 운영하는 경우 아래 명령을 참고하되, 업데이트 전 백업과 스테이징 확인을 권장합니다.
# 현재 버전 확인 php -v # 보안 업데이트 적용 (예: PHP 8.3) sudo apt update sudo apt install --only-upgrade php8.3 php8.3-cli php8.3-fpm php8.3-common # 최신 패치가 apt 에 없으면 ondrej PPA 사용 # sudo add-apt-repository ppa:ondrej/php && sudo apt update # 적용 후 재시작 (FPM 또는 Apache 내장) sudo systemctl restart php8.3-fpm # Nginx + PHP-FPM sudo systemctl restart apache2 # Apache mod_php 인 경우 # 확인 php -v && php-fpm8.3 -v
php -v # 배포판 기본 모듈 sudo dnf update php php-cli php-fpm php-common # Remi 저장소를 쓰는 경우 # sudo dnf update php sudo systemctl restart php-fpm sudo systemctl restart httpd # Apache 인 경우 php -v
# WHM 관리자 WHM → Software → EasyApache 4 → 현재 프로필에서 PHP 패키지 업데이트 WHM → MultiPHP Manager → 계정별 PHP 버전을 지원되는 최신으로 변경 # 또는 커맨드라인(루트) /scripts/check_cpanel_rpms yum update ea-php83-*
서버에 직접 접근할 수 없는 공유 호스팅입니다. 1) 호스팅사 관리 화면 → 'PHP 버전 설정'에서 지원되는 최신 버전(8.2 이상)으로 변경 2) 호스팅사 보안 공지에서 PHP2Shell 패치 적용 여부 확인 3) 버전 변경 후 사이트가 정상 동작하는지 확인 (오래된 코드는 상위 PHP 에서 오류가 날 수 있음)
# 베이스 이미지 태그를 최신 패치로 올린다 # 예: FROM php:8.3-fpm → 최신 8.3.x 패치 포함 이미지 재취득 docker pull php:8.3-fpm docker compose build --pull && docker compose up -d docker compose exec app php -v
# 현재 버전 확인 node -v bun --version # Node.js: nvm 이면 현행 LTS 최신으로 (또는 NodeSource apt 로 22.x 최신) nvm install 22 --lts && nvm alias default 22 # Bun bun upgrade # 1.4.4 이상인지 확인 # 적용 후 앱 재시작 (pm2 또는 systemd) — 재시작해야 반영됩니다 pm2 restart all # 또는: sudo systemctl restart <서비스명>
# 실제로 설치돼 있는지부터 — 직접 쓰지 않아도 다른 패키지가 깔았을 수 있습니다 pip show brotli brotlicffi # 설치돼 있다면 수정 버전으로 pip install -U "brotli>=1.2.1" "brotlicffi>=1.2.1.0" # 잠금 파일(requirements·poetry.lock 등)도 갱신하고, 컨테이너는 다시 빌드·재배포
# Ubuntu · Debian — 배포판 보안 업데이트로 libbrotli 갱신 sudo apt-get update && sudo apt-get install --only-upgrade libbrotli1 # (배포판은 버전 번호를 유지한 채 수정만 넣을 수 있음 — 보안 공지 확인) # Docker — 베이스 이미지를 새로 받아 다시 빌드 docker compose build --pull && docker compose up -d # Envoy · Istio — 1.37.8 / 1.38.6 / 1.39.3 / 1.40.0, Istio 1.30.6 / 1.31.2 이상으로
- 같은 브랜치 내 패치(예: 8.3.x) 업데이트는 보통 호환성 문제가 적습니다. 가능한 한 쓰던 브랜치의 최신 패치로 먼저 올리세요.
- 메이저·마이너 업그레이드(8.1→8.3 등)는 확장 모듈·코드 호환성 점검이 필요합니다. 스테이징에서 먼저 확인하세요.
- 지원이 종료된 PHP·프레임워크는 패치가 없으므로 현행 버전으로 이전(마이그레이션)이 필요합니다.
- HTTP2Shell은 Node.js 만의 문제가 아닙니다 — Python brotli·Bun·배포판 libbrotli·Envoy 까지 쓰는 곳을 모두 올리고, 업데이트 후 앱 재시작·컨테이너 재빌드까지 해야 적용됩니다.
- 업데이트 후 반드시
php -v와 사이트 핵심 기능(로그인·결제·게시판)을 확인하세요. - WAF·접근 제한은 임시 완화일 뿐입니다. 출처가 불분명한 점검 스크립트/PoC는 서버에서 실행하지 마세요.
자주 묻는 질문 (FAQ)
PHP2Shell(CVE-2026-109618·CVE-2026-109619)이 무엇인가요?
2026년 10월 공개된 PHP 코어의 치명적 취약점으로, 로그인(인증) 없이 원격에서 서버 명령을 실행(RCE)할 수 있습니다. CVSS 9.2(치명적)이며, 개별 사이트 코드가 아니라 PHP 자체의 결함이라 PHP로 동작하는 모든 웹사이트가 대상입니다.
어떤 PHP 버전이 안전한가요?
PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 이상에서 패치됐습니다. 지원이 종료된 PHP 8.1 이하는 패치가 제공되지 않으므로, 지원되는 상위 버전으로 전환해야 합니다.
HTTPS를 쓰면 PHP2Shell로부터 안전한가요?
아니요. HTTPS는 데이터가 오가는 전송 구간을 암호화할 뿐이고, PHP2Shell은 데이터가 도착하는 서버의 PHP 프로그램 결함입니다. 보호하는 계층이 달라 HTTPS를 쓰고 있어도 PHP2Shell은 막지 못합니다.
내 서버가 PHP2Shell에 취약한지 어떻게 확인하나요?
php2shell.tpiinsight.ai에 사이트 주소를 입력하면, 공격 요청 없이 공개된 응답 헤더·HTML 메타·사이트맵·피드만으로 PHP 버전과 기반 프레임워크, 마지막 갱신일을 분석해 취약 여부를 알려줍니다.
PHP 버전이 숨겨져 있어도 파악할 수 있나요?
기반 프레임워크·CMS의 버전으로 그 버전이 요구·지원하는 PHP 범위를 파악합니다. 지원하는 PHP 상한이 8.2 미만이면 기저 PHP가 지원 종료 대역으로 확정됩니다. 또 사이트맵·피드의 마지막 갱신일이 패치 공개일(2026-10-21) 이전이면 아직 패치하지 않았을 가능성을 함께 표시합니다.
아임웹·카페24 같은 외부 서비스를 쓰면 PHP2Shell에 안전한가요?
보통 운영사가 서버 PHP를 관리하므로 이용자가 직접 조치할 대상은 아닙니다. 다만 홈페이지가 패치 공개일 이후 갱신된 흔적이 없으면, 운영사의 PHP 패치 적용 여부를 운영사 공지나 관리자 화면에서 별도로 확인하는 것이 좋습니다.
지원이 끝난 프레임워크를 쓰면 왜 위험한가요?
더 이상 유지보수되지 않는 프레임워크·게시판(예: 제로보드, 그누보드4, 구버전 WordPress·Magento 1 등)은 보통 옛 PHP에서만 동작하고 새 보안 패치를 받지 못합니다. 그래서 PHP 버전이 숨겨져 있어도 지원 종료 프레임워크가 발견되면 위험으로 판단합니다.
HTTP2Shell(CVE-2026-111497)도 점검되나요?
예. HTTP2Shell 은 Google Brotli 압축 해제 라이브러리의 결함(CVSS 4.0 9.2)으로, Node.js·Bun·Python brotli·brotlicffi·Envoy·Istio 등 이 라이브러리를 쓰는 곳에 영향을 줍니다. 점검기는 응답에서 보이는 Node.js·Bun 버전과 Envoy 사용 여부로 판정하고, 보이지 않으면 '확인 필요'로 안내합니다. 수정 버전은 Node.js 22.23.4·24.22.1·26.12.1, Bun 1.4.4, Brotli 1.2.1, Python brotli 1.2.1·brotlicffi 1.2.1.0 이상입니다.
Node2Shell 과 HTTP2Shell 은 다른 취약점인가요?
같은 취약점(CVE-2026-111497)입니다. 처음에 Node.js 에서 알려져 Node2Shell 로 불렸지만, 결함이 Brotli 라이브러리 자체에 있어 Python·Bun·Envoy 등으로 영향이 넓어지면서 HTTP2Shell 로 부르게 됐습니다.
공격당하면 무슨 일이 생기나요?
서버 장악, 개인정보·고객 데이터 유출, 홈페이지 변조·악성코드 삽입, 랜섬웨어 감염, 내부망·다른 서버로의 확산으로 이어질 수 있습니다. 병원·쇼핑몰처럼 민감정보를 다루는 사이트는 유출 시 통지·신고 의무까지 더해져 특히 위험합니다.
보안 패치·정밀 점검 문의
직접 조치가 어렵거나, 여러 서버를 정밀하게 점검하고 싶으신가요? 담당자가 확인 후 연락드립니다. 보안 패치 적용 지원, 서버·프레임워크 이전, 상시 관제까지 안내해 드립니다.
MediAX 보안 관제는 서버에 경량 에이전트(읽기 전용·단방향)를 설치해 PHP 버전·프레임워크·패치 상태를 자동으로 수집하고, PHP2Shell 같은 신규 취약점이 나올 때마다 해당 여부를 알려 드립니다. 서버 접근이 어려운 공유 호스팅은 DNS만 바꾸는 HTTPS 엣지 방식으로 감쌉니다.
MediAX 보안 관제 보기 →