WordPress 페이지 템플릿 경로 조작 취약점 (CVE-2026-87902)

NOW Briefing

Brief 1 WordPress 4.7.0~7.1.1의 페이지 템플릿 경로 처리에서 경로 조작 취약점(CVE-2026-87902)이 확인됐습니다.

Brief 2 전제조건이 맞으면 미인증 요청으로 로컬 PHP 파일이 포함되고, 서버 조건이 추가로 갖춰지면 원격 코드 실행까지 이어집니다. 실제 악용이 확인돼 CISA KEV에 등재됐습니다.

Brief 3 7.1.2 등 각 브랜치의 보안 릴리스를 즉시 적용하고, 패치 전 노출된 사이트는 웹셸 여부를 점검해야 합니다.

‍

WordPress 페이지 템플릿 경로 조작 취약점 (CVE-2026-87902)

‍

■ 개요

‍

WordPress는 전 세계에서 가장 널리 쓰이는 콘텐츠 관리 시스템(CMS)입니다. 2026년 9월 22일 공개된 7.1.2 보안 릴리스는 페이지 템플릿을 고르는 과정에서 발생하는 경로 조작(허용 범위를 벗어난 경로를 입력해 다른 위치의 파일에 접근하는 기법) 취약점 CVE-2026-87902를 수정했습니다. 프로젝트가 밝힌 영향 범위는 4.7.0부터 7.1.1까지 모든 릴리스입니다. 발견자는 2026년 7월 20일 HackerOne으로 비공개 제보했고, WordPress는 두 달 뒤 보안 지원 대상 전 브랜치에 패치를 백포트했습니다.

미인증 공격자는 로그인 없이 보낸 요청 하나로 활성 테마 폴더 밖에 있는 읽기 가능한 로컬 PHP 파일을 페이지 템플릿으로 포함시킬 수 있습니다. 다만 이 로컬 파일 포함(LFI)이 성립하려면 세 가지 조건이 서버에 함께 갖춰져야 합니다. page_id로 선택할 수 있는 게시된 페이지, 활성 테마나 부모 테마의 특정 이름 규칙을 따르는 최상위 하위 디렉터리, 그리고 포함 대상이 될 읽기 가능한 로컬 PHP 파일입니다. 여기서 원격 코드 실행까지 가려면 PHP 라이브러리 배포 도구(PEAR)의 읽기 가능한 진입점, 쿼리 문자열을 명령행 인자로 넘기는 PHP 설정, 쓰기 가능한 디렉터리가 추가로 필요합니다. WordPress와 연구자 모두 원격 코드 실행을 "서버 환경과 활성 테마의 전제조건이 충족될 때"로 한정해 설명합니다.

CISA는 2026년 9월 25일 이 취약점을 악용 취약점 목록(KEV)에 원격 파일 포함 취약점으로 등재하고, 연방기관 조치 기한을 9월 28일로 정했습니다. The Hacker News 보도에 따르면 Patchstack은 패치 공개일인 9월 22일 11시 49분(UTC)에 첫 공격 시도를 관측했고, Previdian은 9월 23일부터 68건의 악용 시도를 기록했습니다. 국내에서도 가비아와 카페24가 WordPress 전용·매니지드 호스팅 상품을 판매하고 있으므로, 직접 운영하는 서버뿐 아니라 호스팅 상품에 올려둔 사이트의 버전도 함께 확인해야 합니다.

‍

■ 요약

‍

항목	내용
CVE ID	CVE-2026-87902 (페이지 템플릿 경로 해석의 경로 조작)
CVSS 점수	• CVSS v4.0 9.2 • CVSS v3.1 8.1
취약점 유형	CWE-98, 미인증 로컬 파일 포함(LFI)
영향/위험	• 테마·페이지 전제조건 충족 시 미인증 요청으로 테마 디렉터리 밖의 읽기 가능한 로컬 PHP 파일 포함 가능 • 서버 환경 전제조건이 추가로 충족되면 원격 코드 실행 가능 • 실제 공격에 악용 확인됨(CISA KEV 등재)
취약 버전	4.7.0 ~ 7.1.1 전 릴리스
패치 버전	• 7.1.2 • 7.0.6 • 6.9.9 • 6.8.10 • 보안 지원 브랜치 백포트(4.7.37까지 제공)

‍

■ 기술 분석

‍

취약한 코드는 wp-includes/template.php의 get_page_template()입니다. 이 함수는 페이지 주소를 담는 질의 변수 pagename 값을 읽어 page-{pagename}.php 형태의 템플릿 후보 이름을 만듭니다. 이때 값을 한 번 더 urldecode()한 후보를 목록에 추가하면서, WordPress 내장 경로 검사 함수인 validate_file()을 호출하지 않았습니다. 다른 템플릿 후보 경로에는 같은 검사가 걸려 있었기 때문에, 이 불일치로 취약점이 발생했습니다. 공격자가 상위 디렉터리 이동 문자열을 이중으로 URL 인코딩해 보내면 앞단 정리 과정을 통과한 뒤 이 지점에서 실제 경로 이동 문자열로 복원됩니다.

