PHP 긴급 보안 업데이트: 버전 확인부터 웹 워커 교체까지

지금 필요한 것은 어떤 PHP를 바꿨는지 확인하는 일이다

2026년 10월 21일 PHP 프로젝트는 인증 없이 원격 코드 실행으로 이어질 수 있는 CVE-2026-109618·CVE-2026-109619를 수정했다. upstream 수정 릴리스는 아래와 같다. 이 표는 PHP 프로젝트가 배포한 릴리스의 기준이며, 모든 운영체제 패키지에 같은 숫자를 요구하는 표가 아니다. PHP 보안 공지

사용 중인 upstream 계열	10월 21일 수정 릴리스
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

공지는 웹 요청을 처리하는 PHP-FPM, Apache의 mod_php, php-cgi, FrankenPHP, LiteSpeed 등을 대상으로 삼는다. mod_php에서는 애플리케이션 코드가 실행되기 전 공격이 시연됐다고 설명한다. 따라서 “우리 앱은 로그인해야 쓸 수 있다”는 이유만으로 PHP 런타임 점검을 생략할 수 없다. 공식 적용 범위

이 글은 10월 23일 확인한 공식 자료를 바탕으로 한 운영 판단 안내다. 실제 서버 패치나 공격 재현을 수행하지 않았다. 아래 사례는 가상이며, 명령은 미실행 확인 절차다. 독자가 남길 결과물은 단일 버전 스크린샷이 아니라 서비스 경로별 수정본 적용 기록이다.

요청은 끝났는데 왜 다음 요청까지 영향을 받을까

PHP의 워커는 웹 요청을 처리하는 프로세스다. 하나의 요청이 끝나도 같은 워커가 다음 요청을 받을 수 있다. 요청에 속한 임시 메모리와 워커가 계속 보관하는 상태는 수명이 다르다. 이번 두 문제는 이 경계에서 발생한다.

CVE-2026-109618은 메모리 부족을 처리하는 도중 내부 요청 데이터의 초기화가 중단됐는데, 정리 과정이 불완전한 데이터를 유효한 상태처럼 다룰 수 있는 문제다. 정상적인 업무 코드의 입력 검증만 보고 안전을 판단하기 어려운 이유다. PHP 유지관리자의 보안 권고는 mod_php의 기본 설정에서 원격 코드 실행을 확인했고, PHP-FPM에도 애플리케이션 단계의 경로가 있다고 설명한다. OOM 처리 권고

CVE-2026-109619는 이전 요청의 메모리가 해제된 뒤에도 그것을 가리키는 전역 상태가 남는 문제다. 같은 워커의 다음 요청이 정상 초기화 전에 그 상태를 사용하면 해제된 메모리에 접근할 수 있다. 치명적 오류로 정리 과정이 끊기는 경우뿐 아니라, 정리한 뒤 진단 처리로 상태가 다시 채워지는 경우도 권고에 포함된다. 오래된 전역 상태 권고

두 문제를 “메모리를 많이 쓰면 무조건 해킹된다”로 요약하면 정확하지 않다. 구체적인 실행 경로와 빌드·확장·설정에 따라 조건이 다르다. 그렇다고 한 경로의 공격이 어렵다는 설명을 전체 설치의 안전으로 확대해서도 안 된다. 운영자가 해야 할 일은 자기 서비스에서 공격 성공을 시험하는 것이 아니라, 공급처가 수정한 빌드를 찾아 실행 경로 전체에 적용하는 것이다.

AI가 발견을 도와도 수정과 배포의 병목은 남는다

이번 사건은 AI 보안 연구의 성과를 읽는 방법도 보여 준다. PHP Foundation의 설명에 따르면 OOM 문제의 초기 징후는 2024년 외부 감사 후 수정 과정에서 발견됐다. 이후 Calif·OpenAI·Wiz 등의 보고가 영향을 구체화했고, 팀은 AI 도구와 sanitizer·재현 환경을 함께 사용했다. 재단은 호환성, 확장 생태계, 수정안 선택과 인력 부족이 해결을 늦췄다고 설명한다. PHP Foundation의 경위 설명

