2026년 10월 21일 패치가 공개됐습니다. CVSS 9.2. 인증이 필요 없습니다. 요청 파싱 단계에서 발생하므로 애플리케이션 코드로는 막지 못합니다. PHP 5.4 이후 거의 모든 버전이 대상입니다.
PHP 코어의 메모리 처리 결함 두 건입니다. 애플리케이션 취약점이 아니라 런타임 결함이라, 그 위에서 동작하는 모든 것이 영향을 받습니다.
PHP 는 폼 데이터를 해시 테이블에 담습니다. 칸을 하나 늘릴 때 키를 할당하기 전에 개수 카운터를 먼저 올리는 구간이 있습니다.
그 할당이 memory_limit 에 걸리면 PHP 는 치명적 오류를 내고 삽입을 포기합니다. 카운터는 이미 올라간 뒤라, 값이 들어가지 않은 칸이 테이블에 남습니다.
요청 종료 시점에 PHP 는 그 테이블을 정리하면서 빈 칸의 잔여 바이트를 정상적인 PHP 값으로 해석합니다. 이 지점에서 공격자가 영향을 줄 수 있는 호출이 일어납니다.
발생 시점이 요청 파싱 도중입니다. 대상 스크립트가 실행되기 전이라 애플리케이션 코드에는 막을 자리가 없습니다.
PHP 워커 하나는 요청을 여러 번 처리합니다. 워커 전역 변수 중 일부는 특정 요청이 소유한 메모리를 가리킵니다.
그 메모리를 해제하면서 참조를 비우지 않으면 다음 요청이 이미 해제된 메모리를 따라갑니다. use-after-free 입니다.
상태가 남는 경로는 둘입니다. 치명적 오류가 정리 도중에 끼어드는 경우, 그리고 종료 단계의 진단 출력이 정리된 상태를 되살리는 경우입니다.
업로드 경로가 특히 문제입니다. session.upload_progress 는 기본값이 활성이고, 애플리케이션이 session_start() 를 호출하지 않아도 동작합니다.
PHP Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 3500032 bytes) in Unknown on line 0
[mpm_prefork:notice] AH00052: child pid 3421 exit signal Segmentation fault (11)
POST /index.php HTTP/1.1" 500 - "-" "-" 동일 워커에서 짧게 몰린 뒤 소강
in Unknown on line 0 — 스크립트가 아니라 요청 초기화 중에 발생했다는 표시입니다. 메모리 오류만으로 공격을 단정할 수는 없습니다. 반대로 로그가 조용하다고 안전한 것도 아닙니다. 성공한 공격은 워커를 종료시키지 않고 지나갈 수 있습니다.
노출면을 줄이는 임시 조치입니다. 변종을 모두 막지는 못합니다.
세 번째 자리까지 확인해야 합니다. 8.3 을 쓴다고 끝이 아니라 8.3.36 이상이어야 합니다.
| 브랜치 | php2shell | 고쳐진 버전 | 보안 지원 종료 | 상태 |
|---|---|---|---|---|
| 8.5 | 영향 | 8.5.12 | 2029-12-31 · 1160일 | 정식 지원 |
| 8.4 | 영향 | 8.4.27 | 2028-12-31 · 795일 | 정식 지원 |
| 8.3 | 영향 | 8.3.36 | 2027-12-31 · 429일 | 보안 패치만 |
| 8.2 | 영향 | 8.2.35 | 2026-12-31 · 64일 | 보안 패치만 |
| 8.1 | 영향 | 정식 릴리스 없음 | 2025-12-31 | 지원 종료 |
| 8.0 | 영향 | 정식 릴리스 없음 | 2023-11-26 | 지원 종료 |
| 7.4 | 영향 | 정식 릴리스 없음 | 2022-11-28 | 지원 종료 |
| 7.3 이하 | 영향 | 정식 릴리스 없음 | 2021-12-06 | 지원 종료 |
8.1 이하는 지원이 끝나 정식 보안 릴리스가 나오지 않습니다. 일부 배포판과 상용 벤더가 백포트를 제공하지만, 해당 서버가 그것을 받고 있는지는 따로 확인해야 합니다. 올린 뒤에는 PHP-FPM 이나 아파치를 재시작해야 적용됩니다.
호스팅사의 역할은 서버 임대입니다. PHP 를 올렸다가 사이트가 깨지면 책임 소재가 생기므로, 선택지로만 열어 두고 먼저 적용하지는 않습니다.
php2shell 정식 릴리스는 8.2 이상에만 나왔습니다. 그 아래는 배포판이 따로 백포트해야 하는데, 공유호스팅에서 이 작업은 우선순위가 낮습니다.
PHP-FPM 과 아파치는 워커를 재시작해야 새 바이너리가 적용됩니다. 패키지만 갱신하고 재시작을 빠뜨린 서버가 많습니다.
지원 종료는 공지 한 줄로 끝납니다. 메일함에서 지나가면 그대로 몇 년이 흐릅니다.
타임라인의 점을 선택하면 출시 시점과 주요 변경, 현재 상태가 표시됩니다.
운영 중인 사이트는 그대로 두고 복제 환경에서 먼저 검증합니다.
버전, 확장 모듈, 외부 연동, 트래픽을 먼저 조사합니다. 결제나 본인인증처럼 외부에서 받은 코드가 있으면 해당 배포본부터 확인합니다.
운영 서버는 그대로 둡니다. 동일 구성의 복제본을 구성해 그곳에서 업그레이드를 진행합니다.
경고가 오류로 바뀐 항목을 전수로 처리합니다. 대부분 정해진 패턴이라 수정 범위를 미리 산출할 수 있습니다.
검증이 끝난 뒤 최소 다운타임으로 전환합니다. 복구 지점을 미리 확보합니다.
문법 변경 구간이 많아 코드 수정이 선행되어야 합니다. 전체 구간 중 공수가 가장 큽니다.
가장 흔한 요청 구간입니다. 경고가 오류로 바뀐 항목이 쟁점이고, 워드프레스는 테마와 플러그인 호환까지 함께 검토합니다.
코드 수정은 적습니다. 확장 모듈과 외부 라이브러리 버전이 쟁점입니다.
호스팅이 제공하는 PHP 버전이 한정된 경우입니다. AWS 나 신규 서버로 이전하면서 함께 올리고, 도메인·메일·SSL 까지 이관합니다.
트래픽이 몰리는 매체라 중단 시간을 둘 수 없었습니다. 복제 환경에서 테마와 자체 제작 플러그인을 먼저 맞춘 뒤, 오토스케일링·CloudFront 구성과 함께 최신 PHP 로 올렸습니다.
일본어 콘텐츠와 결제 모듈이 함께 걸려 있었습니다. 문자셋 처리부터 점검해 깨짐 없이 마이그레이션했습니다.
대관예약, 실시간 주차 API, 본인인증, 다국어 자동번역이 얽힌 공공 사이트입니다. 외부 연동을 하나씩 검증하며 단계적으로 올렸습니다.
버전 점검부터 업그레이드, 서버 이전까지 전 영역 상담이 가능합니다.