PHP 8.5.12 긴급 보안 패치, mod_php와 PHP-FPM 중 어디가 더 위험한가

PHP-FPM·php-cgi·FrankenPHP·LiteSpeed는 안전한가?

안전하지 않습니다. 공지는 웹 요청을 처리하는 모든 PHP 설치를 위험 범위로 명시하며 PHP-FPM, php-cgi, FrankenPHP, LiteSpeed를 모두 포함했습니다. 다만 위험의 성격과 완화 수단은 환경마다 다릅니다.

PHP-FPM은 워커 프로세스가 요청을 나눠 처리하는 구조라 두 번째 취약점(잔여 상태 참조)과의 연관성이 상대적으로 부각됩니다. 반면 php-cgi나 FrankenPHP, LiteSpeed는 프로세스 모델과 설정 적용 지점이 달라, 같은 완화 지시가 동일하게 먹히지 않을 수 있습니다. 그래서 완화 설정을 적용할 때는 반드시 해당 SAPI 문서와 실제 동작을 함께 확인해야 합니다.

정리하면 "mod_php가 아니니 괜찮다"는 판단은 성립하지 않습니다. 우선순위의 차이일 뿐, 패치 대상에서는 모두 동일합니다.

패치 버전은 무엇이고 8.1 이하는 어떻게 되나?

업데이트 목표 버전은 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35입니다. 각 마이너 브랜치의 최신 패치 버전으로 올리면 두 취약점이 모두 해결됩니다. 소스와 Windows용 소스·바이너리는 PHP 다운로드 페이지에서 받을 수 있습니다.

문제는 지원 종료 버전입니다. PHP 8.1과 그 이하 버전은 더 이상 PHP 프로젝트의 정기 업데이트 대상이 아닙니다. 다만 일부 리눅스 배포판과 LTS 벤더는 자체적으로 수정 사항을 백포트해 제공하므로, 해당 버전을 계속 쓴다면 벤더에 패치 제공 여부를 먼저 문의해야 합니다.

예외적으로 PHP 보안팀은 PHP 7.4, 8.0, 8.1에 대해 최소한의 소스 백포트를 제공했습니다. LTS 벤더를 이용할 수 없거나 직접 소스를 빌드하는 조직을 위한 조치입니다. 이는 정식 지원 재개가 아니므로 중장기적으로는 지원 버전으로의 이전 계획을 세우는 편이 좋습니다.

배포판 패치와 소스 빌드 중 무엇을 먼저 봐야 하나?

리눅스 배포판이나 LTS 벤더를 쓰고 있다면 배포판 패키지를 먼저 확인하는 것이 순서입니다. 공지에 따르면 이들 벤더는 사전에 패치를 전달받았습니다.

반대로 rpms.remirepo.net처럼 자원봉사로 운영되는 저장소에 의존하는 경우는 주의가 필요합니다. PHP 프로젝트는 이 저장소를 쓰는 사용자에게 배포판 패키지로 전환하거나 소스에서 직접 빌드할 것을 권고했습니다. 공지 시점 기준으로 해당 저장소에는 당일 업데이트가 제공되지 않는다고 밝혔기 때문입니다.

운영 환경에서 저장소를 바꾸는 일은 버전·확장 모듈 의존성까지 건드리는 작업입니다. 급하게 전환하기 어렵다면 최소한 현재 사용 중인 패키지가 어느 경로로 공급되는지 목록화해 두고, 대안 경로를 미리 검증해 두는 것이 현실적입니다.

즉시 업데이트가 어렵다면 무엇을 할 수 있나?

완화 설정은 특정 공격 경로를 줄이는 임시 조치이며, 완전한 해결책은 업데이트뿐입니다. 이 전제를 먼저 분명히 해야 합니다. 그 위에서 실행 가능한 조치를 정리하면 다음과 같습니다.

취약점	완화 조치	적용 위치
CVE-2026-109618 (OOM 경로)	memory_limit=-1 설정, 애플리케이션이 덮어쓰지 못하도록 php_admin_value 등으로 고정	FPM 풀, Apache 설정
CVE-2026-109618 (OOM 경로)	post_max_size를 낮게 유지 (업로드 불필요 시 8M, 필요 시 32M), upload_max_filesize는 그보다 작게	php.ini, 서버 설정
CVE-2026-109618 (OOM 경로)	프록시·웹서버 단에서 요청 크기, 입력 필드 수, 멀티파트 파트 수, 헤더 수, 중첩 깊이 제한	리버스 프록시, 웹서버
CVE-2026-109619 (잔여 상태)	session.upload_progress.enabled=0 설정 후 전 워커 재시작	php.ini, FPM 풀, 서버 설정
CVE-2026-109619 (잔여 상태)	PHP 8.5에서 fatal_error_backtraces=0 설정 후 전 워커 재시작	php.ini, FPM 풀