이 자료에서 읽을 수 있는 함의는 발견 속도와 수정본을 안전하게 배포하는 속도가 별개라는 점이다. 탐지 도구가 늘어도 수정안을 검토하고 배포판에 전달하며 서비스의 오래된 프로세스를 교체하는 일이 사라지지 않는다. 특정 AI가 전체 과정을 혼자 해결했다거나, 이 사건 하나로 도구 간 탐지 성능 순위를 정할 근거는 없다.

버전 숫자를 비교하기 전에 공급처를 맞춘다

백포트는 새 릴리스의 수정 사항을 기존 버전 계열에 반영하는 방식이다. 그래서 배포판이 유지하는 PHP는 앞부분 숫자가 upstream 수정 릴리스보다 낮아도 해당 CVE가 수정돼 있을 수 있다.

10월 23일 확인한 Ubuntu의 두 CVE 페이지 모두 다음 패키지를 수정됨으로 표시했다. 아래 값은 해당 Ubuntu 릴리스의 패키지 기준이다. PPA, 직접 빌드, 다른 배포판 또는 컨테이너 안의 PHP에 자동으로 적용되지 않는다. CVE-2026-109618 상태, CVE-2026-109619 상태

Ubuntu 릴리스·소스 패키지	공지의 수정 패키지 버전	확인할 지점
22.04 LTS · php8.1	8.1.2-1ubuntu2.28	8.1.2만 떼어 비교하지 말고 Ubuntu 패키지 개정 번호까지 확인
24.04 LTS · php8.3	8.3.6-0ubuntu0.24.04.13	CLI·FPM·Apache 모듈 중 실제 사용 패키지와 공급 저장소 확인

PHP 프로젝트는 8.1 이하를 정규 지원하지 않는다. 다만 이번 공지에는 배포판·LTS 공급자의 백포트와, 직접 빌드 등을 위한 7.4·8.0·8.1 최소 소스 백포트도 안내돼 있다. 이 예외를 “오래된 PHP의 일반 지원이 재개됐다”는 뜻으로 읽어서는 안 된다. 관리형 호스팅이라면 운영자가 공급자의 수정 적용 확인을 받아야 한다. 지원 종료 계열의 이번 대응

판정의 입력은 PHP 8.x라는 문자열 하나가 아니라 운영체제 릴리스 + 공급 저장소 + 패키지 전체 버전 + 두 CVE의 수정 상태다. 나중에 더 최신 패키지가 나왔다면 현재 공급자 공지와 변경 이력으로 다시 대조한다. 버전 번호를 문자열 사전순으로 비교해 수정 여부를 자동 판정하지 않는다.

CLI와 웹 서버는 서로 다른 PHP를 볼 수 있다

터미널의 php 명령은 현재 셸이 찾은 실행 파일을 시작한다. 웹 서버는 별도 FPM 풀이나 Apache 모듈, 컨테이너를 사용할 수 있다. PHP 공식 문서도 실행 인터페이스인 SAPI를 cli, fpm-fcgi, apache2handler 등으로 구분한다. SAPI 문서

다음은 관리 권한이 있는 환경에서 확인할 미실행 절차다. 패키지 설치나 서비스 재시작 명령은 아니다.

command -v php
php -v
php --ini

첫 줄은 셸이 찾은 명령 경로, 다음 줄은 그 실행 파일의 버전, 마지막 줄은 해당 실행의 설정 파일 위치를 확인하는 출발점이다. -v와 --ini의 의미는 PHP CLI 옵션 문서에 따른다. 이 결과를 그대로 “웹 서비스 패치 완료”로 적지 않는다. 로컬에 PHP 명령이 없다는 사실도 원격 호스팅이나 컨테이너에 PHP가 없다는 뜻은 아니다.

웹 쪽에서는 웹 서버가 연결하는 FPM 소켓·풀 또는 로드하는 모듈을 찾고, 해당 프로세스가 어느 패키지나 이미지에서 시작됐는지 대조한다. 이미 있는 접근 제한된 운영 진단 화면·배포 기록을 사용하는 편이 좋다. 확인 목적으로 전체 설정과 환경을 노출하는 phpinfo() 페이지를 공개 인터넷에 새로 열 필요는 없다.

