2026년 하루 평균 보고된 CVE가 전년 대비 131% 증가했습니다.
← 모든 취약점

PHP2Shell: 인증 없이 가능한 PHP RCE와 빌드가 영향을 받았는지 확인하는 방법

PHP2Shell은 PHP 자체에 있는 두 가지 치명적인 취약점, CVE-2026-109618과 CVE-2026-109619로, 웹 요청을 처리하는 모든 PHP 설치 환경(PHP-FPM, mod_php를 사용하는 Apache, php-cgi, FrankenPHP, LiteSpeed)에서 인증되지 않은 웹 요청으로 코드가 실행되게 할 수 있습니다. 두 취약점 모두 실제로 악용되고 있으며 CISA의 KEV 카탈로그에 등재되어 있습니다. 수정 버전은 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35이며, PHP 8.1 이하에는 업스트림 릴리스가 없습니다. 업그레이드한 다음, 아직 실행 중인 오래된 태그와 고객에게 제공한 이미지를 포함해 PHP가 들어 있는 모든 컨테이너 이미지를 다시 빌드하고 재배포하세요.

알고 있는 서버를 패치하는 것은 쉬운 부분입니다. 오래 남는 노출은 잊어버린 PHP입니다. 베이스 이미지에 컴파일되어 들어간 런타임, 아직 프로덕션에서 실행 중인 작년 이미지 태그, CI 이미지, 지원이 종료된 PHP를 담은 채 고객에게 제공한 제품 같은 것들입니다. 이 페이지는 먼저 패치를 적용하는 방법을 안내한 다음, 나머지를 찾는 방법을 보여 줍니다.

무슨 일이 있었나

날짜(2026년)사건출처
8월 11일, 21일Calif가 PHP 프로젝트에 두 버그를 보고Calif
10월 17일Amazon이 허니팟에서 처음 관찰한 악용 시도(공개 이전)Amazon Threat Intelligence
10월 20일PHP가 CVSS 4.0 9.2로 평가된 두 취약점을 수정하는 보안 릴리스를 10월 21일 14:00 UTC에 낸다고 발표php.net
10월 21일PHP가 8.5.12, 8.4.27, 8.3.36, 8.2.35를 출시하고 보안 권고를 게시. CVE 레코드가 공개되고 NCSC-NL이 php2shell 리포지토리를 개설PHP 보안 권고, NCSC-NL
10월 21일공식 Docker php 이미지가 수정 버전으로 업데이트됨docker-library/php
10월 21일watchTowr가 두 CVE의 실제 악용을 보고하고 CISA가 경보를 게시watchTowr, CISA
10월 22일Searchlight Cyber가 php2shell-scanner를 공개GitHub
10월 23일PHP가 가능성이 낮은 별도의 RCE 경로인 CVE-2026-115560에 대해 session.upload_progress.enabled=0 설정을 권고php.net
10월 26일CISA가 두 CVE를 KEV 카탈로그에 추가. 미국 연방 기관의 조치 기한은 10월 29일CISA KEV

PHP2Shell이라는 이름은 Calif의 분석 글에서 나왔으며 업계 보도 전반에서 쓰이지만, PHP 자체의 보안 권고에서는 사용하지 않습니다. CVE 레코드는 Calif, Wiz, OpenAI를 발견자로 명시합니다.

영향을 받는 대상

웹 요청을 처리하는 모든 PHP입니다. PHP의 보안 권고는 PHP-FPM, mod_php를 사용하는 Apache, php-cgi, FrankenPHP, LiteSpeed를 명시하고, mod_php의 위험이 가장 높다고 하며 "인증되지 않은 요청이 애플리케이션 코드가 실행되기도 전에 공격을 일으킬 수 있음을 보여 주는 익스플로잇이 입증되었다"고 설명합니다. 버그가 PHP 자체에 있으므로 Laravel, Symfony, WordPress로 만든 애플리케이션도 그 아래의 PHP가 영향을 받으면 함께 노출됩니다.

