PHP 긴급 패치 이후에도 확인할 것: 10/21 업데이트와 10/23 추가 공지

긴급 패치를 설치했는데 며칠 뒤 같은 제품의 추가 공지가 나왔다면, 어디까지 확인해야 할까요? 이번 PHP 공지에서는 업데이트가 해결한 문제와 추가 설정 점검이 필요한 조건을 먼저 구분하는 것이 좋습니다. 버전만 적어 두면 실제 서비스에 반영됐는지 놓칠 수 있죠.

10/21 긴급 업데이트가 해결한 취약점은 무엇인가요?

메모리 부족 처리와 요청 간 상태 관리의 결함으로, 인증 없는 원격 코드 실행이 가능한 문제입니다.

PHP가 공개한 두 보안 권고는 서로 다른 원인을 다루죠. CVE-2026-109618 공식 권고는 메모리 부족 오류가 처리 흐름을 중단하면서, 완전히 초기화되지 않은 요청 데이터를 정리 과정에서 사용할 수 있는 문제를 설명합니다. 메모리가 부족해 요청 하나가 실패하는 상황으로만 이해하면 범위가 좁아지죠.

CVE-2026-109619 공식 권고는 해제된 요청 메모리를 가리키는 상태가 워커에 남아, 뒤이은 요청에서 사용될 수 있는 문제를 다룹니다. 두 권고 모두 확인해야 하는 이유예요.

표는 업스트림 수정 버전이며 배포판 패키지의 판정표는 아닙니다. 공식 권고는 구성 변경만으로 모든 경로를 해결할 수 있다고 설명하지 않죠. 임시 완화와 보안 업데이트를 같은 완료 상태로 기록하지 마세요.

웹 요청을 처리하는 PHP 환경은 어디에서 확인하나요?

명령행 출력만 보지 말고, 실제 웹 요청을 처리하는 PHP 실행 방식과 적용 설정을 함께 확인합니다.

PHP 공식 보안 공지는 PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed 등 웹 요청을 처리하는 설치를 위험 확인 대상으로 안내합니다. 특정 웹서버를 쓰지 않는다는 이유만으로 점검을 끝낼 수는 없죠.

PHP의 명령행 사용 설명은 CLI와 다른 실행 인터페이스를 구분합니다. 설정 파일 설명도 실행 방식에 따른 설정 탐색과 읽기 시점을 안내합니다. 따라서 터미널에서 확인한 실행 파일과 설정이 웹 서비스의 것인지부터 대조해야 하죠.

점검 단위는 서버 이름 하나보다 서비스가 실제 연결되는 실행 환경으로 잡는 편이 좋아요. 호스트와 컨테이너, FPM 풀 등이 나뉘어 있다면 각 대상의 패키지·실행 파일·설정 경로를 따로 적어 보세요. 이는 누락을 줄이기 위한 운영 기록 제안이에요.

버전 확인용 진단 화면을 외부에 공개하는 방식은 피하세요. 기존 관리 경로에서 대상 환경을 확인하고, 웹 요청을 받는 워커까지 적용됐는지 기록하는 편이 좋죠.

업스트림 버전과 배포판 패키지는 왜 따로 확인하나요?

배포판은 보안 수정을 백포트할 수 있으므로, 버전 문자열만으로 패치 적용 여부를 확정할 수 없습니다.

10/21 PHP 공식 발표는 Linux 배포판과 장기 지원 공급자가 패치를 사전에 전달받았다고 안내합니다. 공급자의 업데이트 패키지를 확인하라는 의미죠. 업스트림 번호와 다르다는 사실만으로 수정 여부를 결론 내리지 마세요.

공급자의 보안 공지에서 두 CVE의 수정 패키지를 찾고, 설치한 패키지의 릴리스 정보와 대조하는 순서를 제안합니다. 공지 URL과 패키지 식별자, 확인 시점을 함께 남겨 두면 판단 근거를 다시 확인할 수 있습니다. 서로 다른 배포판의 패키지 이름을 같은 기준으로 비교하지 않는 것이 좋죠.

PHP 8.1과 이전 계열은 PHP 프로젝트의 정규 업데이트 대상이 아닙니다. 이번 긴급 공지의 예외적인 소스 백포트를 정규 지원 재개로 읽으면 안 됩니다. 공급자 지원 범위나 지원되는 계열로의 전환 여부를 별도로 확인해야 해요.

다른 제품의 취약점 대응 절차를 그대로 가져오는 것도 조심해야 합니다. 웹서버 측 사례는 NGINX 치명 취약점 CVE-2026-42533: 영향 범위 확인과 업그레이드 가이드에서 다룹니다. 이번 글에서는 PHP 패키지와 실행 환경의 확인에 집중해요.

10/23 추가 공지는 어떤 환경에 해당하나요?

세션 직렬화 방식을 실행 중 바꾸면서 업로드 진행 상태 기능을 켜 둔 특정 조합을 다룹니다.

10/23 PHP 추가 공지는 다음 조건을 함께 설명합니다. 설정 파일의 session.serialize_handler가 php_binary 또는 php_serialize이고, 애플리케이션이 session_start() 전에 ini_set()으로 이를 php로 변경하며, 세션 업로드 진행 상태 기능도 활성화된 경우입니다. 업로드 기능이 있다는 사실만으로 이 조합이 성립하는 것은 아니죠.

PHP는 다음 정규 버그 수정 릴리스까지 session.upload_progress.enabled=0을 제안합니다. 이미 해당 완화를 적용했다면 유지하라는 안내이며, 직렬화 방식을 런타임에 바꾸지 않는 애플리케이션은 기능을 켜 둘 수 있다고 구분합니다. 우리 코드와 설정이 어느 쪽인지 확인해야 해요.

설정 이름이 비슷해도 파일 업로드 전체와 세션의 업로드 진행 상태 기능을 같은 것으로 설명하지 않아야 합니다. 해당 완화를 적용할 때는 요청 파싱 전에 반영되는 php.ini·FPM 풀·서버 설정을 사용하고, 모든 PHP 워커를 재시작해야 합니다. 공식 보안 공지는 ini_set()이나 FPM의 .user.ini에 의존하지 말라고 안내하죠.

작성 기준일인 10/26에는 추가 문제의 전체 권고가 다음 릴리스와 함께 공개될 예정으로 안내되어 있습니다. 예정된 수정이 이미 배포됐다고 읽지 않도록 후속 공지도 확인하세요.

적용 완료를 판단하기 전 어떤 기록을 남기나요?

공식 수정 근거와 설치 패키지, 실제 웹 실행 환경, 추가 공지 검토 결과를 나누어 기록합니다.

아래 표는 운영팀이 확인 결과를 정리하는 예시예요. PHP 프로젝트가 정한 인증 절차나 침해 여부 판정 기준은 아니죠.

패키지 설치 성공과 실행 중인 서비스의 적용 확인을 구분해 두세요. 여러 실행 환경을 운영한다면 확인한 대상과 아직 남은 대상을 나누는 것이 좋죠. 한 환경의 결과를 전체 서비스의 완료로 확대하지 않아야 합니다.

업데이트 뒤에는 로그인·세션·업로드처럼 서비스가 사용하는 기능을 점검하는 순서를 제안합니다. 기능 시험이 통과했다는 사실은 보안 패치 근거나 침해 조사를 대신하지는 않죠. 패치 적용 상태와 기능 점검 결과는 서로 다른 기록이에요.

이것만 기억하세요

자주 묻는 질문 (FAQ)