wpForo Forum has a high-severity unpatched vulnerability sitting in version 3.0.2 and below. Any user with a Subscriber-level account (the lowest role that requires just email registration) can delete arbitrary files on your server by passing a crafted path through the data[body][fileurl] parameter. No patch exists at the time of writing.
This is CVE-2026-5809. CVSS score: 7.1 (High). Published: April 10, 2026.
What the vulnerability actually does
The bug is classified as External Control of File Name or Path (CWE-73). The short version: wpForo doesn't properly validate or sanitize the data[body][fileurl] parameter before using it in a file deletion operation. A subscriber-level user (think: anyone who created a forum account) can point that parameter at any file the web server process can reach, and wpForo will happily delete it.
That means wp-config.php, your theme's functions.php, plugin files, or anything else sitting in webroot. Delete wp-config.php and WordPress drops into installation mode, effectively wiping the site's database connection config and potentially exposing it to reinstallation by whoever gets there first. It's not remote code execution, but for an attacker with even minimal credentials it's close enough to a site-killer.
Still unpatched
This one has no fix. patched_in_version is null. The vulnerability was disclosed on April 10, 2026, and as of today there's no release that addresses it.
That matters a lot given wpForo's track record. The plugin currently sits at a security score of 40/100 and has accumulated 36 CVEs total, with 1 currently unpatched. Tomdever, the sole developer behind the plugin, carries an average patch time of 479 days and a trust score of just 37/100. So don't assume a fix is coming tomorrow.
This isn't an isolated incident
CVE-2026-3666, disclosed just one week earlier (April 3, 2026), covers a similar arbitrary file deletion issue in versions up to 2.4.16, via the post body. CVSS 8.8. That one was patched in 2.4.17 in a single day.
So here's the timeline: wpForo fixed one arbitrary file deletion bug (2.4.16 -> 2.4.17), then apparently shipped a major version bump to 3.0.x that re-introduced the same class of vulnerability through a different parameter. Same impact, different entry point.
That pattern shows up repeatedly across this plugin's CVE history:
- CVE-2026-1581 (Feb 2026) - Unauthenticated SQL Injection, CVSS 7.5, patched in 2.4.15
- CVE-2026-0910 (Feb 2026) - PHP Object Injection via Deserialization, CVSS 8.8, patched in 2.4.14
- CVE-2025-13126 (Dec 2025) - Unauthenticated SQL Injection, CVSS 7.5, patched in 2.4.13
- CVE-2025-4203 (Oct 2025) - Unauthenticated SQL Injection via
get_members, CVSS 7.5
Five high-severity CVEs in the last six months alone. The plugin's own risk assessment flags 82 out of 91 entry points as lacking authentication checks, and 114 out of 125 taint flows with unsanitized paths. Those aren't just warning signs, they're structural problems that keep producing new CVEs.
How exposed are sites in the wild?
Our crawl data shows 7,310 sites observed running wpForo. The version distribution is grim:
- 1,917 sites still running 2.4.16 (vulnerable to CVE-2026-3666)
- 617 sites with no detectable version
- 397 sites on 2.4.13
- 389 sites on 2.4.15
- 267 sites on 2.4.5
- Only 176 sites on 2.4.17 (the current patched-for-3666 build)
Virtually no one has moved to 3.x, which is the only version range where CVE-2026-5809 applies, so active exploitation of this specific CVE in the wild is likely limited right now. But that changes fast once a PoC circulates, and the attack bar is "create a forum account."
What you should do right now
If you're running wpForo 3.0.x, you're in the worst spot: the newest major version, and the one with an open unpatched CVE. Your options:
Disable new user registrations on your forum until a patch drops. This doesn't protect existing subscriber accounts, but it stops new attackers from self-registering to exploit this.
Audit existing subscriber accounts and trim any accounts you don't recognize. A forum platform naturally accumulates registered users, many of whom have no legitimate relationship with your site.
Consider rolling back to 2.4.17 if you haven't deployed 3.x-specific features you depend on. It's not a great situation either, but at least it doesn't have an open file deletion CVE right now.
Set up a Web Application Firewall rule to block requests containing path traversal patterns (../, /etc/, wp-config) in POST body parameters. Cloudflare WAF, Sucuri, and Wordfence all support custom rules for this.
Monitor the plugin's changelog closely. Given the one-day patch turnaround for CVE-2026-3666, the developer can move fast when motivated. But "can" and "will" are different things, and that 479-day average patch time is the more honest number to plan around.
If your community forum isn't a core business requirement, this is probably the moment to seriously evaluate whether the security overhead of keeping wpForo running is worth it. 36 CVEs across a plugin with 20,000 active installs and a single developer is a hard combination to argue for.
