PHP2Shell 보안 취약점, 워드프레스 업데이트만으로는 부족한 이유와 패치 확인법

워드프레스를 최신 버전으로 업데이트했는데도 서버 보안 패치를 따로 확인해야 하는 일이 생겼습니다. 2026년 10월 21일 공개된 PHP2Shell은 워드프레스를 실행하는 PHP 자체의 취약점입니다. 조건이 맞으면 로그인하지 않은 외부 공격자가 서버에서 코드를 실행할 수 있어, PHP 사용 여부와 수정 버전 적용 상태를 먼저 확인해야 합니다. 워드프레스 공식 공지도 사이트 운영자에게 PHP 업데이트를 촉구했습니다.

이번 사건은 AI가 오래된 소프트웨어의 취약점을 찾아내고 실제 공격 가능성을 입증한 사례로도 주목받았습니다. 다만 AI가 취약점 연구에 쓰였다는 사실과 관측된 모든 공격이 AI로 실행됐다는 주장은 구분해야 합니다.

운영자가 먼저 챙길 세 가지

• 워드프레스 관리자에서 실제 PHP 버전을 확인하고 호스팅사에 패치 적용 여부를 묻습니다.
• Cloudflare WAF를 사용해도 서버 PHP 업데이트를 진행합니다.
• 공개 전 공격 시도 보고가 있으므로 패치와 과거 로그 점검을 함께 진행합니다.

목차

1. PHP2Shell은 무엇이 문제인가
2. AI는 발견과 공격에 어떻게 연결되나
3. Cloudflare의 보호 범위와 한계
4. 수정 버전과 구형 PHP 대응
5. 워드프레스 운영자의 확인 순서
6. 패치 후에도 점검할 침입 흔적
7. 워드프레스 밖의 숨은 PHP까지

PHP2Shell, 플러그인 하나를 지우면 해결되는 문제일까요?

문제는 PHP 실행 환경의 메모리 처리에 있습니다. PHP는 웹사이트의 요청을 처리하면서 메모리를 확보하고 정리하는데, 오류가 발생하는 특정 순간에 불완전한 데이터나 이미 해제된 메모리를 다시 사용할 수 있습니다. 이번에 공개된 두 식별자는 CVE-2026-109618과 CVE-2026-109619입니다. 두 건 모두 CVSS 4.0 기준 10점 만점에 9.2점인 치명적 등급으로 공지됐습니다.

취약점	PHP 공식 설명을 쉽게 풀면	핵심 위험
CVE-2026-109618	메모리 부족 오류로 처리가 중단된 뒤 불완전한 내부 데이터를 정리 과정에서 사용	메모리 손상 및 원격 코드 실행
CVE-2026-109619	이전 요청의 해제된 메모리를 가리키는 상태가 남아 같은 작업 프로세스의 다음 요청에 사용	해제 후 사용과 원격 코드 실행

세부 원인과 조건은 PHP 보안팀의 메모리 부족 오류 공지와 남아 있는 전역 상태 공지에 나뉘어 있습니다. 모든 서버에서 똑같은 공격이 성립한다는 뜻은 아니지만, PHP 공식 권고는 웹 요청을 처리하는 PHP 환경 전체를 점검 대상으로 봅니다.

특히 Apache의 mod_php 방식은 애플리케이션 코드가 실행되기 전에 공격할 수 있는 사례가 입증돼 위험도가 높다고 PHP가 설명했습니다. PHP-FPM, php-cgi, FrankenPHP, LiteSpeed를 쓴다는 이유로 점검에서 제외해서도 안 됩니다. PHP 보안 권고

Wiz는 최신 워드프레스·Drupal·Joomla 컨테이너를 대상으로 인증 없는 원격 코드 실행을 시연했고, 별도로 PHP 프로세스 메모리에서 정보를 읽는 공격도 입증했다고 밝혔습니다. 즉, 서버 장악뿐 아니라 메모리에 남아 있는 비밀번호·토큰·API 키 노출도 살펴야 합니다. 이는 연구진의 시연 결과이며 모든 운영 사이트의 침해가 확인됐다는 의미는 아닙니다. Wiz 연구 결과

AI가 공격했다는 이야기, 어디까지 확인됐을까요?

확인된 핵심은 AI가 취약점 발견과 공격 가능성 검증을 도왔다는 것입니다. OpenAI는 Patch the Planet 프로젝트에서 Calif가 GPT-5.6 Sol을 사용해 치명적 결함을 발견했고, Wiz도 독립적으로 두 취약점을 발견해 보고했다고 설명했습니다. 패치 개발과 릴리스는 PHP 유지보수팀이 이끌었습니다. OpenAI의 공동 대응 설명

