wordpress molester
Find a file
2026-06-08 16:14:42 +00:00
cmd persist Wordfence API key 2026-06-08 16:14:42 +00:00
internal upgrade intelligence imports and reports 2026-06-08 16:01:41 +00:00
.gitignore harden scanner and documentation 2026-06-08 14:42:20 +00:00
go.mod first commit 2026-06-08 14:31:10 +00:00
go.sum first commit 2026-06-08 14:31:10 +00:00
main.go persist Wordfence API key 2026-06-08 16:14:42 +00:00
README.md persist Wordfence API key 2026-06-08 16:14:42 +00:00

wpmolest

wpmolest is a Go CLI for authorized WordPress vulnerability intelligence, component fingerprinting, safe exposure detection, and Nuclei-style WordPress templates.

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

It is built to be fast and conservative: fingerprint once, reuse evidence, dedupe requests, suppress soft-404 noise, avoid state-changing traffic, and downgrade findings when evidence is weak.

Safety Model

wpmolest is non-destructive.

  • 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.

Use it only for systems you are authorized to assess.

Install

From Source

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

If the checkout has broken VCS metadata, build without VCS stamping:

go build -buildvcs=false

The binary is created as ./wpmolest.

Go Install

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

Verify

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 thorough --output csv --output-file findings.csv https://example.org
cat targets.txt | ./wpmolest scan --mode fast -

Commands

wpmolest scan [flags] <target...>
wpmolest --api-set <wordfence-api-key>
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 --url <feed-url>[,<feed-url>] --source <source>
wpmolest db stats
wpmolest version

Common Flags

--mode fast|balanced|thorough|paranoid
--output console|tree|csv|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'
--verbose
--debug
--quiet
--ci

Scan Modes

  • fast: passive-heavy fingerprinting and high-throughput vulnerability matching.
  • balanced: default mode with safe exposure checks and built-in WordPress templates.
  • thorough: deeper safe probing and broader component evidence gathering.
  • paranoid: maximum safe coverage without destructive requests.

Target Input

Single target:

wpmolest scan https://example.org

Multiple targets:

wpmolest scan https://a.example https://b.example

File:

wpmolest scan --targets targets.txt

Stdin:

cat targets.txt | wpmolest scan -

Targets are canonicalized and deduplicated.

Vulnerability Database

The local database stores normalized advisories with:

  • WordPress core, plugin, and theme component types.
  • Slugs and normalized component names.
  • CVEs and aliases.
  • Affected ranges, introduced versions, fixed versions, and patched versions.
  • Severity, CVSS score, CVSS vector, CWE, EPSS, and exploit maturity.
  • Authentication class when the source provides it.
  • References, remediation, source, disclosure date, last updated date, and stale-source marking.

Default database path:

~/.wpmolest/db

Use a custom database path:

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

Import Local Advisory 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 Intelligence

Wordfence Intelligence v3 requires a free API key. Create one in your Wordfence account and export it:

export WORDFENCE_API_KEY='your-api-key'
wpmolest db update --source wordfence

To save the key permanently for future runs:

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

The saved key is written to ~/.wpmolest/config.json with 0600 file permissions. --api-key and WORDFENCE_API_KEY still override the saved value for one-off runs.

Equivalent explicit form without saving:

wpmolest db update \
  --source wordfence \
  --api-key "$WORDFENCE_API_KEY" \
  --url https://www.wordfence.com/api/intelligence/v3/vulnerabilities/production

The Wordfence importer expands each vulnerability's affected software records into component-specific advisories with affected ranges, patched versions, CVE, CVSS, CWE, references, remediation, and authentication class.

Update From 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

Database Stats

wpmolest db stats

If the database has zero advisories, scan output will explicitly warn that vulnerability results cannot be trusted until advisory data is imported or updated.

Outputs

Tree report:

wpmolest scan --output tree https://example.org

CSV:

wpmolest scan --output csv --output-file findings.csv https://example.org

Full JSON report:

wpmolest scan --output json --output-file report.json https://example.org

The JSON report includes target summary, database advisory count, components, reportable findings, informational findings, exposures, and duration.

JSONL finding stream:

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

SARIF:

wpmolest scan --output sarif --output-file wpmolest.sarif https://example.org

Markdown:

wpmolest scan --output markdown --output-file report.md https://example.org

CI mode exits with code 1 only for reportable findings. Informational hardening notes do not fail CI unless verbose reporting is explicitly requested.

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/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.

Validate templates before scanning:

wpmolest templates validate templates/*.yaml

List templates:

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/install actions are rejected.
  • Forbidden headers such as Host, Content-Length, Transfer-Encoding, and Connection are rejected.

False-Positive Controls

wpmolest is intentionally conservative:

  • 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.
  • 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.

Output Fields

CSV and JSONL findings include:

  • target
  • type
  • slug
  • version
  • severity
  • auth_type
  • cve
  • cvss_score
  • cvss_vector
  • title
  • fixed_version
  • status
  • confidence
  • source
  • evidence

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.