PHP 보안 업데이트 후에도 워드프레스가 구버전이었던 이유

By ItInfo

2026.10.23. 5 Min Read

PHP 보안 업데이트를 마쳤는데도 워드프레스는 구버전으로 실행되고 있었다. 2026년 10월 23일 이 블로그 서버를 점검했을 때 실제로 확인한 일이다. 터미널과 패키지 목록에는 PHP 8.2.35가 표시됐지만, 워드프레스 사이트 건강에는 8.2.32가 나왔다. 홈페이지도 멀쩡하게 열렸다. 업데이트가 설치됐다는 사실만 보고 점검을 끝냈다면 놓쳤을 문제다.

이 글은 Debian 12와 Apache mod_php 환경에서 구버전 PHP 모듈을 찾아내고, Apache를 완전히 재시작한 뒤 실제 웹 버전까지 확인한 기록이다. PHP-FPM이나 관리형 호스팅은 구성과 조치 방법이 다르므로, 먼저 자신이 어떤 방식으로 PHP를 실행하는지 확인해야 한다. 기본 관리 명령은 WP-CLI 명령어 정리에 있다.

PHP 보안 업데이트 후 CLI 8.2.35와 웹 PHP 8.2.32의 차이를 표현한 대표이미지 — 실제 점검 상황을 설명하기 위한 개념 표지. 아래 본문의 버전 비교와 검증 결과는 당시 관찰값을 정리한 것이다.

PHP 보안 업데이트가 필요했던 이유

PHP 개발팀은 10월 21일 인증 없이 원격 코드 실행으로 이어질 수 있는 CVE-2026-109618과 CVE-2026-109619의 수정 버전을 공개했다. PHP로 웹 요청을 처리하는 환경이 점검 대상이며, 공식 공지는 Apache mod_php의 위험을 특히 높게 설명한다. 수정 버전과 배포판의 백포트 여부는 PHP 공식 보안 공지에서 확인해야 한다.

PHP 계열	10월 21일 두 취약점 수정 버전
8.2	8.2.35
8.3	8.3.36
8.4	8.4.27
8.5	8.5.12

이 표는 10월 21일 발표된 두 취약점의 수정 기준이다. 이후 추가 권고까지 모두 해결됐다는 뜻은 아니다. 지원이 끝난 구버전이나 배포판이 별도로 보안 수정을 제공하는 패키지는 PHP 숫자만으로 판정하지 말고 공급자의 공지도 함께 봐야 한다.

PHP 보안 업데이트 후 CLI와 웹 버전이 달랐다

확인 위치	재시작 전 관찰값	무엇을 확인했나
설치된 Debian PHP 패키지	8.2.35-1~deb12u1	디스크에 설치된 패키지
터미널의 php -v	8.2.35	CLI에서 새로 실행한 PHP
워드프레스 사이트 건강	8.2.32 / apache2handler	실제 웹 요청을 처리한 PHP
Apache 프로세스 매핑	libphp8.2.so (deleted)	실행 중인 프로세스가 잡고 있는 모듈

처음에는 여러 PHP 버전이 함께 설치된 상황을 의심했다. 하지만 이 서버에서는 Apache가 이전 모듈을 메모리에 계속 잡고 있는 것이 직접 확인됐다. 패키지는 10월 22일 갱신됐는데 Apache 부모 프로세스는 그보다 훨씬 전부터 실행 중이었다. 새 CLI 프로세스와 오래 실행된 웹 프로세스가 서로 다른 코드를 사용한 셈이다.

1. 웹에서 사용하는 PHP 실행 방식을 먼저 확인한다

워드프레스 관리자에서 도구 → 사이트 건강 → 정보 → 서버를 열면 PHP 버전과 PHP SAPI를 볼 수 있다. 이번 서버의 SAPI는 apache2handler였다. 이는 Apache에 PHP 모듈을 올려 실행하는 방식이다. FPM/FastCGI로 표시된다면 해당 FPM 서비스와 풀 구성을 따로 확인해야 한다.

php -v