Calif의 설명에는 앞선 연구의 흔적도 나옵니다. 관련 메모리 부족 문제는 2020년 버그 보고와 2024년 감사에서도 다뤄졌지만, 당시에는 악용 가능성이 입증되지 않았다고 합니다. 오래된 오류를 찾는 것에서 그치지 않고 실제 원격 코드 실행까지 연결하는 난도가 이번 연구의 중요한 부분입니다. Calif의 발견 경위

따라서 이 사건을 “AI가 갑자기 PHP에 구멍을 만들었다”라고 이해하면 원인과 순서가 달라집니다. 오래된 코드에 있던 문제가 AI를 활용한 연구로 구체적인 보안 위험으로 드러났고, 공개 전후로 공격 시도도 관측됐습니다.

AWS는 보안 정보를 공개한 뒤 공격 도구가 만들어지기까지의 시간이 줄어드는 배경으로 AI를 이용한 분석을 지목했습니다. 다만 관측된 각 공격자의 도구 제작 방식이 모두 밝혀진 것은 아닙니다. “AI를 이용한 공격 개발이 쉬워졌다”와 “이번 공격은 전부 AI가 자동 실행했다”는 별개의 주장입니다. AWS 위협 분석

Cloudflare를 쓰면 PHP 패치는 건너뛰어도 될까요?

Cloudflare도 PHP 패치를 적용하라고 권고합니다. 웹 애플리케이션 방화벽인 WAF는 서버 앞에서 공격 트래픽을 차단하는 방어 계층이고, 취약한 PHP 실행 파일을 고치는 것은 서버 업데이트입니다.

Cloudflare는 10월 21일 03:02 UTC, 한국 시간으로 낮 12시 2분부터 무료·유료 WAF 사용 고객에게 PHP2Shell 보호를 기본 적용했다고 밝혔습니다. 공격 트래픽과 탐지 우회를 시도하는 페이로드 변형도 관측했다고 설명했습니다. 이 관측을 개별 사이트의 침해 성공 건수로 바꿔 읽어서는 안 됩니다. Cloudflare 공식 발표

대응 방식도 눈에 띕니다. Cloudflare는 들어오는 요청만으로 공격을 구별하기 어려운 경우를 위해, 같은 HTTP 통신에서 요청과 서버 응답을 함께 분석하는 탐지를 도입했다고 합니다. 알려진 공격에 대한 보호가 추가됐다는 뜻이지, 원본 서버의 취약점 자체가 사라졌다는 뜻은 아닙니다.

WAF는 앞단에서 트래픽을 검사하고, 이번 보안 패치는 워드프레스를 실행하는 PHP 계층에 적용합니다.

개념 참고: Cloudflare, WordPress 공식 공지.

운영자는 사용 중인 도메인의 실제 트래픽이 WAF를 통과하는지, 보호 규칙을 건너뛰는 예외가 있는지, 원본 서버의 PHP가 수정됐는지를 각각 확인하는 편이 좋습니다. Cloudflare의 10월 21일 WAF 변경 이력에는 유료 관리 규칙과 무료 규칙에 각각 추가된 탐지 항목도 공개돼 있습니다.

PHP 보안 패치, 어느 버전부터 해결됐나요?

이번 두 취약점을 수정한 공식 릴리스는 PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12입니다. 버전 숫자는 같은 계열 안에서 비교해야 합니다. 예를 들어 PHP 8.4라는 큰 버전이 같아도 8.4.26은 이번 수정 버전보다 이전입니다. KISA도 다음 기준으로 업데이트를 권고했습니다.

사용 계열	영향받는 버전	이번 수정이 포함된 버전
PHP 8.2	8.2.35 미만	8.2.35 이상
PHP 8.3	8.3.36 미만	8.3.36 이상
PHP 8.4	8.4.27 미만	8.4.27 이상
PHP 8.5	8.5.12 미만	8.5.12 이상

출처: KISA 「PHP 제품 보안 업데이트 권고」. 운영체제나 호스팅 공급자가 기존 버전에 보안 수정을 이식한 패키지를 제공하는 경우에는 해당 공급자의 공지로 수정 여부를 판단해야 합니다.

PHP 8.1 이하라면 별도 확인이 필요합니다

