PHP CVE-2026-109618·CVE-2026-109619 취약점 영향과 대응 방법

PHP 코어 엔진의 비정상 종료 및 요청 상태 관리 과정에서 인증 없이 원격 코드 실행(RCE)이 가능한 CVE-2026-109618, CVE-2026-109619 취약점이 공개되었습니다. 이 문제는 워드프레스나 그누보드 같은 웹 애플리케이션이 아니라 PHP 실행 엔진 자체의 메모리 손상 및 해제 후 재사용(Use-After-Free) 결함에서 비롯됩니다. 문제를 해결하려면 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 등 보안 패치가 적용된 버전으로 즉시 업그레이드하고 워커 프로세스를 재시작해야 합니다.

웹 애플리케이션 업데이트만으로 막을 수 없는 PHP 엔진 취약점

2026년 10월 21일(UTC), PHP 개발팀은 CVSS v4.0 기준 위험도 9.2점으로 안내된 두 건의 보안 취약점을 발표했습니다. 공격자는 별도의 로그인 과정 없이 조작된 HTTP 요청을 전송하는 것만으로 서버에서 임의의 코드를 실행할 수 있습니다.

이 결함은 웹 요청을 파싱하고 메모리를 정리하는 PHP 코어 계층에서 동작합니다. 따라서 사이트의 CMS나 플러그인을 최신으로 유지하더라도 PHP 런타임 자체가 구버전이면 공격에 노출됩니다. 특히 Apache의 mod_php 기본 설정 환경에서는 웹 애플리케이션 코드가 실행되기도 전에 단일 요청만으로 코드 실행이 가능한 것으로 확인되었습니다.

공격이 성공하면 침입자는 PHP 프로세스가 실행되는 시스템 계정의 권한을 얻습니다. 곧바로 루트(root) 권한을 탈취하는 것은 아니지만, 웹 루트 디렉터리에 웹셸을 생성하거나 설정 파일에 기록된 데이터베이스 접속 정보를 열람해 내부 데이터를 유출·변조할 수 있습니다. 단일 서버에서 여러 웹사이트가 동일한 PHP-FPM 실행 계정을 공유하고 있다면 한 사이트의 침해가 서버 내 다른 사이트로 확산될 위험도 존재합니다.

비정상 종료 시 발생하는 메모리 손상과 해제 후 재사용 원리

두 취약점은 모두 요청 처리 중 예외적인 상황이 발생했을 때 메모리를 안전하게 정리하지 못해 일어납니다. 발생 조건과 내부 동작 원리는 각각 다릅니다.

CVE-2026-109618 (메모리 한도 초과 처리 중 발생하는 메모리 손상): PHP는 요청을 처리하다가 허용된 메모리 한도(Out-Of-Memory)를 초과하면 longjmp()를 호출해 실행을 즉시 중단합니다. 이때 내부 요청 자료구조가 아직 완전히 초기화되지 않은 상태에서 작업이 멈추면, 불완전한 상태가 롤백되지 않고 남게 됩니다. 이후 실행되는 요청 정리(cleanup) 루틴이 이 미초기화 메모리를 정상 데이터로 신뢰하고 접근하면서 메모리 손상과 원격 코드 실행으로 이어집니다.

CVE-2026-109619 (이전 요청의 해제된 메모리를 참조하는 Use-After-Free): PHP 내부의 일부 전역 상태나 오류 처리 상태는 단일 요청이 소유한 메모리 영역을 임시로 가리킵니다. 치명적 오류(fatal error)나 메모리 부족으로 요청이 비정상 종료될 때, 실제 메모리는 해제되었으나 이를 가리키는 내부 포인터 참조가 초기화되지 않고 남는 경우가 있습니다. PHP-FPM이나 mod_php처럼 워커 프로세스를 재사용하는 환경에서 동일한 워커가 다음 HTTP 요청을 받아 처리할 때, 이미 해제된 메모리 영역을 다시 읽어 들이면서(Use-After-Free) 코드 실행 경로가 만들어집니다.

공식 보안 공지는 CVE-2026-109619의 확인된 경로로 세션 업로드 진행률 기능(session.upload_progress), 요청 초기화 이전에 출력되는 설정 경고, PHP 8.5의 치명적 오류 백트레이스(fatal_error_backtraces)를 듭니다. 다만 이 경로들을 막아도 다른 변형 경로는 남는다고 밝히고 있습니다.

PHP 버전별 패치 현황과 실행 환경에 따른 영향 범위

수정 버전보다 낮은 PHP 8.2~8.5가 영향을 받고, 지원이 끝난 8.1 이하는 PHP 프로젝트의 공식 업데이트 대상이 아닙니다. 실행 방식으로는 PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed 등 웹 요청을 처리하는 모든 설치가 대상이며, 공식 공지는 그중 mod_php의 위험을 가장 높게 봅니다. Red Hat은 PHP-FPM이 애플리케이션 단계의 경로를 통해 조건부로 영향을 받는다고 분류합니다.

