[ISSUE] PHP는 왜 반복해서 공격받나…‘PHP2Shell’이 드러낸 웹 인프라의 구조적 위험

워드프레스와 플러그인을 모두 업데이트해도 웹 서버에서 작동하는 PHP 엔진에 결함이 남아 있다면 공격 위험은 사라지지 않는다. 10월 공개된 ‘PHP2Shell’은 애플리케이션의 로그인 절차보다 앞선 단계에서 공격이 작동할 수 있는 취약점이다. 기업이 직접 개발하지 않은 웹 서비스까지 실행 환경을 확인해야 하는 이유다.

웹의 뒤편에서 돌아가는 언어
PHP는 30년 넘게 쓰인 서버 측 스크립트 언어다. 워드프레스와 드루팔, 줌라, 마젠토 같은 플랫폼을 구동하며 상용 애플리케이션과 호스팅 서비스에도 쓰인다. PHP 애플리케이션을 직접 개발하지 않는 기업도 외부 업체가 제공한 제품을 통해 이 언어에 의존할 수 있다.


PHP 프로젝트에 따르면 취약점은 웹 요청을 처리하는 PHP 설치 환경에 영향을 미친다. PHP-FPM과 아파치의 mod_php, php-cgi, FrankenPHP, LiteSpeed 등이 해당한다. mod_php에서는 애플리케이션 코드가 실행되기 전에 공격이 작동하는 사례가 확인됐다.

애플리케이션이 아니라 엔진의 결함
PHP2Shell은 PHP 런타임의 취약점 CVE-2026-109618과 CVE-2026-109619를 묶어 부르는 이름이다. 두 결함 모두 인증되지 않은 공격자의 원격 코드 실행으로 이어질 수 있다. PHP 프로젝트가 매긴 CVSS 4.0 점수는 각각 9.2점이다.

첫 번째는 메모리가 부족할 때 요청 데이터의 초기화가 끝나기 전에 처리 흐름이 중단되고, 정리 과정에서 잘못된 데이터를 유효한 것으로 취급하는 문제다. 두 번째는 앞선 요청에서 해제된 메모리를 가리키는 내부 상태가 남아 같은 작업 프로세스의 다음 요청에 영향을 주는 문제다.

결함이 PHP 엔진에 있는 만큼 콘텐츠 관리 시스템이나 플러그인만 업데이트해서는 해결되지 않는다. 애플리케이션 코드가 실행되기 전에 공격이 작동하는 환경에서는 로그인 절차도 방어선이 되지 못할 수 있다.

공격 시도 급증…침해 성공 여부는 아직 불분명
취약점 공개 전후로 공격을 시도하는 트래픽이 관찰됐다. 아마존 위협 인텔리전스는 공개 나흘 전인 10월 17일 자사 허니팟에서 악용 시도를 확인했다. 클라우드플레어 등 보안업체도 공개 직후 대량의 탐색·공격 트래픽을 관찰했다.

인터넷에 노출된 서비스 규모도 컸다. 센서스는 10월 22일 영향받을 가능성이 있는 PHP 서비스 약 3,670만 개를 집계했다. 서비스 단위의 추정치로, 피해 기업이나 장악된 서버의 숫자는 아니다.

소포스는 처음에 고객 환경에서 성공한 공격을 관찰했다고 발표했지만, 추가 분석 뒤 스캔과 소수의 실패한 시도만 확인됐다고 정정했다. 팔로알토네트웍스 유닛42도 앞서 공개한 관련 침해 분석을 철회했다. 공격 시도는 확인됐지만 실제 침해 규모는 아직 드러나지 않았다.

과거 PHP 취약점이 보여준 공격 속도
2024년 6월 공개된 PHP-CGI 취약점 CVE-2024-4577은 윈도 환경의 문자 처리 문제를 이용해 명령을 실행할 수 있는 결함이었다. 아카마이는 공개 하루 뒤 허니팟에서 악용 시도를 관찰했다. 임페르바는 이를 겨냥한 공격 활동을 ‘TellYouThePass’ 랜섬웨어 캠페인과 연결했다.

공개된 취약점을 공격자가 빠르게 시험하는 만큼 기업도 자산 확인과 패치 적용을 서둘러야 한다.

패치가 늦어지는 이유
PHP 업데이트에는 기존 서비스와의 호환성 확인, 유지보수 시간 확보, 작업 프로세스 재시작이 필요할 수 있다. 운영체제 배포판이나 장기 지원 업체가 PHP 버전 번호는 유지하면서 보안 수정만 반영하는 경우도 있다. 기업은 설치된 패키지의 공급업체 권고와 수정 내역을 확인해야 한다.

지원이 끝난 버전은 대응이 더 복잡하다. PHP 프로젝트는 8.1 이하에 정기 보안 업데이트를 제공하지 않는다. PHP2Shell에 대해서는 7.4·8.0·8.1에 제한적인 소스 백포트를 제공했지만, 적용하려면 직접 빌드하거나 별도 지원업체의 패키지를 받아야 한다. PHP 8.2의 지원도 올해 12월 31일 종료된다.

자산 확인부터 패치·침해 조사까지
대응은 인터넷에 노출된 웹 서비스가 어떤 PHP 환경에서 실행되는지 파악하는 데서 시작한다. 자체 서버뿐 아니라 컨테이너와 관리형 호스팅, 외부 업체 애플리케이션의 버전과 배포 방식, 담당자, 패치 상태를 확인해야 한다.

PHP 프로젝트가 10월 21일 공개한 수정 버전은 8.2.35, 8.3.36, 8.4.27, 8.5.12다. 업데이트나 공급업체의 보안 수정 패키지를 적용한 뒤에는 실행 중인 서비스가 수정된 PHP 런타임을 사용하는지 확인해야 한다. 이전 작업 프로세스가 남아 있다면 새 패키지를 설치해도 취약한 코드가 계속 작동할 수 있다.

패치를 준비하는 동안에는 침입방지시스템(IPS)과 웹 애플리케이션 방화벽(WAF)으로 알려진 공격 경로를 차단할 수 있다. 포티넷은 관련 IPS 시그니처 62657번과 62658번 등을 안내했다. 이러한 차단 규칙은 PHP 엔진의 결함을 고치지 못하므로 업데이트와 병행해야 한다.

의심스러운 웹 요청과 예상치 못한 PHP 작업 프로세스 충돌, 설명되지 않는 프로세스 실행, 애플리케이션 파일 변조, 비정상적인 외부 연결도 조사 대상이다. 패치는 취약점을 고치지만 이미 발생한 침입을 되돌리지는 못한다.

PHP2Shell 이후에도 이어진 보안 권고
PHP 프로젝트는 PHP2Shell과 별개로 10월 23일 특정 설정과 애플리케이션 코드가 결합될 때 나타나는 취약점 CVE-2026-115560을 알렸다. 26일에는 Windows 빌드에 포함된 Brotli 라이브러리의 취약점 CVE-2026-111497을 수정한 패키지를 배포했다.

기업의 PHP 관리 범위는 자체 개발한 웹페이지에서 끝나지 않는다. 운영 중인 제품과 호스팅 환경까지 실제 실행 버전과 보안 수정 상태를 확인하고, 패치 전 노출 기간의 침해 흔적을 조사해야 한다. PHP2Shell이 드러낸 위험은 널리 쓰이는 엔진의 결함과 그 엔진이 어디서 돌아가는지 파악하기 어려운 운영 구조가 맞물린 데 있다.