wp-ghsa-7hp8-lab

GHSA-7hp8-65ch-5whp / CVE-2026-87902 — page-template 해석 과정의 인증되지 않은 경로 순회로 인한 조건부 RCE (WordPress, CWE-98, CVSS 4.0: 9.2)에 대한 탐지 도구 및 재현 가능한 테스트베드.

make up      # 테스트베드 기동      make ioc    # 공격 코퍼스 -> 로그 -> 탐지
make scan    # 테스트베드 점검   make test   # 품질 게이트

1. 테스트베드

127.0.0.1 상의 세 WordPress 인스턴스로, 판정의 각 요소를 격리한다.

8092가 가장 교훈적이다: 8091과 동일한 취약한 코어이지만 테마 전제 조건이 결여되어 있다. 이것이 버전만으로 판단하는 트리아지가 노출을 과대평가한다는 것을 보여준다. 8091과 8092 사이의 유일한 변수는 테마이고, 8091과 8093 사이의 유일한 변수는 패치이다: 세 인스턴스 모두 동일한 사용자 정의 콘텐츠 유형(provision/mu-plugins/00-lab-cpt.php)과 동일한 요청 상태 프로브(10-lab-debug.php, is_page(), 로더가 본 pagename 값, 최종적으로 포함된 템플릿을 노출하는 X-Lab-* 헤더)를 포함한다.

make up        # 시작 및 프로비저닝 — 멱등적, 재실행 가능
make status    # 각 인스턴스의 버전
make down      # 중지        make clean : 볼륨도 삭제

로그를 가져올 위치

공식 Docker 이미지는 /var/log/apache2/access.log를 /dev/stdout으로 연결한다: 로그는 파일이 아닌 컨테이너 출력으로 나온다.

docker compose logs --no-log-prefix vuln-pre                  # 접근 + 오류
docker compose logs --no-log-prefix vuln-pre > access.log     # 분석용
docker compose logs -f --no-log-prefix vuln-pre               # 실시간
make logs                                                     # 세 인스턴스 모두

