이 정식
지원 종료 PHP 보안 패치는 기존 애플리케이션의 호환성 때문에 PHP 버전을 즉시 업그레이드하기 어려운 서버에서 검토할 수 있는 보안 유지 방안 중 하나입니다. PHP 7.4, 8.0, 8.1과 같이 공식 지원이 종료된 버전에서도 외부 저장소를 통해 보안 수정 패키지가 제공되는 사례가 있습니다.
최근 PHP2Shell 취약점 대응 과정에서도 이러한 사례가 확인됐습니다. 이번 글에서는 취약점 대응 절차 자체보다는 지원 종료 PHP 버전에 보안 수정 사항이 어떻게 반영되는지, 외부 저장소의 패키지를 확인할 때 어떤 점을 살펴봐야 하는지 소개합니다.
지원 종료 PHP 보안 패치가 필요한 이유
PHP는 버전별 공식 지원 기간이 종료되면 일반적인 보안 업데이트 제공이 중단됩니다. 기존 웹사이트가 특정 PHP 버전에 의존하고 있다면 버전 업그레이드에 따른 호환성 검토와 소스 코드 수정이 필요할 수 있습니다.
| PHP 버전 | 공식 지원 종료일 | 마지막 공식 버전 |
|---|---|---|
| PHP 7.4 | 2022년 11월 28일 | 7.4.33 |
| PHP 8.0 | 2023년 11월 26일 | 8.0.30 |
| PHP 8.1 | 2025년 12월 31일 | 8.1.34 |
출처: PHP 공식 지원 종료 버전
지원 종료 버전이라고 해서 모든 보안 수정 방법이 사라지는 것은 아닙니다. 일부 배포판과 외부 저장소에서는 기존 PHP 버전에 보안 수정 사항을 반영한 패키지를 별도로 제공하기도 합니다.
다만 이러한 패키지는 PHP 프로젝트의 공식 지원과 구분해야 합니다. 저장소별로 제공 범위와 유지보수 정책이 다르므로, 실제 수정 여부를 확인하지 않고 최신 패키지라는 이유만으로 안전하다고 판단해서는 안 됩니다.
PHP2Shell 대응에서 확인된 외부 저장소 사례
PHP2Shell은 CVE-2026-109618 및 CVE-2026-109619로 공개된 PHP 원격 코드 실행 취약점입니다. PHP 공식 프로젝트는 2026년 10월 21일 PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 버전을 공개해 해당 취약점에 대응했습니다.
그러나 PHP 8.1 이하 버전은 공식 지원이 종료된 상태이므로, 기존 버전을 계속 사용하는 환경에서는 별도의 패치 제공 여부를 확인할 필요가 있습니다.
이와 관련해 살펴볼 수 있는 사례가 Remi Repository입니다. Remi는 RPM 기반 Linux 환경에서 다양한 PHP 버전을 제공하며, 지원 종료 버전에 대해서도 일부 보안 수정 사항을 백포트한 패키지를 유지하고 있습니다.
Remi의 2026년 10월 22일 변경 이력에는 PHP2Shell 관련 완화 조치를 반영한 다음 패키지 릴리스가 기록돼 있습니다.
| PHP 버전 | 패키지 릴리스 | 변경 이력 |
|---|---|---|
| PHP 7.4 | 7.4.33-31 | PHP 8.2.35 기준 보안 수정 사항의 완화 조치 반영 |
| PHP 8.0 | 8.0.30-21 | PHP 8.2.35 기준 보안 수정 사항의 완화 조치 반영 |
| PHP 8.1 | 8.1.34-6 | PHP 8.2.35 기준 보안 수정 사항의 완화 조치 반영 |
위 버전은 해당 날짜에 확인된 Remi 패키지 릴리스 사례입니다. 실제 제공 여부와 수정 범위는 운영체제, 저장소 구성 및 패키지 빌드에 따라 확인해야 합니다.
관련 자료:
PHP 보안 패키지의 릴리스 번호가 중요한 이유
외부 저장소의 보안 패키지를 확인할 때는 PHP 버전 문자열만 살펴봐서는 안 됩니다.
예를 들어 PHP 7.4의 마지막 공식 버전은 7.4.33이지만, 외부 저장소에서는 동일한 PHP 버전 문자열을 유지하면서 RPM 릴리스 번호를 변경해 수정 사항을 반영할 수 있습니다.
이러한 방식에서는 php -v 결과가 기존과 동일하게 표시될 수 있으므로, 패키지 릴리스 정보와 변경 이력을 함께 확인해야 합니다.
또한 RPM 릴리스 번호가 변경됐다는 사실만으로 특정 취약점의 해결을 보장할 수는 없습니다. 해당 CVE의 수정 또는 완화 조치가 실제 패키지에 포함됐는지 확인하는 과정이 필요합니다.
지원 종료 PHP 보안 패치 적용 시 고려사항
기존 PHP 버전을 유지하면서 보안 수정 패키지를 적용하는 방식은 메이저 버전을 변경하는 업그레이드보다 변경 범위가 작을 수 있습니다. 하지만 서비스 영향이 없다고 단정할 수는 없습니다.
특히 PHP 확장 모듈과 애플리케이션 코드의 호환성을 확인해야 합니다.
- PHP 확장 모듈: 별도 설치된 확장 모듈의 ABI 호환성이나 재빌드 필요 여부를 확인해야 합니다.
- 애플리케이션 소스 코드: 보안 수정에 따라 함수의 처리 방식이 변경되는 경우 코드 수정이 필요할 수 있습니다.
- 서비스 실행 환경: CLI PHP와 웹 서비스에서 사용하는 PHP 버전이 다를 수 있으므로 실제 실행 환경을 확인해야 합니다.
- 서비스 검증: 패키지 변경 후 PHP-FPM 등 관련 프로세스의 재시작 여부와 주요 기능의 정상 동작을 확인해야 합니다.
따라서 보안 수정 패키지가 제공되더라도 테스트 환경에서 호환성을 검증하고, 운영 반영 전후 서비스 상태를 확인하는 과정이 필요합니다.
외부 저장소 패치는 공식 지원을 대체하지 않습니다
Remi Repository와 같은 외부 저장소는 지원 종료 PHP를 유지해야 하는 환경에서 참고할 수 있는 선택지입니다. 그러나 외부 저장소에서 패키지를 제공한다는 사실이 PHP 프로젝트의 공식 지원을 복원한다는 의미는 아닙니다.
Remi 역시 지원 종료 버전의 패키지 유지는 최선 노력 방식이며, 가능한 경우 지원 중인 PHP 버전으로 업그레이드할 것을 권고합니다.
특정 취약점에 대한 수정 사항이 반영됐더라도 모든 보안 취약점이 해결된 것은 아닙니다. 패키지 제공 범위와 업데이트 일정이 변경될 수 있으므로, 운영 환경에서는 최신 변경 이력과 공식 보안 공지를 기준으로 판단해야 합니다.
마무리
지원 종료 PHP 보안 패치는 기존 애플리케이션의 호환성 때문에 즉시 업그레이드하기 어려운 환경에서 검토할 수 있는 보안 유지 방안입니다. PHP2Shell 대응 과정에서 확인된 Remi Repository의 패키지는 기존 PHP 버전에 보안 수정 사항이 반영될 수 있음을 보여주는 사례입니다.
다만 외부 저장소의 패키지는 공식 지원을 대체하는 장기적인 해결책이 아닙니다. 패키지의 수정 범위와 호환성을 확인하는 동시에, 공식 지원 버전으로 전환하기 위한 업그레이드 및 마이그레이션 계획을 마련해야 합니다.