PHP 보안 권고문 발표 후 해야 할 일

첫 1시간: 무엇이 릴리스되었는지 파악하기

PHP 보안 수정은 보통 지원 중인 모든 브랜치에 걸쳐 조율된 패치 릴리스로 제공되며, PHP 릴리스 페이지에서 발표되고 php-src security advisories에 설명됩니다. 서버를 건드리기 전에 다음 사실을 수집하십시오.

질문	답을 찾을 수 있는 곳
어떤 CVE ID가 관련되어 있습니까?	릴리스 공지, ChangeLog, 보안 권고문
각 브랜치에서 무엇이 수정되었습니까?	브랜치별 수정 버전(예: 8.3.36)
얼마나 심각합니까?	권고문 또는 NVD의 CVSS 점수와 벡터
어떤 조건이 필요합니까?	SAPI, OS, 확장 기능, 함수 또는 구성
실제로 악용되고 있습니까?	권고문의 참고 사항, 벤더 및 보안 커뮤니티 보고

이 가이드에서는 2026-10-21 릴리스를 예로 사용합니다. PHP는 CVE-2026-109618과 CVE-2026-109619를 수정하기 위해 8.5.12, 8.4.27, 8.3.36, 8.2.35를 공개했습니다. 두 취약점은 CVSS v4.0 기준 9.2점의 원격 코드 실행 취약점으로, PHP 5.4부터 8.5.11까지 영향을 줍니다. 지원이 종료된 8.1 이하 브랜치는 수정을 받지 못했습니다.

범위 표기법이 익숙하지 않다면 먼저 PHP CVE와 영향 버전 범위 이해하기를 읽어 보십시오.

1단계: 내 환경에서 얼마나 긴급한지 판단하기

간단한 분류(triage)를 거치면 과잉 반응과 안일함을 모두 피할 수 있습니다.

신호	긴급도를 높이는 요인	긴급도를 낮추는 요인
영향	원격 코드 실행, 인증 우회	로컬 전용, 경미한 정보 유출
전제 조건	기본 구성, 흔히 쓰는 SAPI	드문 플랫폼 또는 비활성화된 확장 기능
노출	공개 웹사이트, 업로드 폼, API	VPN 뒤의 내부 도구
악용	공개된 개념 증명(PoC) 코드, 실제 공격	알려진 익스플로잇 없음

2026년 10월의 두 취약점처럼 기본 구성에 영향을 주는 치명적인 RCE 문제는 인터넷에 노출된 시스템이라면 당일 또는 다음 날 처리할 작업으로 다뤄야 합니다. 전제 조건이 까다로운 낮은 심각도의 문제는 보통 다음 정기 유지 보수 기간까지 기다려도 됩니다. 단, 그러한 기간이 실제로 존재하고 몇 달 뒤가 아니어야 합니다.

2단계: 영향받는 런타임 목록 작성하기

모르는 것은 패치할 수 없습니다. PHP가 실행되는 모든 곳을 나열하십시오.

웹 서버와 그 PHP-FPM 풀 또는 Apache 모듈
cron 작업, 큐 워커, 배포 스크립트에서 사용하는 CLI 인터프리터
CI 파이프라인의 베이스 이미지를 포함한 컨테이너 이미지
스테이징(staging), 개발 서버, 잊힌 레거시 서버
공유 호스팅 계정과 관리형 WordPress 사이트

각 항목에 대해 정확한 버전과 출처(업스트림 빌드 또는 배포판 패키지)를 기록합니다. 직접 관리하는 서버에서는 다음을 실행합니다.

php -v
ls /usr/sbin/php-fpm* 2>/dev/null
dpkg -l | grep -E '^ii\s+php'     # Debian / Ubuntu
rpm -qa | grep -i '^php'          # RHEL family

컨테이너는 이미지 태그와 그 안의 버전을 확인합니다.

docker run --rm your-image:tag php -v

셸 접근 권한이 없는 사이트는 WordPress 사이트 건강(도구 → 사이트 건강 → 정보 → 서버(Tools → Site Health → Info → Server)) 또는 호스팅 패널에서 버전을 확인할 수 있습니다. PHP 버전 검사기를 사용하면 각 업스트림 버전이 영향 범위에 속하는지 빠르게 알 수 있으며, PHP 버전 확인 방법 가이드에서 각 방법을 자세히 다룹니다.

3단계: 노출 정도에 따라 순서대로 패치하기

가장 많이 노출된 곳부터 가장 적게 노출된 곳 순으로 작업하십시오. 공개 운영 사이트를 먼저, 그다음 내부 시스템, 마지막으로 개발 환경 순입니다.

업스트림 빌드와 호스팅 패널

같은 브랜치의 수정된 패치 릴리스로 이동합니다. 이는 위험이 낮은 변경입니다. 브랜치 내 패치 릴리스는 호환성을 깨지 않고 버그와 보안 문제를 수정하기 위한 것이기 때문입니다. 예시 릴리스의 경우 다음과 같습니다.

현재 브랜치	대상 릴리스
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35

