PHP2Shell 취약점은 PHP를 업데이트해 막아야 한다

PHP의 치명적인 원격 코드 실행 취약점 두 건(PHP2Shell, CVE-2026-109618·CVE-2026-109619)이 수정됐다. PHP 웹 요청을 처리하는 서버는 런타임을 패치 버전으로 업데이트하고, 컨테이너를 다시 빌드·배포한 뒤 실제 실행 버전을 확인해야 한다.

컨테이너를 쓰지 않는다면 공급업체가 제공하는 패치를 적용한다. 컨테이너에서는 수정된 php 태그를 가져온 뒤 이미지를 다시 빌드하고 배포한다. 부동 태그보다 버전을 고정한 태그를 권장한다. php:8.5-fpm, php:8.4-fpm, php:8.3-fpm은 이미 수정 버전을 가리키지만, php:8.2-fpm은 여전히 8.2.34를 가리키므로 php:8.2.35-fpm을 지정해야 한다.

PHP 8.4 FPM을 사용하는 경우 베이스 이미지 예시는 다음과 같다.

FROM php:8.4.27-fpm

Docker Compose에서는 다음 명령으로 다시 빌드하고 배포한다.

docker compose build --pull --no-cache docker compose up -d --force-recreate

배포된 컨테이너가 실제로 수정 버전을 실행하는지도 확인해야 한다. 공식 -fpm 이미지에는 php CLI가 포함돼 있다. CLI가 없는 런타임(예: distroless 빌드)에서는 php-fpm -v를 사용하거나 docker scout sbom에서 버전을 확인한다.

docker compose exec <service> php -v

PHP 8.1 이하 브랜치는 지원이 종료돼 업데이트 릴리스를 받지 않는다. 심각성을 고려해 PHP 보안팀은 PHP 7.4, 8.0, 8.1에 최소한의 소스 백포트를 공개했다. 장기적으로는 지원되는 브랜치로 옮기는 것이 해결책이다. 리눅스 배포판 공급업체가 보안 패치를 백포트하는 경우 패키지 버전은 다를 수 있으므로 해당 업체의 보안 권고를 확인해야 한다.

프로덕션 베이스 이미지는 변경될 수 있는 태그 대신 바뀌지 않는 다이제스트로 고정할 수 있다. 현재 다이제스트는 다음 명령으로 확인한다.

docker buildx imagetools inspect php:8.5.12-fpm --format '{{.Manifest.Digest}}'

FROM 줄에서 다이제스트를 지정하는 예시는 다음과 같다.

FROM php:8.5.12-fpm@sha256:8b4b4a764f7985137b13e4cb49dd59e967d9daa7946a731f9d06e31e748e39bb

작성 시점인 2026-10-21에 확인한 멀티 아키텍처 인덱스 다이제스트는 다음과 같다. 베이스 OS가 갱신되면 태그의 다이제스트도 바뀌므로 고정하기 전에 다시 확인해야 한다.

취약점과 패치 일정

PHP는 2026년 10월 21일 취약점을 수정했으며, 공식 컨테이너 이미지도 같은 날 업데이트됐다. PHP 릴리스가 이미지보다 몇 시간 먼저 나왔다.

PHP2Shell은 PHP 자체의 치명적인 원격 코드 실행(RCE) 취약점 두 건을 가리키는 이름이다. CVE-2026-109618은 메모리 부족 처리 과정에서 내부 요청 데이터가 불완전하게 초기화돼 정리 중 메모리 손상이 발생할 수 있는 취약점이다. CVE-2026-109619는 요청별 전역 상태가 할당된 메모리보다 오래 남아 이후 요청에서 해제 후 사용(use-after-free) 취약점으로 이어질 수 있다. 두 취약점 모두 CVSS v4.0 점수는 9.2다.

취약점은 PHP-FPM, Apache mod_php 등 웹 요청을 처리하는 PHP 설치 환경에 영향을 준다. PHP는 애플리케이션 코드가 실행되기 전에 발생할 수 있는 mod_php 공격 사례를 보고했다. 이는 WordPress 플러그인 취약점이 아니며 Composer 업데이트로 해결되지 않는다. 문제는 PHP 런타임에 있다.

컨테이너 확인과 자동화 도구 사용

먼저 컨테이너의 PHP 버전을 확인한다.

docker run --rm --entrypoint php my-php-app:latest -v

취약점 데이터베이스에 새 권고가 반영되기까지 시간이 걸릴 수 있다. CVE 검사 결과를 신뢰하기 전에 이미지의 패키지 목록에서 런타임 버전을 확인한다.

docker scout sbom my-php-app:latest --format list | grep -i php

Docker Scout으로 두 취약점을 검사할 수 있다.

docker scout cves \ --only-cve-id CVE-2026-109618,CVE-2026-109619 \ my-php-app:latest

Trivy를 이용한 검사 명령은 다음과 같다.

trivy image --scanners vuln my-php-app:latest

취약점 데이터베이스가 새 권고를 반영하는 데 시간이 걸릴 수 있으므로, 검사에서 CVE가 나오지 않았다고 해서 이미지가 안전하다고 단정할 수는 없다. PHP 런타임 버전과 공급업체의 패치 상태를 확인해야 한다. 레지스트리에 업데이트된 이미지가 있어도 기존 컨테이너가 계속 실행 중이라면 보호되지 않으므로 실행 중인 컨테이너도 확인한다.

AI 코딩 에이전트를 사용하는 경우 다음 지시문으로 저장소를 점검하도록 할 수 있다.

이 저장소에서 PHP2Shell(CVE-2026-109618 및 CVE-2026-109619)을 점검하라.

Dockerfile, 컨테이너 이미지, CI/CD 설정, 배포 매니페스트에서 PHP 버전을 찾아라.

영향을 받는 런타임을 수정된 릴리스(PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 이상)로 올리되 공급업체 백포트를 고려하라.

이미지 참조와 다시 빌드하는 방법을 업데이트하라. 필요하지 않다면 PHP의 다른 메이저 또는 마이너 브랜치로 올리지 말라.

사용 가능한 테스트와 취약점 검사를 실행하라.

변경 사항, 남은 위험, 프로덕션에서 실행 중인 버전을 확인하는 방법을 보여라.

승인 없이 배포하지 말라. 런타임 버전이나 공급업체의 패치 상태를 확인하지 않고 취약점이 해결됐다고 말하지 말라.

코딩 에이전트는 샌드박스에서 실행하라는 권고도 덧붙였다.

PHP2Shell은 애플리케이션 의존성에 취약점이 하나도 없어도 애플리케이션이 취약할 수 있음을 보여주는 사례다. 원문이 소개한 Security Immediate Plan(SIP)은 강화된 컨테이너 이미지, SBOM, 출처 증명, 실제 릴리스 산출물 검사를 권장한다. 다만 당장 우선할 조치는 PHP 패치, 이미지 재빌드, 재배포, 실행 버전 확인이다.

참고 자료:

• PHP 공식 보안 권고 및 릴리스
• CVE-2026-109618 — 메모리 부족 처리 손상으로 인한 RCE (GHSA-w8hw-w9fx-j79w)
• CVE-2026-109619 — 오래된 전역 상태로 인한 RCE (GHSA-6wmf-4rv5-p3rp)
• Docker Scout CVE 검사
• PHP Docker 이미지 업데이트(techdows.com)