PHP 취약점 PHP2Shell 대응 체크리스트 2026 — 패치 버전·버전 확인 3가지·웹셸 점검

PHP2Shell은 PHP 자체에 있던 원격 코드 실행 취약점 두 개(CVE-2026-109618·109619)예요. 고친 버전은 8.5.12 · 8.4.27 · 8.3.36 · 8.2.35이고 2026년 10월 21일에 나왔어요. 내 버전이 이보다 낮으면 올리고, 웹 서비스를 꼭 다시 시작하세요. 8.1 이하도 "패치가 아예 없는" 건 아니에요. PHP 보안팀이 7.4·8.0·8.1 용 소스 패치를 따로 냈고, 배포판과 호스팅사가 이를 넣고 있어요. 다만 버전 숫자만 보면 틀릴 수 있어요. 직접 돌려 보니 우분투 24.04 는 고쳐진 뒤에도 php -v 가 8.3.6 으로 나왔고, 버전을 못 박은 도커 태그는 다시 받아도 패치 전 PHP 그대로였어요.

글 서순명(웹 에이전시·SI 10년 PM, 솔리드그루 이사) · 퓨쳐인프라 — 국내 IDC 에서 가상서버·앱 호스팅을 직접 운영 · 게시·값 확인 2026-10-27(php.net·NVD·KISA·배포판 공지 원문 대조, 도커 실측) · 운영사 솔리드그루(사업자등록번호 875-44-00335, 서울 구로) · 문의 02-6933-6229 · support@futureinfra.ai · 개인정보처리방침 · 이용약관 · 새 공지가 나오면 다시 확인해 고쳐요

PHP2Shell 은 무엇이고 누가 영향을 받나요?

두 취약점 모두 PHP 엔진 내부의 메모리 관리 문제예요. 앱 코드가 아니라 PHP 자체의 문제라서, 아무리 잘 짠 사이트라도 PHP 버전이 낮으면 해당돼요.

PHP 보안팀은 웹 요청을 받는 모든 PHP 가 위험하다고 했어요. 그중 Apache mod_php 가 가장 위험하다고 적었어요. 앱 코드가 돌기도 전에 공격이 시작되는 사례가 확인됐기 때문이에요. 공격 방법은 이 글에서 다루지 않아요. 지킬 일만 정리해요.

"PHP2Shell"이라는 이름은 처음 찾아낸 Wiz Research 가 10월 21일 공개한 글 제목에서 왔어요. 캐나다 사이버보안센터도 이 이름으로 부르고 있어요.

몇 버전이면 안전한가요?

같은 계열 안에서 아래 번호 이상이면 두 취약점이 고쳐진 버전이에요. 계열을 바꾸라는 뜻이 아니에요. 8.3 을 쓰면 8.3.36 으로 올리면 돼요.

8.1 이하를 두고 "패치가 없다"고 쓴 글이 많아요. 정확히는 PHP 프로젝트가 새 정식판을 내지 않을 뿐이에요. 우분투 22.04 의 PHP 8.1 패키지나 카페24 의 7.4·8.1 서비스처럼 고친 판이 이미 나온 곳이 있어요. 내 서버가 어디서 PHP 를 받았는지가 답을 정해요.

8.2 는 이번에 고친 판(8.2.35)을 받아도 2026년 12월 31일에 지원이 끝나요. KISA 도 8.3 이상으로 옮기라고 권했어요.

표로 보기

계열	보안 지원 끝	남은 기간(2026-10-27 기준)
8.1	2025-12-31	끝남
8.2	2026-12-31	약 2개월
8.3	2027-12-31	약 14개월
8.4	2028-12-31	약 26개월
8.5	2029-12-31	약 38개월

내 PHP 버전은 어떻게 확인하나요? — 3가지

② SSH 에서 확인하는 명령

직접 해 봤어요. 이 PC 의 도커로 공식 PHP 이미지의 패치 전(8.3.35)·후(8.3.36) 태그를 127.0.0.1 에서만 띄우고 같은 명령을 쳤어요(2026-10-27 13:17).

$ docker run --rm php:8.3.35-cli php -v
PHP 8.3.35 (cli) (built: Oct 21 2026 00:32:41) (NTS)

$ docker run --rm php:8.3.36-cli php -v
PHP 8.3.36 (cli) (built: Oct 21 2026 15:57:19) (NTS)

