WordPress Pentest Checklist: What TigerStrike Tests in 2026

1. Core and plugin version fingerprinting

The first question is always: what is this site actually running, and how old is it?

• Fingerprint WordPress core version from <meta name="generator">, /readme.html, /wp-includes/js/wp-embed.min.js?ver= query strings, and feed metadata. Many sites strip the generator meta but forget the asset version strings.
• Enumerate plugins and themes from /wp-content/plugins/ and /wp-content/themes/ 403 vs 404 responses, plus asset version query strings and plugin-specific readme.txt files.
• Match each identified core, plugin, and theme version against the WPScan vulnerability database and the CISA KEV catalog.
• Failure pattern we see weekly: core is patched but a popular plugin is two years out of date and has a public exploit.

2. REST API exposure

• Probe /wp-json/ and /wp-json/wp/v2/users — the latter returns the enumerated author list on sites that have not disabled it.
• Check /wp-json/wp/v2/comments, /pages, /media for unauthenticated reads of sensitive content.
• For each plugin that ships REST endpoints (/wp-json/<plugin>/), probe with auth and without — plugins frequently register endpoints that skip the core permission check.
• Test Application Passwords (/wp-json/wp/v2/users/me/application-passwords) for weak creation/listing enforcement.
• Failure pattern: a form plugin registers an unauthenticated /submit endpoint that does not validate request origin and gives form-data leakage or spam-abuse paths.

3. XML-RPC endpoint

• Probe /xmlrpc.php. If it responds, test for the system.multicall brute-force amplification path.
• Test wp.getUsersBlogs and metaWeblog.getPost for credential-oracle behaviour.
• If the site does not legitimately use XML-RPC (most do not, in 2026), recommend disabling the endpoint entirely via wp-config.php, .htaccess, or at the WAF.
• Failure pattern: XML-RPC is live, pingbacks are enabled, and the site is being used as an SSRF reflector.

4. admin-ajax.php abuse

• Enumerate the registered AJAX actions by crawling JavaScript bundles and plugin source. Every wp_ajax_<action> and wp_ajax_nopriv_<action> is a candidate endpoint.
• For each nopriv action, test for parameter-tampering, SQL injection, path traversal, and SSRF. These are the top-of-funnel RCE sources on WordPress in 2026 — including CVE-2026-119977-class flaws.
• For authenticated-only actions, confirm the nonce is actually validated server-side (many plugins check the nonce only in the UI layer).
• Failure pattern: a plugin registers wp_ajax_nopriv_import_settings that accepts a URL and fetches it server-side with no allow-list — instant SSRF.

5. Authentication, sessions, user enumeration

• Test user enumeration via /?author=1 redirect, /wp-json/wp/v2/users, and /wp-sitemap-users-1.xml.
• Rate-limit test: POST /wp-login.php with increasing frequency; confirm the site enforces lockouts, CAPTCHA, or MFA.
• Session: inspect wordpress_logged_in_* cookie attributes (Secure, HttpOnly, SameSite) and lifetime. Test session invalidation on password change.
• MFA coverage: test whether MFA is enforced for all admin and editor roles, not just the account that happens to have it set up.
• Failure pattern: user enumeration is open, no rate limit on login, no MFA — credential-stuffing lands weekly.

6. File-upload paths

• Test the media library upload for extension-filter bypass (.phtml, .phar, double-extension, polyglot).
• Test plugin upload endpoints (form uploaders, avatar pickers, document-management plugins). Many ship their own uploader with weaker filters than core.
• Verify that wp-content/uploads/ has PHP execution denied at the webserver level (.htaccess or Nginx location rule). Test with a known-good payload.
• Test SVG upload for stored-XSS via embedded JavaScript if SVGs are rendered inline anywhere.
• Failure pattern: PHP execution is allowed in uploads/, a plugin's "quote request" form accepts .phtml, and you have a webshell.

7. Content security and output handling

• Test for stored XSS in post content, comment content (if enabled), custom-field inputs, and plugin settings pages.
• Reflected XSS: parameter-sweep ?s=, ?p=, ?page_id=, and plugin-registered GET params.
• Check security headers: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, Permissions-Policy.
• Test for open redirects in wp-login.php?redirect_to= and plugin-registered redirect params.
• Failure pattern: a page-builder plugin stores HTML without sanitisation; low-privilege editor role can inject JavaScript that fires when an admin visits the page.

8. wp-config and secret exposure

• Probe for /wp-config.php.bak, .swp, .save, .old, .orig, and other editor-leftover variants.
• Check /debug.log, /error_log, /.git/, /.env, /phpinfo.php, and /info.php.
• Test for backup archives in web-root (backup.zip, site.tar.gz, wp-backup.sql).
• Review public-facing readme.html, license.txt, and plugin readme.txt for information disclosure.
• Failure pattern: migration tool leaves wpallimport.log in web-root with DB credentials in plain text.

9. Infrastructure around the site

• PHP version and phpinfo exposure. WordPress-era PHP RCE chains like PHP2Shell × Fragnesia apply to WordPress hosts too.
• Database: is the MySQL/MariaDB port externally reachable? Is the WordPress DB user limited to the wp_ schema only?
• Webserver: directory-listing enabled anywhere? HSTS enforced? OCSP stapling on?
• CDN / WAF posture: can the origin be reached directly bypassing Cloudflare / AWS WAF? Is admin area restricted by IP?
• Email: is SMTP open? SPF / DKIM / DMARC configured? A compromised WordPress site is an ideal phishing launchpad.

10. Supply chain of the admin surface

The most underappreciated angle. Even a fully patched WordPress is compromised if an admin's laptop is compromised or an integration token leaks.

• Admin access: via IP allow-list? MFA enforced? From corporate device-posture, not any laptop?
• Application Passwords and REST API tokens — rotation cadence, ownership, logging.
• Backup provider (Jetpack, BlogVault, UpdraftPlus to S3/GCS): is the backup bucket private? Is encryption at rest enabled?
• Hosting provider admin panel: MFA enforced? Audit log reviewed? SFTP credentials rotated?
• Git / CI integrations that push code or assets to the WordPress host. Each is a credential surface.
• Failure pattern: compromised developer laptop → plugin repo write access → next release contains a backdoor → every site auto-updates to a pre-pwned version.

What TigerStrike delivers

The VAPT AI Engine ships a WordPress detection + exploitation pack that runs against every WordPress site discovered by ASM. Each run produces, per site:

• A core + plugin version inventory with CVE / KEV match.
• Pass / fail per focus area above, with reproducible payloads for the failures.
• Attack-path linkage — which failures chain into which business-critical outcomes.
• Deduplicated, Jira-ready findings with suggested fixes and one-click re-test.
• Signed evidence artefacts retained for your SOC 2 / ISO 27001 / PCI DSS audit cycle.

See continuous VAPT for the surrounding program — scheduled runs against your live WordPress estate rather than a once-a-year audit.

Related reading

• WordPress RCE CVE-2026-119977 added to CISA KEV — 13k attacks in 24 hours
• PHP2Shell: PHP RCE chain — Nov 2026 update (WordPress hosts are directly affected)
• Continuous AI VAPT vs annual pentest