브랜치영향받는 버전수정 버전업스트림 지원
8.58.5.12 이전8.5.12활성 지원
8.48.4.27 이전8.4.27활성 지원
8.38.3.36 이전8.3.36보안 수정만 제공, 2027년 12월 31일까지
8.28.2.35 이전8.2.35보안 수정만 제공, 2026년 12월 31일까지
8.1, 8.0, 7.4모든 버전(Calif와 watchTowr의 보고 기준)릴리스 없음. php-src에 최소한의 소스 백포트 있음지원 종료
7.3 이하(PHP 5 포함)모든 버전(Calif와 watchTowr의 보고 기준)업스트림 수정 없음지원 종료

PHP의 보안 권고는 지원 중인 브랜치만 나열합니다. 그보다 오래된 브랜치에 대해 Calif는 "우리가 찾은 가장 오래된 영향받는 경로는 PHP 5.4.0까지 거슬러 올라간다"고 보고하고, watchTowr는 PHP 7과 PHP 5를 수정 없이 영향받는 버전으로 분류합니다. PHP는 8.1 이하 브랜치가 "더 이상 PHP 프로젝트에서 업데이트를 받지 않는다"고 밝혔지만, 소스에서 직접 빌드하는 사용자를 위해 7.4, 8.0, 8.1용 최소한의 소스 백포트를 공개했습니다. 일부 배포판과 상용 장기 지원 업체는 지원이 종료된 브랜치용으로 백포트한 수정을 제공합니다. 사용 중인 곳에 문의하세요. 다음 메이저 버전을 테스트하고 있다면, 같은 날 출시된 PHP 8.6.0 RC4에도 수정이 포함되어 있습니다.

작동 방식

두 CVE 모두 PHP가 요청을 준비하고 정리하는 과정에 있는 메모리 안전성 버그로, 애플리케이션 코드보다 아래 계층에 있습니다. CVE 레코드는 두 취약점을 모두 해제 후 사용(CWE-416)으로 분류하며, 예외 상황의 부적절한 처리, 초기화되지 않은 포인터 접근, 통제되지 않은 메모리 할당, 잘못된 초기화(CWE-755, CWE-824, CWE-1325, CWE-1419)로도 분류합니다. PHP의 설명은 다음과 같습니다.

  • CVE-2026-109618, OOM 손상을 통한 RCE: "메모리 부족 처리로 인해 내부 요청 데이터가 일부만 초기화된 상태에서 PHP가 중단될 수 있습니다. 그러면 요청 정리 과정에서 잘못된 데이터를 유효한 것으로 취급할 수 있습니다." PHP가 파싱하는 동안 메모리를 소진하도록 만든 요청 본문이 이 중단을 일으킬 수 있습니다. mod_php를 사용하는 Apache는 요청 시작이 실패해도 정리 과정을 실행하므로, 그곳에서는 애플리케이션 코드가 실행되기 전에 공격이 성공합니다. PHP-FPM에 대해 PHP의 보안 권고는 소스 분석상 취약할 가능성이 있다고 보지만, FPM에 대한 완전한 익스플로잇은 아직 입증되지 않았다고 밝힙니다.
  • CVE-2026-109619, 오래된 전역 상태를 통한 RCE: "요청이 소유한 내부 상태가 그 기반 메모리가 해제된 뒤에도 남아 있을 수 있습니다. 같은 워커가 처리하는 이후의 요청이 정상적인 초기화로 재설정되기 전에 그 오래된 상태를 사용할 수 있습니다." 같은 워커에 도달하는 두 요청이 필요합니다. 치명적 오류 등으로 상태를 남기는 요청과 그 상태를 사용하는 요청입니다. PHP의 보안 권고는 세션 업로드 진행률 경로를 mod_php와 FPM에서, PHP 8.5의 치명적 오류 백트레이스 경로를 mod_php에서 확인했습니다.

PHP의 임시 설정이 메모리 한도, 요청 본문 크기, 세션 업로드 진행률, 치명적 오류 백트레이스를 겨냥하는 이유가 여기에 있습니다. 각 설정은 버그 자체가 아니라 버그에 이르는 경로를 하나씩 막습니다. CNA인 PHP는 CVSS 4.0 기준으로 두 취약점을 모두 9.2로 평가합니다. NVD 자체의 CVSS 3.1 평가는 CVE-2026-109618이 9.8, CVE-2026-109619가 8.1입니다.

영향을 받았는지 확인하는 방법

알고 있는 호스트부터 시작한 다음, 빌드하고 제공하는 모든 것에서 PHP를 찾으세요.