서버에서는 아래 명령을 차례로 쳐 보세요. php-fpm 은 배포판마다 이름이 php-fpm8.3·php8.4-fpm 처럼 달라요.

php -v                       # 명령줄 PHP 버전
php-fpm8.3 -v                # PHP-FPM 버전 (배포판 이름에 맞게)
apache2ctl -M | grep -i php  # Apache 가 mod_php 를 쓰는지 (php_module 이 보이면 mod_php)
php -m                       # 켜진 확장 목록

③ 웹이 쓰는 버전을 브라우저로 확인

워드프레스는 관리자 화면 도구 → 사이트 건강 → 정보 → 서버에 PHP 버전이 나와요. 그누보드5 는 관리자 환경설정 → phpinfo() 메뉴가 있어요. 둘 다 없으면 이름을 알아보기 어렵게 지은 임시 파일을 하나 올려 확인하고 바로 지워요.

<?php echo PHP_VERSION, ' ', php_sapi_name();   // 예: ver-check-7f3a.php → 확인 후 즉시 삭제

도커 Apache 컨테이너에 이 파일을 올려 열어 보니 8.3.36 apache2handler 가 나왔어요. 뒤쪽 말은 PHP 가 붙은 방식이에요(apache2handler = mod_php, fpm-fcgi = PHP-FPM). phpinfo() 파일을 써도 되지만 설정 전부가 드러나니 더 서둘러 지워야 해요.

버전 숫자만 보면 틀리는 두 경우

첫째, 배포판 패키지는 번호가 그대로일 수 있어요. 우분투 24.04 컨테이너에 배포판 PHP 를 깔아 보니 php -v 는 8.3.6 이었어요. 8.3.36 보다 한참 낮아 보이지만, 패키지 번호 끝이 .13 이고 변경 이력에 두 CVE 가 적혀 있었어요. 고쳐진 상태예요.

# 데비안·우분투: 설치된 패키지 번호와 변경 이력에서 CVE 찾기
dpkg-query -W 'php*-cli' 'php*-fpm' 'libapache2-mod-php*'
zgrep -n 'CVE-2026-10961[89]' /usr/share/doc/php8.3-cli/changelog.Debian.gz

# 레드햇 계열(Rocky·Alma 포함): 변경 이력에서 CVE 찾기
rpm -q --changelog php-cli | grep -E 'CVE-2026-10961[89]'

둘째, 버전을 못 박은 도커 태그는 다시 받아도 그대로예요. 공식 워드프레스 이미지로 확인했어요. 8월에 만들어진 wordpress:7.0.2-php8.4-apache 는 오늘 다시 받아도 PHP 8.4.24(패치 전)였어요. 10월 21일 이후 빌드된 wordpress:7.1.3-php8.4-apache 는 8.4.27 이었어요. php:8.4-apache 처럼 계열만 적은 태그는 다시 받으면 새 이미지가 와요. 반대로 공식 php:8.1-cli 이미지는 2025년 12월 빌드에 멈춰 있어 이번 수정이 없어요.

$ docker run --rm --entrypoint php wordpress:7.0.2-php8.4-apache -r 'echo PHP_VERSION;'
8.4.24     ← 패치 전 (이미지 생성 2026-08-05)
$ docker run --rm --entrypoint php wordpress:7.1.3-php8.4-apache -r 'echo PHP_VERSION;'
8.4.27     ← 패치 (이미지 생성 2026-10-21)
$ docker run --rm php:8.1-cli php -v | head -1
PHP 8.1.34 (cli) (built: Dec 29 2025 23:35:21) (NTS)   ← 이번 수정 없음

내 환경에서는 무엇을 하면 되나요?

호스팅을 쓰면 무엇을 물어보나요?

예를 들어 카페24 는 10월 23일 종합 공지에서 "8.2 이상은 패치 완료, 7.4~8.1 도 반영 완료, 7.3 이하는 완화 조치"라고 알렸어요. 7.4·8.1 에는 7.4.33p2·8.1.34p2 처럼 이름 뒤에 표시가 붙은 판을 넣었어요. 같은 공지에서 서버호스팅·가상서버처럼 직접 관리하는 서버는 조치 대상이 아니니 KISA 수칙대로 직접 하라고 했어요. 호스팅사가 다르면 문장도 다르니, 내 호스팅사 공지를 확인하세요.

