PHP2Shell CVE-2026-109618·109619 (9.2) · HTTP2Shell CVE-2026-111497 (9.2)

내 서버, PHP2Shell·HTTP2Shell에 안전한가요?

인증 없이 원격 코드 실행이 가능한 두 건의 치명적 취약점입니다 — PHP의 PHP2Shell, Brotli 압축 해제 라이브러리의 HTTP2Shell(Node.js·Python·Bun·Envoy 등). 사이트 주소만 넣으면 공격 요청 없이 어느 쪽에 해당하는지 확인해 드립니다.

PHP2Shell · PHP
9.2/10
CVSS · 치명적(Critical)
HTTP2Shell · Brotli · Node.js·Python 등
9.2/10
CVSS · 치명적(Critical)
🔓 인증 불필요
로그인 없이 누구나
⚡ 원격 코드 실행
서버를 통째로 조종
🎯 공격 관측됨
공개 전부터 시도
🧩 엔진 자체 결함
PHP·Node.js 코어의 구멍
⚠ PHP·Node.js 어느 쪽이든, 해당되면 즉시 패치하세요. 패치 외에는 완전한 해결책이 없습니다.
공격 요청 없음공개 헤더·메타·피드만 확인요청 수 회 · 수 초 내 결과결과는 이 브라우저와 서버에 기록
01

PHP2Shell이 뭔가요? — 쉽게 이해하기

2026년 10월, PHP 코어에서 로그인(인증) 없이 누구나 원격으로 서버에 명령을 실행할 수 있는 두 건의 치명적 취약점(CVE-2026-109618·CVE-2026-109619)이 공개됐습니다. 개별 사이트의 코드 문제가 아니라 PHP 자체의 결함이라, PHP로 돌아가는 모든 웹사이트가 대상입니다. KISA와 미국 CISA가 즉시 업데이트를 권고했고, 공개 전부터 실제 공격 시도가 관측됐습니다.

🏠 비유로 보면
HTTPS가 집으로 오가는 길에 자물쇠를 채워 ‘엿보기’를 막는 보안문이라면, PHP2Shell은 집(서버)을 움직이는 프로그램 자체에 난 구멍입니다. 공격자는 열쇠(로그인) 없이 그 구멍으로 바로 들어와, 집 안의 물건(데이터)을 가져가거나 집을 통째로 조종할 수 있습니다. 보안문이 아무리 튼튼해도, 벽에 구멍이 있으면 소용이 없습니다.
공격이 일어나는 흐름
1공격자
특수하게 조작한 요청·데이터를 서버로 보냄
2취약한 PHP
서버의 PHP가 그 데이터를 잘못 처리
3코드 실행
공격자가 심은 명령이 서버에서 그대로 실행
4서버 장악
데이터 탈취·홈페이지 변조·다른 서버로 확산
02

HTTP2Shell이 뭔가요? — Brotli 압축 해제 라이브러리의 결함 (구 Node2Shell)

CVE-2026-111497CVSS 4.0 9.2 · 치명적CVSS 3.1 기준 8.1(높음)

2026년 10월 공개된 이 취약점은 처음에 Node.js 내장 디코더 문제로 알려져 ‘Node2Shell’로 불렸습니다. 그런데 결함이 Google이 만든 Brotli 압축 해제 라이브러리 자체에 있어, 같은 라이브러리를 쓰는 Bun·Python·Envoy·Istio·curl 등으로 영향이 넓어지면서 지금은 HTTP2Shell로 부릅니다. 별개의 새 취약점이 아니라 같은 CVE입니다.

근본 원인
잘못된 압축 데이터를 ‘형식 오류’로 거부하지 않고 ‘입력이 더 필요한 상태’로 잘못 판단해, 스트리밍 디코더가 8바이트짜리 내부 버퍼에 데이터를 계속 덧붙이다 버퍼 밖 메모리에 씁니다. 그 결과 프로세스 충돌, 메모리 정보 유출, 원격 코드 실행으로 이어질 수 있습니다.
원인 코드는 2월에 소스에서 고쳐졌지만 당시엔 보안 문제로 인식되지 않아 수정 릴리스가 나오지 않았고, 이후 OpenAI Codex Security가 취약점으로 보고했습니다.
영향받는 라이브러리·제품
Node.js
내장 Brotli(node:zlib) · fetch 자동 압축 해제
Bun
내장 Brotli 디코더
Python brotli · brotlicffi
requests·urllib3·HTTPX·aiohttp·Scrapy 가 자동 사용
Google Brotli (libbrotli)
이 라이브러리를 연결한 모든 프로그램
Envoy · Istio
Brotli 압축 해제 필터 사용 시
curl / libcurl 등
연결된 Brotli 라이브러리·배포판 패키지

