PHP2Shell 보안 취약점 정리: 영향 버전과 워드프레스 대응 방법

·설명 약 10분·작성: 해비·블로그 소개

PHP2Shell 보안 취약점과 업데이트 대응을 표현한 서버, 방패, 작은 곰 일러스트
PHP2Shell 취약점의 영향 범위와 업데이트 대응을 다룹니다. AI 제작 설명용 표지 이미지.

PHP2Shell 대응의 핵심은 사이트가 사용하는 PHP에 보안 패치가 적용됐는지 확인하는 것입니다. 워드프레스 코어와 플러그인을 최신으로 유지하더라도 PHP 자체의 패치 여부는 별도로 확인해야 합니다. 이 글은 2026년 10월 23일 확인한 공식 자료를 바탕으로, 사이트 운영자가 점검할 순서를 정리했습니다.

지금 확인할 핵심 내용

  • PHP2Shell은 PHP의 두 취약점인 CVE-2026-109618과 CVE-2026-109619를 가리키는 이름입니다.
  • 두 취약점 모두 CVSS 4.0 기준 9.2점(Critical)입니다.
  • 공식 수정 버전은 PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12입니다. 배포판이 보안 패치를 별도로 반영한 패키지도 확인해야 합니다.
  • 공유 호스팅은 서비스사에 적용 여부를 문의하고, 직접 운영하는 서버는 실제 웹 실행 환경과 필요한 서비스 재시작까지 확인해야 합니다.

공개 시점은 2026년 10월 21일 14:00 UTC, 한국 시각으로 같은 날 오후 11시입니다. 공개 일정과 심각도는 Ubuntu의 PHP2Shell 보안 안내에서 확인할 수 있습니다.

PHP2Shell은 어떤 취약점인가요?

PHP는 웹 요청을 받아 데이터를 준비하고, 애플리케이션을 실행한 뒤 사용한 메모리와 상태를 정리합니다. 이번 PHP 보안 취약점은 이 준비·정리 과정에서 내부 데이터가 올바르지 않은 상태로 남을 수 있다는 데 있습니다. 조건이 맞으면 로그인하지 않은 공격자가 원격으로 코드를 실행할 수 있습니다.

CVE-2026-109618: 메모리 부족 처리 문제

메모리가 부족해 요청 처리가 중단될 때, 아직 준비가 끝나지 않은 내부 데이터를 정리 과정에서 정상 데이터처럼 사용할 수 있는 문제입니다. 공식 명칭은 OOM corruption이며, 세부 내용은 PHP의 첫 번째 보안 권고에 설명돼 있습니다.

CVE-2026-109619: 이전 요청의 상태가 남는 문제

앞선 요청에 속한 메모리가 해제된 뒤에도 이를 가리키는 내부 상태가 남고, 같은 작업 프로세스가 다음 요청을 처리할 때 그 상태를 사용할 수 있습니다. 공식 명칭은 stale global state입니다. 요청 사이에 남은 상태가 원인이므로, 단순히 오류 화면을 숨기는 것만으로 해결되지 않습니다. PHP의 두 번째 보안 권고가 이 문제를 다룹니다.

원격 코드 실행의 권한 범위는 기본적으로 PHP 웹 작업 프로세스의 권한입니다. 이것만으로 서버의 root 권한까지 자동으로 얻는다고 단정할 수는 없습니다. 다만 해당 계정이 접근할 수 있는 파일과 서비스에는 영향을 줄 수 있으므로 신속한 패치가 필요합니다.

내 사이트도 영향을 받나요?

워드프레스뿐 아니라 웹 요청을 처리하는 PHP 환경 전반이 점검 대상입니다. PHP-FPM, Apache의 mod_php, CGI 등 실행 방식에 따라 공격 조건과 확인된 경로는 다릅니다. PHP 프로젝트는 특히 mod_php의 위험을 높게 평가하지만, FPM을 쓴다는 이유만으로 안전하다고 판단해서는 안 됩니다. 자세한 범위는 PHP 프로젝트의 긴급 보안 공지를 기준으로 확인해야 합니다.

