PHP 보안 리포트 · 운영자를 위한 대응 가이드
2026년 10월 PHP 긴급 보안 업데이트,
내 웹사이트는 무엇을 확인해야 할까요?
웹사이트가 정상적으로 열리고 로그인도 잘된다고 해서, 서버의 PHP까지 안전한 것은 아닙니다. 이번 보안 이슈는 웹사이트를 실행하는 PHP 자체의 문제입니다. 버전 확인에서 실제 패치 검증까지, 사이트 운영자가 확인할 내용을 정리했습니다.
01. 로그인 없이도 영향을 줄 수 있는 PHP 실행 환경의 문제
원격 코드 실행(RCE)은 외부의 요청을 계기로 서버에서 의도하지 않은 코드가 실행될 수 있다는 뜻입니다. 이번 공지는 PHP-FPM, Apache의 mod_php, php-cgi, FrankenPHP, LiteSpeed 등 웹 요청을 처리하는 PHP 환경을 점검 대상으로 안내합니다. 특히 mod_php에서는 애플리케이션 코드가 실행되기 전 공격이 가능함이 확인되었다고 설명합니다. 따라서 관리자 비밀번호 변경이나 CMS 업데이트만으로 PHP 실행 환경의 패치를 대신할 수는 없습니다. 영향 환경에 대한 공식 안내 ↗
CVE-2026-109618: 메모리 부족을 처리하는 과정의 오류
PHP가 메모리 부족으로 요청 처리를 중단할 때, 아직 초기화가 끝나지 않은 내부 데이터가 남을 수 있습니다. 이후 요청을 정리하는 과정에서 이 데이터를 정상 상태로 취급하는 것이 문제입니다. 공식 기술 보고서는 mod_php에서 원격 코드 실행을 검증했으며, PHP-FPM도 영향을 받을 수 있지만 해당 보고서에서 완전한 FPM 공격은 시연되지 않았다고 구분합니다. 실행 방식마다 공격 조건이 다르다는 뜻이지, FPM을 사용하면 패치가 불필요하다는 뜻은 아닙니다. 메모리 처리 취약점 기술 보고서 ↗
CVE-2026-109619: 이전 요청의 상태가 다음 요청에 남는 오류
요청에 속한 메모리가 해제된 뒤에도 내부 상태가 남아, 같은 작업 프로세스가 처리하는 다음 요청에서 다시 사용될 수 있는 문제입니다. 사이트 운영에서는 PHP 프로세스가 여러 요청을 이어서 처리하므로, 파일을 교체하는 작업과 실행 중인 프로세스에 수정 내용을 반영하는 작업을 함께 확인해야 합니다. 상태 관리 취약점 기술 보고서 ↗
02. “PHP 8 사용 중”만으로는 부족합니다
버전은 마지막 숫자까지 확인하세요. 예를 들어 PHP 8.4.26과 8.4.27은 같은 8.4 계열이지만, 이번 취약점 수정 여부를 가르는 릴리스입니다. 아래 표는 이번 이슈의 최초 수정 버전을 정리한 것으로, 앞으로도 계속 최신 버전이라는 의미는 아닙니다.
| 사용 계열 | 최초 수정 버전 | 현재 지원 단계 | 보안 지원 종료 |
|---|---|---|---|
| PHP 8.2 | 8.2.35 | 보안 수정만 제공 | 2026. 12. 31. |
| PHP 8.3 | 8.3.36 | 보안 수정만 제공 | 2027. 12. 31. |
| PHP 8.4 | 8.4.27 | 일반 지원 | 2028. 12. 31. |
| PHP 8.5 | 8.5.12 | 일반 지원 | 2029. 12. 31. |
| PHP 8.1 이하 | 공급업체 확인 필요 | PHP 공식 지원 종료 | 지원 계열로 전환 검토 |
출처: PHP 보안 릴리스 공지 · PHP 공식 지원 일정. 지원 단계는 2026년 10월 23일 기준입니다.
특히 PHP 8.2는 이번 패치를 적용하더라도 2026년 말 공식 보안 지원이 끝납니다. 당장의 패치 적용과 다음 계열로의 이전 계획을 함께 잡는 것이 좋습니다. 계열을 바꾸기 전에는 CMS, 테마, 플러그인과 확장 모듈의 호환성을 확인하세요.
버전 숫자가 낮아도 보안 패치가 적용된 경우가 있습니다
운영체제 배포판이나 장기 지원 공급업체는 기존 버전 번호를 유지하면서 수정 사항을 반영하는 백포트를 제공할 수 있습니다. 이때는 공개된 PHP 숫자만 비교하지 말고, 설치 패키지의 전체 버전과 공급업체 보안 공지에서 두 CVE의 수정 여부를 확인해야 합니다. 반대로 “장기 지원 상품”이라는 안내만으로 패치가 적용되었다고 판단해서도 안 됩니다. 공급업체 패치에 관한 공식 안내 ↗
03. 온라인 진단 결과를 실제 조치로 연결하는 방법
이 페이지의 진단기는 외부에 공개된 응답을 확인하는 첫 점검 도구입니다. 서버에 접속해 설치 패키지를 조사하거나, 두 취약점의 공격을 실행하는 검사는 하지 않습니다. 다음 기준으로 결과를 읽어주세요.
- 업데이트 권장
- 공개 버전이 동일 계열의 공식 최신 릴리스보다 낮다는 뜻입니다. 호스팅 관리 화면에서 실제 버전을 확인하고, 백포트 여부를 검토한 뒤 패치 일정을 잡으세요. 이 결과만으로 특정 CVE에 취약하다고 확정하는 것은 아닙니다.
- 업그레이드 필요
- PHP 공식 지원이 끝난 계열입니다. 공급업체의 별도 보안 지원 유무를 확인하고, 지원 중인 계열로 옮길 계획을 세우세요. 오래된 확장 모듈 때문에 이전이 어렵다면 해당 의존성을 먼저 목록으로 정리하는 것이 출발점입니다.
- 확인 불가 또는 사용 추정
- 서버가 버전을 숨기거나 CDN이 헤더를 제거할 수 있습니다. PHPSESSID 쿠키만 발견한 경우도 정확한 버전은 알 수 없습니다. 안전하다는 결과로 받아들이지 말고 운영 담당자에게 서버 측 확인을 요청하세요.
- 최신 패치 버전
- 공개된 숫자가 조회한 공식 최신 릴리스와 일치한다는 뜻입니다. 여러 서버 중 일부만 업데이트되었거나 응답 헤더가 실제 실행 환경과 다를 수 있으므로, 모든 인스턴스의 적용 여부를 확인해야 합니다.
04. 내 운영 환경에 맞게 대응하세요
호스팅을 이용하는 사이트 운영자라면
관리 화면에서 사이트별 PHP 버전 설정을 확인하세요. 같은 호스팅 계정 안에서도 도메인마다 다른 버전을 사용할 수 있습니다. 변경 전에는 데이터베이스와 업로드 파일을 백업하고, 가능하면 복제한 사이트에서 로그인·글쓰기·파일 업로드·결제처럼 중요한 기능을 먼저 점검하세요.
직접 패치할 권한이 없다면 아래 내용을 호스팅 업체에 전달하면 됩니다. “서버가 안전한가요?”라는 질문보다 적용 패키지와 완료 시점을 확인하는 질문이 구체적인 답변을 받는 데 도움이 됩니다.
제 도메인의 웹 요청을 처리하는 PHP에 CVE-2026-109618과 CVE-2026-109619 수정이 적용되어 있나요? 현재 실행 버전과 패키지 전체 버전, 백포트라면 근거가 되는 보안 공지, 적용 완료 시각과 PHP 작업 프로세스 교체 여부를 알려주세요. 미적용 상태라면 예정 시각과 그동안 가능한 접근 제한 방법도 안내 부탁드립니다.
서버나 컨테이너를 직접 운영한다면
먼저 웹 서버가 어떤 PHP-FPM 풀, Apache 모듈 또는 컨테이너로 요청을 전달하는지 확인하세요. 터미널의 php -v는 명령줄 PHP를 보여주므로 웹 요청에 사용되는 버전과 다를 수 있습니다. 여러 버전이 함께 설치되어 있으면 실제 연결된 실행 파일과 서비스 설정을 기준으로 점검해야 합니다.
사용 중인 배포판의 보안 저장소 또는 공식 배포 경로에서 패키지를 업데이트하고, 운영 절차에 따라 PHP 작업 프로세스를 교체하세요. 컨테이너 환경에서는 새 이미지 생성만으로 완료되지 않습니다. 실행 중인 컨테이너가 새 이미지로 교체되었는지, 부하 분산 뒤의 모든 서버에 반영되었는지까지 확인해야 합니다.
즉시 업데이트하기 어렵다면
PHP 공식 공지는 설정 변경으로 특정 공격 경로의 노출을 줄일 수 있지만, 완전한 해결은 업데이트라고 명시합니다. 일반 운영자가 인터넷의 설정 예시를 그대로 복사하기보다는, 담당자와 함께 외부 접근 제한이나 필요한 기능만 일시 제공하는 방안을 검토하고 패치 완료 시점을 정하는 것이 좋습니다. 공식 임시 완화 조치와 한계 ↗
특히 memory_limit=-1 같은 변경은 PHP의 메모리 제한을 없애므로 자원 관리까지 함께 검토해야 합니다. 공식 기술 보고서 역시 이 설정만으로 모든 공격 경로가 차단되는 것은 아니라고 설명합니다. WAF 사용 여부나 버전 헤더 숨김만으로 패치 완료를 대신 판단하지 마세요. 완화 조치의 기술적 제약 ↗
05. 업데이트는 설치보다 확인까지가 중요합니다
다음은 운영자가 패치 후 남겨두면 좋은 확인 기록입니다. 나중에 같은 문제가 생겼을 때, 무엇을 언제 바꿨는지 추적하는 데도 도움이 됩니다.
- 실행 환경 확인. 도메인별 웹 PHP 버전, 설치 패키지 또는 이미지 식별자, 적용 시각을 기록합니다. 백포트라면 공급업체 공지 링크도 함께 남깁니다.
- 모든 서버 반영 확인. 이전 PHP 작업 프로세스가 남아 있지 않은지, 여러 인스턴스가 같은 패치 상태인지 점검합니다. 예약 작업이나 별도 관리 사이트도 목록에서 빠뜨리지 않습니다.
- 핵심 기능 확인. 로그인, 세션 유지, 검색, 업로드, 주문·결제 등 실제 사용 흐름을 점검합니다. 오류율과 PHP 로그를 확인해 호환성 문제를 조기에 찾습니다.
- 외부 응답 재확인. 진단기를 다시 실행해 공개 버전을 비교합니다. 헤더가 계속 숨겨져 있다면 서버 측 확인 기록으로 검증하고, 진단을 위해 버전 정보를 새로 공개할 필요는 없습니다.
- 다음 점검일 예약. 이번 패치만으로 유지보수가 끝나지는 않습니다. 보안 공지 수신 담당자와 다음 정기 업데이트 일정을 정해두세요.
패치 적용은 이미 발생한 침해를 되돌리는 작업과도 구분해야 합니다. 낯선 관리자 계정, 변경된 파일, 비정상적인 외부 통신 등 이상 징후가 있다면 로그와 관련 증거를 보존하고 보안 담당자에게 조사를 요청하세요. 취약한 버전이었다는 사실만으로 침해를 단정할 수 없으며, 패치 후 정상 작동한다는 이유만으로 과거 침해가 없었다고 단정할 수도 없습니다.