수정 버전은 아래 05 · 어떤 버전을 써야 안전한가요?에 정리했습니다.

어떤 경우에 위험한가 — 영향 경로 3가지
① 서버가 압축된 요청을 풀 때
요청 본문이 Content-Encoding: br 이고 서버·프록시가 이를 해제하는 경우입니다(Envoy·Istio 의 Brotli 해제 필터 포함). Apache·Nginx 는 기본 설정에서 Brotli 를 해제하지 않습니다.
② HTTP 클라이언트가 외부 응답을 자동으로 풀 때
Node fetch·node:zlib, Python requests·urllib3·HTTPX·aiohttp 등이 받은 응답을 스스로 풉니다. 링크 미리보기·크롤러·웹훅·외부 API 호출이 대표 경로입니다.
③ 신뢰할 수 없는 Brotli 파일을 풀 때
업로드 파일이나 백그라운드 작업에서 외부에서 온 .br 데이터를 해제하는 경우입니다.

HTTP 를 쓴다는 이유만으로 모두 해당하는 것은 아닙니다. 외부에서 온 데이터를 취약한 디코더로 압축 해제하는지가 판단 기준입니다.

⚠ 놓치기 쉬운 점 — Python
코드에서 brotli 를 직접 설치하거나 불러오지 않아도, 다른 패키지가 함께 설치하면 requests 등이 자동으로 사용합니다. 10월 23일 기준 pip-audit·Dependabot·Safety 가 이 취약점을 잡지 못하는 상태였으므로, 실제 설치된 패키지와 전체 의존성을 확인하세요.
📦 비유로 보면
PHP2Shell 이 집을 움직이는 프로그램(PHP)에 난 구멍이라면, HTTP2Shell 은 ‘압축된 소포를 자동으로 뜯는 기계’의 결함입니다. 같은 기계가 Node.js·Python·Envoy 등 여러 회사의 공장에 똑같이 들어가 있어, 바깥에서 온 소포를 뜯기만 해도 어느 공장이든 터질 수 있습니다.
공격이 일어나는 흐름
1압축 데이터 전달
조작된 Brotli 데이터를 요청 본문으로 보내거나, 서버가 부른 외부 주소가 응답으로 돌려준다
2자동 해제
Node.js·Python·Envoy 등의 Brotli 디코더가 그 데이터를 스스로 푼다
3버퍼 밖 쓰기
형식 오류를 놓친 디코더가 내부 버퍼 밖 메모리를 덮어쓴다
4충돌·유출·장악
프로세스 충돌, 메모리 정보 유출, 원격 코드 실행으로 이어진다
패치 전 임시 대응
  • 들어오는 요청: 압축을 풀기 전 단계(프록시·미들웨어)에서 Content-Encoding: br 요청을 거부합니다.
  • 외부 응답: HTTP 클라이언트의 Brotli 자동 해제를 끄거나, 본문을 처리하기 전에 차단합니다.
  • 요청의 Accept-Encoding 에서 br 만 빼는 것으로는 부족합니다 — 악성 서버는 이를 무시하고 Brotli 로 응답할 수 있습니다.
  • CDN·웹서버의 응답 압축을 끄는 것과 앱의 압축 해제 경로를 막는 것은 별개입니다. gzip·deflate 는 그대로 써도 됩니다.
  • 임시 대응은 시간을 버는 것일 뿐입니다 — 영향받는 구성 요소를 반드시 수정 버전으로 올리세요.

서버 내부 라이브러리 버전은 겉으로 거의 드러나지 않아 이 점검기에서는 대개 ‘확인 필요’로 나옵니다. Node.js·Bun 버전이나 Envoy 사용이 응답에서 보이면 함께 표시합니다.

03

HTTPS가 있으면 괜찮지 않나요? — 보호하는 곳이 다릅니다

