WP2Shell WordPress Core RCE 취약점

들어가며

WordPress 보안 이슈는 보통 플러그인이나 테마에서 많이 발생합니다. 운영자가 오래된 플러그인을 방치했거나, 상용 테마에 취약한 라이브러리가 포함되어 있거나, 관리자 계정이 탈취되는 식의 흐름이 익숙합니다.

그런데 WP2Shell은 결이 다릅니다. 이 이슈는 WordPress Core 자체의 두 취약점을 체인으로 묶어, 인증되지 않은 공격자가 원격 코드 실행(Remote Code Execution, RCE)까지 도달할 수 있는 공격 체인으로 알려졌습니다. 공개 보도와 여러 보안 업체 분석에 따르면, WP2Shell은 CVE-2026-63030과 CVE-2026-60137을 함께 악용하는 형태로 설명됩니다.

이 글에서는 WP2Shell이 어떻게 발견되었고, 어떤 방식으로 악용되고 있으며, 어떤 위협이 있는지, 그리고 WordPress 운영자가 무엇을 확인해야 하는지 정리합니다. 공격 재현을 위한 상세 절차나 악용 코드는 다루지 않습니다. 목적은 방어와 점검입니다.

WP2Shell이란 무엇인가

WP2Shell은 하나의 단일 버그라기보다, WordPress Core의 두 취약점을 연결한 공격 체인으로 보는 것이 적절합니다.

공개 분석에서 언급되는 두 CVE는 다음과 같습니다.

CVE	설명	영향
`CVE-2026-63030`	WordPress REST API batch endpoint의 route confusion 취약점	인증 없는 요청이 의도하지 않은 내부 경로로 전달될 수 있음
`CVE-2026-60137`	`WP_Query`의 `author__not_in` 처리와 관련된 SQL Injection 취약점	데이터베이스 정보 노출 및 체인 구성 시 RCE로 확장 가능

공개된 방어자 가이드와 보안 업체 FAQ를 종합하면, 공격 흐름은 대략 다음과 같이 설명됩니다.

비인증 공격자
  ↓
/wp-json/batch/v1 엔드포인트 접근
  ↓
REST API route confusion
  ↓
WP_Query author__not_in SQL Injection으로 연결
  ↓
DB 정보 추출 또는 조작
  ↓
관리자 계정 생성 / 악성 플러그인 업로드 / 웹셸 배치 등으로 확장
  ↓
WordPress 애플리케이션 권한에서 원격 코드 실행

핵심은 플러그인이나 테마가 없어도 기본 WordPress 설치본이 영향받을 수 있다는 점입니다. 물론 실제 코드 실행 경로에는 환경 조건이 붙습니다. 예를 들어 Eye Security 분석에서는 persistent external object cache, 예를 들면 Redis나 Memcached 같은 외부 객체 캐시 사용 여부가 RCE 체인의 성립 조건에 영향을 줄 수 있다고 설명합니다. 하지만 많은 일반 WordPress 사이트는 기본 구성을 크게 바꾸지 않기 때문에, 운영자 입장에서는 “나는 플러그인을 많이 안 쓰니까 괜찮다”고 판단하면 안 됩니다.

어떻게 발견되었나

공개 자료 기준으로 WP2Shell은 Searchlight Cyber의 Adam Kues가 발견하고 WordPress 측에 보고한 것으로 정리됩니다. Tenable FAQ와 Qualys ThreatPROTECT 글은 Adam Kues가 CVE-2026-63030을 발견·공개했으며, Searchlight Cyber가 초기에는 심각도를 고려해 기술 세부사항을 보류했다고 설명합니다.

타임라인을 간단히 정리하면 다음과 같습니다.

2026-07-17
  - WordPress가 WP2Shell 관련 보안 업데이트 공개
  - Searchlight Cyber가 취약점 존재와 테스트 도구를 공개
  - 상세 exploit 절차는 즉시 공개하지 않음

2026-07-20 전후
  - 여러 보안 업체가 FAQ, 탐지/대응 가이드 공개
  - 공개 PoC가 GitHub 등에 등장
  - CISA KEV에 두 CVE가 추가되었다는 보도 및 업체 분석 확산

2026-08
  - F5 Labs 등에서 센서 기반 exploit payload 관측 내용 공개

흥미로운 점은 Searchlight Cyber의 별도 글 제목에서 “GPT5로 WordPress RCE를 찾았다”는 식의 맥락이 함께 언급된다는 점입니다. 원문 페이지는 접근 제한으로 직접 확인이 어려웠지만, 여러 2차 자료는 이 취약점이 AI 보조 연구 흐름과 함께 이야기되고 있음을 보여줍니다.