패치 커밋 170944a3은 같은 파일의 get_page_template()에서 디코딩된 후보를 목록에 넣기 전에 validate_file() 결과를 확인하도록 조건을 바꿨습니다.

 	if ( $pagename ) {
 		$pagename_decoded = urldecode( $pagename );
-		if ( $pagename_decoded !== $pagename ) {
+		if ( $pagename_decoded !== $pagename && 0 === validate_file( $pagename_decoded ) ) {
 			$templates[] = "page-{$pagename_decoded}.php";
 		}
 		$templates[] = "page-{$pagename}.php";

후보 이름 앞에 page-가 붙는 제약 때문에 실제 파일 포함에는 조건이 더 필요합니다. 활성 테마나 부모 테마에 page-로 시작하는 최상위 디렉터리가 있어야 경로 이동의 기점이 생기고, page_id로 선택할 수 있는 게시된 페이지가 있어야 이 경로가 호출됩니다. WordPress 권고와 Equixly 분석은 Twenty Twelve, Twenty Fourteen, Neve, Hestia, Sydney가 page-로 시작하는 최상위 디렉터리를 포함한다고 지적했습니다.

원격 코드 실행 단계는 PEAR의 명령행 진입점 파일 pearcmd.php를 포함 대상으로 삼습니다. 이 경로는 쿼리 문자열을 명령행 인자처럼 전달하는 PHP 설정 register_argc_argv가 켜져 있어야 성립하는데, Patchstack 기준으로 공식 PHP 도커 이미지와 PHP 8.5 미만 cPanel 환경에서 기본으로 켜져 있습니다. 공격자는 쓰기 가능한 경로에 PHP 파일을 만든 뒤 이를 다시 포함시켜 실행합니다.

패치는 후보 검증을 locate_template() 안으로도 옮겼습니다. 같은 커밋이 추가한 비공개 함수 _wp_is_template_path_allowed()는 경로에 ..가 없으면 즉시 통과시키고, 있으면 realpath()로 실제 위치를 구해 스타일시트 디렉터리·템플릿 디렉터리·테마 호환 디렉터리 안에 있는지 비교합니다. 아래는 같은 커밋에서 locate_template()의 후보 선택 부분을 고친 diff로, 파일을 찾은 즉시 반환하던 구조가 후보를 변수에 담아 검사를 통과할 때만 확정하도록 바뀌었습니다.

 		if ( file_exists( $wp_stylesheet_path . '/' . $template_name ) ) {
-			$located = $wp_stylesheet_path . '/' . $template_name;
-			break;
+			$candidate = $wp_stylesheet_path . '/' . $template_name;
 		} elseif ( $is_child_theme && file_exists( $wp_template_path . '/' . $template_name ) ) {
-			$located = $wp_template_path . '/' . $template_name;
-			break;
+			$candidate = $wp_template_path . '/' . $template_name;
 		} elseif ( file_exists( ABSPATH . WPINC . '/theme-compat/' . $template_name ) ) {
-			$located = ABSPATH . WPINC . '/theme-compat/' . $template_name;
+			$candidate = ABSPATH . WPINC . '/theme-compat/' . $template_name;
+		} else {
+			continue;
+		}
+
+		if ( _wp_is_template_path_allowed( $candidate ) ) {
+			$located = $candidate;
 			break;
 		}
 	}

‍

■ PoC

‍

이 취약점을 발견해 제보한 Robert Ressl은 자신의 PoC 저장소를 공개했습니다. 저장소에는 파이썬 익스플로잇 스크립트와 7.0.2 버전을 고정한 도커 실습 환경이 들어 있고, 롤링 태그를 쓰면 이미 수정된 이미지가 내려와 실습이 성립하지 않는다고 명시돼 있습니다. 별도로 공개된 crowsec-edtech 저장소의 스크립트는 디스크 쓰기 없이 취약 여부만 확인하는 모드와 PEAR 가젯을 엮어 명령 실행까지 수행하는 모드를 함께 제공합니다.

PoC 코드는 본문에 싣지 않았습니다. 원문은 참고 자료의 링크에서 확인할 수 있습니다.

⚠️ WARN

명령 실행까지 수행하는 익스플로잇이 여러 저장소에 공개돼 있고 실제 공격도 관측됐습니다.
검증은 인터넷과 분리된 통제 환경에서만 수행해야 합니다.

‍

■ 탐지 및 점검

‍

• wp-includes/version.php의 $wp_version 값으로 실제 코어 버전을 확인하고, 4.7.0~7.1.1 구간이면 침해 여부를 점검합니다.

• 웹 접근 로그의 쿼리 문자열에서 page_id 파라미터와 config-create 같은 PEAR 인자 문자열이 함께 나타나는 요청을 조회합니다.

• 공격 요청이 pagename 값을 POST 본문에 실으면 일반 접근 로그에는 남지 않으므로, WAF 로그·프록시 본문 로깅·전체 패킷 캡처가 확보된 구간을 함께 확인해야 합니다.

• /tmp, /var/tmp, 웹 루트에서 생성 시각과 소유자가 배포 이력과 맞지 않는 .php 파일을 찾습니다. Patchstack이 제시한 이름은 wp-pear-rce-flag.php, poc87902.php이고 luci_·zeta_로 시작하는 무작위 이름도 함께 언급됐으나, 파일명만으로 침해를 확정하지 말고 같은 시각의 접근 로그와 대조해야 합니다.

• 웹 서버 계정에서 파생된 비정상 자식 프로세스와 raw.githubusercontent.com으로 향하는 예상치 못한 아웃바운드 요청을 점검합니다. 보도된 사례에서는 GitHub에 올려둔 업로더 스크립트를 내려받아 실행한 정황이 언급됐습니다.

‍