2026년 10월 21일 PHP에서 원격 코드 실행(RCE)으로 이어질 수 있는 심각한 보안 취약점 2건에 대한 보안 업데이트가 공개됐습니다. 인증되지 않은 원격 요청으로 공격이 가능할 수 있고, PHP 공식 보안 공지는 수정 버전으로 업데이트하는 것이 유일하게 안전한 해결책이라고 안내하고 있습니다.
저는 별도 호스팅 업체를 이용하지 않고 개인 NAS에서 컨테이너로 워드프레스 사이트 3개를 운영하고 있습니다. 외부 접속은 Cloudflare Tunnel을 사용하고 있어 이번 취약점 소식을 확인한 뒤 세 사이트의 PHP 버전과 서버 정보를 직접 확인했습니다.
먼저 확인 결과부터 정리하면 세 사이트 모두 PHP 8.3.36으로 표시됐습니다. PHP 8.3 계열의 수정 버전이므로 PHP 버전만 놓고 보면 이번 취약점의 패치 버전에 도달한 상태입니다. 다만 실제 운영 환경에서는 워드프레스 관리자 화면에 표시되는 버전뿐 아니라 컨테이너 이미지와 실행 중인 환경도 함께 확인하는 편이 안전합니다.
1. 어떤 취약점인가?
이번에 공개된 취약점은 CVE-2026-109618과 CVE-2026-109619입니다. 두 취약점 모두 원격 코드 실행으로 이어질 수 있으며 각각 메모리 부족 처리와 요청 사이에 남아 있는 내부 상태를 다루는 과정에서 문제가 발생합니다.
| CVE | 주요 내용 | 심각도 |
|---|---|---|
| CVE-2026-109618 | 메모리 부족(OOM) 처리 중 초기화가 완전하지 않은 요청 데이터가 잘못 처리될 수 있는 취약점 | CVSS 9.2점 |
| CVE-2026-109619 | 요청 간에 남은 오래된 전역 상태로 인해 해제된 메모리를 참조하는 문제(Use-After-Free, CWE-416) | CVSS 9.2점 |
첫 번째 취약점은 PHP가 메모리 부족 상황에서 요청 처리를 중단하고 정리하는 과정과 관련이 있습니다. 특정 상황에서는 내부 요청 데이터가 완전히 초기화되기 전에 메모리 할당 실패가 발생하고 이후 정리 과정에서 잘못된 상태를 참조할 수 있습니다.
두 번째 취약점은 요청이 끝난 뒤에도 이전 요청의 메모리를 가리키는 내부 상태가 남을 수 있다는 문제입니다. 이후 같은 작업 프로세스가 다른 요청을 처리할 때 해당 상태를 잘못 사용하면 메모리 오류가 발생하고 원격 코드 실행으로 이어질 가능성이 있습니다.
두 취약점은 모두 인증되지 않은 원격 공격으로 이어질 수 있다는 점에서 가볍게 볼 문제가 아닙니다. 자세한 기술 내용과 영향 범위는 아래 PHP 보안 권고에서 확인할 수 있습니다.
2. PHP-FPM도 안전하다고 볼 수 없다
이번 취약점에서 특히 주의할 부분은 PHP를 실행하는 방식입니다.
PHP-FPM뿐 아니라 Apache mod_php, php-cgi, FrankenPHP, LiteSpeed 등 웹 요청을 처리하는 모든 PHP 설치가 위험 범위에 들어갑니다. 다만 SAPI마다 실제 공격 경로와 재현 조건은 다를 수 있습니다. PHP 공식 보안 공지는 이 중 Apache mod_php 구성을 가장 위험도가 높은 환경으로 평가하고 있습니다. 인증되지 않은 요청만으로 애플리케이션 코드가 실행되기 전에 공격을 유발할 수 있는 경로가 확인됐기 때문입니다.
제가 운영하는 사이트의 서버 정보에는 PHP SAPI가 apache2handler로 표시됩니다. 이는 일반적으로 Apache 모듈 방식인 mod_php 환경에 해당하므로 이번 점검에서 특히 유의해서 확인할 항목입니다.
따라서 PHP-FPM을 사용한다고 해서 이번 취약점과 무관하다고 판단해서는 안 됩니다. 반대로 모든 SAPI에서 공격 조건과 재현 가능성이 똑같다고 이해하는 것도 정확하지 않습니다. 실제 운영 환경에 맞는 수정 버전을 적용하는 것이 가장 중요합니다.
3. 영향을 받는 버전과 수정 버전
PHP 프로젝트가 공개한 수정 버전은 다음과 같습니다.
| PHP 계열 | 영향을 받는 버전 | 수정 버전 |
|---|---|---|
| PHP 8.5 | 8.5.12 미만 | 8.5.12 이상 |
| PHP 8.4 | 8.4.27 미만 | 8.4.27 이상 |
| PHP 8.3 | 8.3.36 미만 | 8.3.36 이상 |
| PHP 8.2 | 8.2.35 미만 | 8.2.35 이상 |
PHP 8.1 이하처럼 공식 지원이 종료된 계열을 운영 중이라면 단순히 현재 표시되는 버전만 확인할 것이 아니라 지원 중인 계열로의 전환도 검토해야 합니다. 일부 배포판에서 별도 보안 패치를 제공하는 경우가 있으므로 실제 설치 경로와 배포판의 패치 정책도 함께 확인해야 합니다.
이번 보안 업데이트에 대한 공식 안내는 아래 자료에서 확인할 수 있습니다.
- PHP 공식 보안 공지 — Critical remote code execution vulnerabilities, update now
- PHP 8.3.36 릴리스 공지
- KISA 보안 공지 — PHP 보안 업데이트 권고
PHP 8.3.36 릴리스 공지는 이번 버전이 두 가지 심각한 취약점을 해결하는 보안 릴리스이며, 완전한 완화책은 없고 업데이트가 안전한 선택이라고 안내합니다.
4. 내가 운영하는 워드프레스 3개 사이트 확인하기
개인 NAS에서 컨테이너로 워드프레스 사이트 3개를 운영하고 있어 각 사이트의 관리자 화면에서 PHP 버전을 확인했습니다.
확인 경로는 다음과 같습니다.
- 워드프레스 관리자에 로그인합니다.
- 도구 → 사이트 건강으로 이동합니다.
- 정보 → 서버 항목을 펼칩니다.
- PHP 버전과 PHP SAPI, 웹 서버 정보를 확인합니다.
세 사이트를 각각 확인한 결과 모두 PHP 8.3.36으로 표시됐습니다. 세 사이트의 PHP 버전이 동일하다는 점은 확인했지만, 사이트마다 컨테이너 구성이 완전히 같은지까지 이 정보만으로 단정할 수는 없습니다.
제가 사이트 건강 화면에서 확인한 주요 서버 정보는 다음과 같습니다.
이 정보에서 가장 먼저 볼 부분은 PHP 버전과 SAPI입니다. PHP 8.3.36은 PHP 8.3 계열의 수정 버전이며, apache2handler는 이번 권고에서 특히 위험도가 높게 평가된 mod_php 계열 환경과 연결되는 단서입니다.
5. Cloudflare Tunnel을 사용해도 확인해야 하는 이유
저는 개인 NAS에서 운영하는 워드프레스 사이트를 외부에서 접속할 수 있도록 Cloudflare Tunnel을 사용하고 있습니다.
Cloudflare Tunnel은 원본 서버의 IP 주소를 직접 공개하지 않고 외부 접속 경로를 구성하는 데 도움이 됩니다. 하지만 공개 호스트네임으로 사이트를 제공하고 있다면 외부 사용자의 HTTP 요청은 Tunnel을 통해 워드프레스까지 도달할 수 있습니다. 원본 IP를 직접 노출하지 않는 것과 웹 애플리케이션이 외부 요청을 받지 않는 것은 서로 다른 문제입니다.
따라서 Cloudflare Tunnel을 사용한다는 이유만으로 이번 PHP 취약점의 영향에서 벗어난다고 판단하면 안 됩니다. 사이트가 일반 공개 상태인지, Cloudflare Access로 인증된 사용자만 접근할 수 있게 제한돼 있는지도 구분해서 확인해야 합니다.
공개 사이트라면 PHP 버전 확인과 패치 적용이 우선입니다. 외부 공개가 필요하지 않은 관리용 사이트라면 접근 제어를 추가하는 것도 위험을 줄이는 데 도움이 됩니다. 다만 접근 제어 역시 PHP 패치를 대신하는 조치는 아닙니다.
6. 컨테이너 환경에서 추가로 확인할 항목
워드프레스 관리자 화면에 표시된 버전을 확인한 다음에는 NAS에서 실제로 실행 중인 컨테이너도 확인하는 것이 좋습니다.
컨테이너 환경에서는 이미지 태그와 실제 실행 중인 이미지가 중요합니다. 이미지 태그만 최신으로 바꿨다고 해서 현재 실행 중인 컨테이너의 PHP가 자동으로 교체되는 것은 아닙니다.
제가 추가로 확인할 항목은 다음과 같습니다.
- 워드프레스 컨테이너가 사용하는 실제 이미지 이름과 태그
- 컨테이너 내부에서 실행 중인 PHP 버전
- 해당 이미지에 적용된 PHP 보안 패치
- 수정된 이미지가 있다면 안전한 백업 후 업데이트 및 컨테이너 재생성
- 업데이트가 끝난 뒤 워드프레스 관리자 화면에서 PHP 버전 재확인
세 사이트 모두 현재 관리자 화면에서는 PHP 8.3.36으로 확인됐습니다. 다만 실제 이미지 태그와 이미지 빌드 정보는 별도로 확인해야 하므로, 확인하지 않은 이미지 업데이트나 컨테이너 재생성까지 완료했다고 볼 수는 없습니다.
7. 임시 완화 설정은 패치의 대안이 아니다
공식 보안 공지에는 즉시 업데이트하기 어려운 환경을 위한 일부 완화 방법도 안내돼 있습니다. 하지만 이런 설정은 특정 공격 경로를 줄이는 임시 조치이며 취약점을 완전히 해결하지는 못합니다.
CVE-2026-109618 관련
PHP 공식 보안 공지는 업데이트가 당장 불가능한 환경에서 관리자가 강제하는 memory_limit=-1 설정을 주요 구성상 완화 방법으로 안내합니다. 다만 이것은 PHP의 요청당 메모리 제한을 없애는 설정이므로 자원 고갈 위험을 키울 수 있습니다. 또한 다른 메모리 할당 실패 경로까지 완전히 막는 방법은 아닙니다.
개인 NAS라고 해서 이 설정을 무조건 적용하는 것은 권하지 않습니다. 메모리 제한을 제거했을 때의 영향을 이해하고 운영 환경에 맞는 자원 제한을 검토해야 합니다.
post_max_size, 입력 변수 개수, multipart 요청의 크기와 헤더 개수 등에 대한 제한 역시 공격 노출을 줄이는 데 도움이 될 수 있습니다. 그러나 PHP를 수정 버전으로 교체하는 조치를 대신할 수는 없습니다.
CVE-2026-109619 관련
공식 보안 공지는 확인된 세션 업로드 진행률 관련 공격 경로를 차단하기 위한 설정으로 session.upload_progress.enabled=0을 안내합니다. 이 설정 역시 모든 가능한 공격 경로를 해결하는 것은 아닙니다. 설정이 요청 처리 초기 단계에 적용되는지 확인해야 하며 PHP 작업 프로세스도 재시작해야 할 수 있습니다.
PHP 8.5에서 언급된 fatal_error_backtraces=0 설정은 특정 fatal backtrace 경로에 대한 완화 방법입니다. 제가 운영하는 환경은 PHP 8.3.36이므로 이 설정을 PHP 8.3의 일반적인 해결책처럼 적용해서는 안 됩니다.
결론적으로 임시 완화 설정을 여러 개 적용하는 것보다 수정 버전으로 업데이트하고 적용 여부를 확인하는 것이 우선입니다. PHP 공식 보안 공지도 두 취약점을 완전히 해결하는 방법은 수정 버전으로 업데이트하는 것이라고 명시합니다.
8. 개인 NAS 워드프레스 보안 점검 체크리스트
이번 점검을 통해 개인 NAS에서 워드프레스를 운영한다면 다음 항목을 함께 확인하는 것이 좋겠다고 정리했습니다.
- 운영 중인 워드프레스 사이트마다 PHP 버전을 확인했는가?
- PHP SAPI와 웹 서버 구성을 확인했는가?
- 실제 실행 중인 컨테이너 이미지와 태그를 확인했는가?
- 수정된 PHP 이미지가 필요한 경우 백업과 업데이트 절차를 준비했는가?
- 업데이트 후 실제 PHP 버전을 다시 확인했는가?
- Cloudflare Tunnel을 통해 공개된 호스트네임과 외부 접근 범위를 확인했는가?
- 워드프레스 코어와 플러그인도 최신 보안 업데이트 상태인지 확인했는가?
- 업데이트 전에 복구할 수 있는 백업이 있는가?
이번에는 세 사이트 모두 PHP 8.3.36으로 표시되는 것을 확인했습니다. 그렇더라도 PHP 버전만 보고 전체 서버의 보안 상태가 완벽하다고 판단할 수는 없습니다. 컨테이너 이미지와 실제 실행 환경, 외부 접근 범위, 워드프레스와 플러그인까지 함께 점검해야 합니다.
개인 NAS는 직접 운영하는 만큼 설정과 업데이트를 스스로 관리해야 합니다. 평소에 정상 운영되고 있던 사이트라도 보안 공지가 나오면 실제 버전부터 확인하고, 수정 버전 적용 여부를 검증하는 습관을 들이는 것이 중요하겠습니다.