The MW WP Form plugin for WordPress is vulnerable to Arbitrary File Move/Read in all versions up to and including 5.1.1. This is due to insufficient validation of the $name parameter (upload field key) passed to the generateuserfiledirpath() function, which uses WordPress's pathjoin() — a function that returns absolute paths unchanged, discarding the intended base directory. The attacker-controlled key is injected via the mwfuploadfiles[] POST parameter, which is loaded into the plugin's Data model via setrequestvaliables(). During form processing, regenerateuploadfilekeys() iterates over these keys and calls generateuserfilepath() with the attacker-supplied key as the $name argument — the key survives validation because the targeted file (e.g., wp-config.php) genuinely exists at the absolute path. The getattachments() method then re-reads the same surviving keys and passes the resolved file path to movetempfiletouploaddir(), which calls rename() to move the file into the uploads folder. This makes it possible for unauthenticated attackers to move arbitrary files on the server, which can easily lead to remote code execution when the right file is moved (such as wp-config.php). The vulnerability is only exploitable if a file upload field is added to the form and the “Saving inquiry data in database” option is enabled.

The MW WP Form plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'memo' parameter in all versions up to, and including, 5.1.3 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with editor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. Because the memo value is stored via updatepostmeta() rather than wpinsertpost(), WordPress's built-in kses and unfilteredhtml protections do not apply, allowing attackers to break out of the textarea element via injected closing tags regardless of role-based content filtering.

The MW WP Form WordPress plugin before 5.1.6 does not sanitise and escape some of its form settings before outputting them back in an admin dashboard page, which could allow users with a role as low as Editor to perform Stored Cross-Site Scripting attacks against high privilege users such as admin.