개요

2026년 10월 21일에 PHP의 취약점 CVE-2026-109618과 CVE-2026-109619가 공개된 직후, 코드 저장소 플랫폼인 GitHub에서 ‘php2shell’이라는 이름을 사용하는 저장소가 단기간에 대량으로 생성되었다. 검색어 php2shell로 조회한 상위 100개 저장소(포크 제외) 가운데 99개가 이 취약점을 다루며, 거의 전부가 10월 21일 하루 동안 만들어졌다.

PHP 공식 공지에 따르면 CVE-2026-109618은 메모리 부족 상태를 처리하는 중에 요청 데이터가 일부만 초기화된 채 정리되면서 발생하고, CVE-2026-109619는 메모리가 해제된 뒤에도 요청이 소유한 내부 상태가 남아 같은 워커의 후속 요청이 오래된 상태를 사용하면서 발생한다. 두 취약점 모두 인증 없는 원격 코드 실행을 허용할 수 있고 CVSS v4.0 점수는 9.2이며, 위험도는 mod_php 환경에서 가장 높다(PHP 공식 공지). 한편 GitHub 저장소들은 session.upload_progress 기능을 공격 경로로 설명하고 이 기능이 PHP 5.4부터 기본으로 활성화되어 있다고 적고 있으나, 이 내용은 저장소 설명에 근거한 것이며 공식 공지에서는 확인하지 못했다.

보안 업체 watchTowr는 자사 허니팟 네트워크에서 10월 21일 기준으로 실제 악용을 관찰했다고 밝혔다. 또한 PHP 5 이후의 모든 버전이 영향을 받을 수 있다고 보고했으나, 이 범위는 공식 확인되지 않았다고 설명한다. 해당 페이지가 작성된 시점에 이 취약점은 CISA KEV 목록에 등재되지 않은 상태였다(watchTowr FAQ).

위협 인텔리전스 관점에서 이번 사안은 공개 PoC가 확산되는 규모와 속도, 그리고 그 신뢰성을 함께 살펴볼 필요가 있다. 공격 코드와 방어 도구가 같은 시기에 공개되었으나 두 유형에 대한 관심은 크게 달랐고, 출처를 확인하기 어려운 코드도 다수 포함되어 있다.
 

위협분석

분석 대상은 2026년 10월 22일 13시 30분에 수집한 저장소 목록이다. 목록에 포함된 마지막 활동 시각은 10월 21일 16시 27분(UTC)이다. 저장소의 이름, 설명, 토픽을 기준으로 용도를 분류했으며, 저장소의 코드는 직접 열어 보지 않았다.

용도별로 분류하면 점검, 완화, 탐지를 목적으로 하는 방어 저장소가 46개이고, PoC와 재현 랩 같은 공격 쪽 저장소가 36개이다. 그러나 관심은 공격 쪽에 집중되어 있다. 전체 스타 1,394개 가운데 83%인 1,158개가 PoC 저장소에 있으며, 방어 저장소가 받은 스타는 모두 합쳐 148개에 그친다(그림 1). 스타 상위 두 저장소인 ikow/php2shell-poc(617개)와 eness의 PoC 저장소(333개)가 전체의 68%를 차지하고, 상위 5개 저장소까지 포함하면 81%에 이른다. 나머지 90개 저장소는 거의 주목받지 못했다. 스타 상위 10개 저장소 중에서는 PoC가 5개이고, 방어 쪽으로는 Apache용 긴급 차단 도구와 upload-progress 핸들러를 비활성화하는 PHP 확장, 네덜란드 국가사이버보안센터(NCSC-NL)의 운영 정보 저장소가 포함되었다.

 

 

