Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Map WordPress core, REST, XML-RPC, plugins, themes, authentication boundaries,
and adjacent installations before selecting a vulnerability-specific test.
WordPress presence, a public route, or a version match is not a finding by
itself.
When to Use
HTML, headers, assets, cookies, or routes identify WordPress.
/wp-json/, /wp-login.php, /xmlrpc.php, or /wp-content/ is reachable.
JavaScript or source code references a WordPress backend.
A staging or subdirectory installation may differ from the main site.
Prerequisites
Explicit authorization and current target boundaries.
curl and jq; wpscan is optional.
Approved test identities for role or authorization checks.
A controlled callback service only when blind SSRF testing is authorized.
Explicit approval immediately before registration, upload, password, plugin,
or other state-changing tests.
Confirm a component with at least two signals when practical: an asset path,
REST namespace, readme or changelog, HTML marker, or versioned file. Match CVEs
only after establishing the exact affected version and prerequisite.
Use wordpress-plugin-hunt for plugin discovery and version validation.
Do not follow redirects during protocol classification. A valid
methodResponse proves XML-RPC behavior; a status code alone does not.
Credential testing, multicall amplification, uploads, and SSRF bypasses require
their own authorization and safety limits. Use xmlrpc-exploitation only when
the relevant method and prerequisites have been confirmed.
6. Check Staging and Secondary Installations
Certificate transparency, archives, and asset paths may reveal staging hosts or
subdirectory installations. Compare:
WordPress and plugin versions;
authentication and WAF behavior;
REST and XML-RPC exposure;
debug configuration and source files;
shared cookies, credentials, storage, and deployment paths.
A weaker staging control matters only when the environment is in scope and its
impact is demonstrated. Use staging-subdomain-hunt for a bounded comparison.
7. Check Source and Error Exposure
Probe only the paths justified by the observed stack. Validate content rather
than status:
Candidate
Required content
.git/HEAD
Git ref such as ref: refs/heads/...
.env
Configuration assignments, not generic HTML
debug.log or error_log
Real application errors or sensitive runtime data
backup archive
Correct file signature and meaningful contents
directory listing
Directory index markers and actual entries
Use source-leak-hunt and error-log-mining; retain only the minimum sanitized
sample needed to demonstrate exposure.
8. Build a Candidate Attack Path
Connect only verified prerequisites:
observed component
-> exact version and configuration
-> reachable vulnerable operation
-> approved identity or synthetic object
-> reproduced security impact
Registration, XML-RPC, an upload route, and an executable PHP configuration do
not automatically form an RCE chain. Confirm the role capability, upload
validation, storage path, and execution behavior independently.
Pitfalls
WordPress routes frequently sit behind CDN, cache, or catch-all behavior.
GET /xmlrpc.php returning 405 does not classify a valid POST method call.
A REST namespace does not prove that a plugin operation is unauthenticated.
Public author metadata is not automatically sensitive.
Plugin versions can be hidden, backported, or reported by stale assets.
Large logs, sitemaps, and REST collections can cause unnecessary data
collection; request bounded samples.
Default credential attempts, password spraying, registration, uploads, and
writes require explicit authorization and agreed lockout limits.
Verification
WordPress is confirmed from content, not only a status code.
Every component finding includes a second signal or explains why one is not
available.
Every CVE association includes exact version and prerequisite evidence.
REST authorization uses approved identities and a negative control.
CORS impact is reproduced in a browser with non-public data.
XML-RPC behavior uses a protocol-valid response or controlled callback.
State-changing tests use synthetic records, preserve cleanup evidence, and
remain within scope.