워드프레스만 업데이트하면 되나요?

아니요. 이번 문제는 워드프레스 아래에 깔린 PHP 에 있어요. 워드프레스·테마·플러그인을 다 올려도 PHP 가 그대로면 해결되지 않아요. 참고로 워드프레스는 PHP 8.3 이상을 권장해요. 8.2 이하라면 이번 기회에 같이 옮길 계획을 세우세요.

퓨쳐인프라 서버에서는 이렇게 하세요

퓨쳐인프라에서 PHP 를 돌리는 방법은 크게 둘이에요. 가상서버에 직접 깐 경우와, 앱 호스팅에 도커 이미지로 올린 경우예요.

가상서버(Debian 13 · Ubuntu)

1. 스냅샷부터 찍어요. 콘솔에서 서버를 고르고 스냅샷을 만들어요. 업데이트 뒤 문제가 생기면 그 시점으로 돌아갈 수 있어요. 스냅샷은 무료예요.
2. SSH 로 들어가요. 만들 때 등록한 SSH 키로 접속해요. root 가 아니면 아래 명령 앞에 sudo 를 붙여요.
3. 배포판 보안 업데이트를 받아요. 데비안·우분투는 배포판이 고친 PHP 패키지를 내놓았어요.
4. PHP 를 다시 시작해요. 쓰는 쪽만 다시 시작하면 돼요(PHP-FPM 이면 fpm, mod_php 면 Apache).
5. 고쳐졌는지 확인해요. 위 표의 패키지 번호와 비교하고, 변경 이력에서 CVE 를 찾아요.

apt update
apt list --upgradable 2>/dev/null | grep -i php     # 올라갈 PHP 패키지 보기
apt upgrade                                          # 보안 업데이트 적용

systemctl restart php8.4-fpm     # Debian 13 기본 PHP-FPM (우분투 24.04 는 php8.3-fpm)
systemctl restart apache2        # Apache mod_php 를 쓰면

dpkg-query -W 'php*-fpm' 'php*-cli'               # 패키지 번호 확인
apt changelog php8.4-cli | head -20                # 맨 위 항목에 CVE-2026-109618 이 보이면 고쳐진 것

Debian 13 은 배포판 기본 PHP 가 8.4 예요. 직접 깔아 보니 고친 패키지(8.4.27-1~deb13u1)에서 php -v 도 8.4.27 로 나왔어요. 우분투 24.04 는 앞에서 본 대로 8.3.6 으로 보여도 패키지 번호 끝이 .13 이면 고쳐진 거예요.

앱 호스팅(도커 이미지로 올린 PHP 앱·원클릭 WordPress)

1. 쓰는 이미지 태그를 확인해요. php:8.3.35-apache 나 wordpress:7.0.2-php8.4-apache 처럼 숫자를 못 박은 태그는 그 안의 PHP 도 그대로예요.
2. 패치된 태그로 바꿔요. 예: php:8.3.36-apache, wordpress:7.1.3-php8.4-apache. 직접 만든 이미지라면 베이스 이미지를 올려 다시 빌드해요.
3. 앱 화면에서 이미지 태그를 바꿔 다시 배포해요. 다시 배포하면 이미지를 새로 받아요. 앱 문서에 적힌 대로 볼륨 데이터는 다시 배포해도 남아요.
4. 바뀐 버전을 확인해요. 앱 주소를 열어 다음 절의 방법(응답 헤더·임시 확인 파일)으로 웹이 쓰는 PHP 버전을 봐요.

API 로 할 때는 앱 문서의 배포 요청에 새 태그를 넣으면 돼요. 앱 문서는 latest 대신 정확한 태그를 쓰라고 권해요. 언제 무엇이 바뀌었는지 알 수 있고, 문제가 생기면 이전 태그로 되돌릴 수 있기 때문이에요.

POST /v1/apps/<앱 id>/deploy
{ "image": "wordpress:7.1.3-php8.4-apache" }

업데이트한 뒤 제대로 됐는지 어떻게 확인하나요?

가장 흔한 실수는 재시작을 안 한 것이에요. 패키지를 올려도 이미 떠 있는 PHP 프로세스는 옛 코드 그대로예요. KISA 도 재시작하지 않으면 여전히 취약하다고 적었어요.

