PHP 2026년 10월 취약점: 수정 버전과 세션 추가 조치 확인법

오늘의 판단: 수정 버전 확인과 추가 권고를 두 줄로 나눕니다

PHP는 10월 21일 인증 없이 원격 코드 실행으로 이어질 수 있는 CVE-2026-109618·CVE-2026-109619의 수정판을 공개했습니다. 웹 요청을 처리하는 PHP 운영자는 실행 환경을 점검하고 업데이트를 우선해야 합니다. 다만 버전 하나를 확인한 뒤 “10월 문제는 모두 해결”이라고 기록하면 23일의 추가 공지를 놓칩니다.

아래 표는 업스트림 PHP의 21일 두 취약점에 대한 브랜치별 수정 버전입니다. 다른 브랜치의 버전 문자열과 단순 비교하지 말고, 현재 사용하는 브랜치의 행을 고릅니다. 23일에 안내된 CVE-2026-115560의 수정 완료표가 아닙니다.

mod_php를 우선 점검하되, FPM을 안전한 예외로 두지 않습니다

CVE-2026-109618은 메모리 부족 처리 중 불완전한 요청 상태가 정리 단계에서 사용되는 문제입니다. 해당 권고는 mod_php의 원격 코드 실행을 확인했으며, 이 OOM 경로의 FPM 영향은 소스 분석에 근거한다고 구분합니다. 이 문장을 PHP-FPM 전체가 안전하다는 뜻으로 읽어서는 안 됩니다.

별도의 CVE-2026-109619는 해제된 요청 메모리를 가리키는 상태가 같은 워커의 다음 요청까지 남는 문제입니다. 이 권고의 세션 생명주기 경로는 mod_php와 FPM에서 검증됐으며, FPM에서는 정상 초기화 이후의 적합한 애플리케이션 동작과 오류 등 조건이 필요합니다. 두 권고의 확인 범위를 섞지 않는 것이 중요합니다.

운영 목록에는 “PHP 사용” 한 줄 대신 웹서버 연결 방식, FPM 풀이나 워커 그룹, 애플리케이션, 컨테이너 또는 패키지 공급자를 나눠 적습니다. 요청을 받는 실행 경로를 빠짐없이 찾기 위한 목록이지, 알려진 공격의 성공 여부를 시험하는 목록이 아닙니다.

• 같은 서비스에 CLI 작업과 웹 요청용 PHP가 따로 있는가?
• 대표 사이트 외에 관리 화면·업로드·가져오기 기능이 다른 풀을 쓰는가?
• 이전 이미지나 오래된 워커가 아직 요청을 처리하는가?
• 직접 설치와 호스팅·배포판 패키지 중 누가 수정판을 공급하는가?

10월 23일 세션 공지는 세 조건을 함께 확인합니다

추가 공지는 CVE-2026-115560을 다음 정규 릴리스에서 다루겠다고 안내했습니다. 23일 확인 시점에는 이 문제의 수정 릴리스가 공개되지 않았습니다. 공지가 설명하는 특수 조건은 아래 세 가지의 조합입니다.

PHP의 권고는 다음 정규 버그 수정 릴리스까지 session.upload_progress.enabled=0을 설정하는 것입니다. 앞선 권고에 따라 이미 껐다면 그 설정을 유지합니다. 직렬화 핸들러를 런타임에 바꾸지 않는 애플리케이션은 이 추가 경로의 조건에 해당하지 않지만, 그것이 21일 두 취약점의 업데이트를 생략할 근거는 아닙니다.

• 설정의 session.serialize_handler가 php_binary 또는 php_serialize이다.
• 애플리케이션이 session_start() 전에 ini_set()으로 핸들러를 php로 바꾼다.
• session upload progress가 계속 켜져 있다.

session.upload_progress.enabled=0

php -v는 출발점이며 웹 워커의 증거는 따로 남깁니다

터미널에서 아래 읽기 전용 명령으로 현재 선택된 CLI 실행 파일의 버전과 설정 파일 위치를 확인할 수 있습니다. 결과는 그 명령으로 실행한 PHP에 대한 정보입니다. 다른 경로의 FPM이나 Apache 모듈, 다른 컨테이너의 PHP까지 같은 버전이라는 증거는 아닙니다.

PHP는 실행 방식에 따라 설정 파일을 선택하고 읽는 시점도 다릅니다. CLI 설정 파일을 고쳤다는 기록만 남기지 말고 실제 웹 요청을 처리하는 프로세스의 빌드·패키지·설정과 연결해야 합니다. 점검을 위해 외부 공개 phpinfo 페이지를 새로 열기보다 기존의 접근이 제한된 운영 진단 수단을 사용합니다.

php -v
php --ini

배포판 백포트는 숫자 대신 공급자의 수정 증거를 확인합니다

PHP 8.1 이하는 PHP 프로젝트의 정규 보안 지원이 끝났습니다. 일부 배포판·LTS 공급자는 수정 사항을 백포트하므로, 업스트림 버전 숫자만 보고 취약하거나 안전하다고 확정하지 말고 공급자의 두 CVE 수정 공지와 설치한 패키지 리비전을 맞춥니다. 지원 중인 브랜치로의 이전 계획도 별도로 남깁니다.

백포트 여부를 알 수 없다면 기록을 “공급자 확인 대기”로 둡니다. “운영체제 업데이트 완료”라는 한 문장 대신 어떤 패키지가 어느 CVE를 고쳤는지 확인 가능한 자료를 연결하세요. 공급자가 다른 버전 표기를 쓰는 경우에도 이 연결이 있어야 나중에 판단을 재검토할 수 있습니다.