PHP 8.1 이하는 PHP 프로젝트의 공식 보안 지원이 끝났습니다. 다만 “구형 버전에는 어떤 패치도 없다”라고 단정할 수는 없습니다. 배포판이나 장기 지원 업체가 수정 패키지를 제공할 수 있고, PHP 보안팀도 소스 빌드 등을 돕기 위한 PHP 7.4·8.0·8.1 최소 소스 백포트를 공개했습니다. 이것이 구형 계열의 정규 지원 재개를 뜻하지는 않습니다. PHP의 구형 버전 안내

공유 호스팅 이용자라면 직접 소스를 빌드하기보다 업체가 두 CVE를 수정했는지 확인하고, 지원 버전으로 옮기는 계획을 세우세요. PHP 8.2도 2026년 12월 31일 지원 종료 예정이므로 장기 운영 계획에는 다음 버전 전환을 함께 넣는 편이 좋습니다. Automattic의 버전 전환 안내

워드프레스 운영자는 이 순서로 확인하세요

먼저 워드프레스 관리자에서 실제 웹사이트가 사용하는 PHP 버전을 확인하고, 그 실행 환경을 관리하는 주체에게 패치를 요청하면 됩니다. 워드프레스 공식 팀은 이번 문제를 해결하기 위한 별도 워드프레스 업데이트가 필요하거나 예정돼 있지는 않다고 밝혔습니다. WordPress 공식 안내

1. 관리자 → 도구 → 사이트 건강 → 정보 → 서버에서 PHP 버전을 확인합니다. 호스팅 관리 화면에도 버전이 표시될 수 있습니다.
2. 호스팅사 공지에서 CVE-2026-109618과 CVE-2026-109619 둘 다 수정 대상에 들어 있는지 확인합니다. “보안 강화 완료”라는 일반 문구만으로 판단하기 어렵다면 구체적으로 문의합니다.
3. 직접 서버를 운영한다면 배포판·저장소의 수정 패키지를 적용하고, 웹 요청을 처리하는 프로세스가 새 코드를 사용하도록 반영합니다. 여러 PHP 버전과 컨테이너가 있으면 각각 확인합니다.
4. 적용 후 웹사이트에서 사용하는 버전을 다시 확인하고 로그인·글쓰기·이미지 업로드·결제 등 주요 기능을 점검합니다.

네덜란드 NCSC도 제3자 이미지, 장비에 포함된 PHP, 내장 실행 환경을 따로 확인하라고 권고했습니다. 터미널의 php -v 한 번만 보고 전체 조치가 끝났다고 판단하기보다, 실제 웹 요청을 받는 환경과 대조해야 합니다. NCSC-NL 운영 대응 자료

호스팅사에 보낼 확인 문구

제 사이트의 웹 요청을 처리하는 PHP에 CVE-2026-109618과 CVE-2026-109619 수정이 모두 적용됐는지 확인 부탁드립니다. 적용된 PHP 또는 벤더 패키지 버전, 적용 시각, 필요한 프로세스 재시작 완료 여부를 알려 주세요. 별도 PHP 버전이나 컨테이너에도 추가 조치가 필요한지 확인 부탁드립니다.

WordPress.com 이용자도 같은 작업을 해야 하나요?

Automattic은 자사가 호스팅하는 WordPress.com, WordPress VIP, WP Cloud, Pressable, Tumblr 사이트는 이미 보호되고 있으며 이용자가 별도로 할 일이 없다고 발표했습니다. 이 안내는 해당 업체의 관리형 서비스에 관한 것입니다. 워드프레스 프로그램을 내려받아 다른 호스팅에 설치한 사이트라면 그 호스팅사의 대응을 확인해야 합니다. Automattic 보호 현황

당장 패치할 수 없다면요?

ENISA 등 유럽 기관은 인터넷에 노출된 시스템을 우선 패치하고, 즉시 조치하기 어렵다면 수정할 때까지 공개 네트워크에서 격리하는 방안을 검토하라고 권고했습니다. 유럽 기관 공동 성명, 영국 NCSC 권고

설정값 하나를 바꾸고 끝내는 대응에는 한계가 있습니다. PHP 공식 공지에는 임시 완화 방법이 나와 있지만 완전한 해결책이 아니라고 명시돼 있습니다. 업로드나 메모리 관련 설정 변경은 사이트 기능·자원 사용에 영향을 줄 수 있으므로 서버 관리자와 검토하고, 패치 또는 노출 차단 결정을 미루는 근거로 삼지 마세요. PHP 임시 완화책의 한계

패치했으면 끝? 공개 전 공격 시도도 확인됐습니다