여기서 중요한 교훈은 “AI가 취약점을 찾았다”는 자극적인 문장이 아닙니다. 더 중요한 것은 다음입니다.

AI가 취약점 연구자의 탐색 속도를 높일 수 있음
그러나 실제 취약점 성립 여부는 여전히 사람이 검증해야 함
WordPress Core처럼 영향 범위가 큰 소프트웨어에서는 disclosure timing이 매우 중요함
공개 PoC가 등장하면 방어자가 준비할 시간은 급격히 줄어듦

WP2Shell은 AI 시대의 취약점 연구가 어떤 속도로 움직일 수 있는지 보여주는 사례로 볼 수 있습니다.

얼마나 악용되고 있는가

여러 보안 업체는 WP2Shell에 대해 “actively exploited in the wild”, 즉 실제 야생 환경에서 악용이 관측되고 있다고 설명합니다. Tenable은 공개 후 며칠 내 여러 보안 업체가 실제 악용을 확인했고, 공개 PoC가 유통되고 있다고 정리했습니다. Qualys는 CISA Known Exploited Vulnerabilities(KEV) Catalog 등재와 함께 긴급 패치를 언급했습니다. F5 Labs는 2026년 8월 Sensor Intel 글에서 WP2Shell exploit payload를 관측했다고 설명합니다.

정량적으로 “전 세계 몇 개 사이트가 침해되었다”고 단정하기는 어렵습니다. WordPress는 전 세계에서 가장 널리 쓰이는 CMS(Content Management System) 중 하나이고, Qualys 글은 5억 개 이상의 웹사이트가 WordPress를 사용한다고 언급합니다. Eye Security는 2억 개 이상의 live WordPress 사이트라는 표현을 사용합니다. 숫자 산정 방식은 자료마다 다르지만, 공통점은 같습니다.

WordPress Core 취약점은 영향 범위가 매우 넓습니다. 플러그인 취약점보다 훨씬 더 많은 운영자가 긴장해야 합니다.

특히 위험한 부분은 공개 PoC입니다. 초기 공개자가 상세 exploit 절차를 보류하더라도, 취약점 정보가 공개된 뒤에는 독립 연구자와 공격자가 빠르게 재현을 시도합니다. Qualys는 공개된 일부 exploit이 SQL Injection을 통해 WordPress password hash를 추출하고, 관리자 비밀번호를 크랙한 뒤, 악성 플러그인을 업로드해 명령 실행으로 이어지는 흐름을 설명했습니다.

즉, WP2Shell은 “이론상 가능한 취약점”이라기보다, 공개 PoC와 실제 스캔·공격 관측이 결합된 고위험 이슈로 보는 편이 안전합니다.

어떤 위협이 있는가

WP2Shell의 위협은 단순히 “WordPress가 뚫린다”로 끝나지 않습니다. WordPress는 대외 공개 웹사이트의 중심에 있는 경우가 많고, 침해 이후 공격자가 얻을 수 있는 이득이 많습니다.

1. 관리자 계정 생성과 웹셸 배치

공개 분석에서는 공격 체인이 rogue administrator, 즉 공격자가 만든 관리자 계정이나 webshell plugin 배치로 이어질 수 있다고 설명합니다. 공격자가 관리자 권한을 얻으면 다음 행위가 가능해집니다.

악성 플러그인 설치
테마 파일 변조
웹셸 업로드
사용자 계정 추가
게시글 또는 페이지 변조
리디렉션 삽입
SEO spam 삽입

운영자는 단순히 WordPress 버전만 올렸다고 끝내면 안 됩니다. 패치 전 이미 침해되었다면, 업데이트 이후에도 공격자가 심어둔 계정이나 플러그인이 남아 있을 수 있습니다.

2. 데이터베이스 정보 유출

CVE-2026-60137은 SQL Injection 성격의 취약점으로 설명됩니다. SQL Injection은 단순히 DB 에러를 내는 문제가 아닙니다. 공격자가 데이터베이스를 읽을 수 있다면 다음 정보가 노출될 수 있습니다.

사용자 계정 정보
password hash
이메일 주소
비공개 게시글
WooCommerce 등 플러그인이 저장한 주문/고객 정보
플러그인 설정값
일부 환경에서는 API key 또는 token성 데이터

