PHP 취약점: PHP2Shell 패치와 PHP 버전 확인 (워드프레스)

테스트 환경 RHEL 계열AlmaLinux 9.8PHP 8.3 · WordPress 7.1.32026-10-22 확인

PHP2Shell은 2026년 10월 21일 패치가 공개된 PHP 취약점 두 건(CVE-2026-109618·CVE-2026-109619)의 이름입니다. 로그인하지 않은 요청으로도 서버에서 코드가 실행되는 원격 코드 실행 결함이라, 사이트가 쓰는 PHP 버전을 확인해 패치 버전으로 올리는 일이 먼저입니다. 워드프레스 7.1.3이 올라간 Nginx + Apache 구성 서버에서 사이트 건강으로 PHP 버전을 확인하고 php 패키지만 패치 버전으로 올린 뒤 다시 확인한 과정입니다.

TOC

3mn read

1️⃣ PHP 취약점 PHP2Shell: 결함 원리와 영향 범위

이 결함은 워드프레스 코드가 실행되기 전에 요청을 읽는 PHP 엔진 안에 있어, 플러그인과 테마를 최신으로 유지해도 PHP를 올리지 않으면 그대로 남습니다. CERT-EU 권고 기준으로 두 건 모두 CVSS 9.2점이며, 기술 세부가 공개되어 논의되고 초기 개념 증명 코드도 유통되기 시작했습니다.

CVE-2026-109618은 요청이 메모리 한도(memory_limit)를 넘겨 중단될 때, 절반만 초기화된 요청 데이터를 정리 과정이 정상 데이터로 다루는 결함입니다. CVE-2026-109619는 치명적 오류 뒤 해제된 메모리의 상태가 남아, 같은 워커가 처리하는 다음 요청에서 초기화 전에 다시 쓰이는 결함입니다.

php.net 공지 기준으로 웹 요청을 처리하는 모든 PHP 설치가 대상이며, 그중 Apache mod_php를 가장 위험한 구성으로 보고 있습니다. 로그인 없는 요청 하나가 애플리케이션 코드 실행 전에 공격을 발동하는 시연이 mod_php에서 있었기 때문입니다.

PHP 실행 방식	영향	비고
Apache mod_php	🔴 영향 · 가장 위험	로그인 없는 요청 하나로 애플리케이션 코드 실행 전에 공격이 발동한 시연
PHP-FPM	🔴 영향	—
php-cgi	🔴 영향	—
FrankenPHP	🔴 영향	—
LiteSpeed	🔴 영향	—

패치 버전은 8.2.35와 8.3.36, 8.4.27, 8.5.12이며, 이보다 낮은 8.2~8.5 계열이 모두 영향권에 들어갑니다. PHP 8.1 이하는 PHP 프로젝트의 지원이 끝난 계열이라 공식 패치 버전이 없고, 배포판·호스팅 업체가 옮겨 넣은 고침(백포트)으로 대응합니다.

CISA 10월 21일 공지 시점에는 실제 악용이 확인되지 않았지만, CISA는 패치하지 않은 채 두면 위험하다고 보고 인터넷에 노출된 시스템부터 즉시 패치하라고 권했습니다. CERT-EU는 같은 날 권고에서 개념 증명 코드가 유통되기 시작해 공격자가 이미 악용하고 있을 가능성이 높아졌다고 판단했습니다.

2️⃣ PHP 버전 확인: 사이트 건강 › 정보 › 서버

결함을 알아도 내 사이트가 어느 PHP 버전으로 실행되는지 모르면 할 일이 정해지지 않습니다. 관리자 화면에서 [도구 › 사이트 건강]을 열고 [정보] 탭의 [서버] 구역을 펼치면, [PHP 버전] 줄에 사이트의 요청을 실제로 처리하는 PHP 버전이 표시됩니다.

사이트 건강 정보 탭 화면: 왼쪽 메뉴 도구 › 사이트 건강, 서버 구역의 서버 구조·웹 서버·PHP 버전·PHP SAPI 줄 — PHP 취약점 PHP2Shell 패치 확인 기준인 PHP 버전(워드프레스 7.1.3)

