CVE-2024-8242 is a medium severity (CVSS 4.3) arbitrary file upload in the MStore API plugin for WordPress, through version 4.15.3. A subscriber level account can upload files without type checks. Update to a release newer than 4.15.3 and review uploads.
What's affected
The record covers all versions of the MStore API plugin (the InspireUI plugin for building native Android and iOS apps) up to and including 4.15.3. The flaw is in the update_user_profile() function, which lacks file type validation.
The plugin's own changelog on WordPress.org lists 4.15.4 with the entry "Fix security issue" directly above 4.15.3. That fits the record, but the entry does not name the CVE, so treat 4.15.4 as the likely fix and confirm against the Wordfence advisory linked in the record. The current plugin release is much newer, so simply updating to the latest version is the safe course.
Severity: the record rates it 4.3 with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N. That is medium, and the integrity impact is low. The record also notes that PHP files are excluded from the upload, yet it warns that remote code execution may still be possible. Those two statements pull in different directions, so judge your own exposure by how your server handles uploaded content.
The weakness is CWE-434, unrestricted upload of a file of a dangerous type. The record does not mark it as known exploited.
How to check if you're exposed
With WP-CLI on the server:
wp plugin get mstore-api --field=version
Anything at or below 4.15.3 is in range. In the dashboard, the Plugins page shows the same version number. If you manage many sites, query each one rather than relying on a spreadsheet.
Also look at the uploads directory for files you do not recognize, especially under paths tied to user profile avatars, and check whether your web server executes anything stored there.
What to do now
- Update MStore API to the latest release from the WordPress plugin directory.
- Check the uploads folder for unexpected files created since you installed the plugin.
- Confirm that your web server does not execute scripts from the uploads directory.
- Review open registration. The record says the issue can be paired with a registration endpoint for unauthenticated users, so a site that lets anyone sign up as a subscriber is the easiest target.
- If the plugin is unused, remove it.
Why it matters
Upload handlers are a classic place for trust to go wrong. The server accepts bytes from a low privilege user and stores them somewhere that the web server can later serve or process. Without validation of type and content, the stored file is whatever the user chose.
The low severity score reflects the PHP exclusion and the limited impact on its own. It understates how this plays out on sites with open registration, where the account barrier is effectively nothing. Scan your WordPress plugin inventory the same way you scan application dependencies, and the free in-browser dependency scan is a quick place to start for code you ship.
Quick check
Is this unauthenticated?
Not directly. The record requires subscriber level access, but it says the flaw can be paired with a registration endpoint that unauthenticated users can reach.
Which version fixes it?
The plugin changelog lists a "Fix security issue" entry in 4.15.4. Confirm with the Wordfence advisory, or simply move to the latest release.
Sources
Last reviewed: 19 October 2026.
