1 서버의 모든 PHP 찾기

많은 서버에서 둘 이상의 PHP가 실행됩니다. 시스템 패키지, 컨트롤 패널이 설치한 버전(cPanel EA-PHP, Plesk, CWP/CloudLinux alt-php, DirectAdmin), 컨테이너, cron이 사용하는 명령줄 빌드 등입니다. 웹 요청을 처리하는 것은 모두 업데이트해야 합니다.

php -v를 실행하고, ps aux | grep php-fpm으로 php-fpm 프로세스를 나열하고, 패널의 PHP 선택기를 확인하십시오.

2 수정된 버전으로 업데이트

업스트림의 수정된 버전은 8.5.12, 8.4.27, 8.3.36 및 8.2.35입니다. 배포판 패키지는 이전 버전 번호로 수정 사항을 포함할 수 있으니 변경 기록에서 CVE-2026-109618 및 CVE-2026-109619를 확인하십시오.

PHP 8.1 이하는 PHP 프로젝트의 릴리스가 없습니다. 소스에서 빌드하는 사용자를 위해 7.4, 8.0, 8.1용 최소 소스 백포트가 공개되었지만, 근본적인 해결책은 지원되는 브랜치로 이전하는 것입니다.

Debian / Ubuntu (배포판 패키지)

배포판의 보안 업데이트를 설치하고 PHP를 재시작하십시오. 버전 번호는 그대로일 수 있으며, 패키지 변경 기록에 CVE가 기재됩니다.

sudo apt update && sudo apt install --only-upgrade 'php*'
sudo systemctl restart 'php*-fpm' apache2 2>/dev/null
apt changelog php8.3-fpm | grep -i -m3 CVE-2026-1096

RHEL / AlmaLinux / Rocky (dnf)

사용 중인 PHP 모듈 스트림에 대한 공급업체 에라타를 적용한 후 재시작하십시오.

sudo dnf upgrade --refresh 'php*'
sudo systemctl restart php-fpm httpd
rpm -q --changelog php-common | grep -i -m3 CVE-2026-1096

Docker / 공식 php 이미지

수정된 태그로 이미지를 받거나 다시 빌드한 후 컨테이너를 다시 생성하십시오.

docker pull php:8.3-fpm   # must report 8.3.36 or later
docker compose up -d --build --force-recreate
docker compose exec app php -v

cPanel, Plesk, CWP, DirectAdmin

설치된 모든 PHP 버전(EA-PHP, Plesk PHP 핸들러, alt-php, CustomBuild)에 대해 패널의 업데이트 도구를 사용한 후 PHP-FPM을 재시작하십시오. 패널은 개별 사이트용으로 오래된 버전을 남겨 두는 경우가 많으니 이것들도 업데이트하거나 제거하십시오.

공유 또는 관리형 호스팅

대개 PHP를 직접 업데이트할 수 없습니다. 결과 카드의 메시지를 사용하여 호스팅 업체에 정확한 버전, 패치 날짜, 워커 재시작 여부를 확인해 달라고 요청하십시오.

Windows / IIS

windows.php.net에서 수정된 빌드를 내려받아 PHP 디렉터리를 교체하고 IIS 애플리케이션 풀을 재활용하십시오.

3 모든 PHP 프로세스 재시작

패키지를 설치해도 이미 실행 중인 코드는 바뀌지 않습니다. PHP-FPM, Apache(mod_php의 경우), LiteSpeed, FrankenPHP, 큐 워커 및 슈퍼바이저를 재시작하십시오. 컨테이너의 경우 새 이미지를 다시 빌드하거나 받아 오십시오. 같은 이미지를 재시작해도 패치는 설치되지 않습니다.

4 확인

각 바이너리에서 php -v를 실행하고, 실행 중인 프로세스가 새 빌드를 사용하는지 확인하십시오(예: ls -l /proc/$(pgrep -o php-fpm)/exe 출력에 "deleted"가 없어야 합니다). 그런 다음 이 검사기를 다시 실행하십시오.