HTTPS — 길을 잠근다PHP2Shell·HTTP2Shell — 벽에 난 구멍방문자서버오가는 데이터를 암호화 (엿보기 차단)구멍열쇠 없이 서버 안으로 들어와 조종

HTTPS(자물쇠)는 데이터가 오가는 ‘길’을 암호화해 중간에서 못 엿보게 합니다. PHP2Shell·HTTP2Shell은 데이터가 도착하는 ‘서버 엔진’(PHP·Node.js)의 결함입니다. 보호하는 계층이 서로 달라, HTTPS를 쓰고 있어도 두 취약점 모두 막지 못합니다. 둘 다 갖춰야 합니다.

04

공격당하면 무슨 일이 생기나요?

🗂️개인정보·고객 데이터 탈취
🧬홈페이지 변조·악성코드 삽입
🔒랜섬웨어 감염(파일 암호화 후 금전 요구)
🌐내부망·다른 서버로 확산
🤖서버를 공격 발판(봇넷)으로 악용
서버가 장악되면 — 단계별로 벌어지는 일
1
침투
조작된 요청(PHP2Shell)이나 악성 압축 응답(HTTP2Shell) 한 번으로 서버에 발판을 만듭니다. 로그인도, 피해자의 클릭도 필요 없습니다.
2
거점 확보 (웹셸)
눈에 보이지 않는 관리용 뒷문(웹셸)을 심어, 언제든 다시 들어올 길을 확보합니다.
3
권한 상승
서버 계정에서 관리자(root) 권한으로 올라서면, 서버 전체가 공격자 손에 들어갑니다.
4
데이터 유출
회원·환자 정보, 결제·진료 기록, 설정 파일과 저장된 비밀번호까지 통째로 빼냅니다.
5
랜섬웨어·백도어
파일을 암호화해 금전을 요구하거나, 조용히 백도어를 남겨 장기간 들여다봅니다.
6
2차 확산
같은 망의 다른 서버·업무 PC로 번지고, 장악한 서버를 다른 곳을 치는 발판으로 악용합니다.
⚠ 가장 위험한 오해 — “우리는 작아서 표적이 안 된다”
공격의 대부분은 사람이 하나씩 고르는 게 아니라, 자동화된 봇이 인터넷 주소를 쉼 없이 훑으며 ‘패치 안 된 버전’을 찾아 무차별로 시도합니다. 규모·업종·유명세와 무관하게, 취약한 상태로 열려 있으면 차례가 옵니다. 공개된 취약점일수록 봇의 표적 목록 맨 앞에 오릅니다 — 공개 시점부터 패치까지의 하루하루가 가장 위험합니다.
🏥 병원이라면 피해가 훨씬 큽니다
진료·건강 정보는 개인정보보호법상 민감정보로 분류돼, 유출 시 피해가 크고 정보주체 통지·관계기관 신고 의무가 따릅니다. 예약·전자차트 같은 서버가 멈추면 진료 자체가 지연되고, 한 번 잃은 환자 신뢰는 되돌리기 어렵습니다. 그래서 의료기관은 ‘해당되면 즉시 패치’가 선택이 아니라 필수입니다.
05

어떤 버전을 써야 안전한가요?

PHP — PHP2Shell (CVE-2026-109618·109619 · 9.2)
PHP 브랜치취약 범위안전한 버전
PHP 8.58.5.12 미만8.5.12 이상
PHP 8.48.4.27 미만8.4.27 이상
PHP 8.38.3.36 미만8.3.36 이상
PHP 8.28.2.35 미만8.2.35 이상
PHP 8.1 이하전부 해당지원 종료 — 상위 버전으로 전환

지원이 종료된 PHP 8.1 이하는 패치가 제공되지 않으므로, 지원되는 상위 버전으로 올려야 합니다.

Brotli — HTTP2Shell (CVE-2026-111497 · 9.2)
대상수정 버전(이상)
Node.js22.23.4 · 24.22.1 · 26.12.1 (20 이하는 지원 종료 — 현행 LTS로)
Bun1.4.4
Google Brotli · libbrotli1.2.1 (이전 계열 1.0.10 · 1.1.1)
Python brotli1.2.1
Python brotlicffi1.2.1.0
Envoy Proxy1.40.0 · 1.39.3 · 1.38.6 · 1.37.8
Istio1.30.6 · 1.31.2
curl / libcurl 등연결된 Brotli 라이브러리 또는 배포판 보안 패키지 업데이트