호스트나 VM에서는 PHP가 보고하는 버전을 확인하세요. php-fpm이나 Apache 모듈은 명령줄과 다른 패키지에서 올 수 있으므로 웹 SAPI도 확인하세요.

php -v
php-fpm -v

배포판 패키지(Debian, Ubuntu, Alpine, RHEL)는 새 업스트림 버전 없이 백포트로 수정을 받는 경우가 많습니다. 예를 들어 Ubuntu 24.04는 수정을 8.3.6-0ubuntu0.24.04.13으로 제공합니다. 이 경우 버전 확인만으로는 오판하기 쉽습니다. 설치된 패키지를 나열하고, 배포판 보안 트래커에 있는 수정된 패키지 버전과 비교하세요.

dpkg -l 'php*' | grep '^ii'    # Debian, Ubuntu
apk info -v | grep '^php'      # Alpine
rpm -qa 'php*'                 # RHEL, Fedora, Rocky, Alma

컨테이너 이미지에서는 공식 php: 이미지가 PHP를 소스에서 컴파일하므로, 버전 정보는 배포판 패키지 목록이 아니라 이미지 자체에 있습니다. 이미지에 직접 물어보세요.

docker run --rm --entrypoint php php:8.3-fpm -v

실제로 실행하는 모든 이미지를 확인하려면 목록을 뽑아 각 이미지에 물어보세요. Kubernetes의 경우:

kubectl get pods -A \
  -o jsonpath='{range .items[*]}{range .spec.containers[*]}{.image}{"\n"}{end}{end}' \
  | sort -u \
  | while read -r image; do
      version=$(docker run --rm --entrypoint php "$image" -r 'echo PHP_VERSION;' 2>/dev/null)
      printf '%s\t%s\n' "${version:-no php}" "$image"
    done

FROM debian이나 FROM alpine으로 빌드하고 패키지 관리자로 PHP를 설치한 이미지는 위의 패키지 확인을 이미지 안에서 실행해야 합니다.

리포지토리에서는 PHP를 선택하는 모든 곳을 검색하세요.

git grep -nE '^FROM[[:space:]]+(.*/)?php:' -- '*Dockerfile*' '*.dockerfile'
git grep -nE 'php-version|image:.*php' -- .github/workflows '*.yml' '*.yaml'

php:8.3.30-fpm 같은 고정 태그는 누군가 바꿀 때까지 취약한 상태로 남습니다. php:8.3-fpm 같은 유동 태그는 10월 21일부터 수정 버전으로 다시 빌드되었지만, 그 전에 빌드한 이미지는 다시 빌드할 때까지 이전 PHP를 유지합니다. php 제약 조건(composer.json)은 코드가 허용하는 버전을 말할 뿐, 실제로 실행되는 버전을 말하지 않습니다.

CI에서는 빌드와 테스트 작업이 자체 PHP를 사용하는 경우가 많습니다. php: 서비스 컨테이너, php-version 입력을 받는 설정 액션, 러너 이미지 등입니다. 이들은 프로덕션 트래픽을 처리하지 않지만, 파이프라인이 어떤 이미지와 버전을 만들어 내는지 보여 줍니다.

노출된 호스트. Searchlight Cyber의 php2shell-scanner는 경로당 약 29 MiB의 대용량 멀티파트 요청으로 URL을 점검합니다. 테스트 권한이 있는 호스트에만 실행하세요. README에서는 memory_limit이 낮은 패치된 PHP에서 오탐이 발생할 수 있으며, PHP가 버전을 공개하지 않으면 스캐너가 패치된 서버와 취약한 서버를 구별할 수 없다고 경고합니다. 증거가 아닌 단서로 취급하세요. NCSC-NL의 리포지토리에는 탐지 규칙과 PHP를 번들로 포함하는 제품 목록 및 그 상태가 정리되어 있습니다.

오늘의 스캔으로 알 수 없는 것. 오늘 레지스트리의 이미지를 스캔하면 오늘 배포할 것만 확인할 수 있습니다. 이전에 고객에게 제공한 릴리스, 고객이 아직 실행 중인 오래된 태그, 어떤 빌드가 취약한 PHP가 든 이미지를 만들었는지는 알 수 없습니다. 이를 알려면 각 빌드에 무엇이 들어갔는지를 릴리스별로 기록해 두어야 합니다. 우리는 영향을 받았는가? 빌드 전반에서 새 CVE를 평가하는 방법을 참조하세요.

