php2shell(CVE-2026-109618 / 109619)은 php -v로 판정할 수 없다 — FPM·Docker·배포판에서 버전 숫자가 어긋나는 곳

웹 요청을 처리하는 PHP(PHP-FPM, Apache의 mod_php, php-cgi, FrankenPHP, LiteSpeed)가 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12보다 이전 버전이면 php2shell로 불리는 CVE-2026-109618과 CVE-2026-109619의 영향을 받는다. 해결 방법은 이 수정 버전(배포판 패키지라면 수정된 패키지)으로 올리고 프로세스를 재시작하는 것이다. 확인해야 할 것은 손 닿는 곳의 php -v가 아니라 “웹을 실제로 구동하는 PHP”와 “설치된 패키지의 버전”이다.

이 글은 버전 숫자만으로 판단하면 틀리기 쉬운 곳을 네 가지로 추려 정리한다. 모든 수치와 상황은 2026-10-22 시점이며, 각 항목의 출처는 끝에 모아 두었다.

2026-10-22 시점에 알려진 내용

PHP 공지는 “완전한 대책은 업데이트뿐”이라고 밝히고 있다. 업데이트 전까지의 완화책은 글 후반에 적었다.

함정 1: php -v와 웹 쪽 PHP는 별개일 수 있다

SSH에서 입력하는 php -v는 CLI용 PHP의 버전을 보여 준다. 웹 요청을 처리하는 것은 PHP-FPM 프로세스나 Apache에 로드된 mod_php이며, 이는 별개의 바이너리, 별개의 패키지다. CLI에만 새 PHP를 설치했거나, 여러 버전을 나란히 설치했거나, FPM 풀이 다른 버전을 가리키는 구성에서는 php -v가 수정 버전이어도 웹 쪽은 옛 버전 그대로일 수 있다.

웹 쪽의 실제 버전을 확인하는 방법은 몇 가지가 있다.

# Debian / Ubuntu의 FPM (버전별로 이름이 붙어 있음)
php-fpm8.3 -v

# RHEL 계열의 FPM
php-fpm -v

# Apache에 mod_php가 로드되어 있는지
apachectl -M | grep -i php

가장 확실한 방법은 웹을 통해 실제로 실행되는 PHP가 직접 버전을 말하게 하는 것이다. 추측하기 어려운 이름의 파일을 임시로 두고, 확인이 끝나면 바로 삭제한다.

<?php echo PHP_VERSION, ' ', PHP_SAPI;

PHP_SAPI가 fpm-fcgi이면 FPM, apache2handler이면 mod_php, cgi-fcgi이면 CGI로 동작하는 것이다. phpinfo()를 노출한 채 두는 것은 그 자체로 정보가 유출되므로 피한다.

또 하나 놓치기 쉬운 것이 재시작이다. 패키지를 교체해도 이미 실행 중인 php-fpm이나 Apache 프로세스가 옛 코드로 계속 동작할 수 있다. 패키지 업데이트 시 자동으로 재시작되는 구성도 있지만 그렇지 않은 구성도 있다. 업데이트했다면 FPM / Apache를 재시작하고, 위의 방법으로 웹 쪽 버전을 다시 확인한다.

함정 2: Docker는 “태그 이름”으로 판단할 수 없다

공식 이미지 php에는 8.3이나 8.3-fpm처럼 내용이 교체되는 “이동 태그”와, 8.3.30처럼 버전을 고정한 태그가 있다.

• 이동 태그는 Docker Hub 쪽에서 수정 버전으로 교체되어도, 로컬에서 다시 pull하기 전까지는 옛 이미지 그대로다. 게다가 실행 중인 컨테이너는 다시 만들기 전까지 옛 이미지로 계속 동작한다. Dockerfile의 FROM php:8.3-fpm도 빌드 캐시에 옛 베이스가 남아 있으면 옛 베이스로 빌드된다.
• 고정 태그는 직접 번호를 올리기 전까지 영원히 옛 버전이다.

수정 버전 태그가 나왔는지는 Docker Hub API로 확인할 수 있다.

curl -s "https://hub.docker.com/v2/repositories/library/php/tags?name=8.3.36&page_size=100"

2026-10-22에 네 개 계열에 대해 조회한 결과는 다음과 같다(시각은 UTC).

이때 확인하면서 알게 된, 숫자로 판단하면 헷갈리는 점이 세 가지 있다.

