nginx 서버도 PHP 보안 패치가 필요할까? PHP-FPM 수정 버전
보안 공지가 가장 위험하다고 짚은 건 Apache의 mod_php인데, 우리 서버는 nginx와 PHP-FPM 조합이다. 이번에 몇 버전까지 올려야 하고, 패치 말고 더 볼 설정은 없을까?

- nginx 뒤에서 돌아가는 PHP-FPM도 이번 PHP 보안 업데이트 대상이다.
- 10월 21일 두 취약점의 최초 수정 버전은 8.2.35·8.3.36·8.4.27·8.5.12다.
- 23일 후속 공지는 드문 세션 설정 조합을 다룬다. 패치와 추가 설정 점검을 함께 마쳐야 한다.
nginx를 쓴다는 이유로 업데이트를 건너뛸 수 없다
PHP-FPM도 패치해야 한다. PHP 프로젝트는 10월 21일 보안 공지에서 웹 요청을 처리하는 PHP 설치를 대상으로 지목했다. 여기에 Apache의 mod_php뿐 아니라 PHP-FPM, php-cgi, FrankenPHP, LiteSpeed도 포함된다.
위험도가 가장 높은 사례로 mod_php가 강조된 것은 애플리케이션 코드가 실행되기 전에도 공격이 가능한 조건이 확인됐기 때문이다. 이를 “Apache를 쓰지 않으면 괜찮다”로 읽으면 안 된다. 앞단에서 HTTP 요청을 받는 프로그램과 뒤에서 PHP 코드를 실행하는 프로그램은 서로 다른 점검 대상이다.
메모리 부족 처리 취약점의 권고문은 FPM이 요청 시작 실패 시 자식 프로세스를 종료하더라도, 정상 시작 뒤 애플리케이션 실행 중에는 취약한 경로가 남을 수 있다고 설명한다. 이전 요청의 내부 상태가 남는 취약점에도 애플리케이션 동작에 의존하는 FPM 경로가 기술돼 있다. 환경마다 공격 조건이 다르다는 사실은 업데이트 면제 조건이 아니다.
현재 쓰는 PHP 계열의 수정 버전부터 맞춘다
PHP 프로젝트와 AWS 보안 권고가 제시한 최초 수정 버전은 다음과 같다. 표의 대상은 10월 21일 공개된 CVE-2026-109618과 CVE-2026-109619다.
| 사용 계열 | 두 취약점의 최초 수정 버전 |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
배포판이나 장기 지원 업체가 수정 코드를 이전 버전에 반영한 백포트 패키지를 제공한다면 그 업체의 보안 공지로 판단한다. 버전 앞자리만 보고 미수정이라고 단정해서는 안 된다.
PHP 8.1 이하는 프로젝트의 정규 업데이트 대상이 아니다. 다만 이번에는 7.4·8.0·8.1에 최소 소스 백포트가 별도로 제공됐다. 이를 정규 지원 재개로 받아들이지 말고, 공급자의 수정 패키지 여부와 지원 버전으로의 이전 계획을 함께 확인해야 한다.
업데이트한 PHP가 실제 웹 요청을 처리하는지 확인한다
운영 점검은 사이트가 연결된 PHP 실행 환경을 찾는 데서 시작한다. 호스트의 명령행 PHP, FPM 서비스, 컨테이너 내부 PHP가 같은 설치본이라는 보장은 없다. 명령행에서 php -v를 실행한 결과만으로 웹 서비스까지 적용됐다고 판단하기 어려운 이유다.
- 사이트가 사용하는 FPM 서비스·컨테이너·호스팅 런타임을 특정한다.
- 해당 실행 환경의 패키지나 이미지를 수정 버전 또는 공급자의 수정 빌드로 교체한다.
- 배포 절차에 따라 PHP 워커를 다시 시작하거나 교체한 뒤, 웹 서비스가 새 실행 환경을 쓰는지 확인한다.
직접 서버를 관리하지 않는다면 호스팅 업체에 두 CVE의 패치 여부와 실제 적용 버전을 요청할 수 있다. 이때 “서버를 업데이트했다”는 답보다 해당 사이트에 연결된 PHP 계열과 수정 패키지가 유용한 확인 정보다.
10월 23일 공지는 특정 세션 설정을 추가로 점검하게 한다
23일 후속 공지는 CVE-2026-115560을 정기 릴리스에서 처리할 예정이라고 밝혔다. 설정에서 세션 직렬화 방식을 php_binary 또는 php_serialize로 정한 뒤, 실행 중 ini_set()으로 php로 바꾸고 session_start()를 호출하며, 세션 업로드 진행 추적도 켜진 드문 조합이다.
PHP 프로젝트는 다음 정기 버그 수정 릴리스까지 아래 설정을 권고했다. 이미 21일 완화 조치로 적용했다면 유지하면 된다. 실행 중 직렬화 방식을 바꾸지 않는 애플리케이션은 해당 기능을 유지할 수 있다는 예외도 공지에 명시돼 있다.
session.upload_progress.enabled = 0 설정은 서버가 PHP를 시작할 때 읽는 구성에 적용하고 모든 PHP 워커를 재시작한다. Red Hat의 권고도 애플리케이션의 ini_set()이나 FPM의 .user.ini로 대신할 수 없다고 설명한다. 이 기능은 세션을 통한 파일 업로드 진행 상태 추적이다. 파일 업로드 자체를 모두 금지하는 설정은 아니지만, 이 방식으로 진행률을 표시하던 화면에는 영향이 있다.
아직 21일 패치를 적용하지 않았다면 업데이트가 먼저다. 세션 설정 하나로 두 취약점의 모든 공격 경로를 막았다고 볼 수 없다. 패치를 마친 뒤에는 애플리케이션의 세션 설정을 대조해야 이번 주의 두 공지를 빠짐없이 반영할 수 있다.