WordPress Penetration Testing 2026: Methodology, Tools & CVEs

WordPress powers 41.9% of all websites as of May 2026 (W3Techs) and 59.5% of all sites running an identifiable CMS. That scale makes WordPress one of the most consequential attack surfaces on the public web — and one of the best-instrumented from a defender’s perspective. The WPScan vulnerability database alone now catalogs 73,213 distinct WordPress core, plugin, and theme vulnerabilities (WPScan), and Wordfence’s 2024 Annual WordPress Security Report documented a 68% year-over-year increase in disclosed vulnerabilities from 2023 to 2024, with Cross-Site Scripting (XSS) accounting for the majority of new disclosures (Wordfence 2024 Annual Report).

This guide explains how to penetration test a WordPress site in 2026. It covers the planning phase, a methodology aligned with the OWASP Web Security Testing Guide (WSTG), a neutral feature comparison of the major tools, three recent CVE case studies showing how real exploits unfold, reporting templates, and what an ongoing security cadence looks like beyond one-off tests. It is written for security-aware developers, technical administrators, and consultants — not for offensive operators looking for novel exploits.

What This Guide Covers

This is a working reference, not a “learn pentesting in 30 minutes” headline. The structure follows the order you would actually move through a test:

Definitions — pentest versus vulnerability scan versus audit.
When penetration testing makes sense (and when it does not).
Planning — scope, legal authorization, success criteria.
Methodology mapped to OWASP WSTG.
WordPress-specific vulnerability categories with current data.
Three recent CVE case studies (2024-2026) with exploitation paths and remediation.
Tools — neutral feature comparison and working command examples.
Lab setup for safe practice.
Reporting — template structure, CVSS scoring, prioritization.
Remediation guidance per vulnerability category.
Ongoing security beyond one-off tests.
FAQs and curated authoritative resources.

If you are looking only for a tools list or a one-page checklist, jump to the Tools section or the Authoritative Resources at the end. If you are evaluating whether your organization needs a formal pentest, the Decision Framework section is the right starting point.

Penetration Testing vs. Vulnerability Scanning vs. Security Audit

These three terms are often used interchangeably, which causes scoping problems and budget mismatches. They are distinct activities:

Vulnerability scanning is an automated process that compares a target against a database of known weaknesses. Tools like WPScan and OWASP ZAP run vulnerability scans. Output is a list of potential issues — usually with a high false-positive rate, because the scanner cannot verify whether each detected weakness is actually exploitable in your specific environment.

Penetration testing goes a step further. A penetration test takes the output of a vulnerability scan (or starts from scratch with reconnaissance), then actively attempts to exploit identified weaknesses. The goal is to confirm what is genuinely reachable and to demonstrate the impact (data accessed, privileges escalated, persistence gained). A penetration test produces a smaller, higher-confidence findings list than a vulnerability scan, plus a narrative of how each finding was reached.

Security audit is a broader exercise — typically including pentest results but also covering policy, access control reviews, hosting configuration, backup integrity, incident response readiness, and compliance posture. A security audit asks “is this organization’s WordPress operation secure as a whole?” rather than “what can a remote attacker do to this site right now?”

For most WordPress site owners, the practical sequence is: regular vulnerability scanning (automated, frequent), periodic penetration testing (manual, annually or semi-annually), and an audit (typically only on major changes or for compliance triggers).

When WordPress Penetration Testing Makes Sense

Not every site benefits from a formal penetration test. The activity has a real cost — direct (consultant fees if outsourced; engineer time if internal) and indirect (the disruption of a test scope being negotiated, environments being snapshotted, stakeholders being briefed). The decision should be evidence-based.

Signs that DIY testing is appropriate

The site is non-critical (personal blog, low-traffic informational site)
No regulated data is processed (no PCI cardholder data, no PHI under HIPAA, no GDPR-special-category data at meaningful volume)
The administrator has working command-line experience and time to learn the tooling
A failure-tolerant testing window is available (off-peak hours, with backups verified)
The goal is education or due diligence, not a compliance artifact

Signs that a professional service is warranted