1. “최근 업데이트됨”은 “수정됨”이 아니다. 고정 태그 8.3.35는 2026-10-21 중에 다시 빌드되었지만, 안의 PHP_VERSION은 8.3.35 그대로였다. 업데이트 시각이 아니라 안에 들어 있는 버전을 봐야 한다.
2. digest가 달라도 내용이 같은 경우가 있다. 8.3과 8.3.36은 태그의 digest(여러 아키텍처를 묶은 인덱스의 값)가 달랐지만, amd64 이미지는 같은 것이었고 둘 다 PHP_VERSION=8.3.36이었다. 8.3-fpm / 8.3.36-fpm, 8.4-apache / 8.4.27-apache, latest / 8.5.12, 8.5-fpm, 8.2-fpm도 마찬가지로 amd64 이미지의 PHP_VERSION은 수정 버전이었다.
3. 8.1 이전의 공식 이미지에는 수정 버전이 없다. 8.1-fpm의 마지막 업데이트는 2025-12-31이었다.

로컬 이미지와 실행 중인 컨테이너를 확인하려면 다음과 같이 한다.

# 로컬에 pull해 둔 이미지의 PHP 버전
docker image inspect php:8.3-fpm --format '{{range .Config.Env}}{{println .}}{{end}}' | grep PHP_VERSION

# 다시 받아서 컨테이너를 다시 만든다
docker compose pull
docker compose up -d

# 직접 빌드한다면 베이스를 다시 받은 뒤 빌드한다
docker compose build --pull

# 실행 중인 컨테이너 안의 버전
docker compose exec app php -r 'echo PHP_VERSION, PHP_EOL;'

마지막 명령의 app은 자신의 서비스 이름으로 바꾼다. 공식 이미지는 이미지 하나에 PHP_VERSION 하나로 빌드되므로, 컨테이너 안 CLI의 버전은 그 컨테이너의 FPM / Apache 버전과 같다(함정 1은 호스트에 직접 설치한 경우의 이야기다).

FrankenPHP는 PHP를 내부에 내장하고 있으므로 FrankenPHP 자체의 버전과 내장된 PHP의 버전은 다른 숫자다. 2026-10-21에 공개된 FrankenPHP 1.13.2의 릴리스 노트에는 Docker 이미지는 PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12로, 정적 바이너리는 PHP 8.5.12로 빌드했다고 적혀 있다.

함정 3: 배포판 패키지는 “옛 숫자 그대로 수정된다”

Ubuntu와 RHEL은 수정 사항만 옛 버전에 이식(백포트)한다. php -v에 나오는 숫자는 옛날 그대로이므로 “8.3.36보다 작으니 위험하다”라고 숫자로 판정하면, 수정되어 있는데도 위험하다고 나온다. 반대로 숫자만 보고 안심할 수도 없다. 판정은 패키지 버전과 각 배포판의 보안 트래커로 한다.

2026-10-22 시점에 각 트래커에 올라 있던 수정된 패키지(두 CVE 모두 동일).

숫자만으로는 판정할 수 없다는 사례가 이 표에 그대로 나와 있다. Ubuntu 24.04의 수정된 PHP는 8.3.6으로 시작하는 버전으로, upstream의 8.3.36보다 훨씬 작다. RHEL 9의 기본 PHP는 8.0.30 그대로 수정되어 있는데, upstream에서는 8.0에 더 이상 수정 버전이 나오지 않는다. Debian은 upstream과 같은 번호(8.2.35 / 8.4.27)로 올렸다.

아직 수정되지 않은 곳도 있다(2026-10-22 시점).

• RHEL 9의 php 모듈 8.4는 “영향 있음, 수정 없음”으로 분류되어 있다.
• Debian forky(testing)는 php8.4 8.4.26-1로 “vulnerable”이다. sid(unstable)의 php8.4는 8.4.27-1로 수정되었다.

내 서버에서 확인하는 명령어 예시.

# Debian / Ubuntu: 설치된 버전과 받을 수 있는 버전
apt-cache policy php8.3-fpm libapache2-mod-php8.3

# Ubuntu: 이 CVE가 내 서버에서 수정되어 있는지
pro fix CVE-2026-109618
pro fix CVE-2026-109619

# RHEL 계열: 이 CVE를 수정하는 업데이트가 있는지, 설치된 버전
dnf updateinfo list --cve CVE-2026-109618
rpm -q php-fpm php-cli

패키지 이름(php8.3-fpm 등)은 자신의 환경에 맞춘다. 나온 버전을 위 표나 트래커의 “수정된 버전”과 비교해서 같거나 더 높으면 수정이 들어간 것이다. 그런 다음 함정 1의 재시작과 웹 쪽 확인까지 마친다.

한편 배포판 기본이 아니라 외부 저장소에서 PHP를 설치했다면 그 저장소의 업데이트를 확인해야 한다. PHP 공지는 자원봉사자가 운영하는 rpms.remirepo.net은 공개 당일에는 업데이트가 나오지 않는다며, 배포판 패키지나 직접 빌드로 전환할 것을 권하고 있다.