수정 방법과 아직 패치할 수 없을 때 할 일

  1. 업그레이드하세요. 8.5.12, 8.4.27, 8.3.36, 8.2.35 또는 배포판의 수정된 패키지로 업그레이드하세요. 8.1 이하라면 지원 중인 브랜치로 옮기세요. PHP의 백포트와 업체 빌드는 임시방편입니다.
  2. 모든 이미지를 다시 빌드하세요. 수정된 베이스에서(베이스 이미지를 다시 pull하거나 캐시 없이 빌드해) 다시 빌드하고 재배포하세요. 이미 실행 중인 이미지는 교체될 때까지 이전 PHP를 유지하므로 워크로드도 다시 시작하세요.
  3. 검증하세요. 새 이미지뿐 아니라 실행 중인 컨테이너를 대상으로 아래 체크리스트에 따라 확인하세요.

아직 업그레이드할 수 없다면, PHP의 보안 권고는 "특정 공격 경로에 대한 노출을 줄이지만 설치 환경을 안전하게 만들지는 않는" 조치를 제시합니다. CVE-2026-109618에 대해서는 다음과 같습니다.

  • "memory_limit=-1을 설정하세요. 가급적 FPM 풀이나 Apache 구성의 php_admin_value처럼 애플리케이션이 덮어쓸 수 없는 방식으로 설정하고, 어떤 풀, 디렉터리, 애플리케이션 설정도 유한한 한도를 되돌려 놓지 않는지 확인하세요."
  • "파일 업로드가 필요 없는 애플리케이션은 post_max_size = 8M으로 설정하세요. 파일 업로드가 필요하다면 post_max_size = 32M으로 설정하세요. upload_max_filesize는 post_max_size보다 작게 유지하세요."
  • 가용성의 경계로는 컨테이너 또는 cgroup 메모리 제한을 사용하고, RLIMIT_AS나 RLIMIT_DATA로 대신하지 마세요. "이들은 취약한 메모리 할당 실패를 일으킬 수 있기 때문"입니다.

CVE-2026-109619에 대해서는 다음과 같습니다.

  • "session.upload_progress.enabled=0을 설정하고 모든 워커를 다시 시작하세요. php.ini, FPM 풀 또는 요청 파싱 전에 적용되는 서버 구성을 사용하세요. ini_set()이나 FPM .user.ini에 의존하지 마세요."
  • "PHP 8.5에서는 fatal_error_backtraces=0을 설정하고 모든 워커를 다시 시작하세요."

각 워커가 실제로 어떤 설정으로 실행되는지 확인하세요.

php-fpm -i | grep -E 'memory_limit|post_max_size|session.upload_progress.enabled'

CISA의 경보는 한발 더 나아가, 즉시 업데이트할 수 없거나 아직 PHP 8.1 이하를 운영하는 조직은 "패치하거나 업데이트할 수 있을 때까지 PHP 기반 시스템을 오프라인으로 전환해야 한다"고 권고합니다. 또한 셸을 실행하거나 도구를 내려받는 PHP 워커 프로세스를 감시하라고 권고합니다.

수정 검증

  1. 배포하려던 이미지가 아니라 실행 중인 PHP에 물어보세요. 실행 중인 각 컨테이너와 각 호스트에서 php-fpm -v(또는 php -v)를 실행해 8.5.12, 8.4.27, 8.3.36, 8.2.35 이상인지 확인하세요.
  2. 배포판 패키지에서는 버전 문자열만 믿지 마세요. Debian, Ubuntu, RHEL 등의 배포판은 이미 제공 중인 버전에 수정을 백포트하므로, 패치된 PHP도 8.3.6으로 표시될 수 있습니다. Ubuntu 24.04의 수정은 8.3.6-0ubuntu0.24.04.13입니다. 전체 패키지 버전을 배포판 보안 트래커와 비교하거나, 패키지 변경 로그에서 CVE를 찾아보세요. 대개 CVE가 명시되어 있습니다. 반대 방향의 함정도 있습니다. 업스트림 버전 번호만 비교하는 스캐너는 백포트된 패키지를 취약하다고 표시할 수 있습니다.
  3. 모든 워크로드가 다시 빌드한 이미지로 실행되는지 확인하세요. 태그가 이제 수정된 이미지를 가리켜도, 이전 이미지를 pull한 파드는 바뀌지 않습니다. 각 컨테이너가 실행 중인 이미지 다이제스트를 빌드한 다이제스트와 비교하세요.