확인 환경: 2026년 10월 22일 기준, Remi 저장소를 사용하는 Linux 서버 환경에서 PHP 8.4.26을 8.4.27로 업그레이드하고 PHP-FPM 워커 재시작 및 웹 요청 반영을 검증했습니다.

패키지 업데이트와 PHP-FPM 완화 설정 적용 절차

PHP 개발팀은 설정 변경만으로는 모든 공격 경로를 차단할 수 없으며, 패치 버전으로 업데이트하는 것만이 유일하고 완전한 해결책이라고 안내합니다. 업데이트 후에도 공격 표면을 줄이기 위해 불필요한 기능을 끄는 완화 조치를 함께 적용할 수 있습니다.

1. PHP 패키지 업데이트 설치
   운영체제 패키지 관리자를 통해 사용 중인 PHP 계열의 수정 버전(8.4 계열의 경우 8.4.27)으로 패키지를 업그레이드합니다. 설치 후 터미널에서 CLI 버전을 먼저 확인합니다.

   php -v

   명령어를 실행하면 화면에 PHP 8.4.27 (cli)와 같이 업데이트된 버전 번호와 빌드 날짜가 출력됩니다. 단, CLI 버전과 실제 웹 서버가 연동하는 PHP 프로세스의 버전 상태는 다를 수 있으므로 다음 단계를 반드시 진행해야 합니다.

2. 공격 표면 감소를 위한 PHP-FPM 설정 조정 (선택 및 임시 완화)
   업데이트를 즉시 적용하기 어렵거나 추가적인 방어 계층을 두려면 php.ini 또는 PHP-FPM 풀 설정 파일(예: /etc/php-fpm.d/www.conf)을 백업한 뒤 아래 항목을 조정합니다.

   php_admin_value[session.upload_progress.enabled] = Off
   php_admin_value[post_max_size] = 32M
   php_admin_value[upload_max_filesize] = 30M

   session.upload_progress.enabled를 비활성화하면 확인된 세션 기반 공격 경로를 차단할 수 있습니다. post_max_size를 낮추면(파일 업로드가 불필요한 환경은 8M, 필요한 환경은 32M 등) 대용량 요청으로 메모리 고갈을 유도하는 시도를 어렵게 만듭니다. 이때 multipart 부가 헤더 크기를 고려해 upload_max_filesize는 post_max_size보다 약간 작게 지정합니다. PHP 8.5 환경이라면 fatal_error_backtraces = 0 설정도 함께 적용합니다.

3. PHP-FPM 설정 문법 검사 및 프로세스 재시작
   설정을 저장한 뒤 문법 오류가 없는지 테스트하고 PHP-FPM 서비스를 재시작합니다.

   php-fpm -t
   systemctl restart php-fpm

   php-fpm -t 실행 시 설정에 문제가 없다면 NOTICE: configuration file ... test is successful 메시지가 화면에 표시됩니다. 워커 프로세스를 재시작해야 메모리에 상주하던 기존 구버전 워커가 종료되고 새 패치와 설정이 반영됩니다.

4. 웹 요청을 통한 실제 적용 버전 확인
   워드프레스의 '사이트 상태(Site Health)' 정보 탭이나 웹 서버 연동 진단 페이지를 호출해 웹 요청을 처리하는 PHP-FPM 워커가 8.4.27 등 패치된 버전으로 응답하는지 확인합니다. 확인을 위해 임시로 생성한 진단용 PHP 파일이 있다면 외부에 시스템 정보가 노출되지 않도록 점검 직후 삭제합니다.

업데이트 지연이나 설정 변경 부작용이 발생할 때의 대처법

서드파티 저장소(Remi 등) 미러 반영이 늦어 패키지가 내려받아지지 않을 때

긴급 보안 패치 직후에는 트래픽 집중이나 동기화 지연으로 인해 서드파티 저장소(예: rpms.remirepo.net)에서 업데이트 패키지가 바로 조회되지 않거나 다운로드 속도가 느려질 수 있습니다. 공식 공지는 자원봉사자가 운영하는 이 저장소에 발표 당일 업데이트가 올라오지 않는다고 밝히고, 배포판 패키지나 소스 빌드로 전환하라고 권했습니다.

이 경우 저장소 설정에서 동기화가 완료된 정상 속도의 미러 서버 주소를 직접 지정해 업데이트를 진행할 수 있습니다. 미러를 수동으로 변경하더라도 패키지 위변조를 막기 위해 GPG 서명 검사(gpgcheck=1)는 활성화 상태로 유지해야 합니다. 미러 사용이 불가능하다면 OS 배포판의 공식 백포트 패키지를 사용하거나 소스 코드를 직접 컴파일해 적용합니다.