The site processes payments directly (PCI DSS scope) or stores sensitive personal data at scale
The site is business-critical (downtime has measurable revenue or contractual impact)
A compliance framework (PCI DSS, HIPAA, SOC 2, ISO 27001) requires independent testing as evidence
The team has no in-house security skill set and the cost of a missed finding exceeds the cost of an external engagement
The site has custom plugins or custom theme code where a methodical code review beyond automated scanning is appropriate
A prior incident has occurred and you need an independent assessment of what was missed

Compliance-driven testing

Several frameworks specify penetration testing as a control:

PCI DSS (v4.0) requires penetration testing at least annually and after any significant change to in-scope systems (Requirement 11.4).
HIPAA does not specify pentesting verbatim, but the Security Rule’s “evaluation” requirement (45 CFR 164.308(a)(8)) is typically interpreted by auditors to include periodic technical security assessment.
ISO 27001:2022 Annex A.8.8 covers technical vulnerability management; ISO 27001-aligned organizations usually pentest annually.
SOC 2 Type II reports increasingly include pentest evidence under the Security criterion.

Compliance pentest scope is narrower and more prescriptive than a general-purpose pentest. If the test is for a compliance artifact, design the scope to match the framework’s exact wording — not the auditor’s verbal preference.

Planning Your WordPress Penetration Test

The work before any tool runs against any URL is the difference between a useful test and an expensive scan output.

Defining scope and goals

A WordPress pentest scope should explicitly cover:

Targets: which hostnames, IP addresses, subdomains, and staging environments are in-scope, and which are out-of-scope.
Surfaces: WordPress admin (/wp-admin), front-end, REST API endpoints, XML-RPC endpoint, file uploads, comment system, third-party integrations.
Auth states: which user roles will be tested (unauthenticated, Subscriber, Contributor, Author, Editor, Administrator).
Forbidden actions: e.g., do not actually delete content, do not lock real user accounts, do not run denial-of-service against shared infrastructure.
Time window: business hours vs. after hours, business days only, holiday exclusions.
Out-of-band channels: how the testing party will reach the site owner if something looks like an active live incident (escalation path).

Document each of these. A one-page scope is more useful than a 20-page legal document for the actual testing team.

Legal authorization — sample template

Penetration testing without explicit written authorization is, in most jurisdictions, a crime under computer-misuse laws (CFAA in the US, Computer Misuse Act in the UK, equivalent statutes elsewhere). Even on a site you own, a written authorization protects you from downstream complications — for example, if shared hosting infrastructure is also targeted, or if a third-party CDN flags the activity and contacts law enforcement.

A minimum authorization document should include:

WORDPRESS PENETRATION TESTING AUTHORIZATION

Authorizing party: [Legal entity name, address]
Tester: [Individual name or company, contact details]
Target systems: [Hostnames, IP ranges, subdomains in scope]
Out-of-scope systems: [Anything not above is out-of-scope]
Authorized testing window: [Start date/time, end date/time, time zone]
Testing types authorized: [Vulnerability scanning, manual penetration testing,
  social engineering Y/N, denial-of-service Y/N (typically N)]
Restrictions: [No data exfiltration beyond proof-of-access screenshots,
  no destructive actions, no real-user account locking]
Emergency contact: [24/7 phone for incident response]
Indemnification: [Scope of liability waiver]

Signed: [Authorizing party representative]
Date: [Date]
Signature: [Wet or qualified electronic signature]

If working with shared hosting (e.g., WordPress.com VIP, WP Engine, Kinsta), check the provider’s penetration testing policy and obtain provider authorization where required. Some providers have explicit pentest authorization forms; others require advance notification.

Test environment vs. production safety

Whenever possible, run the test against a staging environment that mirrors production. Mirror in this context means:

Same WordPress core version
Same active plugins and themes at the same versions
Same PHP version and server-side stack
Realistic-but-non-sensitive data set (synthetic users, content that triggers real code paths)
Same hosting configuration (cache, CDN, WAF, SSL termination)

If only production is available — which is sometimes the reality on small operations — testing safety becomes the dominant constraint. Take a verified full backup immediately before starting, document the exact start time, and have a known-good rollback procedure ready.

Setting success criteria

A pentest’s success is not “we found vulnerabilities” — it is “we systematically tested the in-scope surfaces and produced an actionable report.” Define before starting:

What deliverable counts as completion (executive summary plus technical findings, or technical findings only)
What turnaround time is acceptable from test end to delivered report
How findings will be communicated during the test if a critical issue is discovered mid-engagement (immediate notification vs. end-of-engagement report)
Who signs off on completion

Methodology — Mapped to OWASP Web Security Testing Guide

The OWASP Web Security Testing Guide (WSTG) is the most widely-adopted framework for application-level penetration testing (owasp.org/www-project-web-security-testing-guide). It defines testing categories, individual test cases, and expected procedures. For WordPress, the WSTG framework applies almost entirely — with a small set of WordPress-specific additions covered below.

Information gathering (WSTG-INFO)

The reconnaissance phase establishes what is reachable, what versions are running, and what user enumeration is possible.

For WordPress specifically, useful starting commands:

# Detect WordPress and version
curl -sL https://example.com/ | grep -E "wp-(content|includes)|generator.*WordPress"

# Discover users via REST API (often left open)
curl -s https://example.com/wp-json/wp/v2/users

# Discover users via /?author=N enumeration (older configs)
for i in 1 2 3 4 5; do
  curl -sI https://example.com/?author=$i | grep -i location
done

# WPScan combined enumeration
wpscan --url https://example.com --enumerate u,vp,vt

WPScan v4.0.0 (released May 2026) supports user, vulnerable plugin (vp), all plugin (ap), vulnerable theme (vt), and configuration backup (bf) enumeration in a single command (WPScan GitHub). WPScan is owned and maintained by Automattic.

Configuration and deployment testing (WSTG-CONF)

Configuration issues are over-represented in real-world WordPress incidents because they are often the result of operational drift rather than code bugs. Test cases:

Is wp-config.php accessible via the web (it should not be)?
Are backup files (wp-config.php.bak, *.sql, *.zip) reachable in the document root?
Are file permissions correct (typically 644 for files, 755 for directories, more restrictive for wp-config.php)?
Is the WordPress admin reachable from the public internet, or restricted by IP/VPN?
Are debug logs (debug.log) accessible at default paths?
Are HTTP security headers present (Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security)?

# Check for common backup file leakage
for f in wp-config.php.bak wp-config.php.old backup.sql backup.zip db.sql; do
  curl -sI https://example.com/$f | head -1
done

# Verify HTTP security headers
curl -sI https://example.com/ | grep -iE "content-security|x-frame|strict-transport"

Identity and authentication testing (WSTG-IDNT, WSTG-ATHN)

The most common entry point for compromised WordPress sites remains credential abuse — either through weak passwords, leaked credentials reused from other breaches, or session management flaws.

Test cases:

Account lockout: how many failed attempts trigger lockout, and on what time window? NIST SP 800-63B (current guidance) recommends rate-limiting rather than hard lockout counts; 100 attempts per account per 30 days is a defensible threshold, with progressive delay between attempts (NIST SP 800-63B).
2FA enforcement: is 2FA available, and is it enforced for administrative roles?
Session timeout behavior
Password reset flow security (token entropy, token reuse, leakage via referer)
/wp-json/wp/v2/users exposure (current authentication mechanism behavior)

Session management testing (WSTG-SESS)

WordPress session management uses cookies (wordpress_logged_in_*) signed with the keys defined in wp-config.php. Test for:

Cookie attributes: Secure, HttpOnly, SameSite
Logout effectiveness — does logging out invalidate the session server-side
Concurrent session handling

Input validation testing (WSTG-INPV)

XSS, SQL injection, and command injection live in this category. WordPress has core protections (wp_kses_post, esc_attr, esc_html, prepared statements via $wpdb), but custom plugin and theme code regularly fails to use them correctly.

Test workflow:

Identify input points (forms, URL parameters, search, comments, REST API endpoints)
For each input point, attempt XSS payloads (stored, reflected, DOM-based)
For each input point that interacts with the database, attempt SQL injection (use sqlmap against URL parameters where appropriate)
For file upload endpoints, attempt to upload polyglot files, oversized files, and files with unexpected MIME types

WordPress-specific tests beyond OWASP standard

OWASP WSTG is application-stack-agnostic. WordPress-specific surfaces that warrant explicit testing:

XML-RPC endpoint (/xmlrpc.php): historically abused for amplified brute-force via system.multicall. Should typically be disabled if not actively used.
REST API authentication and rate-limiting (/wp-json/): testable for unauthenticated information disclosure, authentication bypass (see CVE-2024-10924 case study below), and rate-limit absence.
AJAX endpoints (/wp-admin/admin-ajax.php): action-based dispatcher; each action’s authorization needs to be verified.
Plugin auto-update channels (where enabled): integrity of update sources, signature verification.

WordPress-Specific Vulnerability Categories — 2024-2025 Data

Plugin vulnerabilities

Plugins remain the largest contributor to disclosed WordPress vulnerabilities. The Wordfence 2024 Annual WordPress Security Report (wordfence.com) documented:

68% increase in disclosed vulnerabilities from 2023 to 2024
81% of 2024 vulnerabilities scored Medium severity on CVSS
34% of 2024 vulnerabilities required Contributor-level access to exploit (the most common access requirement category)
68% of 2024 vulnerabilities were considered low-risk because they required authentication or user interaction
Approximately 35% of vulnerabilities disclosed in 2024 remained unpatched as of the report’s publication (April 2025)

XSS accounted for the majority of new disclosures, and Wordfence blocked over 9 billion XSS exploit attempts in 2024.

The practical implication for pentesting: most disclosed plugin vulnerabilities are not “single-click full compromise” scenarios. They typically require some level of authentication or user interaction — which means realistic pentest scenarios should include testing from multiple authenticated roles, not just unauthenticated probing.

Theme vulnerabilities

Theme vulnerabilities are less common in absolute count than plugin vulnerabilities but tend to cluster around two patterns:

Custom theme code that handles user input without proper escaping (XSS, SQL injection in theme search forms, comment forms, or custom queries)
Bundled JavaScript libraries with known CVEs that the theme has not updated

The first half of 2025 saw a meaningful uptick in disclosed theme vulnerabilities as more premium theme developers joined Patchstack’s bug bounty program (Patchstack 2025 Mid-Year Report).

Core WordPress vulnerabilities

Core vulnerabilities are rare relative to plugin/theme disclosures, but they exist and matter when they appear. WordPress 6.8.x had an Authenticated (Author+) Stored XSS vulnerability disclosed in 2025 (Wordfence vulnerability database), illustrating that even core requires periodic testing.

Configuration and server-side vulnerabilities

This category includes exposed wp-config.php files, weak file permissions, missing security headers, accessible debug logs, and improperly configured web server rules. These are typically discovered via the WSTG-CONF test cases above rather than via vulnerability scanners.

Real CVE Case Studies — 2024 and 2025

Three cases below illustrate how recent WordPress vulnerabilities unfolded in practice. Each case is selected to represent a different attack category and demonstrate a different pentest lesson.

CVE-2024-10924 — Really Simple Security plugin authentication bypass

CVSS 3.1: 9.8 (Critical)
Disclosed: November 6, 2024
Affected: Really Simple Security plugin versions 9.0.0 through 9.1.1.1
Impact at disclosure: Approximately 4 million WordPress sites

The vulnerability sat in the plugin’s REST API two-factor authentication flow. The check_login_and_get_user function was responsible for validating credentials and returning either a valid user object or an error response. The calling code that handled successful authentication did not validate that the returned value was actually a user object — it proceeded to authenticate and redirect regardless. An unauthenticated attacker could craft a request to the 2FA REST endpoint and effectively log in as any user, including administrators (WPSec full analysis).

The exploitation path was:

Send a POST request to the affected REST endpoint with a target user ID
The endpoint’s authentication check returned an error
The calling code ignored the error and authenticated the requester
Session cookie returned for the target user

Patched in version 9.1.12. CVE details available at the NIST NVD entry for CVE-2024-10924.

Pentest lessons: Authentication flow testing should not rely on whether a flow is documented to require credentials — test what the flow actually accepts. REST API endpoints in particular need direct probing because they often bypass front-end authentication assumptions. The fact that this vulnerability sat in a plugin specifically marketed as a security plugin reinforces the principle that “security plugin” labels do not exempt code from review.

CVE-2025-26909 — WP Ghost plugin LFI to RCE chained exploit

Affected: WP Ghost plugin
Disclosed: 2025
Impact at disclosure: Approximately 200,000 sites

