PHP 보안 취약점(PHP2Shell) 대응: WordPress 서버를 업데이트 기록

작성 기준: 2026년 10월 22일

2026년 10월 21일, PHP 프로젝트에서 인증 없이 원격 코드 실행으로 이어질 수 있는 심각한 취약점 두 건을 공개했다. PHP로 웹 요청을 처리하는 서버가 영향 대상이며, WordPress 운영자도 확인과 조치가 필요하다. PHP 공식 보안 공지에서 영향 범위와 대응 방법을 확인할 수 있다.

운영 중인 블로그의 PHP 버전을 확인해 보니 8.3.33이었다. 이번 취약점의 영향 범위에 포함돼, 같은 8.3 계열의 수정 버전인 8.3.36으로 업데이트했다. 취약점 내용과 실제 작업에서 확인한 사항을 기록한다.

이번에 공개된 PHP 취약점은?

취약점	주요 내용	심각도
CVE-2026-109618	메모리 부족 오류를 처리하는 과정에서 발생하는 메모리 손상	Critical, CVSS 4.0 기준 9.2
CVE-2026-109619	요청이 끝난 뒤 남아 있는 내부 상태가 해제된 메모리를 참조하는 문제	Critical, CVSS 4.0 기준 9.2

첫 번째 취약점은 PHP가 메모리 부족으로 처리를 중단했을 때, 초기화가 끝나지 않은 데이터를 정리 과정에서 사용하는 문제다. Apache의 mod_php 환경에서는 애플리케이션 코드가 실행되기 전에 공격이 성립하는 사례가 확인됐다. CVE-2026-109618 상세 공지에 기술적인 설명이 정리돼 있다.

두 번째 취약점은 이전 요청의 내부 상태가 다음 요청까지 남아 발생한다. 공격 조건이 충족되면 메모리 정보 노출이나 원격 코드 실행으로 이어질 수 있다. PHP-FPM에서도 특정 애플리케이션 동작을 거치는 공격 경로가 검증됐으므로, FPM을 사용하는 서버 역시 업데이트 대상이다. CVE-2026-109619 상세 공지에서 관련 조건을 확인할 수 있다.

WordPress 공식 안내에서도 PHP 업데이트를 권고했다. 이번 문제를 해결하려면 WordPress를 실행하는 PHP 자체에 수정 패키지를 적용해야 한다. 자세한 내용은 WordPress 공식 안내를 참고하면 된다.

어떤 버전으로 업데이트해야 하나?

공식 PHP 배포본의 계열별 수정 버전은 아래와 같다.

PHP 계열	취약한 버전	이번 취약점의 수정 버전
8.2	8.2.35 미만	8.2.35
8.3	8.3.36 미만	8.3.36
8.4	8.4.27 미만	8.4.27
8.5	8.5.12 미만	8.5.12

배포판이나 유지보수 업체가 기존 버전에 보안 수정 사항을 백포트하는 경우도 있다. 따라서 배포판 패키지를 사용한다면 전체 패키지 버전과 해당 업체의 보안 공지까지 확인해야 한다. PHP 8.1 이하를 사용 중이라면 공식 보안 지원이 종료된 상태이므로, 지원되는 계열로의 이전도 검토해야 한다. PHP 업데이트 안내에 배포판 및 유지보수 업체 이용자를 위한 설명도 포함돼 있다.

WordPress가 사용하는 PHP 버전 확인하기

이번에 작업한 서버는 Rocky Linux 9.8에서 Apache와 PHP-FPM을 사용하는 구성이었다. PHP는 Remi 저장소의 8.3 계열 패키지로 설치돼 있었다.

먼저 현재 버전과 실행 구성을 확인했다.

php -v
php-fpm -v
php --ini
php -m

rpm -qa 'php*' | sort
systemctl is-active httpd php-fpm

여기서 주의할 점은 php -v가 명령줄에서 사용하는 PHP 버전을 보여준다는 것이다. 웹서비스가 사용하는 PHP와 다를 수 있으므로, WordPress 관리자 화면에서도 확인하는 편이 좋다.

WordPress에서는 도구 → 사이트 건강 → 정보 → 서버에서 웹사이트가 사용하는 PHP 버전을 확인할 수 있다. WordPress 공식 안내에서도 이 확인 경로를 소개하고 있다.

Rocky Linux에서 PHP 8.3.36으로 업데이트

업데이트 전에는 PHP와 Apache 설정, 설치 패키지 목록, PHP 확장 모듈 목록을 백업했다. 이후 저장소에서 수정 버전이 제공되는지 조회했다.

dnf --refresh --showduplicates list php-cli php-fpm

2026년 10월 22일 작업 시점에는 사용 중인 Remi 저장소에서 8.3.36 패키지를 확인할 수 있었다.

이번 서버에서는 PHP 본체와 함께 설치된 기본 확장 모듈을 업데이트했다. 아래 명령의 대상은 이 서버에 설치돼 있던 패키지들이며, 다른 환경에서는 설치 패키지와 저장소 구성을 먼저 확인해야 한다.

dnf upgrade \
  php-cli php-common php-fpm php-gd php-intl \
  php-mbstring php-mysqlnd php-opcache php-pdo php-xml

변경 대상은 총 10개 패키지였다. 설치된 Redis, Imagick 등의 별도 확장 모듈도 업데이트 후 정상적으로 로드되는지 확인했다.

PHP-FPM 재시작과 업데이트 결과 확인

패키지 설치가 끝난 뒤에는 설정 문법을 검사하고 PHP-FPM을 재시작했다.

php-fpm -t && apachectl configtest && systemctl restart php-fpm

이어서 버전과 서비스 상태를 다시 확인했다.

php -v
php-fpm -v
systemctl is-active php-fpm httpd

확인 결과 CLI와 PHP-FPM 모두 8.3.36으로 변경됐고, 두 서비스 모두 정상 실행 중이었다. FPM 소켓을 통한 별도 확인에서도 실제 요청을 처리하는 PHP 버전이 8.3.36으로 확인됐다.

업데이트 후 점검 결과는 다음과 같다.

• WordPress 홈, 로그인 페이지, REST API 모두 HTTP 200 응답
• 기존 PHP·Apache 설정 파일의 내용 유지
• 업데이트 전후 PHP 확장 모듈 목록 동일
• MySQLi, Imagick, Redis, OPcache 로드 정상
• 작업 이후 확인한 PHP-FPM·Apache의 systemd 서비스 로그에 경고 이상 항목 없음

이번 두 취약점은 설정 변경만으로 완전히 해결할 수 없다는 것이 PHP 프로젝트의 안내다. 수정된 PHP 버전이나 배포판의 보안 패키지를 적용하는 조치가 필요하다. PHP 공식 보안 권고에서 최신 안내를 확인할 수 있다.

WordPress를 운영하고 있다면 웹사이트에서 실제 사용하는 PHP 버전부터 확인하자. 직접 관리하는 서버에서는 패키지 업데이트와 PHP 워커 재시작까지 완료하고, 호스팅을 이용한다면 업체에 CVE-2026-109618과 CVE-2026-109619의 수정 적용 여부를 확인하면 된다.