WPSploit: Metasploit's Unofficial WordPress Arsenal

Hook

WordPress powers 43% of the web, yet Metasploit's core framework contains surprisingly few WordPress-specific exploits. WPSploit was built to fill that gap with 45 specialized modules targeting the world's most popular CMS.

Context

Penetration testers face an interesting paradox when targeting WordPress installations. On one hand, WordPress's ubiquity makes it a constant fixture in security assessments. On the other, its plugin ecosystem creates thousands of unique attack surfaces that generic scanning tools struggle to address comprehensively. While WPScan emerged as the community standard for WordPress vulnerability scanning, it operates outside the Metasploit Framework—meaning penetration testers had to context-switch between tools, manually correlate findings, and rewrite exploits that couldn't leverage Metasploit's payload delivery and session management infrastructure.

WPSploit emerged as a bridge between these worlds. Created by espreto, the project packages WordPress exploits as proper Metasploit modules, allowing security professionals to exploit WordPress vulnerabilities using familiar msf commands, payloads, and post-exploitation workflows. Rather than building yet another standalone scanner, WPSploit leverages the WPScan Vulnerability Database (WPVDB) to identify exploitable conditions, then implements them as standard Metasploit modules. This approach means you get WordPress-specific attack capabilities without abandoning the Metasploit ecosystem's sophisticated payload encoding, session handling, and reporting features.

Technical Insight

WPSploit's architecture follows Metasploit's module conventions religiously. Each exploit or auxiliary module inherits from Msf::Exploit::Remote or Msf::Auxiliary respectively, implementing the standard initialize, check, and exploit methods that Metasploit users expect. The modules live in your local ~/.msf4/modules/ directory, extending Metasploit without modifying its core installation.

A typical WPSploit exploit module follows this structure:

class MetasploitModule < Msf::Exploit::Remote
  Rank = ExcellentRanking

  include Msf::Exploit::Remote::HTTP::Wordpress
  include Msf::Exploit::FileDropper

  def initialize(info = {})
    super(update_info(info,
      'Name'           => 'WordPress Plugin Vulnerable Component RCE',
      'Description'    => %q{
        This module exploits a file upload vulnerability in
        WordPress plugin X versions Y through Z, allowing
        arbitrary PHP execution.
      },
      'License'        => MSF_LICENSE,
      'Author'         => ['Original Researcher', 'espreto'],
      'References'     =>
        [
          ['WPVDB', '8765'],
          ['CVE', '2019-XXXXX'],
          ['URL', 'https://wpvulndb.com/vulnerabilities/8765']
        ],
      'Platform'       => 'php',
      'Arch'           => ARCH_PHP,
      'Targets'        => [['WordPress Plugin X', {}]],
      'DefaultTarget'  => 0
    ))

    register_options(
      [
        OptString.new('TARGETURI', [true, 'WordPress root path', '/'])
      ])
  end

  def check
    check_plugin_version_from_readme('vulnerable-plugin', '1.0', '2.3.4')
  end

  def exploit
    # Leverage Wordpress mixin methods
    print_status("Uploading payload to #{target_uri.path}")
    
    res = wordpress_upload_plugin(payload.encoded)
    
    if res && res.code == 200
      register_file_for_cleanup("wp-content/uploads/#{@payload_name}")
      print_good("Payload uploaded successfully")
    else
      fail_with(Failure::Unknown, 'Upload failed')
    end
  end
end

The key insight here is WPSploit's use of Metasploit's Msf::Exploit::Remote::HTTP::Wordpress mixin. This mixin provides helper methods like wordpress_upload_plugin, check_plugin_version_from_readme, and wordpress_login, abstracting away WordPress-specific HTTP interactions. The exploit author focuses on the vulnerability logic while inheriting authentication handling, version detection, and URI normalization for free.

The auxiliary modules take a similar approach but focus on enumeration rather than exploitation. A user enumeration auxiliary might leverage the WordPress XML-RPC interface to extract valid usernames:

class MetasploitModule < Msf::Auxiliary
  include Msf::Exploit::Remote::HTTP::Wordpress
  include Msf::Auxiliary::Scanner

  def initialize(info = {})
    super(update_info(info,
      'Name'        => 'WordPress XML-RPC Username Enumeration',
      'Description' => 'Enumerates WordPress users via XML-RPC',
      'License'     => MSF_LICENSE,
      'Author'      => ['espreto']
    ))
  end

  def run_host(ip)
    users = wordpress_enumerate_users_via_xmlrpc
    users.each do |user|
      print_good("Found user: #{user}")
      report_note(
        host: ip,
        type: 'wordpress.user',
        data: user
      )
    end
  end
end

The modules also integrate with Metasploit's reporting infrastructure through methods like report_note, report_vuln, and report_loot. This means your WordPress findings automatically populate the Metasploit database, appearing in vulnerability reports and available for post-exploitation queries.

WPSploit's 45 modules span common WordPress attack vectors: theme and plugin vulnerabilities, XML-RPC abuse, user enumeration, brute force attacks, and SQL injection in popular plugins. Each module references its corresponding WPVDB entry, creating traceability between the exploit code and the original vulnerability research. This WPVDB linkage is crucial—it means you can verify whether a given WordPress installation is vulnerable before attempting exploitation, reducing noise in your testing process.

Gotcha

WPSploit's most significant limitation is its maintenance status. The repository's modest star count and the author's explicit acknowledgment that features are missing suggest this isn't a heavily maintained project. In the fast-moving WordPress ecosystem where plugins update frequently and vulnerabilities are patched rapidly, outdated exploit modules become liabilities rather than assets. You'll likely find that some modules target plugin versions so old they're no longer encountered in the wild, while more recent WordPress vulnerabilities lack corresponding WPSploit modules entirely.

The manual installation process introduces friction that modern security tools have eliminated. You're copying Ruby files into specific directories, managing updates manually, and essentially maintaining a fork of your Metasploit installation. There's no package manager, no automated updates, and no guarantee that a Metasploit Framework update won't break WPSploit modules. Compare this to WPScan's straightforward installation via RubyGems or Docker, and you'll understand why adoption remains limited. Additionally, because these modules aren't part of mainline Metasploit, they haven't undergone Rapid7's code review process. While the project received a blog mention from the Metasploit team, individual modules may contain bugs or implementation issues that would have been caught in the official submission process. You're trading official support and quality assurance for immediate access to WordPress-specific functionality.

Verdict

Use if: You're already deeply invested in the Metasploit Framework for penetration testing, regularly encounter WordPress targets, and want to exploit WordPress vulnerabilities without leaving the msfconsole environment. WPSploit makes sense when you need Metasploit's payload flexibility, session management, or post-exploitation features against WordPress sites—particularly when you're chaining WordPress exploits with other attacks in a broader engagement. It's also valuable if you're comfortable auditing Ruby code and verifying that modules still work against current WordPress versions. Skip if: You need actively maintained tooling, want comprehensive WordPress vulnerability coverage, or prefer standalone tools optimized for their specific purpose. WPScan is more current, better maintained, and designed specifically for WordPress security testing. If you're not already using Metasploit extensively, the overhead of manual WPSploit installation and maintenance isn't justified. Most security teams will get better results from WPScan for enumeration, combined with manual exploitation or Nuclei templates for specific vulnerabilities, rather than maintaining an aging collection of Metasploit modules.