PHP2Shell 긴급 패치와 임시 설정의 한계

PHP 프로젝트는 10월 21일 보안 공지에서 인증 없이 원격 코드 실행을 허용할 수 있는 CVE-2026-109618과 CVE-2026-109619의 수정 버전을 공개했다. 웹 요청을 처리하는 PHP가 영향 대상이며, 임시 설정은 확인된 공격 경로의 노출을 줄일 뿐 완전한 해결책은 수정 빌드 적용이다. 운영자는 서버에 새 패키지가 설치됐는지만 볼 것이 아니라 실제 요청을 받는 프로세스까지 교체됐는지 확인해야 한다.

국내에서는 KISA가 10월 21일 PHP 보안 업데이트 권고를 내고 계열별 수정 기준으로 8.2.35, 8.3.36, 8.4.27, 8.5.12 이상을 제시했다. 10월 22일 뉴시스의 티오리 보도에 따르면 티오리는 ‘PHP2Shell’로 불리는 두 결함을 자체 재현·검증하고, 임시 조치로는 취약점을 완전히 막지 못한다고 설명했다. 보도에 제시된 위험도는 두 결함 모두 CVSS 4.0 기준 9.2점이다.

인증 전 웹 요청에서도 코드 실행 위험

두 결함은 사이트마다 작성한 애플리케이션 코드가 아니라 PHP 엔진의 요청 처리 과정에 있다. 따라서 로그인 화면이 있고 접근 권한 검사를 적용했더라도, 그 검사에 앞서 취약한 PHP가 요청을 처리한다면 위험이 남는다. PHP 프로젝트는 웹 요청을 제공하는 PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed를 영향 대상으로 열거했고, 애플리케이션 코드 실행 전 인증되지 않은 요청으로 공격을 유발한 사례가 확인된 mod_php의 위험을 가장 높게 봤다.

CVE-2026-109618은 메모리 부족으로 요청 처리가 중단될 때 일부만 초기화된 내부 데이터를 정리 과정에서 유효한 데이터처럼 다룰 수 있는 문제다. CVE-2026-109619는 요청에 속한 내부 상태가 메모리 해제 뒤에도 남아, 같은 워커가 처리하는 다음 요청에서 초기화 전에 쓰일 수 있는 문제다. 원인이 서로 다른 만큼 세션 관련 설정 하나를 바꿨다는 사실만으로 두 취약점이 모두 제거됐다고 판단할 수 없다.

티오리의 재현·검증 결과는 국내 운영 환경에도 이 문제가 추상적인 가능성에 그치지 않는다는 점을 보여준다. 다만 특정 사이트가 실제로 침해됐는지는 별도의 로그와 시스템 조사로 판단해야 한다. 대응 범위는 공개 웹사이트뿐 아니라 외부 요청이 프록시를 거쳐 들어가는 PHP 서비스, 관리 기능에 내장된 PHP 실행 환경까지 실제 배포 구성에 따라 정해야 한다.

버전 번호보다 실제 요청 처리 경로가 중요하다

KISA가 제시한 영향 범위는 PHP 8.2 계열의 8.2.35 미만, 8.3 계열의 8.3.36 미만, 8.4 계열의 8.4.27 미만, 8.5 계열의 8.5.12 미만이다. 한 서버에서 사이트별로 다른 PHP 계열이나 PHP-FPM 풀을 쓰는 경우에는 각각을 따로 확인해야 한다. 한 풀만 수정 버전으로 올렸다고 같은 서버의 다른 사이트까지 조치가 끝난 것은 아니다.

관리 터미널의 php -v는 CLI 실행 파일의 버전을 보여준다. 웹 요청은 별도의 PHP-FPM 소켓이나 Apache 모듈, 컨테이너 안의 PHP를 거칠 수 있으므로 CLI 결과가 수정 버전이어도 서비스가 구형 빌드를 사용할 수 있다. 예를 들어 패키지 관리자가 새 CLI를 설치한 뒤에도 가상 호스트가 이전 풀에 연결돼 있다면 방문자의 요청은 계속 이전 PHP로 처리된다. 확인 기준은 명령을 실행한 서버의 대표 버전이 아니라 각 도메인과 경로가 실제로 도달하는 실행 환경이다.

PHP 프로젝트의 정규 보안 지원이 끝난 8.1 이하 계열에는 이번 계열별 공식 릴리스가 제공되지 않는다. 다만 일부 리눅스 배포판과 장기 지원 업체는 수정 사항을 기존 버전 번호에 역이식할 수 있고, PHP 보안팀도 일부 구형 계열을 위한 최소 소스 수정분을 제공했다. 따라서 구형 버전 문자열만으로 공급업체 패키지의 패치 상태를 단정하기보다, 해당 업체가 두 CVE를 수정했다고 명시한 빌드인지 확인해야 한다. 그런 지원 경로가 없다면 지원 중인 계열로 이전하는 것이 기준이다.