# 이 글의 Debian 12 / PHP 8.2 패키지 확인 예
dpkg-query -W -f='${Package} ${Version}\n' \
  php8.2-cli php8.2-common libapache2-mod-php8.2

# Apache 설정과 로드된 PHP 모듈 확인
sudo apache2ctl configtest
sudo apache2ctl -M | grep -i php

php -v

# 이 글의 Debian 12 / PHP 8.2 패키지 확인 예
dpkg-query -W -f='${Package} ${Version}\n' \
  php8.2-cli php8.2-common libapache2-mod-php8.2

# Apache 설정과 로드된 PHP 모듈 확인
sudo apache2ctl configtest
sudo apache2ctl -M | grep -i php

php -v는 CLI 확인 명령이다. 웹 버전까지 같다는 보장은 없다. Apache, FPM, 컨테이너, 호스팅 관리 화면에서 서로 다른 PHP를 선택할 수도 있다. 따라서 CLI와 사이트 건강의 결과가 다르면 경로와 실행 방식부터 구분하자. PHP의 CLI와 다른 SAPI 차이도 참고할 만하다.

2. Apache가 삭제된 이전 모듈을 쓰는지 확인한다

# 아래 명령은 조회만 한다. 파일을 삭제하거나 프로세스를 종료하지 않는다.
apache_pid=$(systemctl show apache2 -p MainPID --value)
ps -p "$apache_pid" -o pid,lstart,args
sudo grep libphp "/proc/$apache_pid/maps"

# 각 Apache 프로세스의 PHP 매핑도 함께 확인
for pid in $(pgrep -x apache2); do
  echo "PID=$pid"
  sudo grep libphp "/proc/$pid/maps"
done

# 아래 명령은 조회만 한다. 파일을 삭제하거나 프로세스를 종료하지 않는다.
apache_pid=$(systemctl show apache2 -p MainPID --value)
ps -p "$apache_pid" -o pid,lstart,args
sudo grep libphp "/proc/$apache_pid/maps"

# 각 Apache 프로세스의 PHP 매핑도 함께 확인
for pid in $(pgrep -x apache2); do
  echo "PID=$pid"
  sudo grep libphp "/proc/$pid/maps"
done

재시작 전에는 /usr/lib/apache2/modules/libphp8.2.so 뒤에 (deleted)가 붙어 있었다. 디스크의 파일이 교체됐지만 해당 프로세스가 이전 파일의 매핑을 계속 사용하고 있다는 단서다. 이 표시는 특정 취약점이나 침해를 뜻하는 표식은 아니다. 설치 패키지 버전, 웹 PHP 버전, 프로세스 시작 시각과 함께 해석해야 한다.

/usr/lib/apache2/modules/libphp8.2.so (deleted)

/usr/lib/apache2/modules/libphp8.2.so (deleted)

반대로 (deleted)가 없다는 이유만으로 최신 패치라고 판단해서도 안 된다. 디스크에 구버전이 그대로 설치돼 있으면 삭제 표시 없이 구버전을 사용할 수 있다. 이번에는 새 패키지가 설치돼 있었고 실제 웹 PHP가 구버전이었기 때문에, 모듈 교체와 실행 프로세스 사이의 차이가 원인임을 좁힐 수 있었다.

3. PHP 보안 업데이트를 Apache 재시작으로 실제 적용했다

먼저 Apache 구성 검사를 통과하는지 확인했다. 그다음 작업 중인 요청에 짧은 영향을 줄 수 있다는 점을 고려해 Apache 서비스를 완전히 재시작했다. 아래는 이 서버에서 수행한 명령이다. 서비스 이름이 다르거나 PHP-FPM을 사용하는 서버에 그대로 적용하는 공통 처방은 아니다.

sudo apache2ctl configtest

# Syntax OK 확인 후, 서비스 중단 영향을 고려해 실행
sudo systemctl restart apache2

systemctl is-active apache2
systemctl show apache2 -p MainPID -p ExecMainStartTimestamp

sudo apache2ctl configtest

# Syntax OK 확인 후, 서비스 중단 영향을 고려해 실행
sudo systemctl restart apache2

systemctl is-active apache2
systemctl show apache2 -p MainPID -p ExecMainStartTimestamp

