2026년 10월 21일, PHP에서 심각한 보안 취약점 2건이 공개되면서 긴급 보안 업데이트가 발표됐습니다.
이번 취약점은 특정 조건에서 인증 없이 원격 코드 실행(Remote Code Execution, RCE)이 가능할 수 있다는 점에서 주의가 필요합니다.
PHP 공식 홈페이지와 한국인터넷진흥원(KISA)도 영향을 받는 버전의 사용자에게 신속한 보안 업데이트를 권고했습니다.
그런데 실제 PHP 서버를 관리하는 입장에서는 단순히 업데이트 버전만 확인하고 끝낼 수 없습니다.
현재 서버에서 어떤 PHP가 실행되고 있는지, 웹 요청을 처리하는 PHP와 명령줄에서 실행되는 PHP가 같은지, 기존 확장 모듈은 새 버전과 호환되는지까지 확인해야 하기 때문입니다.
이번 글에서는 2026년 PHP 취약점 내용을 정리하고, Linux 서버를 기준으로 PHP 버전 확인부터 안전한 업그레이드 검토 방법까지 살펴보겠습니다.
이 글은 2026년 10월 22일 기준 공식 발표 자료를 참고한 기술 학습 및 점검 가이드입니다. 명령어는 일반적인 Linux 환경의 예시이며, 실제 운영 환경에서는 설치 방식과 서비스 구성을 확인한 뒤 적용해야 합니다.
1. 2026년 10월 PHP 보안 취약점은 무엇일까?
이번에 발표된 취약점은 다음 두 가지입니다.
- CVE-2026-109618
- CVE-2026-109619
두 취약점 모두 PHP 내부의 메모리 처리 과정과 관련되어 있습니다.
CVE-2026-109618
메모리 부족(Out of Memory, OOM)과 같은 예외 상황을 처리하는 과정에서 내부 데이터가 올바르게 정리되지 않아 메모리 손상으로 이어질 수 있는 취약점입니다.
일반적인 웹 개발에서는 메모리 부족이 발생하면 요청이 실패하거나 오류가 기록되는 상황을 떠올리기 쉽습니다.
하지만 프로그램 내부에서 예외 처리와 메모리 정리가 안전하게 이루어지지 않으면 보안 문제가 발생할 수 있습니다.
CVE-2026-109619
PHP 내부에서 이전 요청에 사용된 메모리가 해제된 후에도 일부 상태 정보가 남아 있고, 이후 요청에서 해당 정보를 다시 참조하면서 발생할 수 있는 Use After Free(UAF) 취약점입니다.
특정 조건에서 이러한 메모리 처리 오류가 원격 코드 실행으로 이어질 수 있습니다.
2. 어떤 PHP 버전이 영향을 받을까?
PHP와 KISA에서 발표한 주요 수정 버전은 다음과 같습니다.
| PHP 계열 | 해당 계열의 수정 전 버전 |
보안 수정 버전 |
|---|---|---|
| PHP 8.2 | 8.2.35 미만 | 8.2.35 이상 |
| PHP 8.3 | 8.3.36 미만 | 8.3.36 이상 |
| PHP 8.4 | 8.4.27 미만 | 8.4.27 이상 |
| PHP 8.5 | 8.5.12 미만 | 8.5.12 이상 |
여기서 주의할 점은 PHP 8.1 이하 버전입니다.
PHP 8.1 이하 계열은 PHP 프로젝트의 공식 보안 지원이 종료되어 이번 수정 버전 목록에 포함되지 않았습니다.
지원 종료 버전이라고 해서 반드시 아무런 대응 방법도 없는 것은 아닙니다. 일부 배포판이나 유지보수 업체가 별도의 보안 패치를 제공할 수 있습니다.
그러나 패치가 제공되는지, 해당 취약점 두 건이 모두 수정되었는지는 별도로 확인해야 합니다.
장기적으로는 공식 보안 지원을 받는 PHP 버전으로 이전하는 것이 권장됩니다.
3. PHP 버전 확인은 php -v만 실행하면 될까?
PHP 보안 업데이트 소식을 접하면 가장 먼저 떠올리는 명령어가 있습니다.
php -v이 명령어는 현재 셸에서 실행되는 PHP CLI(Command Line Interface)의 버전을 확인합니다.
예를 들어 다음과 같은 결과가 나올 수 있습니다.
PHP 8.x.x (cli)하지만 여기서 중요한 점이 있습니다.
명령줄에서 실행되는 PHP 버전과 실제 웹 요청을 처리하는 PHP 버전은 서로 다를 수 있습니다.
서버에 여러 PHP 버전이 설치되어 있거나, 패키지 설치와 별도의 소스 컴파일 설치가 공존할 수 있기 때문입니다.
따라서 다음 항목을 구분해서 확인해야 합니다.
- 명령줄에서 실행되는 PHP CLI
- 웹 요청을 처리하는 PHP-FPM 또는 Apache PHP 모듈
- 실제로 실행 중인 프로세스의 바이너리
- 운영체제 패키지로 설치된 PHP
4. Linux에서 PHP 실행 환경 확인하는 방법
먼저 다음 명령어를 사용해볼 수 있습니다.
command -v php
php -v첫 번째 명령어는 현재 PATH에서 선택되는 PHP 실행 파일의 위치를 보여줍니다.
다음으로 PHP-FPM이 실행 중인지 확인합니다.
ps -ef | grep '[p]hp-fpm'PHP-FPM이 실행 중이라면 master 프로세스와 worker 프로세스를 확인할 수 있습니다.
여기서 PHP-FPM은 웹서버로부터 전달받은 PHP 요청을 처리하는 프로세스 관리자입니다.
일반적인 Nginx와 PHP-FPM 구성에서는 다음과 같은 흐름으로 요청을 처리합니다.
브라우저
↓
Nginx
↓
PHP-FPM
↓
PHP 코드 실행
↓
응답 반환즉, Nginx가 PHP 코드를 직접 실행하는 것이 아니라 PHP-FPM으로 요청을 전달하는 구조입니다.
PHP-FPM 실행 파일의 위치를 확인하려면 실제 master 프로세스의 PID를 파악한 뒤 다음과 같은 명령어를 사용할 수 있습니다.
readlink -f /proc/1234/exe(여기서 1234는 예시 PID이며 실제 환경의 PHP-FPM master PID로 바꿔야 합니다.)
실행 파일을 확인한 다음 해당 바이너리의 버전을 조회할 수 있습니다.
/path/to/php-fpm -v(여기에서 /path/to/php-fpm은 실제 명령어 경로가 아닌 예시입니다. 앞에서 확인한 PHP-FPM 실행 파일의 실제 경로로 바꿔 실행해야 합니다.)
또한 실행 파일 경로와 버전을 확인하는 것만으로 실제 웹 요청을 처리하는 프로세스의 패치 적용 여부를 확정할 수는 없습니다. 업데이트 후에는 서비스 재시작 여부와 실제 웹 실행 환경을 함께 검증해야 합니다.
5. 패키지를 업데이트했는데 PHP 버전이 그대로인 이유
Linux에서 PHP를 설치하는 방법은 하나만 있는 것이 아닙니다.
대표적으로 다음과 같은 방식이 있습니다.
- 운영체제의 패키지 관리자를 이용한 설치
- 외부 저장소를 이용한 패키지 설치
- PHP 소스 코드를 직접 컴파일하는 설치
- 컨테이너 이미지에 포함된 PHP 사용
문제는 하나의 서버에 서로 다른 설치 방식이 공존할 수 있다는 점입니다.
예를 들어 운영체제 패키지 관리자로 PHP를 업데이트했더라도, 실제 웹서버가 별도로 컴파일된 PHP-FPM을 사용하고 있다면 웹 서비스에는 해당 업데이트가 적용되지 않을 수 있습니다.
이때 확인할 수 있는 명령어는 다음과 같습니다.
# RPM 계열 배포판 예시
rpm -qa | grep -i php
# Debian/Ubuntu 계열 예시
dpkg -l | grep php하지만 이 명령어는 패키지 관리자가 알고 있는 설치 정보를 보여줄 뿐입니다.
소스 컴파일로 설치한 PHP는 패키지 목록에 나타나지 않을 수 있습니다.
패키지가 설치되어 있다는 사실과 실제 웹 서비스가 그 패키지의 PHP를 사용한다는 사실은 다릅니다.
보안 점검에서는 설치된 버전뿐 아니라 현재 웹 요청을 처리하는 실행 환경을 확인해야 합니다.
6. PHP-FPM을 사용하면 이번 취약점에서 안전할까?
이번 취약점은 Apache mod_php 환경에서 원격 코드 실행 가능성이 검증됐습니다.
PHP-FPM 역시 취약한 코드의 영향을 받을 수 있지만, 공격이 성립하는 구체적인 조건은 실행 환경에 따라 다릅니다.
따라서 PHP-FPM을 사용한다는 이유만으로 안전하다고 판단해서는 안 되며, 공식 수정 버전 적용 여부를 확인해야 합니다.
또한 WAF나 웹서버 설정만으로 이번 두 취약점을 완전히 해결할 수 있다고 판단해서도 안 됩니다.
근본적인 대응은 두 취약점의 수정 사항이 포함된 PHP 또는 검증된 공급업체 보안 패치를 적용하는 것입니다.
7. PHP 8.1처럼 지원 종료된 버전은 어떻게 해야 할까?
오래된 PHP 환경을 관리할 때 가장 고민되는 부분은 버전 업그레이드입니다.
보안상 업데이트가 필요하다는 사실은 알지만, 기존 프로그램이 새 버전에서도 정상적으로 동작할지 확신하기 어렵기 때문입니다.
특히 오래된 라이브러리나 확장 모듈에 의존하는 프로젝트라면 단순히 PHP 버전만 변경하는 것으로 작업이 끝나지 않을 수 있습니다.
이때는 두 가지를 구분해서 생각하는 것이 좋습니다.
단기 대응: 보안 수정 사항 확보
공식 보안 지원이 종료된 PHP라면 해당 버전에 대한 공급업체 보안 패치나 소스 수준의 백포트가 제공되는지 확인해야 합니다.
백포트(Backport)는 최신 버전에서 수정한 보안 문제를 이전 버전의 코드에 맞게 적용하는 방식입니다.
다만 공식 수정 버전으로 업데이트하는 것과 달리, 백포트는 패치 출처와 적용 범위를 별도로 검증해야 합니다.
특히 이번 취약점처럼 여러 수정 사항이 필요한 경우에는 일부 수정만 적용한 상태를 완전한 해결로 판단해서는 안 됩니다.
장기 대응: 지원 중인 PHP 버전으로 이전
백포트는 단기 대응책이 될 수 있지만 지원 종료 버전을 계속 사용하는 데 따른 위험을 모두 해결하지는 못합니다.
따라서 장기적으로는 보안 지원을 받는 PHP 버전으로 이전하는 계획이 필요합니다.
참고로 PHP 8.2도 2026년 12월 31일 공식 보안 지원이 종료될 예정입니다. 따라서 이번 취약점 수정 버전을 적용하더라도 향후 지원되는 PHP 버전으로 이전할 계획을 함께 검토하는 것이 좋습니다.
8. PHP 8.3과 8.4 중 어떤 버전을 선택해야 할까?
PHP 8.3과 8.4 중 어떤 버전이 적합한지는 기존 코드와 라이브러리의 호환성에 따라 달라집니다.
PHP 8.3은 기존 애플리케이션과의 호환성을 검토할 수 있는 선택지이지만, 공식 보안 지원이 2027년 12월 31일 종료됩니다.
반면 PHP 8.4는 2028년 12월 31일까지 보안 지원이 예정되어 있어 상대적으로 긴 유지보수 기간을 확보할 수 있습니다.
따라서 단순히 버전 번호만 비교하기보다 코드 호환성, 확장 모듈, 시스템 요구사항, 향후 지원 기간을 함께 고려해야 합니다.
9. PHP 업그레이드 시 시스템 라이브러리도 재설치해야 할까?
PHP를 소스 코드로 컴파일해 설치하는 환경에서는 PHP 버전뿐 아니라 관련 라이브러리의 호환성도 중요합니다.
PHP 버전이 올라가면 일부 라이브러리의 최소 요구 버전이 변경될 수 있습니다.
여기서 최소 요구 버전이란 해당 PHP 버전을 빌드하거나 특정 기능을 사용하기 위해 필요한 라이브러리의 최소 버전을 의미합니다.
따라서 시스템에 설치된 라이브러리가 요구조건을 충족한다면 반드시 모든 라이브러리를 재설치해야 하는 것은 아닙니다.
하지만 최소 요구 버전을 충족한다는 사실만으로 전체 빌드 성공이나 애플리케이션의 정상 동작이 보장되는 것도 아닙니다.
실제로는 개발용 헤더 파일, 컴파일러, configure 옵션, 외부 확장 모듈의 호환성까지 확인해야 합니다.
10. 시스템 라이브러리와 PHP 확장 모듈은 다르다
이 부분은 PHP 업그레이드를 공부할 때 꼭 구분해야 하는 개념입니다.
시스템 라이브러리는 운영체제에 설치되어 PHP나 다른 프로그램이 활용하는 구성요소입니다.
반면 PHP 확장 모듈(Extension)은 PHP의 기능을 확장하기 위해 로드되는 모듈입니다.
PHP 업그레이드 시에는 mysqli, PDO, mbstring, curl, gd 등 프로젝트에서 사용하는 확장 모듈이 새 PHP 버전과 호환되는지 확인해야 합니다. 특히 외부 확장 모듈은 PHP 버전 변경에 따라 재빌드나 재설치가 필요할 수 있습니다.
기존 시스템 라이브러리를 그대로 사용하더라도 PHP 확장 모듈까지 그대로 재사용할 수 있다는 의미는 아닙니다.
따라서 업그레이드 검토에서는 다음 세 가지를 별도로 확인하는 것이 좋습니다.
- PHP 본체 버전 및 코드 호환성
- 운영체제 시스템 라이브러리의 요구조건
- PHP 확장 모듈의 빌드 및 실행 호환성
11. PHP 보안 업데이트 전 점검 체크리스트
실제 서비스 환경에서는 보안 업데이트가 필요하다고 해서 충분한 확인 없이 기존 PHP를 덮어쓰는 것은 위험할 수 있습니다.
다음 순서로 점검하면 도움이 됩니다.
| 단계 | 확인 항목 |
|---|---|
| 1 | 웹 요청을 처리하는 PHP 버전 확인 |
| 2 | PHP-FPM, mod_php 등 실행 방식 확인 |
| 3 | 패키지 설치인지 소스 컴파일 설치인지 확인 |
| 4 | 공식 수정 버전 및 공급업체 패치 확인 |
| 5 | 설치된 PHP 확장 모듈 목록 확인 |
| 6 | 시스템 라이브러리와 빌드 요구조건 확인 |
| 7 | 테스트 환경에서 업그레이드 및 기능 검증 |
| 8 | 백업·롤백 절차 및 작업 영향 확인 |
| 9 | 서비스 적용 후 실제 PHP 버전 재확인 |
| 10 | 로그 및 주요 서비스 기능 정상 여부 확인 |
특히 웹 요청을 처리하는 PHP와 명령줄에서 실행하는 PHP를 구분하고, 실제 서비스에 패치가 반영되었는지 검증하는 것이 중요합니다.
긴급 취약점이므로 불필요하게 대응을 미루지 않되, 운영 환경에 영향을 줄 수 있는 변경은 사전 검증과 복구 계획을 함께 준비하는 것이 좋습니다.
마무리
2026년 10월 21일 발표된 PHP 보안 취약점은 단순히 최신 버전으로 업데이트하라는 소식에서 끝나지 않습니다.
실제로 PHP 환경을 관리한다면 어떤 PHP가 웹 요청을 처리하는지, 어떤 방식으로 설치되었는지, 기존 라이브러리와 확장 모듈이 새 버전에서 정상 동작할지까지 확인해야 합니다.
이번 내용을 통해 기억해야 할 핵심은 세 가지입니다.
- PHP 보안 취약점이 발표되면 공식 수정 버전과 지원 종료 여부를 확인한다.
- php -v만 확인하지 말고 실제 웹 요청을 처리하는 PHP 환경을 점검한다.
- 업그레이드할 때는 PHP 본체, 시스템 라이브러리, 확장 모듈을 구분해 검증한다.
보안 업데이트는 신속해야 하지만, 실제 서비스에 적용하는 과정은 정확해야 합니다.
이번 취약점은 PHP 버전 관리뿐 아니라 웹서버와 PHP 실행 구조, 패키지 관리, 라이브러리 의존성까지 함께 공부해볼 수 있는 사례라고 생각합니다.
참고 자료
'IT개발 > Tech Notes' 카테고리의 다른 글
| HTTP와 WebSocket 차이｜실시간 통신은 왜 WebSocket을 사용할까? (0) | 2026.10.21 |
|---|---|
| PHP-FPM max_children이란? Nginx 응답 지연과 서버 부하 원인 분석 (0) | 2026.10.20 |
| localhost:8080 접속 안 됨? 원인별 확인 방법과 해결 순서 (0) | 2026.10.18 |
| 크롬 새로고침해도 화면이 안 바뀔 때｜강력 새로고침·캐시 삭제 차이 (0) | 2026.10.17 |
| GitHub Pages 404 오류 해결 방법｜github.io 배포 후 페이지가 안 뜰 때 확인할 7가지 (0) | 2026.10.10 |
댓글