memory_limit을 무제한으로 두는 조치는 직관과 반대라 오해하기 쉽습니다. 목적은 메모리를 아끼는 것이 아니라, 공격자가 유발할 수 있는 "한도 도달 실패" 자체를 없애는 데 있습니다. 다만 이 경우에도 근본적인 할당 실패는 다른 경로로 발생할 수 있으므로 완전한 차단은 아닙니다.

컨테이너나 cgroup 한도를 가용성 경계로 쓰는 방식도 권고됩니다. 이때 RLIMIT_AS나 RLIMIT_DATA로 대체해서는 안 됩니다. 이 제한들은 오히려 취약한 할당 실패를 유발할 수 있기 때문입니다.

session.upload_progress 설정은 왜 ini_set으로 하면 안 되나?

이 설정은 요청 파싱이 시작되기 전에 적용되어야 하므로, 런타임 함수인 ini_set()이나 FPM의 .user.ini로는 효과가 없습니다. php.ini, FPM 풀 설정, 서버 설정처럼 요청 처리 이전 단계에서 읽히는 위치에 넣어야 합니다.

설정을 바꾼 뒤에는 모든 워커를 재시작해야 합니다. 이미 메모리에 올라간 상태가 남아 있으면 재시작 전까지는 이전 동작이 유지되기 때문입니다. 이 조치는 확인된 세션 관련 경로를 막을 뿐, 다른 변형까지 차단하지는 않습니다.

fatal_error_backtraces=0 역시 PHP 8.5에서 확인된 경로만 막는 제한적 조치입니다. 완화 항목을 적용할 때는 "무엇을 막고 무엇을 막지 못하는지"를 함께 기록해 두어야 나중에 오해가 생기지 않습니다.

요청 단위 진단 설정은 어떤 문제를 만드나?

초기화 이전에 진단 메시지를 출력하는 요청 단위 설정은 제거하는 것이 좋습니다. 폐기 예정이거나 잘못된 설정이 매 요청마다 경고를 내보내는 구조라면, 그 출력 자체가 취약한 경로를 자극할 수 있기 때문입니다.

error_reporting을 낮추거나 display_errors를 끄고 @ 연산자로 감싸는 방식은 근본 대응이 아닙니다. 진단이 화면에 보이지 않게 될 뿐, 설정이 유효하지 않다는 사실과 그로 인한 실행 경로는 그대로 남습니다.

같은 맥락에서 공격자가 도달할 수 있는 치명적 오류와 실행 시간 초과도 점검이 필요합니다. 콜백 처리, 업로드나 가져오기 처리, 정리(cleanup) 단계에서 발생하는 실패가 여기에 해당합니다. 이 지점들은 정상 트래픽에서는 잘 드러나지 않으므로 오류 로그를 평소보다 넓게 훑어야 합니다.

업데이트 우선순위는 어떻게 정하면 되나?

판단 기준은 세 가지입니다. 첫째, mod_php로 서비스 중인가. 둘째, 인증 없이 접근 가능한 엔드포인트가 인터넷에 열려 있는가. 셋째, 해당 서비스가 지원 종료 버전에 머물러 있는가.

세 항목에 모두 해당하는 서버가 있다면 가장 먼저 처리합니다. mod_php가 아니더라도 외부 노출 서비스라면 같은 날 처리를 목표로 잡는 편이 안전합니다. 내부 전용이고 여러 겹의 프록시 제한이 걸려 있는 시스템은 상대적으로 순서를 뒤로 미룰 수 있지만, 미루는 기간 동안 완화 설정을 적용하고 그 사실을 기록해 둡니다.

지원 종료 버전을 쓰는 서버는 별도 트랙으로 분리합니다. 벤더 패치 적용 가능 여부를 확인하는 동시에 상위 버전 이전 일정을 세워야 합니다. 이번 건이 해결돼도 지원이 끝난 브랜치는 다음 취약점에서 같은 문제를 반복합니다.

그래서 지금 무엇을 확인해야 하나

결론은 단순합니다. 서비스 중인 PHP의 SAPI와 버전을 먼저 확정하고, 배포판 또는 LTS 벤더 패키지로 8.5.12·8.4.27·8.3.36·8.2.35에 해당하는 수정이 제공되는지 확인한 뒤, mod_php와 외부 노출 서비스부터 적용합니다.

그와 동시에 완화 설정을 임시로 걸어 두고, 워커 재시작까지 마쳤는지 확인합니다. 완화는 업데이트를 대체하지 않는다는 점을 팀 내에 공유해 두어야 합니다.

마지막으로 인벤토리를 갱신합니다. 어떤 서버가 어떤 SAPI를 쓰고, 어느 저장소에서 패키지를 받으며, 지원 종료 버전이 어디에 남아 있는지 목록으로 유지하면 다음 공지 때 판단 시간이 크게 줄어듭니다.