이것은 현재 활발히 악용되고 있는 취약점(CISA KEV에 등재됨)에 대한 빠른 해설입니다. 무슨 일이 일어나는지, 누가 영향을 받는지, 어떻게 대응해야 하는지를 다루며, 방어자의 관점에서 작성되었고 재현 단계는 포함하지 않습니다.
- CVE
- CVE-2026-87902 (GHSA-7hp8-65ch-5whp)
- 심각도
- NVD: CVSS v3.1 8.1 (공격 복잡도 높음) / WordPress 권고: CVSS v4.0 9.2, Critical
- 유형
- 파일 포함(CWE-98) — 페이지 템플릿 해석의 경로 순회
- 영향
- 테마 밖의 .php 파일 포함; 테마 및 서버 조건이 맞으면 RCE
- 전제 조건
- 인증 불필요, 사용자 상호작용 불필요
- 영향 범위
- WordPress 4.7.0–7.1.1
- 수정
- 7.1.2, 2026년 9월 22일 공개, 4.7까지 모든 브랜치 수정 포함
- 악용
- CISA KEV 등재(2026년 9월 25일 추가, 조치 기한 9월 28일), 포렌식 분류가 필요한 것으로 표시됨
기다리는 것은 얼마나 위험합니까?
WordPress는 가장 널리 쓰이는 CMS이며, 이 결함은 약 10년간의 릴리스에 걸쳐 있고 인증이나 사용자 상호작용 없이 악용될 수 있습니다. WordPress 전문 보안 업체는 수정이 배포된 날부터 탐색이 시작되었고, 다음 날에는 코드 실행 시도로 바뀌었으며, 범용 스캐닝 도구에 포함되었다고 보고합니다. 스캔은 무차별적이므로 사이트 규모는 상관이 없습니다.
어떤 종류의 취약점입니까?
WordPress는 테마 디렉터리에서 템플릿 파일을 찾아 어떤 파일로 페이지를 렌더링할지 결정합니다. 권고문에 따르면 이 페이지 템플릿 해석에 허점이 있어, 인증되지 않은 공격자가 활성 테마 디렉터리 밖의 .php 파일을 포함하도록 만들 수 있었습니다. 외부에서 주어진 값이 불러올 파일을 결정하는 경우가 파일 포함(CWE-98)입니다. 이 사이트는 악용 방법을 설명하지 않습니다.
이것만으로는 코드 실행이 되지 않습니다. 권고문은 RCE의 조건을 테마 측과 서버 측으로 나눕니다.
테마 측 조건(권고문 기준)
- 활성 부모 테마 또는 자식 테마에 이름이
page-로 시작하는 최상위 디렉터리가 있음(예:page-templates) - 권고문에 따르면 이는 레거시 Twenty Twelve 및 Twenty Fourteen 테마와 Neve, Hestia, Sydney 같은 일부 인기 서드파티 테마에 해당합니다(결함은 테마가 아니라 코어의 처리 방식에 있습니다)
서버 측 조건(권고문 기준)
- 포함될 때 위험하게 동작하는 .php 파일이 서버에 존재하며 웹 서버 계정이 읽을 수 있음
- PHP의
register_argc_argv가 켜져 있으면 이 조건이 훨씬 쉽게 충족됨 - 권고문에 따르면 공식 PHP Docker 이미지와 PHP 8.5 이전 버전을 사용하는 기본 cPanel 구성이 영향을 받습니다
① 코어 결함: 테마 밖의 .php를 포함할 수 있음
→ 7.1.2(및 각 브랜치의 릴리스)에서 수정됨
② 테마 조건: page-로 시작하는 디렉터리
→ 스스로 판단하기 어려우므로 판단에 의존하지 마십시오
③ 서버 조건: 위험한 .php가 읽히고 register_argc_argv가 켜져 있음
→ 설정을 끄면 해당 유형의 공격 전체를 차단합니다
영향을 받는 대상
| 브랜치 | 영향 받는 버전 | 수정 버전 |
|---|---|---|
| 7.1 | 7.1.0–7.1.1 | 7.1.2 |
| 7.0 | 7.0.0–7.0.5 | 7.0.6 |
| 6.9 | 6.9.0–6.9.8 | 6.9.9 |
| 6.8 | 6.8.0–6.8.9 | 6.8.10 |
| 6.7 ~ 4.7 | 각 브랜치의 수정 이전 릴리스까지 | 각 브랜치의 수정 버전(6.7.9 … 4.7.37) |
| 4.7 이전 | — | 수정 없음(지원 종료) |
대응 방법
버전을 확인하고 수정된 릴리스로 이동하십시오(최우선)
대시보드에서 대시보드 → 업데이트로 이동해 버전을 확인하십시오. 7.1.2(또는 해당 브랜치의 수정 릴리스)가 아니라면 오늘 업데이트하십시오. 최신 버전만 적극적으로 지원되므로 7.1.2가 가장 안전한 목표입니다.
자동 업데이트가 닿지 않는 사이트를 찾으십시오
백그라운드 업데이트를 지원하는 사이트에서는 업데이트가 스스로 시작됩니다. 위험은 그 경로 밖에 있는 사이트에 있습니다. 자동 업데이트가 비활성화된 사이트, Git이나 컨테이너 이미지에서 코어가 고정된 사이트(업데이트하더라도 재빌드하면 경고 없이 이전 버전으로 돌아갑니다), 호스트가 차단한 업데이트, 그리고 아무도 기억하지 못하는 오래된 사이트가 여기에 해당합니다. 여러 사이트를 운영한다면 각각 확인하십시오(보안 인벤토리 체크리스트).
PHP의 register_argc_argv를 끄십시오(다층 방어)
웹 요청을 처리하는 PHP에는 이 설정이 거의 필요하지 않습니다. php.ini(또는 호스트의 PHP 설정)에서 register_argc_argv = Off로 설정하십시오. 컨테이너에서 실행한다면 이미지의 구성을 확인하십시오. 업데이트를 대체하지는 않지만, 파일 포함에서 코드 실행으로 이어지는 경로를 차단하며, 이는 이 CVE 하나를 넘어서는 효과가 있습니다.
업데이트 전에 침해되었는지 확인하십시오
9월 22일 이후에도 패치되지 않은 사이트가 있다면 그 기간을 의심스럽게 보십시오. CISA도 이 CVE를 포렌식 분류 대상으로 표시했습니다. 최소한 다음을 확인하십시오: (1) /tmp, /var/tmp 또는 wp-content 아래의 낯선 .php 파일, (2) 퍼센트 인코딩된 디렉터리 순회(../에 해당)가 포함된 접근 로그 요청, (3) 알 수 없는 관리자 사용자나 최근 추가된 플러그인.
무언가 이상하다면 '패치 완료'에서 멈추지 마십시오
코드가 실행되었을 가능성이 있다면, 패치는 이미 서버에 놓인 파일이나 이미 탈취된 키를 제거하지 못합니다. 데이터베이스 비밀번호, wp-config.php의 인증 키/솔트, 관리자 비밀번호, 서드파티 API 키를 교체하고 의심스러운 파일을 제거하십시오. 전체 절차는 취약점 대응 플레이북과 WordPress 보안에 있습니다.
이 사이트의 견해: 수정이 공개되면 공격은 즉시 시작됩니다
최근의 Adobe Commerce 사례에서는 수정과 KEV 등재 사이에 44일이 지났습니다. 이번에는 3일이었습니다. 차이는 패치 diff가 공격을 얼마나 쉽게 드러내는지, 그리고 해당 제품을 사용하는 사이트가 얼마나 많은지에 있습니다. 보도된 일정에 따르면, diff와 유사한 형태의 탐색은 수정이 배포된 당일에 시작되었습니다.
교훈은 이렇습니다. 널리 쓰이는 제품의 경우, 수정이 있다고 해서 시간이 더 주어지는 것이 아닙니다. 공격자는 공개되는 순간 작업을 시작하며, 사람이 수동으로 그 속도를 따라가기는 어렵습니다. 그래서 이 사이트는 패치 절차 자체보다 자동 업데이트가 확실히 전달되도록 하는 것을 우선순위에 둡니다. 자동 업데이트를 받은 사이트는 소유자가 아무 일이 있었는지 알기 전에 이미 보호되어 있었습니다. 위험한 사이트는 자신이 자동 업데이트의 범위 밖에 있다는 사실을 깨닫지 못한 사이트입니다.
한 가지 더 있습니다. EPSS는 3%였습니다. EPSS는 유용하지만, 새로 공개된 취약점에 대해서는 뒤처집니다. KEV와 EPSS가 다를 때는 KEV를 따르십시오. KEV는 확인된 사실입니다.
출처
- WordPress — GHSA-7hp8-65ch-5whp (영향 및 수정 버전, RCE 전제 조건, CVSS v4.0 9.2)
- WordPress.org — WordPress 7.1.2 Release (2026년 9월 22일; 4.7까지의 백포트, 자동 업데이트)
- NVD — CVE-2026-87902 (CWE-98, CVSS v3.1 8.1)
- CISA KEV — Known Exploited Vulnerabilities Catalog (2026년 9월 25일 추가, 9월 28일 기한, 포렌식 분류 필요)
- FIRST — EPSS (2026년 9월 25일 기준 0.029)
- 관찰 보고서 — Patchstack (수정 당일부터 탐색, 다음 날 코드 실행 시도; 이 글은 시간표와 방어자 점검 항목만 사용)