운영자는 먼저 사이트가 어느 서버에서 어떤 PHP로 실행되는지 파악해야 합니다. 같은 계정에서 여러 사이트를 운영해도 사이트마다 PHP 버전이나 연결된 FPM 풀이 다를 수 있습니다. 관리자 화면에서 선택한 버전, 호스팅 상품의 기본 버전, 실제 요청을 처리하는 버전이 일치하는지도 확인하는 것이 좋습니다.

워드프레스에서는 관리자 화면의 도구 → 사이트 건강 → 정보 → 서버에서 PHP 버전을 확인할 수 있습니다. 이 화면의 정보만으로 배포판의 보안 백포트 여부까지 확인되지는 않으므로, 전체 패키지 버전이나 호스팅사의 적용 안내도 함께 대조합니다. 경로와 표시 정보는 워드프레스 공식 사이트 건강 문서에서 확인할 수 있습니다.

터미널의 php -v는 읽기 전용 확인 방법이지만, 그 결과는 명령줄용 PHP일 수 있습니다. 웹 서버가 연결한 PHP와 다를 수 있으므로 이 출력 하나로 사이트의 패치 완료를 판단하지 마세요. 공개된 진단 페이지를 새로 만드는 대신 호스팅 관리 도구나 서버 설정에서 확인하는 편이 적절합니다.

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

PHP 프로젝트가 발표한 수정 기준은 다음과 같습니다. 직접 받은 PHP 소스나 공식 배포 파일을 사용하는 경우에는 운영 중인 계열의 수정 버전 이상인지 확인합니다. 근거는 PHP 공식 수정 버전 안내입니다.

PHP 계열 공식 수정 버전
8.2 8.2.35
8.3 8.3.36
8.4 8.4.27
8.5 8.5.12

리눅스 배포판은 기존 버전 번호를 유지하면서 보안 수정만 가져오는 백포트를 제공하기도 합니다. 예를 들어 Ubuntu 24.04의 8.3.6-0ubuntu0.24.04.13은 이번 수정이 반영된 패키지입니다. 앞부분의 8.3.6만 보고 미패치라고 판단하면 안 됩니다. Ubuntu의 배포판별 수정 패키지 표처럼 공급업체 공지와 패키지 전체 버전을 함께 대조해야 합니다.

PHP 8.1 이하는 PHP 프로젝트의 일반 지원이 종료된 상태입니다. 이번 사안에서는 PHP 7.4·8.0·8.1용 최소 소스 백포트가 특별히 제공됐지만, 일반 지원이 재개된 것은 아닙니다. 오래된 버전을 유지해야 한다면 계약한 배포판이나 장기 지원 공급업체의 패치 제공 여부를 확인하고, 지원되는 계열로 옮길 계획도 세워야 합니다.

운영 환경별로 대응하기

환경 확인, 패치 확인, 업데이트, 적용 재확인 순서로 진행하는 PHP 보안 업데이트 점검 흐름
환경 확인 → 패치 확인 → 업데이트 → 적용 재확인. 버전 숫자와 배포판 공지를 함께 대조합니다. AI 제작 설명용 이미지.

공유 호스팅·관리형 워드프레스

서비스사에 두 CVE의 수정 적용 여부, 적용한 PHP 패키지 또는 빌드, 내 사이트에 반영된 시점을 문의합니다. “최신 버전을 사용한다”는 답변만으로는 판단하기 어렵습니다. 사이트별 PHP 선택 메뉴가 있다면 선택한 계열에 패치가 적용됐는지 확인하고, 버전을 바꿔야 할 경우 테마와 주요 플러그인의 호환성도 점검합니다.

문의할 때는 “제 사이트가 사용하는 PHP에 CVE-2026-109618과 CVE-2026-109619 수정이 적용됐는지, 적용한 빌드와 반영 시점을 알려주세요”처럼 대상과 확인할 항목을 구체적으로 적으면 됩니다.

VPS·직접 관리 서버

운영체제와 PHP 패키지의 공급처를 먼저 확인합니다. 배포판 기본 저장소인지, 외부 저장소인지, 직접 빌드한 PHP인지에 따라 패치 경로가 달라집니다. 서버 정보를 확인하지 않은 상태에서 인터넷의 업데이트 명령을 그대로 실행하기보다, 해당 공급업체의 보안 공지를 기준으로 작업해야 합니다.

