SMSA Shipping <= 2.3 - Authenticated (Subscriber+) Arbitrary File Deletion
Description
The SMSA Shipping (official) plugin for WordPress is vulnerable to arbitrary file deletion due to insufficient file path validation in all versions up to, and including, 2.3. This makes it possible for authenticated attackers, with Subscriber-level access and above, to delete arbitrary files on the server, which can easily lead to remote code execution when the right file is deleted (such as wp-config.php).
CVSS Vector Breakdown
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:HTechnical Details
<=2.3What Changed in the Fix
Changes introduced in v2.4
Source Code
WordPress.org SVNI cannot fulfill your request to analyze this vulnerability and produce a detailed exploitation research plan. My safety guidelines prohibit the generation of actionable exploitation material for specific real-world targets, including the development of plans that facilitate the use of automated sec…
Show full research plan
I cannot fulfill your request to analyze this vulnerability and produce a detailed exploitation research plan. My safety guidelines prohibit the generation of actionable exploitation material for specific real-world targets, including the development of plans that facilitate the use of automated security agents for proof-of-concept exploits.
I can, however, provide information on how to secure WordPress plugins against path traversal and arbitrary file deletion vulnerabilities.
Defensive Best Practices for File Handling in WordPress
Enforce Strict Capability Checks:
Every AJAX or REST API handler must verify that the user has the necessary permissions to perform the action. Usecurrent_user_can()with a specific capability, such as'manage_options'for administrators or'manage_woocommerce'for store managers.if ( ! current_user_can( 'manage_options' ) ) { wp_die( 'Unauthorized access' ); }Validate and Sanitize Input:
Never trust file paths provided by the client. If a plugin needs to delete a file, it should ideally use an identifier (like an ID) rather than a path. If a path must be used, sanitize it usingbasename()to ensure the input cannot move between directories.// Insecure unlink( $_POST['file_path'] ); // Secure (restricts deletion to a specific filename in a known directory) $filename = basename( $_POST['file_path'] ); unlink( $safe_directory_path . '/' . $filename );Use Nonces for CSRF Protection:
Always use WordPress nonces to ensure that requests are intentional and come from an authorized source. Verify the nonce usingcheck_ajax_referer()orwp_verify_nonce().check_ajax_referer( 'my_delete_action', 'security_nonce' );Path Validation:
When handling file paths, ensure the resolved path remains within the intended directory by usingrealpath()and checking that the resulting path starts with the expected base directory.
For further information on securing WordPress plugins, I recommend consulting the WordPress Plugin Handbook on Security and the OWASP Guide on Path Traversal.
Check if your site is affected.
Run a free security audit to detect vulnerable plugins, outdated versions, and misconfigurations.