WP Ghost is positioned as a WordPress hardening plugin — its product purpose is to obscure WordPress fingerprints and reduce attack surface. The vulnerability allowed Local File Inclusion (LFI) in one of the plugin’s handlers, which could then be chained into Remote Code Execution by combining LFI with PHP wrapper abuse or log poisoning (Patchstack advisory).

The exploit chain mirrors a classic web application pentest pattern: discover an LFI primitive, identify what files the LFI can read, then escalate to code execution via either log file inclusion (if PHP logs are reachable), php://input wrapper abuse, or session file manipulation.

Pentest lessons: Chained vulnerabilities are the most consequential category — a single LFI looks like an information disclosure issue (Medium severity) until it becomes an RCE (Critical). When pentesting plugins that handle file paths, always evaluate not just the immediate primitive but what it chains into. Plugins that are sold for “security hardening” warrant the same scrutiny as any other plugin; the marketing category does not affect the code review.

CVE-2025-6327 and CVE-2025-6325 — King Addons for Elementor

Affected: King Addons for Elementor plugin
Disclosed: 2025
Impact at disclosure: Approximately 10,000+ sites

Two distinct vulnerabilities in the same plugin, both unauthenticated:

CVE-2025-6327: arbitrary file upload — unauthenticated attackers could upload arbitrary files (including PHP) to a web-accessible directory, leading directly to remote code execution.
CVE-2025-6325: privilege escalation via the registration endpoint — unauthenticated users could register new accounts with arbitrary roles, including administrator.

The combination meant either flaw alone was a critical compromise vector, and together they offered two parallel paths to full site control (Patchstack King Addons advisory).

Pentest lessons: The Elementor ecosystem (Elementor core plus third-party “addons for Elementor” plugins) is a high-value target because it touches millions of sites collectively. Pentesting a site that uses Elementor extensions should include enumeration of every Elementor-related plugin and direct probing of each plugin’s REST endpoints, AJAX handlers, and file upload paths. Two vulnerabilities in a single plugin is not unusual — once you find one, look for adjacent flaws.

Tools — Neutral Feature Comparison

The WordPress penetration testing tool ecosystem spans WordPress-specific scanners, general-purpose web application testing tools, network-level tools, and a newer category of AI-driven offensive security platforms. This section presents features without recommendations.

Feature comparison

Tool	Licensing	Primary use case	WordPress-specific features
WPScan	Free for personal/non-commercial; commercial API key available	WordPress-specific vulnerability scanning	Yes — native plugin/theme/core CVE detection, user enumeration
Burp Suite	Community Edition free (rate-limited, no extensions); Professional commercial	General web application pentesting (proxy, scanner, intruder, repeater)	No native WP features; extensible via BApp Store
OWASP ZAP	Free, open source	General web application pentesting (proxy, active scanner)	No native WP features; community add-ons exist
Nmap	Free, open source	Network reconnaissance and port scanning	No
sqlmap	Free, open source	SQL injection detection and exploitation	No (general-purpose)
Wordfence	Free + commercial tiers	Real-time WAF and malware scanning (defensive, not offensive)	Yes — WP-native
Sucuri	Commercial managed service	Managed WAF, malware cleanup (defensive)	Yes — WP-native
Kali Linux	Free, open source distribution	Bundle of pentest tools including WPScan, Burp Suite, Nmap, sqlmap, Metasploit, Hydra	Distribution, not tool
Patchstack	Free + commercial tiers	Vulnerability monitoring and virtual patching (defensive)	Yes — WP-native
Aikido Attack	Free tier + commercial	AI-driven general application security testing (not WordPress-specific)	No — general web app
XBOW	Commercial enterprise	Autonomous offensive security for general production applications	No — general web app

The general-purpose web application tools (Burp Suite, OWASP ZAP, sqlmap) can target WordPress effectively but require manual configuration of WordPress-specific test cases. The WordPress-specific tools (WPScan, Wordfence, Sucuri, Patchstack) are designed around WordPress’s architecture but trade flexibility for that specificity.

AI-driven tools (Aikido Attack, XBOW) are positioned for general web application testing rather than WordPress-specific pentesting. They can be applied to WordPress targets, but their value proposition is autonomous attack-path discovery across general application stacks — not WordPress-specific CVE coverage.

Working command examples