도커로 실제 헤더를 찍어 봤어요. 공식 Apache 이미지는 기본 설정이라 PHP 번호가 그대로 보였어요. 아래 「하드닝 체크리스트」의 설정을 넣자 그 줄이 사라졌어요.

$ curl -sI http://127.0.0.1:18080/        # 기본 설정
HTTP/1.1 200 OK
Server: Apache/2.4.69 (Debian)
X-Powered-By: PHP/8.3.36

$ curl -sI http://127.0.0.1:18181/        # expose_php = Off 를 넣은 컨테이너
HTTP/1.1 200 OK
Server: Apache/2.4.69 (Debian)

바로 못 올리면 임시로 무엇을 하나요?

PHP 보안팀은 아래 설정이 일부 공격 경로만 줄일 뿐, 설치가 안전해지지는 않는다고 못 박았어요. 업데이트 날짜를 잡는 동안만 쓰는 방법이에요.

설정을 바꾼 뒤에는 PHP 프로세스를 전부 다시 시작해야 해요. RLIMIT_AS 같은 메모리 제한은 오히려 문제 경로를 부를 수 있어 쓰지 말라고 했어요. 이것도 어렵다면 KISA 는 업데이트 전까지 외부 접속을 막거나 서비스를 잠시 멈추는 방안까지 권했어요.

해킹 흔적은 어떻게 보나요? — 웹셸 점검 기초

업데이트는 앞으로의 공격을 막을 뿐이에요. 그 전에 들어온 흔적은 따로 찾아야 해요. KISA 는 최소 10월 20일 이후 기록 전체를 보라고 했어요. 아래는 지키는 쪽에서 쓰는 기초 명령이에요.

도커 컨테이너 안에 무해한 한 줄짜리 가짜 파일 4개(정상 PHP 2개는 9월 날짜, 업로드 폴더의 PHP 1개는 10월 22일 날짜, 사진 1개)를 만들고 돌려 봤어요.

# ① 10월 20일 이후 새로 생기거나 바뀐 PHP 파일
$ find /tmp/site -type f -name "*.php" -newermt "2026-10-20" -printf "%TY-%Tm-%Td %TH:%TM  %p\n"
2026-10-22 03:14  /tmp/site/data/uploads/thumb.php

# ② 업로드 폴더 안의 PHP 파일 (원래 있으면 안 되는 곳)
$ find /tmp/site -path "*upload*" -type f -iname "*.php*"
/tmp/site/data/uploads/thumb.php

# ③ 웹 서버 계정이 띄운 셸·다운로드 프로세스
$ ps -eo user,pid,args | awk '$1=="www-data"' | grep -E '(^| )(sh|bash|curl|wget)( |$)'
(없음)

실제 서버에서는 /tmp/site 자리에 웹 폴더(예: /var/www)를 넣어요. 플러그인 업데이트처럼 정상으로 바뀐 파일도 같이 나오니, 목록을 보고 하나씩 확인해요. 시간 정보는 공격자가 바꿀 수도 있어서, 안 나왔다고 안심하면 안 돼요.

# 접근 기록에서 응답 코드별 개수 (Apache·nginx 기본 형식은 9번째 칸)
awk '{print $9}' /var/log/apache2/access.log | sort | uniq -c | sort -rn

비밀번호도 바꾸세요. 이번 취약점은 서버 메모리에 든 비밀번호·토큰·API 키를 새게 할 수 있어요. 업데이트 전까지 인터넷에 열려 있던 서버라면 DB 비밀번호, 외부 서비스 키, 관리자 비밀번호를 바꾸는 게 좋아요. 흔적이 나왔다면 반드시 바꿔요.

앞으로 무엇을 해 두면 좋을까요? — 하드닝 체크리스트

아래는 우리가 PHP 서버를 운영하며 실제로 적용한 구성이에요. 이번 같은 엔진 결함을 설정으로 막을 수는 없어요. 대신 뚫렸을 때 피해를 줄이고, 빨리 알아채게 해 줘요.

웹 방화벽 기록을 보면 .env·.git 같은 설정 파일을 찾는 자동 요청이 꾸준히 들어와요. 웹 폴더 안에 이런 파일을 두지 말고, 웹서버에서 점(.)으로 시작하는 경로를 막아 두면 좋아요.

PHP 하드닝 ini 예시예요. 사이트가 쓰는 함수가 있으면 disable_functions 에서 빼야 해요. 적용 전에는 스냅샷이나 백업을 먼저 해요.