• 공급자 공지에 CVE-2026-109618과 CVE-2026-109619가 모두 포함되는지 확인합니다.
• 패키지 이름·전체 리비전·저장소 또는 이미지 digest와 공지의 대응을 기록합니다.
• CVE-2026-115560은 별도 항목으로 두고 다음 릴리스·공급자 안내를 다시 확인합니다.

변경 순서는 목록, 검증 환경, 워커 전환, 실제 확인입니다

먼저 영향 목록을 만든 뒤 공급자가 제공한 수정판과 애플리케이션·확장 모듈의 호환성을 검증 환경에서 확인합니다. 서비스마다 패키지 관리와 배포 방식이 다르므로 이 글은 공통 업데이트나 재시작 명령을 제공하지 않습니다. 담당자가 승인한 절차와 복구 계획에 맞춰 진행해야 합니다.

패키지나 이미지가 준비된 상태와 요청을 처리하는 워커의 전환 완료는 다른 단계입니다. 모든 대상 풀과 복제본에서 새 빌드 및 필요한 시작 설정의 적용을 확인하고, 확인하지 않은 대상을 남겨둡니다. 정상적인 작은 샘플로 로그인·일반 업로드·해당 업무 기능을 점검하되 악성 입력이나 대량 요청으로 재현하지 않습니다.

새 빌드의 오류 때문에 이전 버전으로 돌아가야 한다면 가용성 복구와 보안 위험을 함께 기록합니다. 취약 버전으로 복구한 상태를 보안 조치 완료로 남기지 말고, 남은 노출과 다음 변경 담당자를 명확히 합니다.

• 변경 전: 대상 실행 경로, 공급자 수정 근거, 현재 패키지·설정과 복구 자료를 확보합니다.
• 검증 중: 필요한 확장 모듈과 일반 업무 기능의 결과를 기록합니다.
• 전환 후: 실제 웹 워커의 빌드·설정과 오래된 워커 잔존 여부를 확인합니다.
• 마무리: 두 CVE 패치 상태와 추가 세션 조치 상태를 각각 기록합니다.

완화 설정과 패치를 같은 완료 항목에 넣지 않습니다

OOM 권고에는 업데이트할 수 없는 환경의 조건부 완화로 memory_limit=-1이 나오지만, 원문도 완전한 해결이 아니라고 구분합니다. 이 글은 이를 모든 서버에 복사할 공통 처방으로 제시하지 않습니다. 메모리·가용성 경계와 실제 설정 적용을 검토하지 않고 값 하나로 해결했다고 판단해서는 안 됩니다.

세션 경로의 session.upload_progress.enabled=0도 요청 파싱 전에 적용되는 설정에서 다뤄야 하며, 애플리케이션의 ini_set()이나 FPM .user.ini에만 의존하면 안 됩니다. 설정 변경 후에는 담당 절차에 따라 대상 워커 전체에 반영됐는지 확인합니다. 업로드 진행률을 쓰는 서비스라면 일반 업로드뿐 아니라 진행률 표시의 변화도 검수 대상으로 둡니다.

오류를 화면에서 숨기거나 로그가 조용하다는 이유로 안전 판정을 내리지 않습니다. 관련 권고는 일부 문제가 로그에 남지 않을 수 있음을 설명합니다. 설정·실행 빌드·업무 확인 결과를 함께 보관하고, 임시 완화는 패치와 구분해 다음 확인일까지 관리합니다.

가상 실패 사례: 터미널은 새 버전인데 서비스는 이전 워커입니다

다음은 실제 침해 사례가 아닌 점검을 위한 가상 상황입니다. 운영자가 호스트에서 PHP 8.4.27을 확인하고 작업을 닫았지만 웹서버는 다른 컨테이너의 PHP 8.4.26 FPM에 요청을 전달한다고 가정합니다. CLI 결과가 틀린 것이 아니라, 그 결과로 증명하려 한 대상이 달랐던 것입니다.

이때 기록은 “CLI 확인 완료, 웹 실행 경로 미확인”으로 되돌리고 연결된 풀·이미지·실행 워커를 다시 식별합니다. 수정 빌드 전환을 확인한 뒤에도 세션 추가 조치를 별도 행으로 남깁니다. 실제로 확인한 범위만 완료 처리하면 누락된 복제본이나 설정을 찾기가 쉬워집니다.

완료 보고에는 판단과 남은 조건을 함께 씁니다

결과는 “최신 버전” 대신 대상과 확인 시점을 포함해 남깁니다. 아래 양식은 독자가 자신의 환경에서 채우는 기록 예시이며, HLB Studio가 실제 운영 서버에서 수행한 결과가 아닙니다. 확인하지 못한 칸을 완료로 바꾸지 않습니다.

10월 21일 두 CVE의 수정 빌드 적용과 23일 세션 권고를 각각 관리하고, 추가 수정판이 공개되면 공식 공지와 공급자 정보를 다시 대조합니다. 적용 증거는 점검 시점의 상태를 설명하며 과거 침해가 없었다거나 이후 모든 취약점이 해결됐음을 증명하지 않습니다.

확인 시각 / 담당자: <입력>
대상 서비스 / 풀 / 복제본: <입력>
실제 웹 SAPI / 버전 / 빌드: <입력>
공급자 수정 근거 / 패키지 리비전 또는 이미지 digest: <입력>
CVE-2026-109618·109619: <패치 확인 / 공급자 확인 대기 / 미조치>
session.upload_progress.enabled 실제 적용값: <확인값 또는 미확인>
CVE-2026-115560 조건 점검 / 임시 조치: <입력>
정상 업무 확인 / 남은 영향 / 다음 확인일: <입력>