kubectl get pods -A \
  -o jsonpath='{range .items[*]}{range .status.containerStatuses[*]}{.image}{"\t"}{.imageID}{"\n"}{end}{end}'
  1. 모든 워커가 다시 시작되었는지 확인하세요. PHP-FPM과 Apache는 다시 시작할 때까지 이전 코드를 메모리에 유지합니다. "침해 여부 확인"의 프로세스 점검으로 아직 이전 코드를 실행 중인 프로세스를 찾을 수 있습니다.
  2. 아직 임시 설정에 의존하고 있다면, 위의 php-fpm -i 명령으로 각 풀을 확인하고, 모든 곳에서 업그레이드가 끝날 때까지 설정을 유지하세요.
  3. 확인 방법 섹션의 인벤토리를 다시 실행하세요. 프로덕션뿐 아니라 레지스트리, CI 이미지, 고객이 실행 중인 릴리스 전체를 대상으로 하세요.

침해 여부 확인

PHP2Shell은 실제로 악용되고 있으며, Amazon은 수정 4일 전인 2026년 10월 17일에 첫 시도를 관찰했습니다. 인터넷에 노출된 PHP가 그 이후 어느 시점에든 임시 설정 없이 영향받는 버전으로 실행되었다면 확인하세요.

노출 규모. CybelAngel이 보도한, Mallory가 10월 20일에 공개한 Shodan 배너 집계에 따르면 PHP를 표시하는 인터넷 노출 호스트는 224만 대였습니다. 버전을 표시하는 약 150만 대 중 883,717대(59%)가 공식 수정이 없는 브랜치를 실행합니다. 이는 호스트 수이지 취약성이 확인된 시스템 수가 아닙니다. 백포트된 패키지는 오래되어 보여도 패치되어 있을 수 있고, 약 74만 대의 호스트는 버전을 숨깁니다.

PHP를 번들로 포함하는 어플라이언스와 제품. PHP는 어플라이언스, 네트워크 장비, 관리 인터페이스, 업체 제품 안에서도 실행되며, 직접 업데이트할 수 없는 경우가 있습니다. NCSC-NL의 목록은 2026년 11월 9일 기준으로 이런 제품 968개를 추적했습니다. 수정됨 205개, 취약 215개, 조사 중 93개, 런타임에 따라 다름 240개, 영향 없음 214개입니다. 이런 제품은 별도로 확인하고, 업체 업데이트가 나오는 즉시 적용하세요.

수정이 실제로 실행 중인지 확인하세요. 호스트와 VM에서는 업그레이드 전에 시작된 PHP-FPM, php-cgi, Apache 프로세스가 여전히 이전 코드를 실행합니다. 이때 메모리 맵에는 교체된 바이너리나 libphp가 삭제됨으로 표시됩니다. 프로세스 시작 시각도 업그레이드 시각과 비교하세요.

for pid in $(pgrep -f 'php-fpm|php-cgi|apache2|httpd|frankenphp'); do
  grep -qE '(php|libphp)[^/]*\(deleted\)' "/proc/$pid/maps" 2>/dev/null \
    && echo "PID $pid still runs a replaced PHP"
done
ps -o pid,lstart,args -p "$(pgrep -d, -f 'php-fpm|php-cgi|apache2|httpd|frankenphp')"

1차 출처의 침해 지표:

  • 요청: 문자열 PHP_SESSION_UPLOAD_PROGRESS가 포함된 폼 업로드 POST 요청. Amazon Threat Intelligence가 악용 시도에서 관찰한 것입니다. Amazon은 출발지 주소(103.216.220.92, 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188, 95.217.98.37)도 제시하지만, 공유 익명화 인프라에 속한다고 밝힙니다. 일치하면 조사하되 증거로 취급하지 마세요.
  • 프로세스와 파일: 셸을 실행하거나 도구를 내려받는 PHP 워커 프로세스(10월 23일에 Sigma 탐지 규칙을 추가한 CISA 기준), 웹 서버의 예상치 못한 프로세스 실행이나 파일 변경(Amazon 기준).
  • 로그: Apache, PHP-FPM, 리버스 프록시, 서비스 로그에서 스크립트 실행 전에 반복되는 경고나 코어 오류, 치명적 오류와 파싱 오류, Maximum execution time exceeded. PHP의 보안 권고는 "로그에 오류가 없다고 해서 안전하다는 증거는 아니다"라고 덧붙입니다.