5 오늘 업데이트할 수 없는 경우

업데이트할 수 있을 때까지 아래의 부분 완화 조치를 적용하고 사이트에 접근할 수 있는 대상을 제한하십시오. 이 조치들은 위험을 줄일 뿐 없애지는 못합니다.

6 침해 흔적 점검 및 비밀 정보 교체

취약한 사이트가 인터넷에서 접속 가능했다면 2026년 10월 20일 이후의 활동을 검토하십시오. PHP-FPM 또는 Apache 오류 로그의 PHP 워커 충돌(SIGSEGV), 웹 루트의 새로 생기거나 수정된 PHP 파일, 새 cron 작업, 새 관리자 계정, 예상치 못한 외부 연결 등입니다.

CVE-2026-109619는 코드를 전혀 실행하지 않고도 PHP 프로세스 메모리를 노출할 수 있으므로, 파일 시스템이 깨끗하다고 해서 아무것도 유출되지 않았다는 증거가 되지는 않습니다. 노출되었던 사이트의 데이터베이스 비밀번호, API 키, 결제 및 메일 자격 증명을 변경하고 사용자 세션을 무효화하십시오.

7 업데이트 후

이번 수정으로 새로운 하드 메모리 제한이 도입됩니다. 이 제한에 도달한 프로세스는 즉시 종료되며 종료 핸들러는 실행되지 않습니다. 메모리 부족 상황에서 애플리케이션이 어떻게 동작하는지 확인하고, memory_limit를 post_max_size 및 max_input_nesting_level과 함께 검토하며, 패치 전에 임시로 설정한 memory_limit = -1이 있다면 되돌리십시오. expose_php = Off로 버전을 숨기는 것은 선택적인 보안 강화일 뿐 해결책이 아닙니다.

부분 완화 조치(php.net 및 보안 권고 기준)

이 조치들은 알려진 공격 경로를 좁힐 뿐입니다. php.net은 업데이트만이 유일하게 안전한 선택이라고 밝히고 있습니다.

; php.ini / FPM pool (php_admin_value) — 적용 후 모든 워커 재시작
session.upload_progress.enabled = 0
fatal_error_backtraces = 0        ; PHP 8.5
post_max_size = 8M                ; 32M 업로드가 필요한 경우
max_input_nesting_level = 16      ; default 64
display_errors = 0

; FPM pool
pm.max_requests = 200

이 설정은 php.ini, PHP-FPM 풀(php_admin_value) 또는 서버 구성에서 지정하십시오. ini_set()이나 .user.ini로는 지정하지 마십시오. 그리고 워커를 재시작하십시오. 보안 권고와 연구팀이 제시한 추가 조치는 다음과 같습니다.

memory_limit = -1은 PHP 자체 메모리 제한에 의존하는 일부 경로를 차단하지만, 메모리 고갈 처리를 운영 체제에 넘깁니다. 반드시 cgroup v2 memory.max 제한과 함께 사용하십시오. RLIMIT_AS나 RLIMIT_DATA는 사용하지 마십시오. 같은 취약 경로를 유발할 수 있습니다.
양식이 허용하는 범위에서 max_input_nesting_level을 최대한 낮추십시오.
PHP-FPM pm.max_requests를 낮춰 워커가 더 자주 교체되도록 하십시오(성능 비용이 있습니다).
웹 서버나 프록시에서 요청 크기, 필드 수, 중첩 깊이를 제한하고, 유효하지 않거나 더 이상 사용되지 않는 요청별 INI 설정을 제거하십시오.
SELinux 또는 AppArmor 정책으로 침해된 워커가 실행할 수 있는 것을 제한할 수 있습니다. 피해를 줄일 뿐 메모리 유출을 막지는 못합니다.

참고 자료

출처: php.net 보안 권고, 2026년 10월 21일. 최종 확인일 2026-10-23.