업데이트는 앞으로의 취약점 악용을 막는 조치이고, 이미 침입했는지를 확인하는 작업은 따로 필요합니다. AWS는 MadPot 허니팟에서 10월 17일의 PHP2Shell 공격 시도를 찾았다고 밝혔습니다. 이는 10월 21일 공개보다 나흘 빠릅니다.

AWS는 익명화 네트워크를 이용한 접근과 공개 전후 추가 시도를 설명하면서, 해당 시도들이 실제 운영 환경에서 성공했을지는 불명확하다고 덧붙였습니다. 그러므로 “공개 전 시도가 있었다”는 근거를 “이미 모든 PHP 서버가 뚫렸다”는 결론으로 확대해서는 안 됩니다. AWS의 최초 관측과 확인 한계

공격 시도는 패치 공개보다 먼저 관측됐습니다. 사이트 운영자는 공개 날짜 이전의 로그까지 살펴야 합니다.

개념 참고: AWS, Cloudflare, ENISA. 시각 표시는 한국 시간 기준.

ENISA는 수정 버전이 10월 21일 13:40 UTC에 배포됐다고 설명했습니다. 한국 시간으로는 밤 10시 40분입니다. 사전 공지의 예정 시각인 14:00 UTC, 한국 시간 밤 11시와 구분해야 합니다. 수정 버전 배포 시각

• 웹·프록시 로그: AWS 권고에 따라 적어도 10월 17일부터의 기록을 살펴보고, 의심스러운 POST 요청과 평소와 다른 접근 흐름을 확인합니다.
• PHP 오류와 프로세스: 비정상 multipart 요청 뒤의 메모리 제한 오류, HTTP 500 급증, 잦은 PHP 작업 프로세스 종료를 함께 대조합니다.
• 서버 변경: 예상하지 못한 명령 실행, 새 파일과 파일 변경, 낯선 외부 통신을 확인합니다.

AWS와 Wiz가 제시한 단서들입니다. 단일 오류나 요청 문자열만으로 침해를 확정할 수는 없습니다. 반대로 오류가 보이지 않는다는 이유만으로 안전하다고 결론내리기도 어렵습니다. 의심 흔적이 있다면 로그를 보존하고 호스팅사나 보안 담당자에게 조사를 요청하세요. AWS 조사 지침, Wiz의 탐지 단서

워드프레스가 아니어도 놓치면 안 되는 곳

점검 대상은 인터넷에 공개된 블로그만이 아닙니다. ENISA와 네덜란드 NCSC는 PHP를 내부에 포함한 소프트웨어·장비도 영향을 받을 수 있다고 설명합니다. 오래된 외주 홈페이지, 테스트용 서브도메인, 관리 화면, 컨테이너 이미지처럼 운영자가 평소 PHP를 의식하지 않는 곳부터 목록으로 만들어 확인할 필요가 있습니다. PHP 내장 제품과 운영 자료

Drupal, Joomla, Magento 같은 PHP 기반 제품도 애플리케이션의 이름만 보고 안전 여부를 판단할 수 없습니다. 장비나 서비스에 PHP가 묶여 제공된다면 해당 제품 공급자의 패치를 확인해야 합니다. 그렇다고 임의로 장비 안의 PHP 파일을 교체하기보다는 공급자가 지원하는 업데이트 경로를 따라야 합니다.

“전 세계 웹사이트 약 70%”라는 표현도 감염률로 읽으면 안 됩니다. 관련 발표가 PHP의 광범위한 사용을 설명하며 인용한 비율이지, 그만큼의 사이트가 해킹됐다는 집계가 아닙니다. 개별 사이트의 노출 여부는 PHP 버전·설정·배치 방식과 패치 상태로 확인해야 합니다. Cloudflare의 영향 범위 설명

이번 사건에서 남는 질문은 단순합니다. 내 사이트를 실제로 실행하는 PHP는 누가 관리하며, 두 취약점의 수정이 적용됐다는 근거가 있는가? 호스팅사의 답변과 실행 환경의 버전을 확인하고, 공개 전 로그까지 살피는 것이 운영자가 할 수 있는 구체적인 대응입니다.

공식 자료를 더 확인하려면

• 버전·기술 조건: PHP 공식 보안 권고, KISA 업데이트 권고
• 발견과 공동 대응: OpenAI, Calif, Wiz, PHP Foundation
• 워드프레스 운영: WordPress.org, Automattic
• 방화벽과 공격 관측: Cloudflare, AWS
• 기관 대응과 내장 제품 목록: ENISA, NCSC-NL