Envoy 1.36.12·Istio 1.29.9 에도 수정이 들어갔지만 지원 종료 계열입니다. Linux 배포판은 버전 번호를 그대로 둔 채 수정만 넣을 수 있으니 배포판 보안 공지를 확인하고, 라이브러리를 내장하거나 정적으로 연결한 프로그램·컨테이너는 다시 빌드해야 합니다.

06

PHP 프레임워크·게시판이 지원 종료됐다면? (심화 진단)

PHP 버전을 숨겨도 안심할 수 없습니다. 쓰고 있는 PHP 프레임워크·게시판이 더 이상 유지보수되지 않으면, 보통 옛 PHP에서만 돌고 새 보안 패치를 받지 못합니다. 그래서 이 점검기는 겉으로 드러난 흔적으로 기반 기술을 찾아, 지원이 끝난 것이면 위험으로 표시합니다.

PHP 기반 전용 · PHP2Shell 관련아래 목록은 모두 PHP로 만든 프레임워크·게시판·쇼핑몰입니다. Node.js 사이트는 여기에 해당하지 않으며, Node 버전으로 판정합니다(02·05 참고).
지원 종료 — 즉시 조치15종
보안 패치가 더 이상 제공되지 않습니다. 현행 버전으로 이전이 필요합니다.
Kohana
PHP
PHP 프레임워크
2017년경 개발 중단
FuelPHP
PHP
PHP 프레임워크
사실상 유지보수 중단
Zend Framework 1·2
PHP
PHP 프레임워크
종료 — 후속 Laminas 로 이전
코드이그나이터 2 이하
PHP
PHP 프레임워크
종료 — 4가 현행
CakePHP 3 이하
PHP
PHP 프레임워크
종료 — 4·5가 현행
Yii 1
PHP
PHP 프레임워크
종료 — 2가 현행
제로보드
PHP
게시판
오래전 개발 종료 — 후속 XE
그누보드4
PHP
게시판
종료 — 5·6으로 이전
XpressEngine 1
PHP
CMS
종료 — 후속 XE3·라이믹스
Drupal 7 이하
PHP
CMS
2025-01 종료 — 9·10·11이 현행
Joomla 3 이하
PHP
CMS
종료 — 4·5가 현행
Silex
PHP
PHP 마이크로 프레임워크
2018 종료 — Symfony 로 통합
Lithium(li3)
PHP
PHP 프레임워크
개발 중단 — 전환 필요
Magento 1
PHP
쇼핑몰
2020-06 종료 — Magento 2 로 이전
텍스트큐브(태터툴즈)
PHP
블로그
개발 사실상 중단 — 전환 권장
버전에 따라 확인 필요11종
같은 이름이라도 버전마다 지원 기간이 다릅니다. 쓰는 버전이 보안 지원 중인지 확인하세요.
Laravel
PHP
PHP 프레임워크
버전별 보안 지원 기간 상이 — 최신 유지
Symfony
PHP
PHP 프레임워크
메이저별 지원 기간 상이 — 최신 유지
코드이그나이터 3
PHP
PHP 프레임워크
보안 패치만 제공 — 4로 이전 권장
워드프레스
PHP
CMS
코어·플러그인·테마 최신 유지(취약점은 대개 플러그인)
XpressEngine 3
PHP
CMS
지원 상태 확인 필요
Magento 2
PHP
쇼핑몰
2.4.x 현행 — 세부 버전 지원 기간 확인
PrestaShop
PHP
쇼핑몰
1.7·8 현행 / 1.6 이하 종료
phpBB
PHP
포럼·게시판
3.3 현행 / 3.2 이하 종료
Moodle
PHP
LMS
버전별 지원 기간 확인 — 구버전 종료
TYPO3
PHP
CMS
버전별 지원 기간 확인 — 구버전 종료
킴스큐(Kimsq)
PHP
CMS
유지보수 활발하지 않음 — 버전·패치 확인
현행 — 최신 패치 유지10종
유지보수 중인 계열입니다. 세부 보안 패치는 계속 최신으로 유지하세요.
그누보드5 · 6
PHP
게시판
현행 — 플러그인·테마 포함 최신 유지
라이믹스(Rhymix)
PHP
CMS
현행 — XE 후속
영카트
PHP
쇼핑몰(그누보드 기반)
현행 — 최신 유지
코드이그나이터 4
PHP
PHP 프레임워크
현행
CakePHP 4·5 · Yii 2
PHP
PHP 프레임워크
현행
Drupal 9·10·11 · Joomla 4·5
PHP
CMS
현행
Laminas
PHP
PHP 프레임워크
현행 — Zend 후속
Slim · Phalcon · Nette
PHP
PHP 프레임워크
현행 — 유지보수 중
OpenCart
PHP
쇼핑몰
현행 — 최신 유지
MediaWiki
PHP
CMS(위키)
현행 — 최신 유지
SaaS·빌더 — 서버는 운영사 관리3종
서버·PHP를 운영사가 관리합니다. PHP2Shell은 병원·사이트 측 조치 대상이 아닙니다.
아임웹 · Wix · 식스샵
운영사 관리
SaaS 빌더
운영사가 서버·보안 관리
카페24 쇼핑몰 · 고도몰 · 메이크샵
운영사 관리
SaaS 쇼핑몰
운영사가 서버·보안 관리
애니빌드 · 네이버 모두
운영사 관리
빌더
운영사가 서버·보안 관리