# WPScan — full enumeration
wpscan --url https://example.com \
       --enumerate u,vp,vt \
       --api-token YOUR_TOKEN \
       --random-user-agent

# WPScan — password spray against discovered user
wpscan --url https://example.com \
       --usernames admin \
       --passwords /usr/share/wordlists/rockyou.txt \
       --max-threads 5

# Nmap — service enumeration on standard WordPress hosting
nmap -sV -p 80,443,2222,21,3306,8080 example.com

# sqlmap — test a URL parameter for SQL injection
sqlmap -u "https://example.com/?p=1" \
       --batch --risk=2 --level=3 \
       --random-agent

# Hydra — HTTP form brute force (lab use only, authorized targets only)
hydra -l admin -P /usr/share/wordlists/rockyou.txt \
      example.com http-post-form \
      "/wp-login.php:log=^USER^&pwd=^PASS^:F=Invalid"

# sslyze — TLS configuration check
sslyze --regular example.com

# curl — REST API user enumeration check
curl -s https://example.com/wp-json/wp/v2/users | jq '.[] | {id, slug, name}'

# OWASP ZAP — automated baseline scan via Docker
docker run -t owasp/zap2docker-stable zap-baseline.py \
  -t https://example.com -r zap-report.html

Each command above assumes explicit authorization for the target.

Setting Up a WordPress Penetration Testing Lab

Practicing against a production site — even your own — is not the same as practicing against a deliberately vulnerable target. A dedicated lab lets you reproduce attack techniques without consequences and verify exploit behavior against known-vulnerable configurations.

Docker-based vulnerable WordPress

The fastest way to get a reproducible vulnerable WordPress environment is via Docker:

# Create a project directory
mkdir wp-pentest-lab && cd wp-pentest-lab

# Save the following as docker-compose.yml
cat > docker-compose.yml <<EOF
version: '3.8'
services:
  db:
    image: mariadb:10.6
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wp
      MYSQL_PASSWORD: wp
    volumes:
      - db_data:/var/lib/mysql

  wordpress:
    image: wordpress:6.4-php8.1
    depends_on:
      - db
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wp
      WORDPRESS_DB_PASSWORD: wp
      WORDPRESS_DB_NAME: wordpress
    ports:
      - "8080:80"
    volumes:
      - wp_data:/var/www/html

volumes:
  db_data:
  wp_data:
EOF

# Start the lab
docker compose up -d

Once running, browse to http://localhost:8080, complete WordPress installation, then deliberately install older plugin versions with known CVEs (download via wordpress.org SVN tags). The Docker setup provides isolation — testing against this environment does not affect any production system.

For a broader vulnerable target environment, see also DVWA (Damn Vulnerable Web Application), which includes WordPress modules in some community forks.

Required tools

Beyond Docker, the typical lab toolchain installed on a Linux host (Ubuntu, Debian, or Kali):

# WPScan (requires Ruby)
sudo apt update && sudo apt install -y ruby-full
gem install wpscan

# Nmap, sqlmap, hydra, sslyze
sudo apt install -y nmap sqlmap hydra
pip install --user sslyze

# OWASP ZAP (via Docker)
docker pull owasp/zap2docker-stable

# Burp Suite Community Edition — download from portswigger.net

Reporting Findings

The deliverable from a penetration test is the report, not the testing activity. A report that the recipient cannot act on is a wasted engagement.

Reporting template structure

A minimum useful structure:

1. Executive Summary (1 page, non-technical)
   - Engagement scope, dates, testing team
   - Overall risk posture (High / Medium / Low / Information)
   - Top 3 findings by risk
   - Recommended immediate actions (3-5 bullets)

2. Methodology
   - Standards followed (OWASP WSTG, NIST SP 800-115)
   - Scope and authorization references
   - Tools used

3. Detailed Findings (one per finding)
   Per finding:
   - Title and CVSS score
   - Affected component (plugin name + version, file path)
   - Description (what the vulnerability is)
   - Proof of concept (steps reproducible by the reader)
   - Impact (what an attacker could do)
   - Remediation (specific, actionable)
   - References (CVE ID if applicable, CWE category, vendor advisory)

4. Findings Summary Table
   - All findings listed with CVSS, status, owner, target remediation date

5. Appendices
   - Tool output excerpts
   - Detailed test cases executed

