PHP 런타임에서 인증 전 원격 코드 실행(RCE)으로 이어질 수 있는 취약점 두 건이 공개됐습니다. CVE-2026-109618과 CVE-2026-109619는 웹 요청 처리 중 발생하는 서로 다른 메모리 안전성 결함입니다. 두 취약점은 커뮤니티에서 PHP2Shell로 함께 불리지만, PHP 프로젝트는 별개의 CVE로 추적합니다.
한눈에 보기#
대상: 웹 요청을 처리하는 PHP 런타임
취약점: CVE-2026-109618, CVE-2026-109619
영향: 취약한 실행 경로에서 인증 전 원격 코드 실행 가능
심각도: 각각 CVSS v4.0 9.2, PHP 프로젝트 기준 Critical
수정 버전: PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35
확인 기준: 2026년 10월 24일 공개된 PHP·CISA·Censys 자료
영향 범위: PHP 요청 처리 경로#
웹 요청은 웹 서버를 거쳐 PHP SAPI와 런타임에서 파싱·초기화된 뒤 애플리케이션 코드로 전달됩니다. PHP2Shell은 이 초기 요청 처리 경로의 메모리 상태가 손상되는 문제입니다.
따라서 워드프레스나 특정 플러그인만의 취약점으로 분류하면 안 됩니다. 애플리케이션·플러그인을 업데이트해도 웹 요청을 처리하는 PHP 런타임이 취약하면 노출이 남습니다.
PHP는 Apache mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed 등 여러 SAPI로 배포됩니다. PHP 프로젝트는 웹 요청을 처리하는 PHP 설치 전반을 영향 범위로 안내하고, mod_php에서는 애플리케이션 코드가 실행되기 전에 취약 경로에 도달하는 사례를 확인했습니다. 다만 각 SAPI의 요청 수명주기와 설정에 따라 검증된 경로와 악용 가능성은 다릅니다.
공격 경로는 어떻게 달랐나#
CVE-2026-109618: OOM 처리 중 부분 초기화된 요청 상태 참조#
메모리 할당 실패(Out of Memory, OOM)가 요청 파싱 중 발생하면 PHP 내부 요청 구조가 완전히 초기화되기 전에 처리 흐름이 중단될 수 있습니다. 이후 정리 경로가 초기화되지 않은 상태를 유효한 데이터처럼 읽거나 분기하면서 메모리 손상으로 이어집니다. 공격자는 이 경로를 통해 코드 실행을 유발할 수 있습니다.
PHP 프로젝트는 Apache mod_php에서 애플리케이션 코드가 실행되기 전 요청 시작·정리 과정에 도달하는 경로를 확인했습니다. PHP-FPM 등 다른 SAPI도 영향 범위에 포함되지만, 동일한 조건으로 재현된다고 일반화할 수는 없습니다.
CVE-2026-109619: 요청 간 잔존한 전역 상태의 use-after-free#
PHP-FPM처럼 장시간 실행되는 워커는 여러 요청을 연속 처리합니다. 요청이 끝나며 요청 소유 메모리가 해제된 뒤에도 전역 상태가 그 영역을 가리키면, 같은 워커가 후속 요청을 초기화하는 과정에서 해제된 메모리를 다시 참조할 수 있습니다. 이 use-after-free는 요청 간 상태 초기화가 어긋나며 발생합니다.
PHP 보안 권고는 세션 업로드 진행률 등 여러 처리 경로에서 이 문제가 코드 실행으로 이어질 수 있음을 설명합니다. 실제 공격 경로는 SAPI와 애플리케이션 설정에 따라 달라지며, 모든 서버 구성이 같은 방식으로 악용된다는 뜻은 아닙니다.
두 결함의 차이는 오류 처리의 시간축에 있습니다. CVE-2026-109618은 현재 요청이 OOM으로 중단되는 시점의 불완전한 초기화, CVE-2026-109619는 요청 종료 후 해제된 상태가 다음 요청까지 잔존하는 문제입니다.
취약점은 어떻게 발견·공개됐나#
PHP 프로젝트는 2026년 10월 20일 유지관리자와 일부 대응 조직에 사전 안내를 하고, 10월 21일 수정 버전을 공개했습니다. 취약점 정보가 공개 전에 유출되면서 공개 일정이 앞당겨졌다고 Censys는 정리했습니다.
발견 과정에는 AI를 활용한 연구도 있었습니다. OpenAI는 Patch the Planet 협력 과정에서 Calif가 GPT-5.6 Sol을 활용해 중대한 PHP 결함을 찾았고, Wiz도 두 취약점을 독립적으로 발견해 신고했다고 발표했습니다. 수정과 배포는 PHP 유지관리자가 주도했으며, 연구자와 보안 업체들이 패치 검증과 대응 준비에 참여했습니다.
따라서 “AI가 두 취약점을 혼자 발견했다”고 쓰면 부정확합니다. 공개된 자료가 확인하는 것은 AI를 활용한 연구, 별도의 연구팀이 진행한 발견·신고, PHP 유지관리자의 수정, 여러 조직의 공개 전 대응이 함께 진행된 과정입니다.
악용 시도와 실제 침해는 구분해야 한다#
공개 시점과 악용 정황은 빠르게 바뀌고, 현재 공개된 분석도 일치하지 않습니다. CISA는 10월 21일 공지에서 당시까지 악용을 관찰하지 못했다고 밝혔습니다. 이후 Censys가 10월 23일 갱신한 분석에서는 Amazon이 사전 공개 시기의 시도와 공개 후 활동을 근거로 CVE-2026-109618의 광범위한 악용을 언급한 반면, Dataminr와 캐나다 사이버보안센터는 관측된 활동이 주로 스캔·탐색이며 확인된 침해는 없다고 평가했습니다. VulnCheck 센서가 관측한 CVE-2026-109618 시도 한 건은 실패한 것으로 기록됐습니다.
악용 시도가 보였다는 사실과 실제 서버 침해가 확인됐다는 주장은 다릅니다. Censys는 10월 23일 기준 두 CVE가 CISA의 알려진 악용 취약점 목록에 없다고 기록했습니다. Censys의 후속 보고 역시 성공한 침해의 규모를 두고 상반된 평가를 함께 소개합니다.
전체 추이를 보는 Censys 대시보드#
Censys는 로그인 없이 무료로 열람할 수 있는 PHP2Shell 전용 공개 대시보드를 운영합니다. Affected, Patched, All PHP 필터와 브랜치 선택 메뉴를 이용해 Censys가 인터넷에서 관측한 PHP 서비스의 버전 분포와 패치 추이를 살펴볼 수 있습니다. Live from the Scanners 그래프는 최근 24시간의 스캐너 응답을 분당 단위로 보여주며, 한 시간마다 갱신됩니다.
이 페이지는 특정 사이트 주소를 입력해 취약 여부를 판정해 주는 개별 사이트용 취약점 검사기가 아닙니다. Censys 스캐너가 받은 응답과 거기서 식별한 버전을 집계한 현황판입니다. 같은 서비스가 여러 번 관측될 수 있어 분당 응답 수가 고유 서버 수를 뜻하지 않으며, 버전을 숨긴 서비스는 분류되지 않을 수 있습니다. 배포판이 패치를 백포트한 경우에도 외부에서 보이는 버전 문자열은 그대로일 수 있습니다. 따라서 이 자료만으로 특정 서버의 안전 여부를 판단하면 안 됩니다.
도메인 하나를 살펴보는 무료 외부 확인기#
개별 도메인을 외부에서 확인하는 무료 도구로는 SOCRadar의 PHP2Shell Checker가 있습니다. 계정 없이 사용할 수 있으며, 기본 확인은 사이트가 일반 방문자에게 공개하는 PHP 버전 단서를 읽고 수정 버전과 비교합니다. 도구 설명에 따르면 기본 확인은 익스플로잇을 시도하지 않습니다.
이 방식은 버전이 외부에 노출된 경우에만 단서를 얻는 수동 확인입니다. 서버가 PHP 버전을 숨기거나 CDN·프록시를 사용하는 경우 inconclusive로 나올 수 있는데, 이는 “취약하지 않다”는 뜻이 아닙니다. 페이지에는 별도의 선택형 live check도 있으므로, 권한과 점검 범위를 확인하지 않은 채 실행하지 않는 것이 좋습니다. 본인 또는 점검 승인을 받은 도메인만 입력해야 합니다.
두 도구는 확인 범위가 다릅니다. Censys는 인터넷에서 관측한 서비스 전체의 추이를 보여주고, SOCRadar는 입력한 한 도메인이 공개한 정보를 확인합니다. 둘 다 서버 내부의 실제 패키지와 배포판 백포트 상태를 완전히 알 수 없습니다. 내 서버의 최종 패치 여부는 웹 요청을 처리하는 PHP-FPM·Apache 모듈·컨테이너의 패키지와 공급자 보안 공지로 확인해야 합니다. php -v는 CLI 버전만 출력할 수 있어 웹 서버가 쓰는 런타임과 다를 수 있습니다.
능동적인 테스트 요청은 서비스에 영향을 주거나 보안 로그에 공격 시도로 기록될 수 있습니다. 운영 서버에 출처 불명의 검사기나 익스플로잇 코드를 실행하기보다, 호스팅 업체·배포판 공급자에게 패치 적용 여부를 확인하고 승인된 점검 절차를 따르는 편이 안전합니다. 타인의 시스템은 허가 없이 검사하면 안 됩니다.
수정 버전과 운영자가 확인할 점#
PHP 프로젝트가 공개한 수정 버전은 다음과 같습니다.
PHP 8.5: 8.5.12
PHP 8.4: 8.4.27
PHP 8.3: 8.3.36
PHP 8.2: 8.2.35
Linux 배포판이나 호스팅 업체는 수정 사항을 기존 패키지에 백포트할 수 있습니다. 이 경우 표시되는 PHP 버전 문자열이 PHP 공식 수정 버전과 다를 수 있으므로, 버전 숫자만 비교하지 말고 공급자의 보안 공지와 패키지 변경 이력에서 두 CVE의 수정 여부를 확인해야 합니다.
PHP 프로젝트는 8.1 이하 브랜치에 일반 릴리스를 제공하지 않지만, 7.4·8.0·8.1에 대해서는 직접 빌드하는 사용자를 위한 최소 소스 백포트를 공개했습니다. Linux 배포판이나 장기 지원 업체가 별도로 패치를 백포트했을 수도 있으므로, 해당 업체의 보안 공지를 확인해야 합니다. Censys는 5.4~7.3 브랜치를 지원 종료 상태로 분류하고 업스트림 수정판이 없다고 안내했습니다.
php -v가 보여주는 CLI 버전과 실제 웹 요청을 처리하는 PHP-FPM·Apache 모듈의 버전이 다를 수 있습니다. 웹 서버나 호스팅 관리 화면에서 요청을 처리하는 런타임을 확인하고, 공급자가 제공하는 수정 패키지를 적용한 뒤 해당 런타임의 작업 프로세스가 새 버전으로 재시작됐는지 점검해야 합니다.
PHP 프로젝트는 업데이트를 완전한 해결책으로 안내합니다. 즉시 업데이트하기 어려운 경우 공식 권고의 임시 완화책을 검토할 수 있지만, 각 완화책은 특정 공격 경로만 줄이며 취약점을 제거하지는 않습니다. CISA는 PHP 설치 위치를 전수 확인하고 인터넷에 노출된 시스템부터 패치하며, 업데이트할 수 없는 지원 종료 시스템은 수정 전까지 오프라인으로 두도록 권고했습니다. 패치 뒤에도 PHP 워커가 셸을 실행하거나 외부 도구를 내려받는 등 평소와 다른 동작이 있었는지 살펴야 합니다.
직접 서버를 운영한다면 아래 순서로 확인합니다.
서버뿐 아니라 컨테이너와 관리형 서비스에 포함된 PHP도 자산 목록에서 찾습니다.
PHP 버전과 실행 방식(PHP-FPM, Apache 모듈 등)을 확인하고, 배포판 또는 호스팅 공급자 공지에서 CVE 두 건의 수정 여부를 대조합니다.
수정 패키지를 적용하고 웹 요청을 처리하는 워커를 재시작합니다. CLI의
php -v만으로 웹 런타임이 바뀌었다고 판단하지 않습니다.업데이트 전후의 웹 서버·PHP 로그를 확인하고, PHP 프로세스가 예상하지 못한 셸이나 외부 도구를 실행한 흔적이 있는지 살핍니다.
공유 호스팅이나 관리형 서비스를 이용한다면 관리자 화면의 버전만 보지 말고, 공급자에게 CVE-2026-109618과 CVE-2026-109619 수정이 실제 서비스 런타임에 적용됐는지 문의합니다.
패치 전후에 PHP 프로세스가 예상하지 못한 셸을 실행하거나 외부 도구를 내려받은 흔적이 발견되면, 단순히 버전만 올리고 끝내지 않습니다. 해당 시스템을 네트워크에서 분리하고 로그와 증거를 보존한 뒤, 침해 범위와 계정·비밀정보 노출 여부를 조사하고 복구 절차를 진행해야 합니다. CISA도 PHP 워커가 셸을 실행하거나 도구를 내려받는 행위를 확인하도록 권고했습니다.
별도 후속 공지: CVE-2026-115560#
PHP 프로젝트는 10월 23일 세션 업로드 진행률 기능과 관련한 별도의 잠재적 RCE 경로를 안내하고 CVE-2026-115560을 예약했습니다. 이 문제는 세션 업로드 진행률이 활성화돼 있고, 애플리케이션이 session.serialize_handler를 특정 방식으로 바꿨다가 요청 중 다시 변경하는 드문 조합에서 발생할 수 있다고 설명했습니다.
PHP는 다음 정기 릴리스 전까지 session.upload_progress.enabled=0을 임시로 권고했습니다. 런타임에서 세션 직렬화 핸들러를 바꾸지 않는 애플리케이션은 해당 기능을 계속 사용할 수 있다고 안내했습니다. 이 후속 이슈는 PHP2Shell의 두 CVE와 별개이며, 전체 기술 권고와 수정 버전은 다음 정기 릴리스에 공개될 예정입니다.
정리하며#
PHP2Shell은 웹 애플리케이션의 코드만 점검해서는 서버의 위험을 파악하기 어렵다는 점을 보여줍니다. PHP 런타임과 실행 방식, 공급자의 패치 상태도 함께 확인해야 합니다. 특히 PHP는 웹 애플리케이션과 여러 관리형 서비스에 포함되어 있어, 조직이 직접 설치한 서버 외에 호스팅·컨테이너·외부 솔루션의 런타임도 점검 대상입니다.
이번 이슈에서는 취약점 공개와 패치 사이의 시간이 짧았고, 악용 시도에 관한 보고도 엇갈렸습니다. 확인된 사실과 추정, 스캔과 공격 시도, 실제 침해를 구분해야 합니다. Censys 대시보드는 전체 노출 추이를 보는 보조 자료로 활용하고, 내 서버는 웹 런타임과 공급자 패치 내역으로 확인하는 것이 핵심입니다.
참고 자료#
추가로 공유된 X 게시물#
아래 게시물은 관련 논의와 추가 맥락을 확인할 수 있도록 함께 남깁니다. 기술적 사실과 대응 기준은 위의 PHP·CISA·Censys 등 원문 자료를 기준으로 정리했습니다.