[PHP 버전] 줄 바로 아래 [PHP SAPI] 줄은 PHP 실행 방식을 표시하며, fpm-fcgi는 PHP-FPM 구성입니다. 결함이 요청을 읽는 PHP 엔진 안에 있어 이 구성도 대상이며, php.net 공지는 그중 Apache mod_php를 가장 위험한 구성으로 꼽았습니다. 여기서는 [서버] 구역의 [PHP 버전]·[PHP SAPI] 두 줄만 봅니다.

🧩 PHP2Shell 공격 흐름

설명 다이어그램

①로그인 없는 요청누구나 보낼 수 있는 웹 요청

②특별하게 만든 요청PHP가 워드프레스 코드보다 먼저 읽음

③PHP 결함메모리 부족 → 덜 만든 데이터를 그대로 씀CVE-2026-109618끝난 요청의 상태를 다음 요청이 씀CVE-2026-109619

④서버에서 코드 실행사이트 장악

✅ 패치 버전에서는 이 흐름이 막힘8.2.35 · 8.3.36 · 8.4.27 · 8.5.12

공격은 로그인 없는 요청으로 시작합니다. 특별하게 만든 요청을 PHP가 워드프레스 코드보다 먼저 읽는 단계에서 두 결함 중 하나를 건드리고, 서버에서 코드 실행으로 이어집니다. 패치 버전은 이 흐름을 막으므로, 할 일은 사이트의 PHP를 패치 버전 이상으로 올리는 것입니다.

터미널의 [php -v]는 명령줄 기본 PHP의 버전만 표시합니다. cPanel의 EA-PHP나 CloudLinux의 alt-php처럼 한 서버에 PHP를 여러 버전 설치하는 구성에서는 사이트가 쓰는 버전과 다를 수 있습니다. 그래서 기준은 사이트 건강의 [PHP 버전] 값으로 둡니다.

php -v

PHP 8.3.xx (cli) (built: Jun  3 2025 17:17:57) (NTS gcc x86_64)

관리자 화면에 들어갈 수 없는 서버에서는 웹 요청을 처리하려고 실행 중인 PHP-FPM 프로세스로 사이트가 쓰는 버전을 찾습니다. Debian·Ubuntu 패키지는 FPM 마스터가 읽은 설정 파일 경로에 버전 숫자가 들어 있으며, 아래는 한 관리형 호스팅의 Debian 12 테스트 서버에서 확인한 결과입니다.

ps -eo user,args | grep '[p]hp-fpm'

root     php-fpm: master process (/etc/php/8.2/fpm/php-fpm.conf)
abcdefg+ php-fpm: pool abcdefghij-82
klmnopq+ php-fpm: pool klmnopqrst-82

설정 경로의 8.2가 이 서버에서 사이트가 쓰는 PHP 버전이며, 이 호스팅은 풀 이름 끝(-82)에도 버전 숫자를 붙입니다. 켜져 있는 FPM 서비스가 실행한 파일은 [systemctl status]의 [Main PID] 줄에서도 확인할 수 있으며, root 계정이 아니어도 표시됩니다.

systemctl status php8.2-fpm --no-pager | head -6

● php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.2-fpm.service; enabled; preset: enabled)
     Active: active (running) since Thu 2026-10-22 07:14:57 UTC; 7h ago
       Docs: man:php-fpm8.2(8)
    Process: <PID> ExecStartPost=/usr/lib/php/php-fpm-socket-helper install /run/php/php-fpm.sock /etc/php/8.2/fpm/pool.d/www.conf 82 (code=exited, status=0/SUCCESS)
   Main PID: <PID> (php-fpm8.2)

AlmaLinux 같은 RHEL 계열 배포판의 기본 패키지는 마스터 설정 경로가 /etc/php-fpm.conf라 버전 숫자가 나오지 않으며, 이때는 [rpm -qf /usr/sbin/php-fpm]으로 FPM 패키지의 버전을 확인합니다.

3️⃣ PHP 8.2 미만이면: 호스팅에 백포트 적용을 확인하고 없으면 요청

사이트 건강의 [PHP 버전]이 8.2 미만(7.x·8.0·8.1)이면 php.net의 공식 패치 버전이 없습니다. php.net 지원 버전 표(2026년 10월 22일 확인) 기준으로 지원 중인 계열은 8.2·8.3·8.4·8.5 넷뿐이고, 8.1 이하 공식 버전에는 보안 패치가 나오지 않습니다.