특히 password hash가 유출되면, 오프라인 크래킹을 통해 관리자 계정 탈취로 이어질 수 있습니다. Qualys가 언급한 공개 exploit 흐름도 이 점을 지적합니다.

3. 악성코드 유포와 피싱 인프라화

침해된 WordPress 사이트는 공격자의 인프라가 됩니다. 공격자는 기존 사이트의 평판과 검색 노출을 이용할 수 있습니다.

가능한 악용 시나리오는 다음과 같습니다.

피싱 페이지 호스팅
drive-by download 유도
악성 JavaScript 삽입
방문자 리디렉션
검색 결과 조작용 SEO spam
C2(Command and Control) 중계
다른 WordPress 사이트 공격을 위한 스캐너 배치

기업 홈페이지가 이런 방식으로 악용되면 기술적 피해뿐 아니라 브랜드 신뢰도에도 영향을 줍니다.

4. 로그에서 보기 어려운 공격 흐름

Eye Security는 WP2Shell exploit이 단일 요청으로 끝나는 공격이 아니며, 여러 요청이 batch POST body 안에서 이뤄질 수 있다고 설명합니다. 일반적인 access log만 보는 환경에서는 결정적인 데이터가 본문(body)에 있어 탐지가 어렵습니다.

즉, 운영자는 단순히 “access.log에 이상한 GET 요청이 없다”고 안심하면 안 됩니다. REST API batch endpoint로 들어온 POST 요청, 관리자 계정 생성 이력, 플러그인 설치 이력, 파일 타임스탬프, DB 변경 이력까지 함께 봐야 합니다.

영향받는 버전과 패치 버전

공개 자료 기준으로 영향받는 버전과 패치 버전은 다음과 같이 정리됩니다. 운영 중인 환경에서는 반드시 WordPress 공식 보안 공지와 현재 설치된 브랜치를 기준으로 재확인해야 합니다.

항목	영향 버전	조치 버전
`CVE-2026-63030`	WordPress 6.9.0–6.9.4, 7.0.0–7.0.1	6.9.5 또는 7.0.2
`CVE-2026-60137`	WordPress 6.8.0–6.8.5, 6.9.0–6.9.4, 7.0.0–7.0.1	6.8.6, 6.9.5 또는 7.0.2

Eye Security는 6.8.6, 6.9.5, 7.0.2를 branch별 fixed release로 언급하고, WordPress.org가 강제 자동 업데이트를 수행했다고 설명합니다. 하지만 자동 업데이트를 끄거나, 파일 권한 문제로 업데이트가 실패하거나, 이미 침해된 사이트는 여전히 위험할 수 있습니다.

운영자가 즉시 해야 할 조치

WP2Shell 대응은 크게 네 단계로 나눌 수 있습니다.

1. 버전 확인과 업데이트

가장 먼저 현재 WordPress 버전을 확인합니다.

# WordPress 루트 디렉터리에서 실행
wp core version

WP-CLI가 없다면 관리자 화면 또는 wp-includes/version.php에서 버전을 확인할 수 있습니다.

# 예시: 버전 파일 확인
grep '\$wp_version' wp-includes/version.php

패치 버전이 아니라면 즉시 업데이트합니다.

# WordPress Core 업데이트
wp core update

# DB 마이그레이션이 필요한 경우
wp core update-db

운영 환경에서는 업데이트 전 백업과 스테이징 검증이 필요하지만, 인터넷에 공개된 취약 버전이라면 지연 자체가 위험입니다.

2. 임시 완화: batch API 차단

즉시 업데이트가 어렵다면 임시로 REST batch endpoint 접근을 제한합니다. Qualys는 다음 경로 차단을 임시 완화책으로 언급합니다.

/wp-json/batch/v1
?rest_route=/batch/v1

Nginx라면 예시로 다음과 같이 차단할 수 있습니다.

location = /wp-json/batch/v1 {
    return 403;
}

if ($arg_rest_route = "/batch/v1") {
    return 403;
}

Apache라면 .htaccess 또는 VirtualHost 레벨에서 차단 규칙을 둘 수 있습니다.

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/wp-json/batch/v1$ [OR]
RewriteCond %{QUERY_STRING} (^|&)rest_route=/batch/v1(&|$)
RewriteRule ^ - [F,L]

다만 이 방식은 임시 조치입니다. WordPress Core 업데이트를 대체할 수 없습니다.

3. 침해 여부 확인

패치보다 더 중요한 질문이 있습니다.

패치 전에 이미 공격을 받았는가?

확인해야 할 항목은 다음과 같습니다.

관리자 계정 점검