관리형 호스팅에서는 보통 제공 업체가 패치 릴리스를 배포합니다. 릴리스 후 며칠이 지나도 패널에 여전히 이전 패치 버전이 표시된다면, 티켓을 열어 구체적인 적용 날짜를 문의하십시오.

컨테이너는 업데이트된 베이스 이미지로 이미지를 다시 빌드하고 재배포합니다. Dockerfile의 태그만 바꾸고 다시 빌드하고 재배포하지 않으면 운영 환경에는 아무 변화도 없습니다.

배포판 패키지

패키지 관리자를 통해 업데이트를 설치합니다.

sudo apt update && sudo apt upgrade        # Debian / Ubuntu
sudo dnf upgrade --security                # RHEL family

배포판은 수정을 백포트(backport)하므로, 패키지 버전이 업스트림 수정 릴리스와 반드시 일치하지는 않습니다. PHP 보안 패치 설치 여부 확인의 단계를 따라 해당 CVE ID가 처리되었는지 확인하십시오. 배포판이 아직 수정을 공개하지 않았다면 그 사실을 기록하고, 완화 조치를 적용한 뒤, 다시 확인하십시오.

지원 종료 브랜치

서버가 8.1, 8.0 또는 7.x를 실행한다면 설치할 업스트림 패치 릴리스가 없습니다. 벤더가 백포트된 수정을 제공하고 이 CVE ID들에 대해 직접 확인한 경우가 아니라면, 유일한 실질적 해결책은 지원되는 브랜치로 업그레이드하는 것입니다. 이는 더 큰 변경이므로 다음과 같이 진행하십시오.

지금 완화 조치를 적용합니다(4단계).
PHP 업그레이드 계획에 따라 호환성 테스트를 거친 업그레이드를 즉시 시작합니다.
확정된 기한을 정하고 추적합니다.

4단계: 아직 패치할 수 없다면 완화하기

완화 조치는 위험을 줄일 뿐, 수정을 대체하지는 않습니다.

접근을 제한합니다. 관리자 패널, 스테이징 사이트, 내부 도구를 인증, IP 허용 목록 또는 VPN 뒤에 두십시오.
사용하지 않는 구성 요소를 비활성화합니다. 취약점이 사용하지 않는 SAPI나 확장 기능에 있다면 제거하거나 비활성화하십시오.
웹 애플리케이션 방화벽(WAF) 규칙을 사용합니다. 제공 업체가 해당 CVE에 대한 규칙을 공개했다면 적용하고, 사이트가 정상 동작하는지 테스트하십시오.
정보 노출을 줄입니다. expose_php = Off로 설정해 X-Powered-By 헤더가 버전을 알리지 않게 하고, 남아 있는 phpinfo() 파일을 모두 제거하십시오. 이것으로 무언가가 수정되지는 않지만, 자동화된 스캔에서 눈에 덜 띄는 대상이 됩니다.
모니터링을 강화합니다. 웹 서버와 PHP 오류 로그에서 비정상적인 요청, 크래시, 쓰기 가능한 디렉터리에 새로 생긴 파일을 살펴보십시오.

; php.ini
expose_php = Off

5단계: 수정이 실제로 적용되었는지 확인하기

패치 후 가장 흔한 실패는 서비스를 재시작하지 않은 것입니다.

PHP-FPM 또는 웹 서버를 재시작합니다.
```
sudo systemctl restart php8.3-fpm
```
CLI뿐 아니라 웹 서버가 사용하는 버전을 확인합니다. 사이트 건강, 호스팅 패널, 또는 확인 후 즉시 삭제하는 임시 phpinfo() 페이지를 이용하십시오.
결과를 CVE 검사기나 벤더의 추적 페이지로 확인합니다.
웹사이트 보안 점검 도구로 공개 사이트를 다시 점검해 버전 헤더 노출 등의 문제를 확인합니다.

6단계: 수행한 작업 기록하기

시스템당 몇 줄이면 충분합니다. 가상의 서버 세 대에 대한 기록 예시입니다.

2026-10-22  web-01  PHP 8.3.35 -> 8.3.36 (upstream)   FPM restarted 14:10 UTC   verified
2026-10-22  web-02  distro php package   CVE IDs checked in changelog   result recorded
2026-10-22  legacy  PHP 8.1.34 (EOL)   no fix   restricted to VPN   upgrade ticket due 2026-11-15

이 기록은 고객이나 감사인의 질문에 답하는 데 도움이 되며, 어떤 시스템이 계속 뒤처지는지 보여 줍니다. 보안 권고가 나올 때마다 목록에 오르는 시스템이 바로 업그레이드나 폐기를 우선 검토해야 할 대상입니다.

다음 보안 권고에 대비하기

2단계의 목록을 매번 새로 만들지 말고 최신 상태로 유지하십시오.
PHP 릴리스 공지와 사용 중인 배포판의 보안 공지를 구독하십시오.
지원되는 브랜치를 유지해, 앞으로의 모든 수정이 적용될 곳이 있도록 하십시오.
도구가 허용하는 범위에서 패치 수준 업데이트를 자동화하고, 회귀를 잡아낼 수 있도록 모니터링을 함께 운영하십시오.