PHP 계열	패치 버전	보안 지원 끝
8.2	8.2.35	2026년 12월 31일
8.3	8.3.36	2027년 12월 31일
8.4	8.4.27	2028년 12월 31일
8.5	8.5.12	2029년 12월 31일
8.1 이하	공식 버전 없음 · 배포판·호스팅 백포트	끝남

8.2 계열은 2026년 12월 31일에 보안 지원이 끝나므로, 지금 올린다면 8.3 이상을 선택합니다.

대신 배포판·호스팅 업체가 버전 숫자를 그대로 둔 채 고침만 옮겨 넣은 패키지(백포트)를 내는 경우가 있습니다. 한 관리형 호스팅 테스트 서버의 7.4.33·8.0.30·8.1.34 패키지가 그 예입니다. 변경 기록에 [Backported from 8.2.35 — CVE-2026-109618, CVE-2026-109619] 줄이 들어 있었습니다.

버전 숫자가 같아도 고침이 들어 있는지는 패키지 변경 기록에서 CVE 번호를 찾아 확인하며, 줄이 나오면 고침이 들어간 패키지입니다. Debian·Ubuntu 계열은 아래처럼 찾고, 경로의 버전 숫자는 사이트가 쓰는 버전에 맞춥니다.

zcat /usr/share/doc/php8.2-cli/changelog.Debian.gz | grep 109618

   + (CVE-2026-109618, CVE-2026-109619): Avoid state corruption via

RPM 계열은 아래 명령으로 찾습니다.

rpm -q --changelog php-common | grep 109618

그래서 8.2 미만이면 먼저 호스팅 업체에 백포트가 적용되었는지 확인하고, 적용되지 않았거나 확인이 안 되면 지원 버전으로 올려 달라고 요청합니다. 올린 뒤에는 사이트 건강의 [PHP 버전] 값으로 다시 확인합니다.

CISA는 8.1 이하를 쓰는 조직이 바로 업데이트할 수 없다면 패치나 업그레이드 전까지 PHP 기반 시스템을 오프라인으로 두라고 권했습니다.

서버를 직접 운영하면서 8.1 이하를 쓴다면 배포판의 백포트 패키지를 받거나 PHP 보안팀이 낸 7.4·8.0·8.1용 소스 패치를 적용할 수 있습니다. 그래도 지원이 끝난 계열이므로 지원 버전으로 올리는 것이 근본 대응입니다.

4️⃣ PHP 8.2 이상이면: 패치 버전으로 업데이트하고 다시 확인

8.2 이상인데 패치 버전보다 낮다면 PHP 자체를 올립니다. 관리형·공유 호스팅은 업체가 서버 전체에 패치를 적용하므로 업체 공지나 문의로 적용 여부와 빌드를 확인하고, 사이트 건강의 [PHP 버전]이 바뀌었는지 봅니다. 클라우드웨이즈는 상태 페이지 공지에서 10월 21일 22:19 UTC에 PHP 5.6·7.4·8.0~8.4의 패치를 적용 중이라고 알렸고, 10월 22일 10:11 UTC에는 적용이 끝났다고 밝혔습니다.

🪐참조PHP2Shell 2

📡[긴급] 웹사이트 70% 쓰는 PHP 비상｜취약점 및 당장 할일 정리 🌌Cloudways 관리형 호스팅

직접 운영하는 서버는 php.net 공지대로 배포판·LTS 업체 저장소의 패키지로 올립니다. 업데이트 전에 미리 보기로 바뀔 패키지 목록을 확인해 php로 시작하는 패키지만 올라가고 다른 패키지가 딸려 오지 않는지 보고, 운영체제의 다른 업데이트와 섞지 않습니다.

dnf upgrade --assumeno 'php*'

종속성이 해결되었습니다.
================================================================================
 꾸러미        구조    버전              저장소   크기
================================================================================
향상 중:
 php           x86_64  8.3.xx-1.…        …       1.9 M
 php-cli       x86_64  8.3.xx-1.…        …       5.6 M
 php-common    x86_64  8.3.xx-1.…        …       1.3 M
 php-fpm       x86_64  8.3.xx-1.…        …       1.9 M
 (php-gd · php-intl 같은 확장 패키지 줄 생략)

