attack-patterns-reference

Attack Patterns Reference

This catalog maps observed web and WordPress behavior to the skill that owns its validation. Pattern IDs are navigation labels. They do not establish exploitability, severity, prevalence, or a confirmed attack path.

When to Use

• A recon result needs to be classified before focused testing.
• Several verified behaviors may form a candidate attack path.
• A WordPress, CORS, XML-RPC, source-leak, or exposed-service signal needs an owning validation procedure.

Do not use the catalog as a scanner finding list or a substitute for the verification section of the owning skill.

Prerequisites

• An authorized target and current scope constraints.
• Captured evidence for the observation being classified.
• The tools and identities required by the selected follow-up skill.

How to Run

1. Match the observed behavior to the closest pattern.
2. Open the owning skill listed in the table.
3. Check its prerequisites and side effects.
4. Run the smallest validation and negative control that can falsify the hypothesis.
5. Record the result as observed, inferred, confirmed, or not tested.

Procedure

General Web Patterns

Pattern	Initial signal	Owning skill
WordPress user exposure	REST or author route returns user metadata	wp-mass-recon
Credentialed CORS	Untrusted origin reflected with credentials	cors-credential-wordpress
XML-RPC methods	Protocol-valid system.listMethods response	xmlrpc-exploitation
XML-RPC SSRF	pingback.ping reaches a controlled callback	xmlrpc-exploitation
Public registration	Registration is enabled	wp-mass-recon
Plugin surface	REST namespace, asset, or version marker	wordpress-plugin-hunt
Staging difference	Non-production host has weaker controls	staging-subdomain-hunt
Exposed error log	Response contains real application errors	error-log-mining
PHPInfo exposure	PHP configuration page is reachable	phpinfo-to-rce
Source or backup leak	Response contains repository, configuration, or database content	source-leak-hunt
JavaScript secret candidate	Bundle contains a credential-shaped value	js-secrets-extraction
Public service	Non-HTTP or administrative service is internet reachable	port-service-discovery

See references/p-patterns.md for the extended pattern notes.

CORS Variants

Variant	Initial signal	Required validation
Origin reflection with credentials	Untrusted origin plus ACAC: true	Credentialed browser reads non-public data
Null-origin trust	ACAO: null plus ACAC: true	Sandboxed browser reads non-public data
Wildcard without credentials	ACAO: *	Determine whether the response is already public
Credentialed preflight	OPTIONS accepts origin, method, and headers	Actual request succeeds and browser exposes response
Auth-route CORS	CORS headers appear on a protected route	Approved session returns readable protected data
Plugin-specific CORS	Only one plugin namespace accepts the origin	Response contains protected data or performs an authorized test action
Environment-specific CORS	Staging and production policies differ	Demonstrate impact in the authorized environment
Third-party allowlist	One external service origin is trusted	Establish control of that origin and protected-data access

Candidate Attack Paths

These are composition templates, not confirmed findings:

Path	Preconditions that must be verified
CORS to protected-data read	Approved session, untrusted origin, browser-readable non-public response
XML-RPC SSRF to cloud metadata	Controlled callback, reachable metadata service, usable secondary impact
Open registration to upload	Approved synthetic account, upload-capable role, executable file path
Exposed log to account access	Current credential material, approved identity, valid authentication control
Staging exposure to production impact	Shared trust boundary, reusable secret or deployment path, explicit scope

Use cross-attack-chains only after every prerequisite is independently verified.

Pitfalls

• Historical frequency is not evidence about the current target.
• A product name, version, status code, or header does not prove impact.
• A catch-all route can make sensitive paths appear reachable.
• Public client identifiers and intentionally public APIs are not automatically credentials or authorization failures.
• Pattern prerequisites change across product and plugin versions.
• An attack path inherits the uncertainty of its weakest step.

Verification

• Match every pattern to captured request and response evidence.
• Run a negative control that distinguishes the result from public or generic behavior.
• Use a browser for CORS impact; headers alone are insufficient.
• Use a controlled callback for blind SSRF; a protocol status alone is insufficient.
• Use exact component and prerequisite checks before associating a CVE.
• Report only the impact reproduced within scope.