Critical CVSS 9.2 CVE-2026-109618 · CVE-2026-109619 2026-10-21 공개 · 2026-10-22 갱신

php2shell — PHP 엔진 인증 전 원격코드실행

취약점이 애플리케이션이 아니라 PHP 코어에 있습니다. 설정이나 프레임워크 종류와 무관하게 성립하며, 연구진은 PHP 업그레이드가 유일한 완전한 조치라고 명시했습니다.

TL;DR

수정 릴리스(8.2.35 · 8.3.36 · 8.4.27 · 8.5.12)로 업그레이드
Apache · PHP-FPM · 장시간 실행되는 모든 PHP 워커 재시작
컨테이너 이미지 · 호스팅 · 제품 내장 PHP까지 전수조사

점검 스캐너로 전수조사 자주 묻는 질문

Impact

PHP를 쓰는 모든 자산이 대상입니다

WordPress · Drupal · Joomla도 예외가 아닙니다. 취약점이 PHP 엔진 자체에 있어 애플리케이션 종류나 설정과 무관하게 성립합니다.

서버의 PHP

가상 호스트별로 다른 버전이 떠 있을 수 있습니다.

컨테이너 이미지

베이스 이미지를 다시 빌드해야 반영됩니다.

호스팅 업체

패치 적용 여부를 업체에 직접 확인해야 합니다.

제품 내장 PHP

장비·어플라이언스 펌웨어 안의 PHP도 포함됩니다.

Vulnerabilities

취약점 2건

PHP 코어에서 서로 연관된 두 유형이 확인됐습니다. 메모리 부족(OOM) 손상, 그리고 요청 간에 남는 낡은 전역 상태입니다. 두 건 모두 CVSS 9.2입니다.

CVE	유형	공격자가 할 수 있는 것	입증된 공격
CVE-2026-109618	메모리 부족(OOM) 손상	인증 없이 PHP 웹 워커 권한으로 코드 실행	WordPress · Drupal · Joomla 인증 전 RCE
CVE-2026-109619	요청 간 낡은 전역 상태	use-after-free로 워커 메모리 노출 또는 코드 실행	WordPress · Drupal 인증 전 RCE, 메모리 노출

Patch

업그레이드 대상 버전

패키지만 교체하고 워커를 재시작하지 않으면 기존 워커가 구 코드로 계속 동작합니다.

브랜치	취약 버전	첫 수정 릴리스
8.2	< 8.2.35	8.2.35
8.3	< 8.3.36	8.3.36
8.4	< 8.4.27	8.4.27
8.5	< 8.5.12	8.5.12
7.4 · 8.0 · 8.1	정규 릴리스 없음	php-src 소스 백포트

Mitigation

지금 업그레이드가 어렵다면

아래는 모두 시간을 버는 수단이지 해결책이 아닙니다. 설정을 바꾼 뒤에도 영향받는 워커를 재시작해야 적용됩니다.

대체 메모리 한계로 RLIMIT_AS나 RLIMIT_DATA를 사용하지 마십시오. 연구진이 명시한 금지 사항입니다.

memory_limit 비활성화 검토 일부 경로 차단

post_max_size 하향 메모리 압력 축소

max_input_nesting_level 하향 메모리 압력 축소

session.upload_progress.enabled = 0 일부 경로 차단

display_errors = 0 정보 노출 축소

fatal_error_backtraces = 0 PHP 8.5 해당

pm.max_requests 하향 공격 구간 축소

SELinux · AppArmor 정책 악용 후 영향 제한

ZIEN view

영향 목록보다 공격 가능성 판정이 병목입니다

php2shell은 패치 버전만 알면 끝나는 사안이 아닙니다. PHP를 쓰는 모든 자산이 대상이라 영향 목록이 길게 나오고, 그중 실제로 공격이 성립하는 자산을 가려야 조치 순서가 정해집니다.

판정에 필요한 변수는 자산마다 다릅니다. mod_php인지 PHP-FPM인지, multipart 요청이 그 경로에 닿는지, session.upload_progress와 memory_limit이 어떤 값인지에 따라 같은 버전이라도 결과가 갈립니다.

조직이 실제로 치르는 비용은 패치 작업 자체보다 영향 범위를 닫는 데 드는 시간입니다. 구성품과 버전 정보를 평소에 정리해 두면 다음 취약점 때 그 시간이 줄어듭니다.

FROM DETECTION TO DECISION

30%

전체 CVE 중 실제로 공격이 성립하는 비율

70%

공격 가능성 판정으로 줄어드는 패치 대상

FAQ

자주 묻는 질문

php2shell의 해결책은 무엇인가요?

영향받는 모든 런타임에 PHP 보안 업데이트를 적용하고 관련 서비스와 워커를 재시작하는 것입니다. 연구진은 "PHP 업그레이드가 유일한 완전한 조치"라고 명시했습니다.

WAF로 보호할 수 있나요?

완전히는 보호하지 못합니다. 연구진은 WAF 커버리지가 제공업체와 악용 경로에 따라 달라진다고 밝혔고, PHP 공식 공지도 완전한 완화책은 없으며 업데이트가 유일한 안전한 선택이라고 명시했습니다.

우리 제품·시스템이 영향받는지 어떻게 점검하나요?

세 가지를 확인합니다. CLI의 php -v가 아니라 웹 요청을 처리하는 SAPI 기준의 실제 버전, 배포판 패키지의 전체 버전 번호, 그리고 패치 후 워커 프로세스 재시작 여부입니다.

구성품 목록(SBOM)이 없으면 영향 범위 판정 자체가 어렵습니다.

memory_limit을 비활성화하면 공격을 막을 수 있나요?

일부 경로만 막습니다. PHP 공식 보안 공지는 기저 할당 실패가 여전히 취약 경로에 도달할 수 있다고 밝혔습니다. 메모리 한계를 없애면 요청 하나가 서버 메모리를 전부 소비할 수 있으므로 요청 크기 제한을 함께 적용해야 합니다.

PHP 8.1 이하를 쓰고 있다면 어떻게 해야 하나요?

정규 릴리스는 없지만 방법이 있습니다. PHP 보안팀이 7.4 · 8.0 · 8.1에 최소 소스 백포트를 php-src 저장소의 전용 브랜치로 공개했습니다. 배포판과 LTS 벤더의 백포트 패키지 제공 여부도 확인하시기 바랍니다.

참고 자료

PHP2Shell 연구진 공개 자료 · PHP 공식 보안 공지 · NVD 109618 · NVD 109619

연구·책임 공개: Wiz Research, OpenAI Codex Security, Calif. 버전·완화 항목은 2026년 10월 22일 조회 기준이며, 배포판별 패치 상태와 실제 실행 환경은 별도로 확인해야 합니다.