Apache의 graceful 동작은 진행 중인 요청과 프로세스 세대를 관리하는 방식이므로, 설정을 다시 읽었다는 사실과 PHP 모듈 교체가 끝났다는 사실을 같게 보면 안 된다. 이번 작업에서는 완전한 서비스 재시작을 수행했다. 다른 환경에서도 명령 성공 여부만 보지 말고 실제 작업자와 웹 버전을 확인해야 한다. Apache의 동작 차이는 Apache 공식 재시작 문서에 설명돼 있다.

4. PHP 보안 업데이트 완료는 웹과 프로세스 양쪽에서 확인한다

재시작 후에는 서비스 상태가 active인지 확인하고, 새 부모 프로세스와 모든 Apache 작업자가 새 모듈을 사용하는지 확인했다. 점검한 8개 프로세스에서 이전 모듈의 (deleted) 표시는 사라졌다. 워드프레스 사이트 건강을 새로 고침했을 때 PHP 버전도 8.2.35로 바뀌었다.

확인 항목	이번 작업 결과
Apache 구성 검사	Syntax OK
서비스와 프로세스	active, 새 부모 프로세스와 작업자 확인
실제 웹 PHP	8.2.32 → 8.2.35
홈·글·로그인·REST 응답	HTTP 200
재시작 직후 로그	새로운 PHP/Apache 치명적 오류 확인되지 않음

HTTP 200은 사이트가 응답한다는 뜻이지 PHP 보안 업데이트가 적용됐다는 증거는 아니다. 이번에는 재시작 전에도 홈페이지가 HTTP 200이었다. 웹 버전과 모듈 확인을 함께 해야 하는 이유다. 이후 운영 로그에서 장애를 추적하는 방법은 워드프레스 치명적인 오류 해결기와 journalctl 로그 확인 방법에서 이어서 볼 수 있다.

10월 23일 추가 PHP 권고도 별도로 확인해야 한다

글을 정리하던 10월 23일 PHP 공식 사이트에 세션 업로드 진행 기능에 관한 추가 권고가 게시됐다. 공지는 설정에서 session.serialize_handler가 php_binary 또는 php_serialize이고, 애플리케이션이 세션 시작 전에 ini_set()으로 php로 바꾸며, 업로드 진행 기능도 활성화된 특이한 조합을 설명한다. 런타임에 이 핸들러를 바꾸지 않는 애플리케이션은 해당 기능을 유지할 수 있다고도 명시한다.

PHP 팀은 다음 정기 버그 수정 릴리스까지 session.upload_progress.enabled=0을 권고하고, 관련 CVE-2026-115560의 전체 공지를 다음 릴리스에 공개할 예정이라고 밝혔다. 따라서 10월 21일 수정 버전 표만 보고 모든 추가 위험까지 해결됐다고 써서는 안 된다. 이 글에서 확인한 것은 앞서 설치한 두 취약점의 패치가 실제 웹 프로세스에 반영됐다는 점이며, 23일 추가 조건의 해당 여부는 별도 설정·코드 점검이 필요하다. 최신 내용은 PHP 공식 최신 공지를 기준으로 확인하자.

PHP 보안 업데이트 점검을 마치며

이번 문제의 핵심은 설치된 파일과 실행 중인 프로세스가 달랐다는 데 있었다. 패키지 업데이트 → 실제 웹 PHP 확인 → 실행 프로세스 확인 → 필요한 재시작 → 웹·프로세스·로그 재검증까지 이어져야 점검이 끝난다. 보안 공지에서 패치 버전을 찾는 일과 내 서비스에 그 코드가 올라갔음을 확인하는 일은 서로 다른 단계였다.

일반적인 계정·로그인·파일 설정은 워드프레스 보안 설정에서 다뤘다. PHP 보안 업데이트는 이런 애플리케이션 설정과 별도로 서버에서 확인해야 한다. 또한 패치 적용을 확인했다고 해서 과거 침해가 없었다는 뜻은 아니다. 이 글은 실제 업데이트 적용 과정의 기록이며, 침해 여부를 단정하는 포렌식 보고서는 아니다.