일반 서버에서는: /var/log/apache2/access.log, /var/log/nginx/access.log, 또는 대부분의 공유 호스팅에서 /home/*/logs/. 형식은 쿼리 문자열을 포함해야 한다 — %r 또는 combined 형식은 포함하지만, %U로 구성된 LogFormat은 이를 잃게 되며, 이것이 없으면 어떤 탐지도 불가능하다.

2. 컨트롤러 — check/wp-ghsa-7hp8-check.py

인터넷에서, 서버 접근 없이. 페이로드 없음, 순회 없음, 쓰기 없음. 각 호스트에 대해: WordPress 탐지, 다섯 소스(meta generator, RSS 피드, wp-links-opml.php, readme.html, 코어 리소스의 ?ver=)에서 교차 확인된 버전, 활성 테마, page-* 디렉터리 프로빙.

python3 check/wp-ghsa-7hp8-check.py --hosts-file hosts.txt --csv out.csv --json out.json

"영향받음"은 취약한 코드가 존재함을 의미하며, 공격자가 코드를 실행할 수 있음을 의미하지 않는다. docs/ANALYSIS.md 참조.

--transport browser(기본값)는 설치된 Google Chrome을 구동한다; 하위 요청은 페이지 내에서 실행되는 fetch()에서 발생하며 페이지의 TLS 스택, HTTP/2 헤더 순서, 쿠키를 상속받아, URL이 읽히기 전에 CDN에 의해 필터링되는 것을 방지한다. --transport direct는 표준 라이브러리만 사용한다. --scheme http|https는 https → http 폴백을 방지하는데, 이는 그렇지 않으면 대상 로그에 원시 TLS ClientHello와 함께 400 줄을 남긴다.

각 요청은 JSONL 로그에 밀리초 단위로 타임스탬프된다: 세션 식별자, 요청 번호, 단계, URL, 상태, 크기, 지속 시간, 송신 IP, 마커. 마커 SECAUDIT/<nonce>는 X-Security-Audit 헤더 및 User-Agent 접미사로 전송된다 — 추가되며, 결코 대체되지 않아, 브라우저 서명을 깨지 않고 표준 access log에서 가시적으로 유지된다. --marker로 사용자 정의 가능.

원격 오라클 없음. --probe-inclusion 옵션은 비활성 대상(wp-includes/version.php, 부트스트랩 시 이미 로드됨: require_once가 완전한 no-op으로 만든다)에 대해 차등 비교를 수행한다. 표준 설치에서 이는 취약한 코어에서도 NOT_REACHABLE을 반환하며, 패치된 인스턴스와 미패치 인스턴스 간에 바이트 단위로 동일한 응답을 보인다. 이것은 도구의 한계가 아니다: WordPress는 템플릿 계층을 참조하기 전에 404를 응답한다. 수치화된 시연은 docs/ANALYSIS.md 섹션 3에 있다.

3. 탐지 및 IoC

구조적 규칙

pagename=.*%2e%2e%2f와 같은 리터럴 정규식은 대소문자 변경(%2E), 한 번 더 인코딩(%252e), 또는 리터럴과 인코딩 혼용(templates/..%2f../)으로 우회된다. 모든 패턴 목록은 구조적으로 불완전하다.

따라서 공격자의 작성 방식이 아닌 코드에서 출발한다:

1. pagename은 디스크에 도달하기 전에 최대 두 번의 디코딩을 거친다 — 쿼리 문자열에 대한 PHP의 디코딩, 그 다음 get_page_template()의 명시적 urldecode().
2. 테마 디렉터리를 벗어나려면 file_exists()에 전달된 경로가 .. 컴포넌트를 포함해야 한다. Linux에서 상위 디렉터리는 정확히 두 바이트 0x2E 0x2E로 쓰인다; 파일 시스템 수준에서 다른 표현은 존재하지 않는다.

따라서: 고정점까지 디코딩하고 각 수준에서 테스트한다. 이것은 WordPress가 하는 것의 엄격한 상위 집합이다 — 인코딩 계층을 추가하는 것은 단지 일치를 한 수준 이동시킬 뿐이며, 우리는 그것도 통과한다.

python3 detect/wp-ghsa-7hp8-ioc.py access.log
docker compose logs --no-log-prefix vuln-pre | python3 detect/wp-ghsa-7hp8-ioc.py -

Sigma 규칙은 detect/sigma-wp-ghsa-7hp8.yml에 있다. Sigma는 재귀적으로 디코딩할 수 없으므로, 규칙은 수준 0~3을 열거한다: 이는 1차 트리아지를 위한 가정된 근사치이다. 일치 항목을 분석기로 다시 전달하여 결정하라.

한계 — 신뢰하기 전에 알아야 할 사항

• POST. WP::parse_request()는 $_GET 이전에 $_POST를 읽는다. 따라서 pagename이 요청 본문에 도착할 수 있으며, 어떤 access log에도 없다. WAF 또는 ModSecurity 수준에서 본문에 대한 커버리지가 필요하다.
• 로그 형식. 쿼리 문자열이 기록되지 않으면 아무것도 탐지할 수 없다.
• 시도이지 성공이 아니다. 404는 모든 구성에서 실패를 입증하지 않는다.

access log에 대한 어떤 규칙도 첫 번째 지점을 커버하지 않는다. 이는 규칙이 아닌 지원의 한계이지만, 완전한 커버리지를 발표하기 전에 알아야 한다.

자체 탐지 검증

offensive/generate-traces.py는 동일 페이로드의 12가지 다른 작성 방식(리터럴, 단일/이중/삼중 인코딩, 대문자 및 소문자, 혼용, UTF-8 과잉 인코딩, 점-공백)과 이들과 유사한 7가지 정당한 요청(점이 있는 슬러그, 슬러그 내 wp-includes, 날짜 퍼머링크, 인코딩된 퍼센트)을 재생한다.

이것은 아무것도 얻지 못한다: 표준 설치에서 이 벡터에 대한 원격 익스플로잇은 존재하지 않는다. 이것은 트레이스를 생성한다 — 그것이 전부이다.

make ioc     # 코퍼스 생성, 실제 로그 가져오기, 분석기 실행

예상되며, 실제 Apache 로그에서 make test로 검증됨: 12개 페이로드 중 12개 탐지(11개 CRITICAL, 과잉 인코딩은 Linux에서 익스플로잇 불가하므로 MEDIUM), 7개 정당한 요청에 대해 0개 경고, 그리고 세 가지 다른 디코딩 수준에서의 효과적인 탐지.

대상은 로컬 테스트베드로 제한됨; 다른 대상은 --i-have-authorization이 필요하다.

4. 완화

1. 해당 브랜치의 패치 버전으로 업데이트 — 7.1.2, 7.0.6, 6.9.9, 6.8.10, 6.7.9, … 4.7.37까지. 전체 매트릭스는 컨트롤러에 있다.
2. 웹 SAPI의 php.ini에서 register_argc_argv = Off; 사용하지 않으면 PEAR 제거 — 이것이 권고에서 언급된 포함 → 실행 피벗이다.
3. open_basedir을 사이트 루트로 제한: 모든 로컬 포함을 격리한다.
4. 위 규칙을 배포하고, POST 요청 본문도 커버하라.

5. 신뢰성

make test는 게시 조건이다: 권고의 25개 브랜치 매트릭스(비교 함정 포함 — 수치적으로 6.8.9 < 6.8.10, 사전 릴리스, 매트릭스 외 브랜치), 세 인스턴스에 대한 컨트롤러, 실제 로그에서 검증된 IoC 규칙. 프로브의 NOT_REACHABLE 어서션은 의도적으로 고정되어 있다: 이것이 깨지면 동작이 변경된 것이며 분석을 재개해야 한다.

사용 프레임워크

귀하가 책임지는 자산, 또는 서면 위임 하에서만 사용하라. 테스트베드는 127.0.0.1에서만 수신한다; 취약한 인스턴스는 결코 노출되어서는 안 된다. 10-lab-debug.php 프로브는 서버 경로를 노출한다: 테스트베드 전용이다.