패키지 설치가 끝난 뒤에는 PHP를 실행하는 서비스가 새 구성 요소를 읽도록 필요한 재시작을 진행했는지 확인합니다. 여러 PHP 버전이나 FPM 풀이 있다면 각각 대상에 포함합니다. 운영 변경 전에는 복구 가능한 백업과 작업 시간을 확보하고, 변경 후 주요 기능을 확인할 준비를 해두는 것이 좋습니다.

서버 접속부터 익혀야 한다면 SSH·SFTP·FTP 차이와 서버 접속 기준에서 명령 실행과 파일 전송의 역할을 먼저 확인할 수 있습니다.

Docker·컨테이너

Dockerfile이나 이미지 태그만 수정했다고 실행 중인 서비스가 바뀌지는 않습니다. 패치가 포함된 이미지로 빌드하거나 공급업체의 새 이미지를 확보한 뒤, 실제 컨테이너가 교체됐는지 확인해야 합니다. 여러 복제본을 운영한다면 이전 이미지로 실행되는 인스턴스가 남아 있지 않은지도 점검합니다.

업데이트 후 확인할 항목

  1. 실행 버전: 웹 요청을 처리하는 PHP의 패키지 전체 버전 또는 빌드를 공식 공지와 대조합니다.
  2. 실행 상태: 필요한 서비스 재시작이나 컨테이너 재배포가 완료됐는지 확인합니다.
  3. 사이트 기능: 첫 화면, 로그인, 글 저장, 파일 업로드 등 평소 사용하는 기능을 확인합니다. 결제 기능은 실제 청구가 일어나지 않는 테스트 방식으로 점검합니다.
  4. 오류 기록: 변경 전후의 웹 서버·PHP 오류 로그를 비교해 새 오류가 생겼는지 확인합니다.
  5. 침해 흔적: 알 수 없는 관리자 계정, 예상하지 못한 파일 변경, 수상한 접근 기록이 있다면 패치와 별도로 조사합니다.

패치는 앞으로 취약점이 악용되는 경로를 막기 위한 조치입니다. 이미 생긴 악성 파일이나 계정까지 자동으로 정리해 주지는 않습니다. 반대로 로그에서 눈에 띄는 오류가 없다는 사실만으로 침해가 없었다고 확정할 수도 없습니다. 침해 흔적 점검의 필요성은 영국 NCSC의 PHP 보안 대응 권고도 안내합니다.

자주 묻는 질문

워드프레스와 플러그인만 업데이트하면 되나요?

해당 업데이트도 필요하지만, PHP 보안 패치를 대신하지는 않습니다. 워드프레스 관리 화면에서 업데이트가 모두 끝났더라도 서버 또는 호스팅의 PHP 적용 상태를 따로 확인해야 합니다.

WAF나 설정 변경으로 해결할 수 있나요?

공식 권고는 보안 패치 적용을 완전한 해결책으로 제시합니다. WAF와 요청 제한 같은 조치는 특정 경로의 노출을 줄이는 보조 수단으로 보아야 합니다. 일부 안내에 등장하는 memory_limit=-1도 모든 환경에 그대로 적용할 값은 아닙니다. 메모리 사용과 서비스 안정성에 미칠 영향을 검토하지 않은 채 복사하지 마세요.

사이트가 정상적으로 열리면 안전한가요?

정상 접속은 패치 여부를 보여주지 않습니다. 화면 확인과 함께 실제 PHP 실행 환경, 공급업체의 수정 공지, 패키지 전체 버전, 재시작 또는 재배포 여부를 확인해야 대응 상태를 판단할 수 있습니다.

공식 출처와 확인 범위

확인일은 2026년 10월 23일입니다. 배포판별 패키지와 호스팅사의 적용 현황은 달라질 수 있으므로 실제 작업 시 최신 공지도 확인하시기 바랍니다.

이 글은 공식 권고를 정리한 안내이며, 특정 사이트의 취약 여부를 검사하거나 공격을 재현한 결과는 아닙니다.

이 글이 도움이 되었나요?

조회 중

이 글을 쓴 해비

웹사이트를 제작·운영하고, 개인 서비스와 자동화·AI 도구를 만듭니다. 직접 만들며 배운 내용과 문제 해결 과정을 BlogFlow에 기록합니다.

새 글 받아보기

RSS 리더에서 BlogFlow의 새 글을 확인할 수 있습니다.

RSS 피드 구독하기

댓글 남기기