; /etc/php/8.4/fpm/conf.d/99-hardening.ini  (경로는 버전·방식에 맞게)
expose_php = Off
display_errors = Off
log_errors = On
allow_url_include = Off
disable_functions = exec,passthru,shell_exec,system,proc_open,popen,pcntl_exec,show_source
open_basedir = /var/www:/tmp
session.cookie_httponly = 1
session.use_strict_mode = 1
session.upload_progress.enabled = 0

넣기 전과 뒤를 도커로 비교했어요. 공식 PHP 이미지는 php.ini 가 없는 기본값이라, 점검한 9개 중 2개만 권장값이었어요.

$ php -i | grep -E "^(expose_php|display_errors|disable_functions|open_basedir|session.upload_progress.enabled) "
# 넣기 전 (php:8.3.36-cli 기본)          # 넣은 뒤
expose_php => On                          expose_php => Off
display_errors => STDOUT                  display_errors => Off
disable_functions => no value             disable_functions => exec,passthru,shell_exec,...
open_basedir => no value                  open_basedir => /var/www:/tmp
session.upload_progress.enabled => On     session.upload_progress.enabled => Off

자주 묻는 질문

실제로 공격이 있나요?

KISA 는 패치 전에 정보가 새어 나갔고 해외 보안업체 중심으로 공격 시도가 보고된다고 했어요. 미국 CISA 는 10월 26일 두 CVE 를 '실제 악용이 확인된 취약점' 목록에 올렸어요. 캐나다 사이버보안센터는 10월 23일 기준 공개된 시험 코드는 있으나 활발한 악용은 확인 안 됐다고 적었어요. 기관마다 확인 시점이 달라요.

'PHP2Shell' 이름은 누가 붙였나요?

처음 찾아낸 Wiz Research 가 10월 21일 공개한 글 제목과 소개 사이트(php2shell.com)에서 쓴 이름이에요. 공식 CVE 이름은 아니고, 정부 기관들도 이 별칭을 함께 쓰고 있어요.

인터넷에 도는 점검 스크립트·공격 코드로 확인해 봐도 되나요?

권하지 않아요. KISA 는 출처가 불분명한 공격 코드 중에 악성코드가 숨은 가짜가 많다며, 버전 확인과 기록 점검으로 판단하라고 했어요. 분석이 꼭 필요하면 업무망과 분리된 곳에서만 하세요.

10월 23일에 또 나온 CVE-2026-115560 은 뭔가요?

세션 처리의 다른 결함이에요. 설정 파일에서 session.serialize_handler 를 php_binary 나 php_serialize 로 두고, 코드에서 ini_set() 으로 php 로 바꾸는 드문 경우에만 해당해요. 10/21 패치로는 안 고쳐지고 다음 정기 릴리스에서 고쳐질 예정이에요. session.upload_progress.enabled=0 을 이미 넣었다면 추가로 할 일은 없어요.

업데이트하면 사이트가 깨지지 않나요?

8.3.35 → 8.3.36 처럼 같은 계열 안에서 올리는 건 보안 수정 릴리스예요. 8.1 → 8.3 처럼 계열을 바꾸면 코드가 안 맞을 수 있어요. 어느 쪽이든 스냅샷이나 백업을 먼저 하고, 로그인·글쓰기·결제 같은 주요 기능을 확인하세요.

8.1 을 쓰는데 당장 8.3 으로 못 옮겨요.

먼저 배포판이나 호스팅사가 낸 8.1 백포트 패치를 받으세요. 직접 빌드한다면 PHP 보안팀이 공개한 8.1 용 소스 패치를 쓸 수 있어요. 그다음 8.3 이상으로 옮길 날짜를 정해요. 그 사이에는 「바로 못 올리면」 절의 임시 설정과 앞단 제한을 겹쳐 두세요.

PHP 8.6 은요?

8.6 은 아직 정식판이 아니에요. 10월 21일에 나온 8.6.0 RC4 에 수정이 들어갔지만, php.net 은 운영 서버에 쓰지 말라고 했어요.

이럴 땐 이렇게

함께 보면 좋은 글 — 서버 스냅샷과 백업, 뭐가 달라요? · 워드프레스 호스팅 비교 · 도커 호스팅 비용

이 글의 사실은 어디서 왔나요?