wpmolest

wpmolest is a go cli for wordpress vulnerability intelligence, component fingerprinting, safe exposure detection, and nuclei-style wordpress templates.

repository: https://git.nadeko.net/legs/wpmolest

built for pwnage, stealth intel, and zero-bullshit evidence. we wuz h4x0rs, pwn dem wordpressed breasts.

---

safety model (non-destructive, obvs)

wpmolest is non-destructive by design. because getting caught is for amateurs.

• no brute force.
• no login attacks.
• no exploit execution.
• no shell upload.
• no persistence.
• no state-changing template requests.
• no cross-host template requests.
• no vulnerability match from unknown component versions.

---

install

git clone https://git.nadeko.net/legs/wpmolest.git
cd wpmolest
go build

if the checkout has broken vcs metadata:

go build -buildvcs=false

install directly with go:

go install git.nadeko.net/legs/wpmolest@latest

verify the build:

go test ./...
go vet ./...
go build

---

quick start

./wpmolest scan https://example.org
./wpmolest scan --mode fast --output tree https://example.org
./wpmolest scan --mode thorough --output json --output-file report.json https://example.org
./wpmolest scan --mode supamolest --output tree https://example.org
cat targets.txt | ./wpmolest scan --mode fast -

---

commands

wpmolest scan [flags] <target...>
wpmolest fingerprint [flags] <target...>
wpmolest inventory [flags] <target...>
wpmolest vulns [flags] <target...>
wpmolest templates validate <files...>
wpmolest templates list [dir]
wpmolest db import [flags] <files...>
wpmolest db update --source <source> [--url <feed-url>]
wpmolest db stats
wpmolest version
wpmolest --api-set <wordfence-api-key>
wpmolest --wpscan-api-set <wpscan-api-key>

---

common flags

--mode fast|balanced|thorough|supamolest|paranoid
--output console|tree|csv|json|jsonl|sarif|markdown
--output-file <path>
--targets <file>
--templates <dir>
--db <dir>
--concurrency <n>
--host-concurrency <n>
--timeout <seconds>
--retries <n>
--proxy <url>
--header 'Header: value,Header2: value'
--cookie 'name=value; name2=value2'
--public-intel
--public-wporg
--wpscan-api-key <key>
--verbose
--debug
--quiet
--ci

---

scan modes

• fast: high-throughput passive-heavy fingerprinting and version matching.
• balanced: default safe exposure checks, component detection, and built-in wordpress templates.
• thorough: deeper safe probing and broader component evidence gathering.
• supamolest: thorough local scanning plus public wordpress.org plugin/theme registry validation, live wpscan api matching when a token is configured, and public epss/cisa kev enrichment for cve findings.
• paranoid: maximum safe coverage without destructive requests.

supamolest mode does not create findings from public cve feeds or wordpress.org registry metadata alone. public enrichment only decorates existing cve findings with epss and cisa kev evidence. wordpress.org metadata validates public plugin/theme slugs and names, and weak unconfirmed slugs are kept as inventory-only unless stronger target evidence exists. live wpscan api findings still require a detected component, a usable detected version, and an affected/fixed range match.

---

api keys

wordfence intelligence database updates require a wordfence api key:

wpmolest --api-set 'wordfence-api-key'
wpmolest db update --source wordfence

wpscan live advisory lookup requires a wpscan api token:

wpmolest --wpscan-api-set 'wpscan-api-key'
wpmolest scan --mode supamolest https://example.org

saved keys are written to ~/.wpmolest/config.json with 0600 permissions. one-off environment variables and flags are also supported:

WORDFENCE_API_KEY='key' wpmolest db update --source wordfence
WPSCAN_API_TOKEN='key' wpmolest scan --mode supamolest https://example.org
wpmolest scan --wpscan-api-key 'key' --mode supamolest https://example.org

public enrichment uses no-registration feeds:

• wordpress.org plugin information api for public plugin slug/name validation.
• wordpress.org theme information api for public theme slug/name validation.
• first epss api for cve exploit probability.
• cisa known exploited vulnerabilities feed for confirmed exploited cves.

these feeds do not create vulnerabilities by themselves.

---

target input

wpmolest scan https://example.org
wpmolest scan https://a.example https://b.example
wpmolest scan --targets targets.txt
cat targets.txt | wpmolest scan -

