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

2mn 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 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)

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 이하 공식 판에는 보안 패치가 나오지 않습니다.

대신 배포판·호스팅 업체가 판 숫자를 그대로 둔 채 고침만 옮겨 넣은 꾸러미(백포트)를 내는 경우가 있습니다. 한 관리형 호스팅 테스트 서버의 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] 꼴로 찾습니다. RPM 계열은 [rpm -q --changelog php-common | grep 109618] 꼴이며, 꾸러미 이름의 판 숫자는 사이트가 쓰는 판에 맞춥니다.

그래서 8.2 미만이면 먼저 호스팅 업체에 백포트가 적용되었는지 확인하고, 적용되지 않았거나 확인이 안 되면 지원 판(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~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 조각 수, 헤더 수, 중첩 깊이에 상한을 두라고 안내합니다.

🔢 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 6

📡PHP: Security advisory — Critical remote code execution vulnerabilities, update now (2026-10-21) 📡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)

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