wp user list --role=administrator

모르는 관리자 계정이 있으면 즉시 비활성화하거나 삭제하기보다, 먼저 증거를 보존해야 합니다. 계정 생성 시간, 이메일, usermeta, 관련 로그가 침해 범위를 파악하는 단서가 될 수 있습니다.

최근 설치된 플러그인 확인

wp plugin list
find wp-content/plugins -maxdepth 2 -type f -mtime -14 -print

최근 생성된 낯선 플러그인, 난독화된 PHP 파일, eval, base64_decode, assert, shell_exec, passthru 같은 문자열이 있는 파일을 확인합니다.

find wp-content -type f -name '*.php' -mtime -14 -print

웹셸 흔적 확인

find wp-content/uploads -type f -name '*.php' -print
find wp-content -type f -name '*.php' -exec grep -HnE 'eval|base64_decode|shell_exec|passthru|system\(' {} \;

이 명령은 오탐이 나올 수 있습니다. 일부 정상 플러그인도 비슷한 함수를 사용할 수 있기 때문에, 결과를 바로 삭제하지 말고 파일 경로와 생성 시간을 함께 봐야 합니다.

REST batch 요청 로그 확인

웹 서버 access log에서 다음 경로를 확인합니다.

grep -E 'wp-json/batch/v1|rest_route=/batch/v1' /var/log/nginx/access.log*

Apache 환경이라면 로그 경로가 다를 수 있습니다.

grep -E 'wp-json/batch/v1|rest_route=/batch/v1' /var/log/apache2/access.log*

단, Eye Security가 지적했듯이 결정적인 값이 POST body 안에 있을 수 있어 access log만으로는 충분하지 않습니다. 로그는 침해 여부의 “증거 일부”일 뿐입니다.

4. 침해가 의심되면 증거 보존 후 복구

침해 흔적이 있다면 바로 파일을 지우기보다 먼저 증거를 보존합니다.

# 예시: 웹 루트와 DB 백업
 tar czf wordpress-webroot-incident-$(date +%F).tar.gz /var/www/html
 mysqldump -u root -p wordpress > wordpress-db-incident-$(date +%F).sql

이후에는 다음 순서로 대응합니다.

사이트를 유지보수 모드 또는 접근 제한 상태로 전환
웹 루트와 DB 백업 보존
의심 관리자 계정 확인 및 비활성화
낯선 플러그인·테마·업로드 PHP 파일 확인
WordPress Core, 플러그인, 테마 최신화
모든 관리자 비밀번호 재설정
DB 계정 비밀번호 및 salt 재발급
서버 계정, SSH key, 배포 토큰 등 연계 자격 증명 점검
WAF/EDR/웹 서버 로그를 기준으로 침해 시점과 공격 IP 범위 정리
필요 시 깨끗한 백업에서 복구

탐지 관점에서 볼 포인트

WP2Shell은 WordPress Core 취약점이므로 단순히 플러그인 버전만 보는 취약점 점검으로는 부족합니다. 다음 탐지 포인트를 함께 봐야 합니다.

영역	확인할 내용
버전	WordPress Core가 fixed release인지 확인
네트워크	`/wp-json/batch/v1`, `?rest_route=/batch/v1` 접근 급증 여부
계정	신규 관리자 계정, 이메일 변경, 권한 상승 흔적
파일	`wp-content/plugins`, `wp-content/uploads` 내 신규 PHP 파일
DB	`wp_users`, `wp_usermeta`, `wp_options`, `wp_posts`의 비정상 변경
로그	POST 요청, 500 응답, 비정상 User-Agent, 동일 IP 반복 요청
무결성	WordPress Core 파일 변조 여부

WP-CLI가 있다면 Core 파일 무결성 확인도 도움이 됩니다.

wp core verify-checksums

다만 침해자가 Core 파일은 건드리지 않고 플러그인이나 uploads 디렉터리에 웹셸을 심었다면 이 명령만으로는 탐지되지 않습니다.

대응 체크리스트

아래 체크리스트는 운영자 관점의 최소 조치입니다.