WordPress 사용자는 도구 → 사이트 건강 → 정보 → 서버에서 PHP 버전을 볼 수 있다. 이 위치는 현재 사이트가 보고하는 서버 정보를 확인하는 출발점이고, 호스팅 관리 화면의 업데이트 안내와 대조할 수 있다. WordPress 공식 공지는 이번 문제에 별도의 WordPress 업데이트가 필요한 것은 아니라고 설명한다. WordPress 본체나 플러그인을 업데이트한 것만으로 PHP 수정이 끝난 것은 아니다. WordPress의 확인 경로

화면 캡처는 이 글에 포함하지 않았다. 위 메뉴는 공식 안내를 옮긴 것이며, 직접 로그인해 사용한 결과가 아니다. 모바일에서는 서버 정보 영역을 펼쳐 값을 확인하고, 보이는 버전만으로 공급자의 백포트 적용 여부까지 추정하지 않는다.

파일 설치와 모든 워커의 교체를 나누어 기록한다

패키지 관리 화면의 설치 성공은 디스크의 파일이 바뀌었다는 증거다. 이미 실행 중인 프로세스와 여러 복제본까지 새 수정본을 사용한다는 결론에는 실행 상태가 더 필요하다. 아래는 이 차이를 놓치지 않기 위한 편집 제안이다. 제품별 재시작 명령이나 모든 환경에 통하는 자동 판정기는 아니다.

직접 그린 설명도다. 특정 서버의 실제 배포 상태나 취약점 재현 결과가 아니다.

운영 형태	업데이트 뒤 확인할 대상	완료로 보기 어려운 증거
FPM	웹 서버가 연결하는 모든 풀, 새 수정본으로 시작한 워커, 교체 전 워커의 종료	터미널의 php -v만 새 버전
Apache mod_php	실제 로드되는 PHP 모듈과 이를 사용하는 프로세스의 교체	PHP CLI 패키지만 업데이트
컨테이너·복제본	수정 패키지를 담은 이미지의 digest, 각 실행 인스턴스의 이미지와 교체 상태	레지스트리에 새 태그를 올리거나 이미지만 pull
관리형 호스팅	해당 사이트·풀의 수정 빌드, 적용 시각, 공급자의 완료 확인	전체 고객 대상의 “업데이트 예정” 공지

재시작과 점진적 교체의 구체적인 동작은 서비스 관리자·제품의 절차를 따라야 한다. 여기서 확인할 종료 조건은 구 수정본으로 시작한 워커가 더 이상 요청을 받지 않는가다. 점진적 교체 중 오래된 워커가 남았다면 그 상태와 종료 계획을 기록한다. 단순히 재로드 명령이 성공했다는 메시지만 남기지 않는다.

컨테이너에서는 호스트 PHP를 업데이트해도 이미지 내부의 PHP가 바뀌지 않을 수 있다. 새 이미지를 만들었어도 기존 인스턴스가 남아 있을 수 있다. 한 번의 정상 응답은 그 응답을 처리한 경로의 관측일 뿐이므로, 여러 복제본이 있다면 배포 목록과 실행 목록의 대응을 확인해야 한다. 새 트래픽으로 자동 확장될 때 쓸 이미지나 시작 템플릿도 함께 바꿔야 한다.

가상 쇼핑몰: 세 줄의 보고가 왜 서로 다를까

한 쇼핑몰이 Ubuntu 24.04 서버의 FPM 두 풀과 별도 컨테이너형 관리자 앱을 쓴다고 가정하자. 고객 사이트의 CLI에는 8.3.6이 보이고, 패키지 기록에는 8.3.6-0ubuntu0.24.04.13이 설치돼 있다. 담당자는 “숫자가 8.3.36보다 낮아서 아직 취약하다”고 판단했다.

첫 판단부터 공급처가 섞였다. 이 가정의 패키지는 앞의 Ubuntu 공지와 일치한다. 그러나 이것만으로 작업을 닫을 수도 없다. 첫 번째 FPM 풀은 교체됐지만 두 번째 풀의 워커가 아직 남아 있고, 관리자 앱 컨테이너는 전날 이미지로 실행 중이라고 가정하면 다음처럼 기록한다.