연결 요약
================================================================================
향상  xx 꾸러미

dnf upgrade 'php*'

향상되었습니다:
  php-8.3.xx-1.….x86_64
  php-cli-8.3.xx-1.….x86_64
  php-common-8.3.xx-1.….x86_64
  php-fpm-8.3.xx-1.….x86_64
  (확장 패키지 줄 생략)

완료되었습니다!

이번 실측에서는 php로 시작하는 패키지만 패치 버전으로 올라갔고, 패키지 설치가 끝나면서 php-fpm이 스스로 다시 시작되었습니다. 패치 버전은 php-fpm 워커가 다시 시작되어야 적용되므로, 자동 재시작이 없는 환경이면 [systemctl restart php-fpm]을 직접 실행합니다.

올린 뒤에는 [php -v]와 사이트 건강 [정보] 탭의 [PHP 버전] 줄이 모두 패치 버전 이상인지 보고, php-fpm 서비스 상태와 사이트 응답까지 확인합니다. 명령줄 값만 바뀌고 [PHP 버전] 값이 그대로면 php-fpm을 다시 시작한 뒤 다시 확인합니다.

사이트 건강 정보 탭 화면: 업데이트 뒤 서버 구역의 PHP 버전 줄이 패치 버전 이상인지 다시 확인 — 왼쪽 메뉴 도구 › 사이트 건강, 서버 구역의 PHP 버전·PHP SAPI 줄(워드프레스 7.1.3)

업데이트 뒤에도 같은 [도구 › 사이트 건강]의 [정보] 탭에서 [서버] 구역을 펼쳐 [PHP 버전] 줄을 봅니다. 이 값이 올린 버전으로 바뀌어 있으면 php-fpm 워커까지 새 버전으로 실행되고 있는 것입니다.

php -v

PHP 8.3.xx (cli) (built: Oct 19 2026 14:00:34) (NTS gcc x86_64)

systemctl is-active php-fpm

active

curl -s -o /dev/null -w '%{http_code}\n' 'https://example.com/?r=1'

버전 숫자 자체가 올라가는 패키지는 새 버전 번호로, 버전 숫자를 그대로 둔 백포트 패키지는 변경 기록의 CVE 번호로 패치 여부를 확인합니다. 이번 서버는 전자라 [rpm -q --changelog php-common]에 CVE 번호 줄이 없었고, 변경 기록 첫 줄의 새 버전 번호로 확인했습니다.

5️⃣ 당장 올릴 수 없을 때: php.net이 안내한 임시 조치

바로 올릴 수 없는 서버를 위해 php.net은 아래 설정을 임시 조치로 안내하면서, 이 조치들은 특정 공격 경로만 줄일 뿐 설치를 안전하게 만들지는 않는다고 밝혔습니다. 메모리 한도를 RLIMIT_AS나 RLIMIT_DATA로 대신 걸면 오히려 취약한 할당 실패를 일으킬 수 있어 쓰지 말라고도 적었습니다.

설정	값	어디에	막는 것
memory_limit	-1	FPM 풀·Apache 설정의 php_admin_value(애플리케이션이 되돌리지 못하게)	CVE-2026-109618 · 메모리 한도 실패 경로(완전하지 않음)
post_max_size	8M(업로드가 필요하면 32M) · upload_max_filesize는 그보다 작게	php.ini · 풀 설정	CVE-2026-109618
session.upload_progress.enabled	0 + 모든 워커 재시작	php.ini · FPM 풀 · 서버 설정(ini_set()·.user.ini 불가)	CVE-2026-109619 · 확인된 세션 경로만
fatal_error_backtraces	0 + 모든 워커 재시작(PHP 8.5만)	위와 같음	CVE-2026-109619 · 확인된 역추적 경로만

php_admin_value는 애플리케이션이 되돌릴 수 없는 서버 쪽 설정이라 공유 호스팅 사용자는 직접 바꿀 수 없는 경우가 많고, 이때도 결국 호스팅 업체에 요청하게 됩니다. php.net은 웹 서버나 프록시 단계에서도 요청 본문 크기와 입력 필드 수, multipart 조각 수, 헤더 수, 중첩 깊이에 상한을 두라고 안내합니다.