PHP 버전이 보이지 않아도, 위 ‘지원 종료’에 해당하는 프레임워크·게시판이 발견되면 점검 결과를 위험 높음으로 표시합니다. 버전은 겉으로 드러난 흔적 기준이므로, 정확한 버전과 패치 여부는 서버에서 확인하세요.

07

보안 패치 방법 (상세)

패치가 유일한 완전 해결책입니다. 운영 환경에 맞는 방법으로 지원되는 최신 버전으로 올리세요. 서버를 직접 운영하는 경우 아래 명령을 참고하되, 업데이트 전 백업과 스테이징 확인을 권장합니다.

Ubuntu · Debian (직접 운영 서버)
# 현재 버전 확인
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
Rocky · CentOS · RHEL (직접 운영 서버)
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
cPanel · WHM
# WHM 관리자
WHM → Software → EasyApache 4 → 현재 프로필에서 PHP 패키지 업데이트
WHM → MultiPHP Manager → 계정별 PHP 버전을 지원되는 최신으로 변경

# 또는 커맨드라인(루트)
/scripts/check_cpanel_rpms
yum update ea-php83-*
웹호스팅 (카페24 · 가비아 · 닷홈 등)
서버에 직접 접근할 수 없는 공유 호스팅입니다.
1) 호스팅사 관리 화면 → 'PHP 버전 설정'에서
   지원되는 최신 버전(8.2 이상)으로 변경
2) 호스팅사 보안 공지에서 PHP2Shell 패치 적용 여부 확인
3) 버전 변경 후 사이트가 정상 동작하는지 확인
   (오래된 코드는 상위 PHP 에서 오류가 날 수 있음)
Docker · 컨테이너
# 베이스 이미지 태그를 최신 패치로 올린다
# 예: 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
HTTP2Shell — Node.js · Bun
# 현재 버전 확인
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 <서비스명>
HTTP2Shell — Python (brotli · brotlicffi)
# 실제로 설치돼 있는지부터 — 직접 쓰지 않아도 다른 패키지가 깔았을 수 있습니다
pip show brotli brotlicffi

# 설치돼 있다면 수정 버전으로
pip install -U "brotli>=1.2.1" "brotlicffi>=1.2.1.0"

# 잠금 파일(requirements·poetry.lock 등)도 갱신하고, 컨테이너는 다시 빌드·재배포
HTTP2Shell — 배포판 libbrotli · 컨테이너
# 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는 서버에서 실행하지 마세요.
08

자주 묻는 질문 (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 보안 관제 보기 →
본 점검은 응답 헤더 기반의 참고용 진단이며, 공격 요청을 보내지 않습니다. 취약 버전 정보는 2026-10-22 기준입니다.
제공: TPIINSIGHT · MediAX · 문의 support@tpiinsight.co.kr · 마지막 업데이트 2026-10-24
💬보안 문의