생성 시점을 보면 방어 저장소가 먼저 나타났다. 가장 이른 관련 저장소는 Corelight의 탐지 규칙으로 10월 18일 06시 43분(UTC)에 생성되었고, 최초의 PoC는 10월 20일 19시 16분(UTC)에 생성된 저장소이다. 이후 PoC는 오후로 갈수록 늘어나 15시(UTC, 한국 시간 22일 0시)에 가장 많이 생성되었다(그림 2). 또한 한 저장소의 IoC 목록은 CVE가 공개되기 전에 만들었다고 밝히고 있어, 보안 벤더 사이에 취약점 정보가 사전에 공유되었을 가능성이 있다. 다만 수집 자료가 10월 21일 16시 27분(UTC)에서 끝나므로 그 이후의 추이는 다시 수집해서 확인해야 한다.
 

 

NCSC-NL, Corelight, syhunt, openai 계정의 저장소처럼 기관과 보안 벤더가 직접 참여한 사례도 확인되었다. 코드 언어는 Python이 47개, Shell이 24개로 대부분을 차지하며, PoC와 점검 도구는 주로 Python으로, 서버 완화 스크립트는 주로 Shell로 작성되었다. 라이선스가 지정되지 않은 저장소가 51개로 절반을 넘는다. 설명은 대부분 영어이지만 중국어, 프랑스어, 러시아어, 포르투갈어, 스페인어, 네덜란드어로 작성된 저장소도 있어 여러 국가에서 동시에 대응에 나선 것으로 보인다. 한국어로 작성된 저장소는 확인되지 않았다.

공개된 코드의 신뢰성에는 주의가 필요하다. PoC 27개 가운데 21개는 스타가 10개 미만이며, 전체 저장소 중 61개는 스타가 1개 이하이다. 설명이 없는 저장소가 29개이고 코드 언어 정보가 없는 저장소도 11개인데, 이러한 저장소는 비어 있거나 문서만 있는 것으로 보인다. 이름을 먼저 확보한 뒤 나중에 코드를 채우는 사례도 있으므로 현재 내용만으로 안전성을 판단하기 어렵다.

공개 PoC가 실제로 동작하는지도 확실하지 않다. 일부 저장소는 원격 코드 실행이 가능하다고 주장하지만, 다른 저장소는 원격 코드 실행이 아닌 상태 손상 버그만 재현된다고 밝혔고 재현에 실패한 기록을 남긴 저장소도 있다. 한 저장소는 설명이 ikow/php2shell-poc와 완전히 동일하여, 인기 있는 저장소를 복제한 뒤 코드를 변경해 배포하는 방식이 사용되었을 가능성이 있다. 인기 있는 CVE를 이용해 가짜 PoC에 악성 코드를 넣고 보안 연구자를 노리는 사례는 과거에도 반복되었다.

방어를 표방하는 도구도 위험이 될 수 있다. 일부 완화 스크립트는 ‘한 줄로 모든 PHP 설치에 적용’하는 방식으로 배포되는데, 이러한 스크립트는 root 권한으로 실행되므로 보안 도구를 가장한 공격 경로로 악용될 수 있다. 한 도구는 AI로 작성했으며 보증하지 않는다고 스스로 밝히고 있다.
 

대응 및 시사점

근본적인 해결책은 PHP를 수정 버전으로 업데이트하는 것이다. PHP는 10월 21일에 보안 릴리스를 배포했으며, 공식 공지는 즉시 업데이트가 가장 확실한 해결책이라고 안내한다. 운영자가 취할 조치는 다음과 같다.

 

1.    PHP 버전 파악과 패치: 운영 중인 PHP의 버전을 자산별로 파악하고 수정 버전인 8.5.12, 8.4.27, 8.3.36, 8.2.35로 업데이트한다. 8.2 브랜치는 2026년 12월 31일에 지원이 종료된다. 배포판과 LTS 벤더는 패치를 사전에 받았으므로 패키지 업데이트를 먼저 확인하고, 위험도가 가장 높은 mod_php 환경을 우선 조치한다. 다운로드와 변경 내역은 PHP 공식 사이트에서 확인한다(다운로드).

2.    8.1 이하 버전: 공식 릴리스는 제공되지 않는다. PHP 보안팀이 7.4, 8.0, 8.1용 최소 백포트를 소스 저장소 브랜치로 공개했으므로, 직접 빌드하는 환경에서는 이를 검토할 수 있다. 그러나 근본적으로는 지원되는 버전으로 이전하거나 LTS 벤더의 백포트 제공 여부를 확인해야 한다.