CVSS scoring — worked example

CVSS 3.1 scoring uses base metrics (Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope, Confidentiality/Integrity/Availability impacts) to compute a 0.0-10.0 severity score.

Worked example for an unauthenticated SQL injection in a WordPress plugin:

Metric	Value	Reasoning
Attack Vector (AV)	Network (N)	Exploitable over the internet
Attack Complexity (AC)	Low (L)	No special conditions required
Privileges Required (PR)	None (N)	Unauthenticated
User Interaction (UI)	None (N)	Direct exploit
Scope (S)	Unchanged (U)	Affects only the vulnerable component
Confidentiality (C)	High (H)	Full database read
Integrity (I)	High (H)	Database write possible
Availability (A)	Low (L)	Could affect availability via DROP

Computed base score: 9.4 (Critical).

The full CVSS 3.1 specification and calculator are at first.org/cvss/calculator/3.1.

CVSS 4.0 was released in 2023 and is increasingly adopted; for current pentest reports, either CVSS 3.1 or 4.0 is acceptable as long as the version is stated.

Prioritization framework

Not every finding warrants the same urgency. A practical prioritization:

Critical (CVSS 9.0-10.0): remediate within 24-72 hours, mitigations in place immediately
High (CVSS 7.0-8.9): remediate within 7 days
Medium (CVSS 4.0-6.9): remediate within 30 days
Low (CVSS 0.1-3.9): remediate within next regular maintenance window
Informational: documented, no required remediation

For findings without a CVE/CVSS context (e.g., misconfigurations), use OWASP Risk Rating Methodology — likelihood × impact, each rated 0-9, producing a risk score.

Remediation Guidance per Vulnerability Category

The remediation step is where pentest findings turn into reduced risk. Generic “patch the plugin” guidance is insufficient — different vulnerability classes need different remediation patterns.

XSS (most common per Wordfence 2024)

Stored XSS in custom theme/plugin code: escape output with the appropriate WordPress function (esc_html, esc_attr, esc_url, wp_kses_post for limited HTML)
Reflected XSS: validate input on entry and escape on output (defense in depth)
DOM-based XSS: review front-end JavaScript that handles URL fragments, query strings, or postMessage
Site-wide mitigation: deploy a Content Security Policy header restricting inline scripts and external sources

Authentication bypass

Plugin auth flaws (like CVE-2024-10924): update affected plugin to patched version; if no patch exists, virtual-patch via a WAF rule or disable the plugin
Weak password policies: enforce minimum length (NIST SP 800-63B current guidance: 8+ characters, no complexity rules), screen against breached-password lists
Missing 2FA: enforce 2FA for all administrative roles; consider hardware keys (WebAuthn) for high-privilege accounts

SQL injection

In custom plugin/theme code: use $wpdb->prepare() for all queries that include user-controlled data — never concatenate user input into SQL
In third-party plugins: update to patched version; if no patch, disable plugin or restrict access to vulnerable endpoint via web server rule

File upload

Restrict allowed MIME types and extensions server-side (do not rely on client-side validation)
Store uploads outside web root where possible
Disable PHP execution in upload directories via web server configuration (Apache .htaccess or Nginx location block)
Scan uploaded files for malicious content before exposing them

Configuration hardening

Move wp-config.php outside the web root, or set it to mode 0400
Disable XML-RPC if not used (add_filter('xmlrpc_enabled', '__return_false');)
Restrict /wp-admin access by IP allowlist or VPN where operationally feasible
Set HTTP security headers via web server or a security plugin (Strict-Transport-Security, X-Content-Type-Options, Content-Security-Policy, X-Frame-Options, Referrer-Policy, Permissions-Policy)

Plugin/theme update workflow

Maintain an inventory of all installed plugins and themes with versions
Subscribe to vulnerability disclosure feeds (Patchstack, WPScan, Wordfence Intelligence) and treat advisories as actionable input
Test plugin updates in a staging environment before production deployment
Have a documented rollback procedure for problematic updates

Ongoing Security Beyond One-Off Tests

A penetration test is a point-in-time snapshot. The set of disclosed vulnerabilities, the plugin codebase, and configuration drift continue after the test report is delivered. Ongoing security requires:

Continuous vulnerability monitoring

