Project Manager by weDevs: patch to 4.1.2 now, there's a public exploit

Published 3 Nov 2026

Project Manager by weDevs: public exploit out, update to 4.1.2 now. Update to 4.1.2 or later. If you can't yet, deactivate it. Then look for PHP files in uploads and admin users you don't know.

If you run the Project Manager plugin by weDevs (slug wedevs-project-manager), update it to 4.1.2 today. Versions up to and including 4.1.1 have an unauthenticated remote code execution bug, tracked as CVE-2026-116512 and rated 9.8 out of 10 by Wordfence. The fix shipped on 29 October 2026. On 1 November a working exploit went up on GitHub, and it's built for mass use: it drops a webshell on any site still on 4.1.1 or older that it finds.

The plugin's full name on WordPress.org is "Project Manager – AI Powered Project Management, Task Management, Kanban Board & Time Tracker", with more than 5,000 active installs. The attack needs no special settings: an active copy of the plugin on a live site is enough to put it at risk.

Timeline for CVE-2026-116512 in Project Manager by weDevs. Wordfence reported it on 26 October 2026 and version 4.1.2 fixed it on 29 October. The advisory came out on 30 October and the CVE went live on 31 October, rated 9.8. A public exploit was posted on GitHub on 1 November. On 4.1.1 or older, update to 4.1.2 or later.
Dates from the CVE record, the 4.1.2 changelog and ThreatWire.

Why a logged-out visitor can run code

The bug is in the plugin's REST API. The id parameter from the request gets pasted into a validation rule string, and the plugin then calls each piece of that string as a PHP function, with no list of allowed functions. So whoever controls id controls which PHP functions run.

The plugin does have a permission check. It just never gets a say, because WordPress runs a REST route's validation step first, so the injected functions run before anyone is asked to log in.

At the time of writing, CISA hasn't added this CVE to its Known Exploited Vulnerabilities list, and NVD, GitHub and weDevs don't report attacks in the wild. With a ready-made tool public, automated scanning usually follows, so I wouldn't wait for those lists to catch up.

What to do now

  1. Go to Plugins in wp-admin and update Project Manager to 4.1.2 or later. If auto-updates are on, confirm the version number yourself.
  2. If you can't update yet, deactivate or delete the plugin until you can. Your project data sits in the database and should still be there when you reactivate, but take a backup first.
  3. Look for PHP files you didn't put there, starting with wp-content/uploads, which should hold images and documents, not .php files. Then check the plugin folders.
  4. Open Users and filter by Administrator. Any admin account you don't recognise is a bad sign.
  5. In your access logs, look for odd REST requests to the plugin's pm/v2 routes, especially from before you updated.

If you find something

Treat the site as compromised. Updating closes the hole but doesn't remove a webshell that's already in place. The clean route is to restore from a backup taken before the attack, update the plugin on the restored copy, and then change your WordPress admin passwords, your database password and the WordPress salts in wp-config.php. If you don't have a clean backup, the site needs a proper cleanup: every file compared against known-good copies of core, themes and plugins, and the database checked for injected content and rogue users.

Not sure if your site is affected?

If you don't know which plugins your site runs, or you'd like a second pair of eyes on it, run a free CrawlCare scan or get in touch for a chat. We'll tell you what we find before anything else happens.

Source: ThreatWire, 2 Nov 2026

Further reading