표의 session.upload_progress.enabled 설정은 10월 23일 php.net 안내에서 한 번 더 권고되었습니다. php.net은 가능성이 낮은 원격 코드 실행 경로(CVE-2026-115560)까지 막기 위해, 다음 정기 버그 수정 버전까지 이 값을 0으로 두라고 권했습니다. 10월 21일 GHSA-6wmf-4rv5-p3rp 권고에 이미 완화책으로 실린 설정이라, 그때 적용했다면 그대로 두면 됩니다.

이 경로는 설정에서 session.serialize_handler를 php_binary나 php_serialize로 둔 애플리케이션이 session_start() 전에 ini_set()으로 php로 바꾸고, 세션 업로드 진행 기능도 켜져 있을 때만 생깁니다. CVE-2026-115560 경로만 놓고 보면, 실행 중에 직렬화 방식을 바꾸지 않는 애플리케이션은 이 기능을 켜 둔 채 사용할 수 있다고 php.net은 밝혔습니다.

🔢 FAQ & 추천 콘텐츠

워드프레스 자동 업데이트는 코어와 플러그인, 테마, 번역만 다루며, PHP는 서버에 설치된 프로그램이라 서버 관리자나 호스팅 업체가 올립니다. 코어·플러그인·테마 자동 업데이트는 워드프레스 업데이트 화면과 플러그인·테마 화면에서 각각 켜며, 그 화면들에 PHP 버전은 나오지 않습니다.

전체 기술 세부는 php.net 공지가 CVE 번호 옆에 연결한 GitHub 보안 권고 둘에 있습니다. CVE-2026-109618은 GHSA-w8hw-w9fx-j79w, CVE-2026-109619는 GHSA-6wmf-4rv5-p3rp입니다. CERT-EU 권고도 같은 두 권고를 참고 문헌으로 들고 있으며, 공격 재현 세부는 이 글에 넣지 않았습니다.

CISA는 PHP 워커 프로세스가 셸을 띄우거나 도구를 내려받는 움직임을 감시하라고 안내합니다. 패치 전까지는 웹 애플리케이션 방화벽이 어느 정도 보호가 될 수 있다고도 적었습니다. PHP는 다른 소프트웨어의 부품으로 들어가 눈에 띄지 않는 경우가 많으므로, PHP가 실행되는 시스템부터 목록으로 만들라고 권했습니다.

보안 wp-config.php 보안 취약점 wp-config.php 파일의 노출을 막고 보안 설정을 강화하는 방법입니다.

보안 워드프레스 XML-RPC xmlrpc.php 공격을 로그로 판별하고 비활성화하는 세 가지 방법입니다.

서버 php-fpm max_children 경고 워커를 늘리기 전에 로그로 경고의 원인을 가려내는 실측입니다.

🪐참조PHP2Shell 7

📡PHP: Security advisory — Critical remote code execution vulnerabilities, update now (2026-10-21) 📡PHP: Informational advisory — Session upload progress (2026-10-23) 📡CISA: Critical Vulnerabilities in PHP Require Immediate Patching (2026-10-21) 📡CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP 📡GitHub 보안 권고 GHSA-w8hw-w9fx-j79w (CVE-2026-109618) 📡GitHub 보안 권고 GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) 🛰️Sansec: PHP2Shell — PHP RCE (CVE-2026-109618, CVE-2026-109619)

ℹ️ 제휴 안내
본 사이트의 콘텐츠에는 제휴 링크가 포함되어 있습니다. 방문자가 이 링크를 통해 상품 또는 서비스를 구매하면 본 사이트는 판매처로부터 수수료를 지급받습니다. 이 과정에서 구매자가 지불하는 금액^{(이벤트 할인 시 금액이 내려갑니다↓)}은 오르지 않습니다. 게시된 가격·할인·재고 정보는 작성 시점 기준이며 실제와 다를 수 있으므로, 구매 전 판매처에서 최종 확인하시기 바랍니다. 상품 선정과 평가는 자체 기준에 따라 작성되며, 수수료 지급 여부가 소개 순서나 평가 내용에 영향을 주지 않습니다.