함정 4: 공유 호스팅·매니지드 환경은 직접 올릴 수 없다

공유 호스팅이나 매니지드 PHP 환경에서는 PHP 본체를 교체하는 것이 사업자다. 여기서도 숫자만으로는 판단할 수 없다. 사업자가 독자적으로 빌드했거나 수정을 이식했다면 버전 숫자는 옛날 그대로일 수 있다.

직접 할 수 있는 것은 이 세 가지다.

1. 웹 쪽 버전을 확인한다. 함정 1의 임시 파일로 PHP_VERSION과 PHP_SAPI를 출력하고 바로 삭제한다. 관리 화면에 PHP 버전을 고르는 화면이 있다면 어느 버전을 선택하고 있는지도 적어 둔다.
2. 사업자의 공지를 확인하고, 없으면 문의한다. 물어볼 것은 “CVE-2026-109618과 CVE-2026-109619의 수정이 내 계약의 어느 PHP 버전에 언제 들어가는지(들어갔는지)”다. 버전 숫자가 아니라 CVE 번호로 물으면 백포트 여부까지 답을 받을 수 있다.
3. 지원이 끝난 버전을 선택하고 있다면 올린다. 8.1 이전은 PHP 프로젝트에서 수정이 나오지 않는다. 8.2도 2026-12-31에 지원이 끝난다. 사업자가 수정을 이식하지 않았다면 버전 전환이 확실한 길이다.

호스팅 업체별 대응 상황(2026-10-22 시점)

공유 호스팅에서는 PHP 본체의 업데이트를 업체 쪽에서 하는 것이 보통이며, 공지에서도 “이용자 측 작업은 불필요”라고 하는 곳이 많다. 이용자가 할 일은 계약 중인 회사의 공식 공지를 확인하는 것, 그리고 관리 화면에서 옛 PHP 버전을 선택하고 있다면 공지가 안내하는 버전(수정 버전이 있는 버전)으로 전환할지 검토하는 것, 이 두 가지다.

아래 표는 각 회사의 공식 페이지(공지·점검 정보)에 적혀 있는 내용만 정리한 것으로, 공지 문구를 요약했다. 공지는 수시로 갱신되므로 실제 상황은 반드시 출처의 공식 페이지에서 확인하기 바란다.

공식 공지를 찾지 못했거나 열 수 없었던 회사는 표에 “확인하지 못함”, “찾지 못함”이라고 적었다. 거기에 실려 있지 않다는 것이 대응하지 않았다는 뜻은 아니다. 계약 중인 회사의 공지와 지원 창구에서 직접 확인하기 바란다.

바로 업데이트할 수 없는 동안의 완화책

PHP 공지에는 업데이트 전까지 공격 경로를 줄이는 설정이 실려 있다. 다만 공지 자체가 “안전해지는 것은 아니다”라고 명시하고 있다. 주요 항목은 다음과 같다.

• CVE-2026-109619용: session.upload_progress.enabled=0을 php.ini, FPM 풀, 서버 설정에 넣고 모든 워커를 재시작한다(ini_set()이나 FPM의 .user.ini로는 적용되지 않는다). PHP 8.5에서는 fatal_error_backtraces=0도 설정한다.
• CVE-2026-109618용: 애플리케이션에서 덮어쓸 수 없는 형태로 memory_limit=-1로 하고, post_max_size를 줄인다(업로드가 없으면 8M, 있으면 32M). RLIMIT_AS / RLIMIT_DATA로 대용하지 않는다.

영국 NCSC는 바로 업데이트도 완화도 할 수 없는 시스템은 오프라인으로 돌리는 것을 검토하고, 업데이트나 완화에 앞서 침해 흔적이 없는지 확인할 것을 권고하고 있다.

출처(2026-10-22에 확인)

• php.net: Security advisory: Critical remote code execution vulnerabilities, update now (2026-10-21)
• php.net: Upcoming Critical PHP Security Release (2026-10-20)
• php.net: PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 릴리스 공지
• GitHub: GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GitHub: GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Docker Hub: 공식 이미지 php
• FrankenPHP 1.13.2 릴리스 노트
• Debian Security Tracker: CVE-2026-109618 / CVE-2026-109619
• Ubuntu: CVE-2026-109618 / CVE-2026-109619 / USN-8948-1 / USN-8948-2
• Red Hat: CVE-2026-109618 / CVE-2026-109619 (수정된 패키지 버전은 Red Hat의 VEX 데이터 기준)
• NCSC: Critical security issue affecting PHP