[ ] WordPress Core 버전을 확인했다.
[ ] 6.8.6 / 6.9.5 / 7.0.2 이상 fixed release로 업데이트했다.
[ ] 업데이트 실패 사이트가 없는지 별도로 확인했다.
[ ] /wp-json/batch/v1 및 ?rest_route=/batch/v1 접근 로그를 확인했다.
[ ] 모르는 관리자 계정이 없는지 확인했다.
[ ] 최근 생성된 플러그인과 uploads 내 PHP 파일을 확인했다.
[ ] wp core verify-checksums를 실행했다.
[ ] 관리자 비밀번호를 재설정했다.
[ ] 의심 흔적이 있으면 웹 루트와 DB를 보존했다.
[ ] WAF에서 REST batch endpoint 접근 정책을 점검했다.
[ ] 외부 모니터링에서 사이트 변조, 리디렉션, SEO spam 여부를 확인했다.

WordPress Core RCE가 주는 경고

WP2Shell을 보면서 가장 먼저 든 생각은 “WordPress라서 위험하다”가 아니었습니다. 오히려 더 큰 문제는 너무 널리 쓰이는 소프트웨어의 Core 취약점이 공개 PoC와 만나면 방어 시간이 거의 사라진다는 점입니다.

플러그인 취약점은 어느 정도 범위가 제한됩니다. 특정 플러그인을 쓰는 사이트만 영향받습니다. 하지만 Core 취약점은 다릅니다. 운영자는 “우리 사이트는 플러그인을 많이 안 쓴다”는 이유로 안심하기 어렵습니다. 자동 업데이트가 켜져 있더라도, 실제로 업데이트가 성공했는지 확인해야 합니다.

또 하나의 포인트는 AI입니다. WP2Shell의 발견 과정은 AI 보조 연구와 함께 이야기되고 있습니다. 이것이 사실이라면, 앞으로 더 많은 연구자가 AI를 이용해 대규모 코드베이스에서 취약점 후보를 빠르게 찾을 것입니다. 좋은 일입니다. 하지만 동시에 공개 이후 exploit 재현 속도도 빨라집니다.

방어자는 더 이상 “공개 후 며칠 안에 패치하면 되겠지”라고 느긋하게 움직이기 어렵습니다. 특히 다음 조건이 겹치면 우선순위를 최상단으로 올려야 합니다.

Core 또는 기본 설치 구성에 영향
인증 불필요
인터넷에서 직접 접근 가능
공개 PoC 존재
CISA KEV 등재 또는 실제 악용 관측
관리자 권한 또는 RCE로 확장 가능

WP2Shell은 이 조건을 상당수 만족합니다. 그래서 운영자는 단순 업데이트가 아니라 침해 여부 확인까지 해야 합니다.

마치며

WP2Shell은 WordPress Core에서 발생한 비인증 RCE 체인으로, CVE-2026-63030과 CVE-2026-60137을 함께 봐야 하는 이슈입니다. 공개 PoC와 실제 악용 관측이 결합되어 있어, WordPress 운영자는 패치 여부를 반드시 확인해야 합니다.

핵심은 세 가지입니다.

패치: WordPress Core를 fixed release로 업데이트합니다.
완화: 즉시 업데이트가 어렵다면 REST batch endpoint를 임시 차단합니다.
침해 확인: 패치 전에 공격을 받았을 가능성을 계정, 파일, DB, 로그 기준으로 점검합니다.

WordPress는 너무 널리 쓰이는 소프트웨어입니다. 그래서 Core 취약점 하나의 파급력은 생각보다 큽니다. WP2Shell은 운영자에게 익숙한 질문을 다시 던집니다. “최신 버전인가?”보다 더 중요한 질문입니다.

“패치되기 전에 이미 들어온 흔적은 없는가?

References

Eye Security, “wp2shell: incident response guide (CVE-2026-63030 + CVE-2026-60137)”: https://research.eye.security/wp2shell-defenders-guide/
Qualys ThreatPROTECT, “WordPress wp2shell Vulnerabilities Exploited in the Wild (CVE-2026-63030 & CVE-2026-60137)”: https://threatprotect.qualys.com/2026/07/20/wordpress-wp2shell-vulnerabilities-exploited-in-the-wild-cve-2026-63030-cve-2026-60137/
Tenable, “wp2shell (CVE-2026-63030, CVE-2026-60137): Frequently asked questions about remote code execution chain in WordPress Core”: https://www.tenable.com/blog/wp2shell-cve-2026-63030-cve-2026-60137-frequently-asked-questions-about-remote-code-execution
F5 Labs, “CVE-2026-63030 and CVE-2026-60137: 'wp2shell' Captured Exploit Payload”: https://www.f5.com/labs/articles/cve-2026-63030-and-cve-2026-60137-wp2shell-captured-exploit-payload
CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
WordPress Security Releases: https://wordpress.org/news/category/security/

저작자표시 비영리 동일조건 (새창열림)