- 무슨 일: PHP가 10월 21일 원격 코드 실행 취약점 2개의 수정판을 공개했습니다.
- 왜 중요한가: PHP-FPM·mod_php 등 웹 요청을 처리하는 PHP 환경이 점검 대상입니다.
- 아직 모르는 것: 개별 호스팅의 패치 적용 여부는 공급자에게 확인해야 합니다.
PHP 보안팀은 웹 요청을 처리하는 PHP 운영자에게 8.2.35·8.3.36·8.4.27·8.5.12 중 해당 계열의 수정판이나 공급자가 보안 패치를 반영한 패키지로 업데이트할 것을 권고했습니다.
‘PHP 보안 비상’이라는 말이 모든 웹사이트의 해킹을 뜻하는 것은 아닙니다. 2026년 10월 21일 공개된 공식 공지는 인증 없이 원격 코드 실행으로 이어질 수 있는 취약점 두 개와 수정판을 함께 알렸습니다. 10월 23일 확인한 공지의 핵심은 막연한 불안이 아니라, 내 사이트의 실행 환경과 실제 패치 상태를 구분하는 데 있습니다.
운영자가 직접 PHP를 설치했는지, 호스팅 업체가 패키지를 관리하는지에 따라 업데이트 경로가 달라집니다. 같은 PHP라는 이름을 쓰더라도 서로 다른 계열의 버전 숫자를 비교해 안전 여부를 판단해서는 안 됩니다. 공식 수정판과 공급자 안내를 자신의 환경에 맞춰 읽어야 합니다.
내 사이트도 대상일까? PHP-FPM과 mod_php까지 포함됩니다
PHP 보안팀이 명시한 범위는 웹 요청을 처리하는 PHP 설치 전반입니다. PHP-FPM, Apache의 mod_php, php-cgi, FrankenPHP, LiteSpeed가 예시로 제시됐습니다. 자신이 사용하는 방식의 이름을 모른다면 서버 관리 화면이나 호스팅 지원 창구에서 확인하는 것이 첫 단계입니다.
공지에서는 mod_php의 위험을 가장 높게 평가했습니다. 애플리케이션 코드가 실행되기 전, 인증하지 않은 요청으로 공격이 가능한 사례가 실증됐다는 설명입니다. 따라서 사이트 로그인 기능이나 애플리케이션의 평소 동작만 보고 PHP 런타임의 보안 상태를 판단하기는 어렵습니다. 다만 이 설명만으로 자신의 서버가 이미 침해됐다고 단정할 수는 없습니다.
수정 버전은 4개, 호스팅에서는 무엇을 물어봐야 하나요?
공식 수정 버전은 PHP 8.2 계열의 8.2.35, 8.3 계열의 8.3.36, 8.4 계열의 8.4.27, 8.5 계열의 8.5.12입니다. 각각 자신이 운영하는 계열에 대응하는 수정판입니다. 다운로드 페이지에는 소스와 Windows 설치 경로가 있으며, 서버에 맞는 배포 방식을 선택해야 합니다.
Linux 배포판과 장기지원 공급자는 패치를 사전에 전달받았다고 PHP 보안팀은 밝혔습니다. 이 경우에는 화면에 보이는 PHP 버전 문자열뿐 아니라 공급자가 제공하는 보안 패키지의 적용 여부를 확인해야 합니다. 업체에 문의할 때는 CVE-2026-109618과 CVE-2026-109619 두 식별자를 함께 제시하면 점검 대상을 분명하게 전달할 수 있습니다.
PHP 8.1 이하는 백포트와 공식 지원을 구분해야 합니다
PHP 8.1 이하는 PHP 프로젝트의 일반 업데이트 지원이 끝났습니다. 일부 배포판이나 장기지원 공급자는 보안 수정을 이전 버전에 반영하는 백포트를 제공할 수 있으므로, 공급자의 적용 여부를 확인하거나 지원 중인 버전으로 전환해야 합니다. ‘구버전이지만 작동한다’는 것과 ‘보안 수정이 제공된다’는 것은 다른 조건입니다.
이번에는 PHP 보안팀이 소스 빌드 사용자 등을 돕기 위해 PHP 7.4·8.0·8.1용 최소 소스 백포트도 제공했습니다. 이것을 해당 계열의 일반 지원 재개로 읽어서는 안 됩니다. 또한 PHP 8.2도 2026년 12월 31일 지원 종료가 예정돼 있어, 이번 패치 적용과 이후 버전 전환 계획을 함께 살펴볼 필요가 있습니다.
설정만 바꾸면 해결될까? 공식 답은 업데이트입니다
공식 공지는 임시 설정 조치가 특정 공격 경로의 노출을 줄일 수는 있지만, 설치를 안전하게 만드는 완전한 해결책은 아니라고 설명합니다. 개별 설정을 무작정 복사하기보다 서버 운영자와 공급자가 자신의 구성에 맞는 보안 패키지를 적용하는 것이 우선입니다. 이 글은 공격 재현 코드나 일괄 설정 변경 명령을 제공하지 않습니다.
정리하면, 내 웹사이트의 PHP 실행 방식과 계열을 확인하고 두 취약점의 패치가 실제 반영됐는지 확인해야 합니다. 자체 운영은 해당 수정판을, 관리형 호스팅은 공급자의 보안 적용 안내를 기준으로 삼으면 됩니다. 사이트별 침해 여부나 호스팅별 완료 시점은 PHP의 공통 공지만으로 확인할 수 없습니다.
쓱보고가 편집팀은 운영 책임자 봉형의 편집 표기입니다. AI·자동 발행의 역할과 한계는 사이트 소개에서 확인할 수 있습니다.