Subscribe to WPScan, Patchstack, and Wordfence Intelligence vulnerability feeds
Configure WordPress to send security-relevant logs (failed logins, admin actions, file modifications) to a centralized system you actually review

When to re-test (triggers)

Recommended retest triggers:

After any major WordPress core upgrade (e.g., 6.x to 7.x when that happens)
After installing new plugins that handle user input, authentication, or payments
After significant theme changes affecting input/output paths
After a security incident has been remediated (to verify the fix and discover related issues)
Annually as a baseline cadence
Quarterly for compliance frameworks that require it

Automation considerations

Schedule WPScan or OWASP ZAP baseline scans weekly or monthly
Monitor file integrity (Wordfence and similar plugins offer this; can also be done via custom tooling)
Automate plugin/theme update checks; manual approval for changes to plugins that affect critical functionality
Use a WAF (Wordfence, Patchstack, Sucuri, Cloudflare WAF) for virtual patching while plugin patches propagate

Frequently Asked Questions

How often should I run a WordPress penetration test?

Annually is a defensible baseline for most WordPress operations. Compliance frameworks may require more frequent testing — PCI DSS requires at minimum annually and after significant changes. High-value targets (sites with payment processing, regulated data, or high public profile) typically warrant semi-annual testing. Smaller informational sites may be served by regular vulnerability scanning plus less-frequent manual testing.

Can I penetration test my own WordPress site without explicit permission?

If the site is operating on infrastructure you fully control (your own VPS, your own bare-metal server, a dedicated hosting plan), and the testing activity does not reach beyond your scope, you are generally clear of the legal risk. On shared hosting or managed hosting (WP Engine, Kinsta, WordPress.com VIP, Pressable), the underlying infrastructure is shared with other tenants and provider-side resources — provider authorization is appropriate before testing. Document the authorization in writing even when testing your own systems; it eliminates ambiguity in the event of any downstream complications.

What is the difference between a free vulnerability scan and a paid penetration test?

A free vulnerability scan (e.g., WPScan against your site) compares your configuration against a known-CVE database and reports possible matches. A paid penetration test adds: manual verification of each finding to filter false positives, exploitation of discovered weaknesses to demonstrate real impact, custom testing of business-logic flaws that scanners cannot detect, and a structured report your team can act on. The difference in cost reflects manual effort — typically days to weeks of specialist time per engagement.

Are AI-driven penetration testing tools (Aikido Attack, XBOW) suitable for WordPress sites?

AI-driven autonomous security platforms are designed for general web application testing, not WordPress-specific CVE coverage. They can be applied to WordPress targets, but their value proposition is autonomous attack-path discovery across general application stacks — they will not match the depth of WordPress-specific tools (WPScan) for plugin/theme CVE detection. Used together with traditional WP-specific tools, they can supplement a testing program; used alone, they may miss WordPress-specific vulnerability patterns.

What should I do first if a penetration test finds a critical vulnerability in production?

Three actions in parallel: (1) take a verified backup so any active exploitation does not corrupt the only available state, (2) apply mitigations (virtual patch via WAF, disable the affected plugin, restrict access to the vulnerable endpoint), (3) patch the underlying vulnerability via plugin update or code fix. Avoid the temptation to skip step 1; an attacker who detected the vulnerability before you may already be present.

Authoritative Resources

OWASP Web Security Testing Guide — the foundational methodology framework
Wordfence 2024 Annual WordPress Security Report — current vulnerability statistics across plugins, themes, and core
Patchstack vulnerability database — searchable advisories and disclosures
WPScan vulnerability database — WordPress-specific CVE catalog (73,213+ entries as of May 2026)
NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment — US government standard methodology
NIST SP 800-63B — Digital Identity Guidelines: Authentication and Lifecycle Management — authoritative current authentication guidance
PortSwigger Web Security Academy — free training material covering tools and techniques
Wordfence Threat Intelligence — real-time vulnerability disclosure feed

Need an independent review before the next security test?

A penetration test shows how a site behaves under attack; a code review can expose the implementation flaws behind those findings. Osom Studio reviews custom WordPress and WooCommerce code for access-control, input-handling, and maintainability risks through a WordPress code audit.

WordPress Penetration Testing in 2026: Methodology, Tools, and Recent CVE Case Studies