• 고객 사이트의 수정 패키지 확보: 확인. Ubuntu 릴리스와 전체 패키지 버전, 두 CVE의 수정 상태가 맞는다.
• 고객 사이트의 실행 적용: 진행 중. 두 번째 풀의 구 워커가 종료되는지 확인해야 한다.
• 관리자 앱의 실행 적용: 미확인. 호스트 패키지 기록을 컨테이너의 증거로 재사용할 수 없다.

이 사례의 숫자 중 Ubuntu 수정 버전만 공식 자료에서 가져왔다. 서버 구성·풀 수·교체 상태는 설명을 위한 가정이다. 실제 쇼핑몰이나 이 블로그의 운영 관측이 아니다.

설정 완화와 롤백에서 놓치기 쉬운 조건

PHP 프로젝트는 수정본 업데이트만이 완전한 해결책이라고 설명한다. 공지의 임시 조치는 특정 공격 경로의 노출을 줄이지만 설치 전체를 안전하게 만들지는 않는다. 예를 들어 session.upload_progress.enabled=0은 확인된 세션 경로를 막는 조치이며, 요청 파싱 전에 적용돼야 하고 모든 워커 재시작이 필요하다고 명시한다. 애플리케이션 안의 ini_set()으로 같은 효과를 가정해서는 안 된다. 공식 임시 조치의 범위

이 글은 그 설정 하나를 범용 처방으로 권하지 않는다. 운영팀은 현재 공지의 조건과 서비스 영향을 확인해야 한다. WAF 규칙이 적용됐다는 연락도 PHP 수정본 적용 완료와는 다른 항목으로 기록한다. 즉시 수정할 수 없다면 호스팅·보안 담당자와 접근 제한이나 일시 중단을 결정하고, 임시 조치의 해제 시점을 수정본 검증에 연결한다.

패치 후 애플리케이션 문제가 생겼을 때도 “이전 이미지로 복귀”를 무조건 안전한 복구로 취급할 수 없다. 이전 이미지가 취약한 PHP를 포함한다면, 재노출을 막은 상태에서 문제를 진단하거나 수정된 런타임을 유지한 대안을 마련해야 한다. 로그인·세션·업로드 등 서비스가 실제 사용하는 기능의 정상 동작을 확인하되, 공격 코드를 보내는 방식으로 패치 여부를 시험할 필요는 없다.

또한 업데이트가 성공해도 그 전에 침해가 없었다는 결론은 나오지 않는다. 의심스러운 프로세스·파일 변경·계정 활동이 확인됐다면 패치 작업과 별도로 조직의 사고 대응 절차로 조사한다. 여기서는 특정 환경의 침해 여부나 전체 인터넷의 공격 현황을 판정하지 않는다.

작업을 닫기 전에 남길 기록

다음 양식을 서비스별로 복사해 사용할 수 있다. 한 행의 상태는 확인 / 진행 중 / 미확인으로 남기고, 모르는 값을 추정해 채우지 않는다.

서비스·담당자:
웹 실행 경로: 도메인 → 웹 서버 → FPM 풀/모듈/컨테이너
공급처: OS 릴리스 / 저장소 또는 이미지 공급자
수정 근거: 두 CVE의 공지 URL / 확인 시각
설치 증거: 전체 패키지 버전 또는 이미지 digest
실행 증거: 풀·복제본 목록 / 교체 완료 시각 / 구 워커 잔존 여부
다음 생성 경로: 자동 확장·재시작 때 사용할 이미지·템플릿
기능 확인: 정상 요청 / 로그인·세션 / 사용하는 업로드 기능
임시 조치: 적용 범위 / 남은 노출 / 해제 조건
복구 조건: 취약 런타임으로 돌아가지 않을 대안
미확인 항목·다음 담당자·재확인 시각:

최종 보고에서는 “PHP 업데이트 완료”보다 어느 공급자의 수정본을 어느 서비스의 모든 실행 경로에 적용했는지를 적으면 다음 담당자가 판단을 이어갈 수 있다. 공급망 문서와 빌드 증거의 연결은 SBOM·Provenance·VEX 글, 변경 뒤 옛 응답을 볼 때의 캐시 진단은 HTTP 캐시와 재검증 글에서 이어서 볼 수 있다. 이 절차를 저장해 두되, 실제 다음 업데이트 때에는 공급자 공지의 날짜와 수정 패키지를 다시 확인하자.