brentmartinmiller/php2shell-checkPHP2Shell(CVE-2026-109618, CVE-2026-109619) 이후 WordPress 사이트를 위한 읽기 전용 트리아지 스크립트입니다. 침해 징후를 확인하고 사이트별로 보고서를 작성합니다.
PHP2Shell(CVE-2026-109618 및 CVE-2026-109619) 이후 WordPress 사이트를 위한 읽기 전용 트리아지 스크립트입니다. PHP2Shell은 2026년 10월 21일에 공개된 PHP 엔진의 두 가지 치명적인 원격 코드 실행 취약점입니다.
PHP에 패치를 적용하면 문은 닫히지만, Amazon의 허니팟은 공개 disclosure 4일 전인 10월 17일에 익스플로잇 시도를 기록했습니다. 당시 버그는 아직 엠바고 상태였습니다. 이는 누군가 공개한 가장 이른 활동일 뿐, 공격이 시작된 날은 아니므로 최소 기준으로 삼아야 합니다. 해당 기간 동안 패치되지 않은 PHP로 접근 가능했던 사이트는 이미 백도어가 있을 수 있으며, PHP를 업데이트해도 백도어는 제거되지 않습니다. 이 스크립트는 하나 또는 여러 WordPress 사이트에서 코드 실행 권한을 가진 공격자가 일반적으로 남기는 흔적을 확인하고, 각 사이트에 대한 Markdown 보고서를 작성합니다.
세 번째 버그인 CVE-2026-115560은 10월 23일에 발표되었습니다. 아직 수정 빌드가 없습니다. 10월 포인트 릴리스(8.2.35, 8.3.36, 8.4.27, 8.5.12)는 이 버그를 포함하지 않으며, 수정은 11월의 다음 정기 릴리스에 포함될 예정입니다. php.net은 그때까지 모든 사용자에게 php.ini 또는 PHP-FPM 풀에서 session.upload_progress.enabled=0을 설정할 것을 요청합니다. 이 스크립트는 해당 설정이 적용되었는지 확인합니다.
이 스크립트는 어떤 것도 수정하거나 삭제하지 않습니다. 나열하고, 검증하고, 보고할 뿐입니다. 발견된 사항을 어떻게 처리할지는 사용자의 몫입니다.
| 영역 | 확인 내용 |
|---|---|
| PHP | 설치된 CLI 버전과 수정 릴리스(8.2.35, 8.3.36, 8.4.27, 8.5.12) 비교. php.net에서 릴리스가 제공되지 않은 수명 종료(EOL) 브랜치를 표시합니다. 이전 PHP 브랜치 참조. |
| 업로드 진행률 | CVE-2026-115560 완화책인 session.upload_progress.enabled=0이 실제로 적용되는 위치에 설정되어 있는지 확인: PHP-FPM 자체 뷰(php-fpm -i), 읽을 수 있는 모든 php.ini, conf.d, FPM 풀 및 Apache 설정. 사이트 수준의 .user.ini 및 .htaccess는 보고되지만 인정되지 않습니다. php.net에 따르면 이 설정에는 작동하지 않기 때문입니다. |
| 코어 무결성 | wordpress.org를 대상으로 wp core verify-checksums 실행 |
| 플러그인 무결성 | wp plugin verify-checksums --all 실행 및 검증할 수 없는 프리미엄/커스텀 플러그인 나열 |
| 업로드 | wp-content/uploads 아래의 PHP 실행 가능 파일 ("Silence is golden" 스텁은 무시) |
| 최근 변경 | 기간 시작(기본값 2026-10-17) 이후 수정된 PHP 및 설정 파일. WordPress 번역 팩(wp-content/languages/**/*.l10n.php)은 엄격한 형태 검사를 통과한 경우 별도로 집계되며, 실패하면 플래그가 지정됩니다. |
| Prepend 훅 | .user.ini, .htaccess, php.ini의 auto_prepend_file / auto_append_file |
| Must-use 플러그인 | wp-content/mu-plugins 내용 (모든 요청에서 실행되며 일반 플러그인 목록에서 숨겨짐) |
| 코드 패턴 | wp-content 내의 전형적인 웹셸 시그니처 (eval(base64_decode(...)), $_POST[...](), 등) |
| 사용자 | 모든 관리자 및 기간 내에 등록된 모든 계정 |
| 데이터베이스 | siteurl/home, 주입된 스크립트나 난독화된 코드가 포함된 옵션 및 게시물 |
| Cron | WP-Cron 예약 이벤트 |
| 로그 | 액세스 로그: 기간 동안의 일별 5xx 응답 수와 기간 이전 최대 7일의 기준선 비교, 그리고 기간 내에 5xx를 반환한 URL. 오류 및 PHP-FPM 로그: 워커 크래시(segfault/bus error). |
| 서버 | 사이트 사용자의 crontab 및 SSH authorized_keys |
| Docker | php 바이너리가 있는 모든 실행 중인 컨테이너: 컨테이너 내부의 PHP 버전, 그리고 컨테이너가 디스크의 이미지보다 오래된 빌드를 여전히 실행 중인지 여부 (풀되었지만 재생성되지 않음) |
WP-CLI는 --skip-plugins --skip-themes와 함께 실행되므로 백도어가 심어진 플러그인이나 테마가 검사 중에 실행될 수 없습니다.
검사 대상 각 머신에서:
bash 3.2+, find, grep 및 sort -V (Linux 호스트의 표준이며, 기본 macOS 워크스테이션에서도 작동)php원격 사이트의 경우: 스크립트를 실행하는 머신에서 SSH 키 액세스. 스크립트는 SSH를 통해 자체적으로 실행되며, 위 요구 사항 외에는 원격 호스트에 설치할 필요가 없습니다.
curl -O https://raw.githubusercontent.com/brentmartinmiller/php2shell-check/main/php2shell-check.sh
chmod +x php2shell-check.sh
# One site
./php2shell-check.sh /var/www/example.com
less php2shell-reports/*.md
# Every site on the box
printf '%s\n' /var/www/*/public_html > sites.txt
./php2shell-check.sh sites.txt
cat php2shell-reports/SUMMARY.md
가능하면 사이트 파일을 소유한 사용자로 실행하세요. root로도 동작하지만
(WP-CLI에 --allow-root가 전달됨), 이 경우 crontab 및 SSH 키 검사가 웹 사용자가 아닌
root의 것을 검사하게 됩니다.
git clone https://github.com/brentmartinmiller/php2shell-check.git
cd php2shell-check
cp sites.txt.example sites.txt # edit: one site per line
./php2shell-check.sh sites.txt
각 user@host:path 항목에 대해 스크립트는 SSH로 접속하여 그곳에서 자기 자신을 실행하고, 보고서를 당신의 머신에 있는 php2shell-reports/로 가져옵니다. 원격 호스트에는 아무것도 설치되지 않습니다. SSH는 BatchMode=yes로 실행되므로, 비밀번호 프롬프트 없이 작동하는 키 기반 접근이 필요합니다.
대부분의 공유 호스트(Hostinger, SiteGround, Bluehost 등)는 SSH를 제공하지만 wp가 경로에 없는 경우가 많습니다. which wp로 확인하십시오. 없다면 WP-CLI를 홈 디렉터리에 한 번 다운로드하고 스크립트가 그것을 가리키도록 하십시오:
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
WP="php $HOME/wp-cli.phar" ./php2shell-check.sh domains/example.com/public_html
WP-CLI가 없어도 파일 시스템 검사는 여전히 실행되며, 보고서에는 무엇이 건너뛰어졌는지 기록됩니다. 어느 경우든 패치된 PHP가 언제 배포되었는지 호스트에 직접 문의하세요. 계정 수준 검사로는 확인할 수 없는 부분이기 때문입니다.
sites.txt는 한 줄에 사이트 하나씩이며, 로컬 경로 또는 user@host:path 형식입니다.
상대 원격 경로는 SSH 사용자의 홈 디렉터리를 기준으로 합니다. #으로 시작하는 줄은
무시됩니다. sites.txt.example을 참고하세요. 이 파일은 .gitignore에 포함되어 있어
클라이언트 호스트 이름이 커밋에 남지 않습니다.
비표준 SSH 포트, 키, 점프 호스트는 ~/.ssh/config에 지정합니다:
Host client-a
HostName 203.0.113.10
Port 2222
User deploy
IdentityFile ~/.ssh/client-a
그런 다음 사이트를 client-a:/var/www/html로 나열하세요.
Docker 호스트에서 php -v를 실행해도 컨테이너에 대해서는 아무것도 알 수 없으며, 고정된 이미지를 pull해도 해당 이미지로 컨테이너를 다시 생성하기 전까지는 아무것도 패치되지 않습니다. 한 팀의 사이트가 바로 그 이유로 pull 후 3일 동안 8.3.35에 머물러 있었습니다.
스크립트가 docker ps가 작동하는 호스트에서 실행되면, 보고서에 Docker 컨테이너 섹션이 추가되어 php 바이너리가 있는 모든 실행 중인 컨테이너, 그 안의 PHP 버전, 그리고 컨테이너가 오래되었는지 여부(디스크에 더 새로운 이미지 빌드가 있지만 컨테이너가 다시 생성되지 않음)를 나열합니다. docker compose up -d로 다시 생성하거나, 컨테이너를 중지하고 제거한 뒤 다시 실행하세요.
컨테이너 내부에서 전체 검사를 실행하려면, 컨테이너를 대상으로 나열하세요:
docker:wordpress-php-1:/var/www/html
스크립트는 docker exec로 파이프되어 그 안에서 실행되며, 컨테이너에는 아무것도 설치되지 않습니다. 컨테이너 내부에 bash가 필요합니다. 공식 php:* 및 wordpress:* Debian 기반 이미지에는 bash가 있지만, Alpine 기반 이미지(-alpine)에는 없으므로 먼저 docker exec NAME apk add bash를 실행하거나 docker exec NAME php -v로 만족해야 합니다. 데이터베이스는 보통 별도의 컨테이너에 있으므로, PHP 컨테이너가 데이터베이스에 접근할 수 없는 한 사용자, 옵션 및 cron 검사는 건너뜁니다.
다음 항목을 환경 변수로 설정하십시오:
| 변수 | 기본값 | 의미 |
|---|---|---|
SINCE | 2026-10-17 | "최근 수정됨" 및 "최근 등록됨" 검사의 기간 시작점입니다. 이는 첫 번째 공격이 아니라 첫 번째 확인된 익스플로잇 시도이므로, 중요한 사이트라면 더 이른 시점으로 설정하십시오 |
WP | wp | 대상에서의 WP-CLI 명령입니다. 예: 공유 호스트의 경우 WP="php $HOME/wp-cli.phar" |
LOGS | 자동 | 스캔할 액세스, 오류 및 PHP-FPM 로그의 공백으로 구분된 경로 또는 glob입니다. 예: LOGS="/var/log/nginx/*.log* /var/log/php8.3-fpm.log*". 기본적으로 스크립트는 사이트 옆(../logs), ~/logs, ~/access-logs 및 ~/domains/*/logs에서 찾은 다음 /var/log 아래에서 찾습니다. 로테이션된 .gz 파일도 읽습니다 |
OUT | ./php2shell-reports | 보고서가 작성되는 위치입니다 |
WP="php $HOME/wp-cli.phar" SINCE=2026-10-15 ./php2shell-check.sh sites.txt
php2shell-reports/SUMMARY.md는 사이트당 한 행으로 구성된 표입니다:
| 사이트 | CLI PHP | 업로드 진행 | ⚠️ 문제 | 🔎 검토 | 보고서 |
|---|---|---|---|---|---|
| client-a:/var/www/html | 8.3.36 | off | 0 | 2 | client-a_var_www_html.md |
업로드 진행은 서버 수준에서 session.upload_progress.enabled=0이 확인된 경우 off, 확인되지 않은 경우 on, 읽을 수 있는 PHP 설정이 없는 경우 ?입니다.
각 사이트의 보고서는 검사 항목당 하나의 섹션으로 구성된 Markdown 파일이며, 다음을 사용합니다:
⚠️ 항목부터 시작한 뒤 🔎 항목을 차례로 확인하세요.
공격 시도는 침해가 아닙니다. 인터넷상의 거의 모든 PHP 사이트는 지금 이 순간에도 스캔당하고 있습니다. 액세스 로그에 나타난 익스플로잇 시도는 해당 사이트가 표적이 되었다는 것을 알려줄 뿐, 침해되었다는 것을 의미하지는 않습니다. 침해 여부는 파일 및 데이터베이스 검사를 통해 판단합니다.
5xx 버스트는 단일 로그 신호 중 가장 좋은 지표입니다. 이 취약점들은 메모리 손상 버그이므로, 실패하거나 부분적으로 성공한 공격 시도는 PHP 워커를 크래시시키는 경향이 있으며, 방문자는 접속한 URL에서 500 또는 502를 받게 됩니다. 전체 기간에 걸쳐 프록시 로그를 조사했지만 5xx가 전혀 없었다고 밝힌 한 팀은 이를 가장 안심이 되는 결과라고 평가했습니다. 트래픽이 많은 사이트에서는 기간 이전의 기준선이 필요합니다. 그렇지 않으면 정상적인 오류가 신호를 묻어버리기 때문입니다. 그래서 보고서는 SINCE 이전 최대 7일치를 해당 기간과 함께 보여줍니다. 동일한 URL에서 꾸준히 발생하는 소량의 오류는 고장 난 플러그인이며, 무작위 URL에 걸쳐 퍼진 버스트는 PHP-FPM 로그의 segfault 라인과 함께 면밀히 살펴볼 가치가 있습니다.
체크섬이 타임스탬프보다 신뢰할 수 있습니다. 공격자는 파일의 수정 시간을 임의로 조작할 수 있습니다. "최근 수정됨" 목록이 깨끗하다는 것은 안심이 되지만, verify-checksums 결과가 깨끗하다는 것은 증거입니다. 이 점은 여기서 평소보다 더 중요합니다. 10월 17일에 이 취약점을 익스플로잇하던 누군가에게는 아무도 살펴보기 전까지 나흘의 조용한 시간이 있었고, 이는 파일의 날짜를 소급 조작하고 로그를 정리하기에 충분한 시간입니다.
일부 탐지는 정상입니다.