패치, 워커 교체, 노출 경로 확인 순서

대응은 인터넷 요청이 도착하는 경로를 찾는 일에서 시작한다. 도메인과 가상 호스트가 어느 프록시, PHP-FPM 풀, Apache 모듈 또는 컨테이너 이미지로 연결되는지 따라가면 패치할 실행 파일을 특정할 수 있다. 자산 목록의 설치 기록과 현재 서비스 경로가 다를 수 있으므로, 외부에 공개된 경로와 각 경로를 처리하는 노드를 함께 대조하는 편이 정확하다.

실행 버전 확인. CLI 버전을 참고하되 웹 서버 설정의 소켓·모듈 경로와 PHP-FPM 풀 설정, 실행 중인 컨테이너 이미지를 별도로 확인한다. 여러 노드가 같은 사이트를 제공한다면 각 노드가 어떤 PHP를 로드했는지도 확인한다. 웹 요청으로 버전을 확인하는 임시 진단 경로를 썼다면 외부에 노출하지 말고 확인 직후 제거한다.
수정 빌드 배포. 직접 PHP를 배포한다면 운영 계열의 수정 릴리스를 적용한다. 배포판 패키지나 호스팅 서비스를 쓴다면 공급업체 공지에서 두 CVE의 수정 포함 여부와 설치된 패키지 빌드를 대조한다. 애플리케이션이나 플러그인만 갱신해도 PHP 엔진은 그대로일 수 있다. 컨테이너 환경에서는 새 이미지 제작에 더해 실제 실행 인스턴스의 교체까지 필요하다.
워커와 웹 서버 재시작. 새 파일이 디스크에 있어도 오래 실행된 PHP-FPM 워커나 Apache 프로세스는 이전 빌드를 계속 사용할 수 있다. 서비스 방식에 맞춰 풀과 웹 서버를 재시작하거나 새 컨테이너로 전환한 뒤 구형 프로세스가 남아 있는지 확인한다. 트래픽을 나눠 받는 환경에서는 교체가 끝난 노드와 아직 이전 버전을 쓰는 노드를 구별해야 한다.
노출 경로 재대조. 외부 도메인, 업로드·가져오기 기능, 프록시 뒤의 서비스가 각각 어떤 PHP 런타임에 연결되는지 다시 확인한다. 별도 이미지로 배포된 관리 기능이나 오래된 가상 호스트가 목록에서 빠졌다면 패치된 대표 사이트의 결과를 전체 환경에 적용할 수 없다. 이전에 의심스러운 요청이 있었는지는 접근 로그와 운영 기록을 통해 별도로 살펴야 한다.

임시 설정이 줄이는 공격 경로와 남는 위험

즉시 업데이트할 수 없다면 PHP가 제시한 임시 설정으로 일부 경로의 노출을 줄일 수 있다. CVE-2026-109619에 대해서는 session.upload_progress.enabled=0을 요청 해석 전에 적용되는 php.ini, PHP-FPM 풀 또는 서버 설정에 넣고 모든 워커를 재시작하는 방법이 제시됐다. 애플리케이션 코드의 ini_set()이나 FPM의 .user.ini에만 의존하면 적용 시점이 늦다. 이 설정은 확인된 세션 경로를 막지만 다른 변형까지 차단하지는 않는다.

메모리 부족 처리 결함에 대해서는 애플리케이션이 덮어쓸 수 없도록 memory_limit=-1을 설정하고 요청 크기를 제한하는 완화책이 제시됐다. 이 조치는 PHP가 설정한 메모리 한도 때문에 생기는 실패를 줄여도 시스템의 실제 메모리 할당 실패까지 없애지는 못한다. 업로드가 필요 없는 서비스와 필요한 서비스의 요청 크기 기준도 달라야 하며, 프록시의 제한은 Content-Length가 없거나 쓸 수 없는 요청에도 적용돼야 한다.

PHP 8.5 환경에서 fatal_error_backtraces=0을 설정하고 워커를 재시작하면 확인된 치명적 오류 역추적 경로의 위험을 줄일 수 있다. 이 역시 해당 경로에 한정된 조치다. 세션 업로드 진행이나 요청 크기 설정을 바꾸면 서비스 기능에도 영향이 생길 수 있으므로, 임시 완화 적용과 수정 빌드 배포 완료는 운영 기록에서 분리해 다뤄야 한다.

패치 완료 시점은 파일을 설치한 시각이 아니라 마지막으로 취약한 요청 처리 프로세스가 교체된 시점에 가깝다. 여러 노드 중 구형 워커가 남아 있거나 한 도메인이 이전 풀을 가리킨다면 그 경로로 들어오는 요청의 위험은 계속된다. 국내 운영자는 마지막 노드까지 실제 PHP 실행 버전과 연결 경로를 확인한 뒤에야 해당 서비스의 조치를 완료로 판단할 수 있다.

함께 읽기: