wpForo Forum CVE-2026-5809: Brief Summary of Arbitrary File Deletion via Poisoned Postmeta

Introduction

A two step logic flaw in the wpForo Forum plugin for WordPress lets any authenticated user, even one with only subscriber level privileges, delete arbitrary files on the server by poisoning postmeta records with attacker controlled file paths. For the more than 20,000 WordPress sites running wpForo, a low privilege account created through open registration can be used to remove wp-config.php and force the entire site into an unrecoverable state without any admin involvement.

wpForo Forum is a popular community and discussion board plugin for WordPress, developed by tomdever and the gVectors Team. With over 1.6 million total downloads, it is a primary forum solution for a large number of WordPress powered communities. Because it integrates deeply with WordPress core (user roles, database, media handling), wpForo vulnerabilities carry weight across the broader WordPress ecosystem.

Technical Information

CVE-2026-5809 is classified under CWE-73 (External Control of File Name or Path) and carries a CVSS score of 7.1. The vulnerability exists in wpForo Forum versions up to and including 3.0.2 and is exploitable by any authenticated user with subscriber level access or above. The root cause is a two step logic flaw spanning the plugin's topic handling, postmeta storage, and file management subsystems.

Step 1: Postmeta Poisoning via Unrestricted Data Array Acceptance

The topic_add() and topic_edit() action handlers in Actions.php (lines 746 and 761, respectively) accept arbitrary user supplied data[*] arrays directly from the $_REQUEST superglobal. These values are then stored as postmeta in the plugin's custom database table, with no restriction on which fields may contain nested array values.

The critical detail is that body sits in the plugin's allowed topic fields list, as defined in Posts.php. So an attacker can craft a request that supplies data[body][fileurl] with a value pointing to any file path on the server, for example wp-config.php or an absolute server path like /var/www/html/wp-config.php. The plugin dutifully persists this poisoned fileurl value into its postmeta table, treating it as legitimate topic metadata.

Step 2: Triggering Unvalidated File Deletion

With the poisoned postmeta record in place, the attacker submits a second request: a topic_edit action containing wpftcf_delete[]=body. This parameter tells the plugin to delete the file attachment associated with the body field.

The execution flow proceeds as follows:

1. The add_file() method in PostMeta.php (around line 523) retrieves the stored postmeta record for the body field.
2. It extracts the fileurl value from the record, which is now the attacker controlled path.
3. The path is passed through wpforo_fix_upload_dir() (defined in functions.php at line 2641). This function normalizes paths within the wpForo uploads directory, and it only rewrites paths that match legitimate wpForo upload directory patterns. Any path that does not match (such as wp-config.php or an absolute path elsewhere on the filesystem) comes back unchanged.
4. The unvalidated path is then passed directly to WordPress core's wp_delete_file() function, which deletes the target file if the PHP process has write permissions.

Attack Flow Summary

The full exploitation sequence for an attacker with a subscriber account:

1. Authenticate to the WordPress site with a subscriber (or higher) role.
2. Create or edit a forum topic, injecting a malicious payload in the request body: data[body][fileurl]=wp-config.php (or any target file path).
3. The plugin stores this poisoned value in its postmeta table without validation.
4. Submit a second topic_edit request with wpftcf_delete[]=body.
5. The plugin retrieves the poisoned fileurl, passes it through a path normalization function that leaves non upload paths alone, and calls wp_delete_file() on the attacker controlled path.
6. The target file is deleted from the server.

Deleting wp-config.php drops WordPress into its installation setup mode, which takes the site offline and can let an attacker reconfigure the database connection. Deleting other files (such as .htaccess, plugin files, or theme files) causes varying degrees of disruption.

Why the Sanitization Fails

The wpforo_fix_upload_dir() function had a narrow purpose: correct paths within the wpForo upload directory structure. It was never meant to be a security boundary for arbitrary file operations. Given a path outside its expected upload directory, it simply returns the input unchanged. This is a function repurposed as a security control without the validation logic that role requires.

Affected Systems and Versions

The vulnerability affects the wpForo Forum plugin for WordPress in all versions up to and including 3.0.2. Any WordPress installation running wpForo 3.0.2 or earlier with user registration enabled (allowing subscriber level accounts) is vulnerable. The attack needs only authenticated access at the subscriber privilege level, which is the lowest standard WordPress user role.

Version 3.0.3, released on April 10, 2026, contains the security fix for this vulnerability.

Vendor Security History

The gVectors Team's wpForo plugin has a substantial history of security vulnerabilities. The Wordfence vulnerability database catalogs 36 distinct vulnerabilities for wpForo. Several recent high severity issues give useful context:

Two arbitrary file deletion vulnerabilities in the same month (CVE-2026-5809 and CVE-2026-3666) point to systemic problems in how the plugin handles file operations and user supplied input. Organizations relying on wpForo should keep patching aggressively and weigh whether the plugin's risk profile fits their security requirements.

References

• Wordfence Vulnerability Advisory for CVE-2026-5809
• Wordfence Detailed Advisory: Authenticated (Subscriber+) Arbitrary File Deletion
• Wordfence wpForo Vulnerability History
• Actions.php (line 746) in wpforo/tags/3.0.2
• Actions.php (line 761) in wpforo/tags/3.0.2
• PostMeta.php (line 402) in wpforo/tags/3.0.2
• PostMeta.php (line 421) in wpforo/tags/3.0.2
• PostMeta.php (line 523) in wpforo/tags/3.0.2
• Posts.php (line 1961) in wpforo/tags/3.0.2
• functions.php (line 2641) in wpforo/tags/3.0.2
• wpForo Changeset 3503313
• wpForo Forum on WordPress.org