완화 설정 적용 시 메모리 부족(OOM)이나 업로드 거부가 우려될 때

공식 공지는 바로 업데이트할 수 없을 때 CVE-2026-109618의 완화책으로 memory_limit = -1(무제한)을 제시하고, 이때 컨테이너나 cgroup 메모리 제한을 함께 두라고 안내합니다. 그러나 물리 메모리가 넉넉하지 않은 서버에서 메모리 제한을 해제하면, 단일 요청이 서버 메모리를 모두 소모해 운영체제의 OOM Killer가 핵심 데몬을 강제 종료시키는 장애가 발생할 수 있습니다. 이 설정은 업데이트 전까지의 임시 조치이며, 패치 버전으로 업데이트한 뒤에는 원래의 메모리 제한으로 되돌리는 것이 안전합니다.

또한 post_max_size를 기존(예: 64MB)보다 낮출 때는 사이트의 파일 전송 방식을 먼저 점검해야 합니다. 관리자 웹 페이지를 통해 대용량 백업 파일이나 플러그인을 직접 업로드하는 사이트는 요청이 차단될 수 있습니다. 반면 대용량 파일을 SFTP나 rsync로 전송하는 환경이거나, 애플리케이션 자체 제한이 이미 30MB 이하로 설정된 경우라면 PHP의 업로드 제한을 32MB로 낮추어도 서비스에 영향이 없습니다.

한편, PHP 버전 업그레이드 후 간헐적으로 PHP-FPM 워커가 비정상 종료된다면 OPcache의 JIT(Just-In-Time) 컴파일 설정을 의심해 볼 수 있습니다. JIT 기능(예: opcache.jit=1255)은 이번 보안 취약점과 직접적인 연관은 없으나, 버전 변경 시 안정성 문제를 일으킨 이력이 있다면 설정 파일에서 opcache.jit=off로 비활성화해 충돌을 예방할 수 있습니다.

자주 묻는 질문

워드프레스나 플러그인을 최신 버전으로 업데이트하면 해결되나요?

해결되지 않습니다. 이 취약점은 워드프레스나 보안 플러그인이 실행되기 전 단계인 PHP 코어 엔진에서 발생합니다. 웹 방화벽(Cloudflare, AWS WAF 등)을 통해 알려진 공격 패턴을 일시적으로 차단할 수는 있지만, 근본적인 해결을 위해서는 호스팅 업체나 서버 관리자를 통해 서버의 PHP 버전 자체를 업데이트해야 합니다.

session.upload_progress.enabled 설정을 끄면 업데이트하지 않아도 안전한가요?

안전하지 않습니다. 공식 공지는 이 설정이 확인된 세션 경로만 막을 뿐 다른 변형 경로는 막지 못한다고 밝힙니다. 또한 설정은 ini_set()이나 FPM의 .user.ini가 아니라 php.ini·FPM 풀·서버 설정처럼 요청 해석 전에 적용되는 곳에 두고 모든 워커를 재시작해야 합니다. 완전한 해결은 패치 설치뿐입니다.

패치 적용을 완료했다면 추가 점검 없이 바로 운영해도 되나요?

업데이트는 앞으로의 공격을 막을 뿐 이전에 침해됐는지는 알려 주지 않습니다. 업데이트를 마친 뒤에도 사전 침해 여부를 별도로 점검하는 것이 좋습니다. 웹 디렉터리 내에서 최근 비정상적으로 생성되거나 수정된 PHP 파일(웹셸 등)이 있는지 확인하고, 웹 서버 접근 로그와 PHP 오류 로그에서 비정상적인 대용량 POST 요청이나 반복적인 메모리 오류 기록이 있는지 조사하는 것이 좋습니다.

컨테이너나 클라우드 이미지 환경에서는 어떻게 대응해야 하나요?

호스트 서버의 패키지를 업데이트하더라도 컨테이너 내부에 포함된 PHP 런타임은 자동으로 바뀌지 않습니다. 따라서 패치된 버전(8.5.12, 8.4.27, 8.3.36, 8.2.35)이 반영된 베이스 이미지를 사용해 컨테이너 이미지를 다시 빌드하고 재배포해야 합니다.

출처

• PHP: Security Advisory (CVE-2026-109618, CVE-2026-109619)
• PHP: PHP 8.4.27 Release Announcement
• PHP: PHP 8 ChangeLog (8.4.27)
• Red Hat Customer Portal - CVE-2026-109618
• Red Hat Customer Portal - CVE-2026-109619
• PHP 원격 코드 실행 취약점 CVE-2026-109618, CVE-2026-109619 대응 및 PHP 8.4.27 업데이트