침해를 가정해야 할 때. 이 지표 중 하나라도 발견되거나, 노출된 서버가 완화 조치 없이 영향받는 PHP를 실행했고 로그로 악용을 배제할 수 없다면 침해된 것으로 간주하세요. PHP는 영향을 웹 워커 계정 권한의 원격 코드 실행으로 설명하며, 이 계정은 대개 애플리케이션의 구성과 시크릿을 읽을 수 있습니다.

워커가 읽을 수 있었던 것을 교체하세요. 환경 변수와 구성 파일에 있는 데이터베이스 비밀번호, API 키, 토큰, 세션이나 쿠키에 서명하는 키(와 그 키로 서명된 세션), 호스트에서 사용할 수 있는 클라우드 자격 증명입니다. 새 시크릿이 침해된 머신에 놓이지 않도록 호스트를 다시 구축한 뒤에 교체하세요.

정리하지 말고 다시 구축하세요. 침해된 호스트나 컨테이너는 신뢰할 수 있는 이미지로 교체하고, 업로드 디렉터리, 캐시, 생성된 코드처럼 워커가 쓸 수 있었던 파일은 옮기지 마세요. 침해된 호스트에서 만든 이미지, 빌드 캐시, 아티팩트도 재사용하지 마세요.

고객에게 알릴 내용

PHP로 실행되는 소프트웨어를 제공한다면 고객이 물어 올 것입니다. 모든 답을 갖추기 전이라도 버전과 조치로 답하세요. 상황에 맞게 고쳐 쓸 수 있는 답변 예시입니다.

PHP2Shell(CVE-2026-109618, CVE-2026-109619)은 8.5.12, 8.4.27, 8.3.36, 8.2.35 이전 PHP 버전과 그보다 오래된 모든 PHP 브랜치에 영향을 줍니다. [제품] 버전 [xy]는 PHP [버전]을 포함하며 영향을 받습니다. [날짜]에 출시된 버전 [z]는 PHP [수정 버전]을 포함합니다. [z]로 업그레이드해 주세요. 바로 업그레이드할 수 없다면 저희 보안 권고 [링크]의 PHP 설정을 적용하고 애플리케이션에 대한 네트워크 접근을 제한해 주세요. [제품] 버전 [ab]는 영향을 받지 않습니다. [날짜]까지 이 공지를 업데이트하겠습니다.

아직 확인 중이라면 그렇다고 말하고, 언제 답할지 알려 주세요. 첫 공지와 결과별 템플릿은 공급망 공격 후 고객에게 답하는 방법을 참고하세요.

CRACI의 역할

CRACI는 GitHub Actions 작업을 실행하면서 각 작업이 빌드 중에 가져오는 것(컨테이너 이미지, apt 및 apk 패키지, Composer 패키지 등)을 기록하고, 모든 과거 빌드를 SBOM과 함께 보관합니다. CVE가 공개되면 지속적인 재평가가 영향받는 패키지를 포함했던 과거 빌드를 표시하므로, 오늘의 스캔 결과뿐 아니라 어떤 릴리스가 얼마나 오랫동안 노출되었는지 알 수 있습니다. 정책 게이트로 특정 CVE가 포함된 빌드를 차단할 수도 있습니다.

이번 사고에는 한계가 하나 있습니다. 공식 php: 이미지에 컴파일되어 들어간 PHP는 패키지 다운로드가 아니라 이미지 안에 담겨 들어옵니다. CRACI는 각 빌드가 pull한 이미지 참조를 기록하므로, PHP 패키지뿐 아니라 php: 태그로도 빌드를 검색하세요.

취약한 PHP를 제공한 빌드를 모두 찾아보세요

빌드 기록에 대해 더 알아보기: 빌드 시점 SBOM, Docker 이미지 SBOM, 컨테이너 스캔이 놓치는 것, CISA KEV 카탈로그, CVE 공개 동향. 다른 사고: 모든 취약점.

