Skip to main content

wordpress-full-compromise

Use when verified WordPress findings may combine into an authorized path to administrative or server control.

소스 정보

저장소
uphiago/recon-skills
최근 소스 활동
2026년 7월 30일 00:23
감지된 SKILL.md 언어
영어
스타
1,306
포크
218

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
2 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
wordpress-full-compromise
description
Use when verified WordPress findings may combine into an authorized path to administrative or server control.
version
2.0.0
license
MIT
platforms
["linux","macos"]
compatibility
Requires curl, a browser, approved test identities, and WordPress component evidence
tags
["chains","wordpress","validation","attack-path"]
category
chains
related_skills
["cross-attack-chains","hunt-wordpress","triage-validation","wordpress-cors-xmlrpc-rce-chain","wordpress-plugin-hunt","xmlrpc-exploitation"]
# WordPress Compromise Path Analysis Use this skill to determine whether verified WordPress primitives actually compose into administrative control or benign code-execution proof. It is a chain gate, not a checklist for forcing escalation after a prerequisite fails. ## When to Use - A plugin vulnerability has exact version and route evidence. - An approved identity may have an unexpected WordPress capability. - An upload or configuration write could reach executable handling. - CORS, XML-RPC, staging, or source exposure may supply a missing prerequisite. ## Prerequisites - Explicit authorization for registration, authentication, upload, write, and execution testing. - An approved synthetic account and disposable content. - Exact WordPress, plugin, theme, and hosting behavior. - A benign marker for any execution test. - Cleanup and stop conditions. ## How to Run Build a prerequisite table: ```text Step State Required evidence Component vulnerability observed exact version and affected operation Authorized identity confirmed approved account and current role Write or upload capability unverified synthetic artifact accepted Executable handling unverified benign marker executed Administrative control not tested approved admin-only action Cleanup planned artifact and account removal ``` Do not proceed past an unverified prerequisite. ## Procedure ### 1. Confirm the Component Use `hunt-wordpress` and `wordpress-plugin-hunt` to establish: - component identity from more than one signal; - exact version or commit; - vulnerable route or handler; - authentication and role prerequisite; - affected configuration and file type. A public readme or stale asset is not sufficient by itself. ### 2. Confirm Identity and Capability Use only approved test identities. Record the current role and the exact capability checked by the operation. Subscriber, customer, author, editor, and administrator roles are not interchangeable. Do not bridge missing authorization with password spraying, credential stuffing, or unrelated leaked credentials. ### 3. Validate State Change With Synthetic Data Use a uniquely named synthetic post, object, or inert file. Record: - request and identity; - response and resulting object ID; - location and content; - expected authorization policy; - cleanup result. If the object cannot be removed safely, stop before creation. ### 4. Separate Upload From Execution An accepted upload proves only an upload boundary. Establish executable handling separately: - server maps the stored extension to an interpreter; - MIME and extension validation permit the tested type; - storage path is web reachable; - plugin processing does not rename or sanitize the file; - a benign marker can execute in the approved environment. Never deploy a command shell as a generic proof. ### 5. Evaluate Administrative Impact Administrative control requires an approved admin-only effect, such as reading a synthetic private setting or changing a disposable configuration value and restoring it. User enumeration, REST metadata, or an available login page does not establish account takeover. ### 6. Assemble the Path Use `cross-attack-chains` to connect only confirmed transitions. Use `wordpress-cors-xmlrpc-rce-chain` when CORS and XML-RPC are actual prerequisites, not merely additional findings on the same installation. ## Pitfalls - Open registration normally creates a low-privilege role. - XML-RPC method presence is not authorization to call that method. - Enabled PHP process functions do not create an upload primitive. - Plugin version evidence can be stale or backported. - A staging site may have a separate database and no production trust path. - Failure of a prerequisite is evidence that the proposed chain stops there. ## Verification - Component identity, version, route, and prerequisites are confirmed. - The approved identity has the exact required capability. - State changes use synthetic resources and are reversed. - Upload and execution are demonstrated as separate steps. - Administrative impact uses an approved disposable action. - Every missing step remains inferred or not tested.
GitHub에서 보기