3.    임시 차단: 즉시 패치할 수 없는 서버는 session.upload_progress.enabled를 Off로 설정해 임시로 차단한다. 이 설정은 파일 업로드 진행률 표시 기능을 끄므로 해당 기능을 쓰는 서비스에 미치는 영향을 먼저 확인한다. PHP 공식 공지는 완화 조치가 일부 공격 경로만 줄일 뿐 시스템을 안전하게 만들지 않는다고 안내하므로, 이 설정은 패치를 대체할 수 없다.

4.    웹 방화벽 규칙: 의심스러운 multipart 요청을 차단하는 규칙은 오탐을 시험한 뒤에 운영 환경에 적용한다.

5.    탐지 규칙: 탐지는 Corelight의 Zeek와 Suricata 규칙, NCSC-NL의 운영 정보처럼 기관과 보안 벤더가 제공하는 자료를 먼저 참고한다.

6.    공개 코드 취급: PoC나 점검 도구를 써야 한다면 코드를 직접 읽어 내용을 확인한 뒤 격리된 환경에서만 실행한다.

 

패치를 적용하기 전에 인터넷에 노출되어 있던 서버는 침해 여부도 점검해야 한다. watchTowr가 10월 21일에 실제 악용을 관찰했다고 밝힌 만큼, 업데이트 이전에 노출된 서버는 침해되었을 가능성을 배제하기 어렵다. 웹 서버 로그에서 비정상적인 multipart 요청을 확인하고, 웹 루트 등에 생성된 의심 파일과 웹 서버 계정으로 실행된 비정상 프로세스가 있는지 조사한다. 침해 정황이 확인되면 증거를 보존한 상태에서 DFIR 절차에 따라 사고를 조사하고, 국내 기관은 한국인터넷진흥원(KISA) 인터넷침해대응센터에 침해사고를 신고한다. 개인정보 유출이 확인되면 개인정보보호법에 따라 개인정보보호위원회 또는 KISA에 신고하고 정보주체에 통지해야 한다.

 이번 사례는 취약점 공개 후 하루 만에 약 100개의 관련 저장소가 만들어졌으나 방어 도구에 대한 관심은 상대적으로 낮았다는 점을 보여 준다. 또한 공개된 저장소 가운데에는 동작 여부가 불확실한 PoC와 출처가 불분명한 코드가 많았다. 따라서 공식 권고문과 신뢰할 수 있는 기관의 자료를 우선 확인하고, 검증되지 않은 저장소의 코드는 실행하지 않는 원칙을 조직 내에 공유할 필요가 있다.

 

패치 및 참고 링크

•    PHP 공식 보안 릴리스 공지: https://www.php.net/archive/2026.php#2026-10-21-5
•    CVE-2026-109618 상세(GHSA-w8hw-w9fx-j79w): https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
•    CVE-2026-109619 상세(GHSA-6wmf-4rv5-p3rp): https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
•    PHP 8.5.12 변경 내역: https://www.php.net/ChangeLog-8.php#8.5.12
•    PHP 8.4.27 변경 내역: https://www.php.net/ChangeLog-8.php#8.4.27
•    PHP 8.3.36 변경 내역: https://www.php.net/ChangeLog-8.php#8.3.36
•    PHP 8.2.35 변경 내역: https://www.php.net/ChangeLog-8.php#8.2.35
•    PHP 7.4 최소 백포트 브랜치: https://github.com/php/php-src/tree/PHP-7.4-CVE-2026-109618-109619
•    PHP 8.0 최소 백포트 브랜치: https://github.com/php/php-src/tree/PHP-8.0-CVE-2026-109618-109619
•    PHP 8.1 최소 백포트 브랜치: https://github.com/php/php-src/tree/PHP-8.1-CVE-2026-109618-109619
•    watchTowr FAQ: https://watchtowr.com/intelligence/php-cve-2026-109618-faq/