이번 사고를 넘어선 PHP 보안은 PHP 보안 가이드를 참고하세요.

출처 및 업데이트

1차 출처:

조사 및 분석:

업데이트:

  • 2026-11-11: 정보 상자에 NVD 점수, EPSS, CWE 분류, 발견자, 최신 안전 버전, 지원 종료일을 추가하고, PHP 8.6.0 RC4와 버그 작동 방식, 수정 검증, 침해 여부 확인 섹션을 추가.
  • 2026-11-11: 최초 게시.

자주 묻는 질문

PHP2Shell이란 무엇인가요?

PHP2Shell은 PHP 자체에 있는 두 가지 치명적인 취약점, CVE-2026-109618과 CVE-2026-109619를 가리키는 이름입니다. 둘 다 PHP를 실행하는 서버에서 인증되지 않은 웹 요청으로 코드가 실행되게 할 수 있습니다. PHP는 2026년 10월 21일에 두 취약점을 수정했으며, CVSS 4.0 기준으로 각각 9.2로 평가합니다.

PHP2Shell이 실제로 악용되고 있나요?

네. Amazon Threat Intelligence는 공개 이전인 2026년 10월 17일자 악용 시도를 보고했고, watchTowr는 10월 21일에 두 CVE가 실제로 악용되고 있다고 보고했습니다. CISA는 2026년 10월 26일에 두 CVE를 알려진 악용 취약점(KEV) 카탈로그에 추가했습니다.

PHP2Shell을 수정한 PHP 버전은 무엇인가요?

2026년 10월 21일에 출시된 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35입니다. 이 브랜치들의 그 이전 릴리스는 모두 영향을 받습니다. 배포판 패키지는 이전 버전 번호를 유지한 채 수정 사항을 포함할 수 있으므로 사용 중인 배포판의 보안 트래커를 확인하세요.

PHP 7이나 PHP 5도 영향을 받나요? 수정 버전이 있나요?

PHP 8.1 이하 버전은 더 이상 PHP 프로젝트에서 릴리스를 받지 않습니다. Calif와 watchTowr는 PHP 7과 PHP 5도 영향을 받는다고 보고합니다. PHP 보안 팀은 7.4, 8.0, 8.1용 최소한의 소스 백포트를 php-src의 브랜치로 공개했지만, 그보다 오래된 버전에는 업스트림 수정이 없습니다. 업그레이드하거나 배포판 또는 장기 지원 업체에 문의하세요.

PHP2Shell은 PHP-FPM, Apache mod_php, FrankenPHP, LiteSpeed에 영향을 주나요?

네. PHP의 보안 권고는 PHP-FPM, mod_php를 사용하는 Apache, php-cgi, FrankenPHP, LiteSpeed를 포함해 웹 요청을 처리하는 모든 설치 환경을 명시하며, mod_php의 위험이 가장 높다고 봅니다. 명령줄 PHP도 대개 같은 빌드에서 나오므로 함께 업그레이드하세요.

지금 바로 업그레이드할 수 없다면 어떻게 해야 하나요?

애플리케이션이 덮어쓸 수 없는 방식으로 memory_limit=-1을 설정하고, post_max_size를 8M(업로드가 필요하면 32M)으로, session.upload_progress.enabled=0으로 설정한 뒤 모든 워커를 다시 시작하세요. PHP에 따르면 이 조치들은 특정 공격 경로에 대한 노출을 줄이지만 설치 환경을 안전하게 만들지는 않습니다. CISA는 패치할 수 없다면 PHP 시스템을 오프라인으로 전환하라고 권고합니다.

서버가 침해되었는지 어떻게 알 수 있나요?

Amazon이 첫 악용 시도를 관찰한 2026년 10월 17일까지 거슬러 올라가, PHP_SESSION_UPLOAD_PROGRESS가 포함된 폼 업로드 POST 요청, 셸을 실행하거나 도구를 내려받는 PHP 워커, 예상치 못한 파일 변경을 찾아보세요. 인터넷에 노출된 서버가 임시 설정 없이 영향받는 PHP를 실행했고 악용 가능성을 배제할 수 없다면 침해된 것으로 간주하세요. 깨끗한 이미지에서 다시 구축하고 웹 워커가 읽을 수 있었던 모든 시크릿을 교체하세요.