targets are canonicalized and deduplicated. redirects are handled within the configured client policy, and template requests are scoped to the target host.

---

vulnerability database

default path:

~/.wpmolest/db

use a custom path:

wpmolest scan --db ./db https://example.org

the database stores normalized advisories for wordpress core, plugins, and themes, including cves, aliases, affected ranges, fixed versions, severity, cvss, cwe, epss, exploit maturity, authentication class, references, remediation, source, disclosure date, last updated date, and stale-source marking.

import local and private packs:

wpmolest db import --source local --format json advisories.json
wpmolest db import --source custom --format yaml private-pack.yaml
wpmolest db import --source wpscan wpscan-data.json
wpmolest db import --source nvd nvdcve-1.1-recent.json
wpmolest db import --source wordfence wordfence.json
wpmolest db import --source patchstack patchstack.json
wpmolest db import --source ghsa ghsa.json

update from wordfence:

wpmolest db update --source wordfence

update from explicit urls:

wpmolest db update --source nvd --url https://example.org/nvd.json
wpmolest db update --source custom --format json --url https://example.org/private-pack.json

inspect database status:

wpmolest db stats

if the database has zero advisories, scan output warns that vulnerability results cannot be trusted until advisory data is imported or updated.

---

outputs

wpmolest scan --output tree https://example.org
wpmolest scan --output csv --output-file findings.csv https://example.org
wpmolest scan --output json --output-file report.json https://example.org
wpmolest scan --output jsonl https://example.org
wpmolest scan --output sarif --output-file wpmolest.sarif https://example.org
wpmolest scan --output markdown --output-file report.md https://example.org

the full json report includes target summary, database advisory count, components, reportable findings, informational findings, exposures, evidence, and duration. tree output groups vulnerabilities by component, severity, authentication class, cve, cvss, exploit maturity, and epss where available.

ci mode exits with code 1 for reportable findings:

wpmolest scan --ci --output jsonl https://example.org

---

fingerprinting

wpmolest fingerprint https://example.org
wpmolest inventory https://example.org

detection sources include:

• wordpress generator tags.
• rest and feed indicators.
• asset query-string versions.
• wp-content/plugins and wp-content/themes paths.
• plugin readme, changelog, and stable-tag files when exposed.
• theme style.css metadata when exposed.
• rest namespace hints.

each detected component carries a confidence score and evidence source.

---

templates

templates are yaml and wordpress-specific. they support safe raw/generated requests, variables, payload lists, component-aware execution, matchers, extractors, dsl checks, evidence capture, and request dedupe through the http cache.

wpmolest templates validate templates/*.yaml
wpmolest templates list templates/

template safety rules:

• only get, head, and options are accepted.
• request bodies are rejected.
• absolute urls are rejected.
• cross-host requests are rejected.
• dangerous request patterns such as delete, update, upload, and install actions are rejected.
• forbidden headers such as host, content-length, transfer-encoding, and connection are rejected.

---

false-positive controls

• unknown versions do not create vulnerability findings.
• non-numeric versions such as trunk do not match advisory ranges.
• weak component fingerprints remain inventory-only.
• advisory matches require a detected version and confidence gate.
• version-only matches are potential, never confirmed.
• live api findings require affected-range evidence.
• public epss and kev feeds enrich findings but do not create them.
• wordpress.org registry data validates component identity but never supplies installed target versions.
• exposure checks require content-specific evidence.
• exposure checks are compared against a random 404 control path to suppress routed fallback pages.
• informational hardening checks are separated from reportable vulnerabilities.
• stale advisory sources lower confidence.

---

finding fields

csv, json, and jsonl findings include target, url, component type, slug, component name, detected version, affected range, fixed version, title, cve aliases, severity, cvss, cwe, epss, exploit maturity, authentication class, confidence, status, evidence, request metadata, response metadata, source advisory, references, remediation, and timestamp.

---

development

go test ./...
go vet ./...
go build

no generated binary is committed. the repository ignores local build artifacts, logs, coverage files, and local database directories.

---

final words

wpmolest is for authorized security research, bug bounties, and your own infrastructure.
but you already knew that, right?

now go forth, molest those wp instances, and may your findings be juicy.