CVE-2025-1128: Critical Unauthenticated Arbitrary File Upload in Everest Forms (100,000+ Sites, CVSS 9.8)

A contact form is the most boring thing on your website. It is also, quite often, the most dangerous. In February 2025, Wordfence disclosed a critical flaw in Everest Forms — a popular WordPress form builder with more than 100,000 active installations — that allowed completely unauthenticated attackers to upload, read, and delete arbitrary files on the server. No login. No account. No user interaction. Just a crafted request to a public form.

Tracked as CVE-2025-1128 and scored 9.8 out of 10 (Critical), this is about as bad as WordPress vulnerabilities get. An attacker who can drop a PHP file onto your server can generally do anything your web server can do — which usually means owning the entire site, and sometimes the entire hosting account. If you run Everest Forms and you have not updated since early 2025, stop reading and go check your version now.

CVE Details

• CVE ID: CVE-2025-1128
• Plugin: Everest Forms – Contact Forms, Quiz, Survey, Newsletter & Payment Form Builder for WordPress (by WPEverest)
• CVSS 3.1 Score: 9.8 (Critical) — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
• Vulnerability Type: Unrestricted Upload of File with Dangerous Type (CWE-434), with arbitrary file read and arbitrary file deletion as secondary impacts
• Affected Versions: All versions up to and including 3.0.9.4
• Patched Version: 3.0.9.5
• Privileges Required: None (unauthenticated)
• Disclosed: 25 February 2025, credited to Wordfence as CNA

The CVSS vector tells the whole story in shorthand: the attack comes over the network (AV:N), it is easy to pull off (AC:L), it needs no privileges (PR:N), it needs no victim to click anything (UI:N), and it fully compromises confidentiality, integrity, and availability (C:H/I:H/A:H).

How the vulnerability works

Everest Forms lets you add a file upload field to any form — a résumé attachment on a careers page, a photo on a support request, a document on an application form. Handling uploads safely is one of the hardest things a plugin can do, because you are accepting a file chosen by a stranger and writing it to your own disk.

The flaw lived in the format method of the EVF_Form_Fields_Upload class. Two validation steps that should have been enforced were not:

• Missing file type validation. The code checked whether the submitted file had a permitted extension, and if it did not, it set an error message — but then kept going anyway. Setting an error is not the same as stopping execution. The upload proceeded regardless, meaning a file with a .php extension could land on the server even though PHP was never an allowed type.
• Missing path validation. The file path derived from user-supplied input was not properly constrained to the intended uploads directory. That opened the door to directory traversal — using sequences like ../ to climb out of the uploads folder and reach, read, or delete files elsewhere in the WordPress installation.
• No authentication gate. Front-end form submission is, by design, open to the public. Anyone who can load a page with an Everest Forms upload field can reach the vulnerable code path.

What does an attacker need? Only a publicly reachable Everest Forms form with a file upload field, and a vulnerable plugin version. From there they submit a request containing a malicious file — typically a small PHP web shell — and then request that file’s URL directly in a browser. Because the file sits inside the web root and ends in .php, the server happily executes it.

The official fix, visible in the plugin’s public commit history, is small but decisive: the patched code calls wp_die() when an invalid file type is detected, terminating the request instead of drifting onward into the upload logic. It is a reminder that in security code, failing loudly and immediately matters more than failing politely.

Real-world impact

Arbitrary file upload is the vulnerability class that turns “a bug in a plugin” into “somebody else’s server.” Once a web shell is running on your site, an attacker typically has the same power your PHP process has. On a normal WordPress host, that means:

• Full site takeover. Create a new administrator account, change existing passwords, lock the real owner out.
• Database access. A web shell can read wp-config.php, which contains your database credentials in plain text. From there: customer records, order history, hashed passwords, email addresses.
• Persistent backdoors. Attackers rarely stop at one file. They seed additional shells in obscure directories, add malicious cron jobs, and inject code into theme files so that removing the original file changes nothing.
• SEO and reputation damage. Spam injection, malicious redirects, pharma pages, and eventually a Google Safe Browsing warning in front of your homepage.
• Destruction. Because the flaw also permits arbitrary file deletion, an attacker can delete wp-config.php. That sounds harmless — it is not. A WordPress site with no config file reverts to the installation wizard, letting an attacker point it at a database they control and take ownership outright.
• Lateral movement. On shared hosting, a compromised site is often a stepping stone to every other site in the same account.

How to check if you’re affected

• In your WordPress dashboard, go to Plugins → Installed Plugins and look for Everest Forms. If it is not there, you are not affected by this CVE.
• Check the version number listed beneath the plugin name. Anything at or below 3.0.9.4 is vulnerable. 3.0.9.5 and above contain the fix.
• Note that the Pro add-on shares the same codebase family; if you run Everest Forms Pro, update it too.
• Your exposure is highest if any of your live forms include a file upload field. Review your forms under Everest Forms → All Forms and check which ones accept attachments.
• Look for signs of prior compromise: unexpected .php files inside /wp-content/uploads/ (there should be none), administrator accounts you did not create, and recently modified core or theme files.

How to fix it

Update Everest Forms to version 3.0.9.5 or later. That is the fix, and it should take about thirty seconds from Dashboard → Updates. Given the plugin has continued to ship releases since, updating to the current version is the better move.

Beyond the patch, a few hardening steps make the entire class of arbitrary file upload attacks far less useful to an attacker:

• Block PHP execution in the uploads directory. Nothing in /wp-content/uploads/ should ever run as code. On Apache, place a .htaccess file in that directory denying access to .php files; on Nginx, add an equivalent location block. This single change neuters most web shells even when an upload bug exists.
• Disable the file editor. Add define('DISALLOW_FILE_EDIT', true); to wp-config.php so a stolen admin session cannot trivially edit theme files.
• Remove upload fields you do not need. If a form does not genuinely require attachments, delete the field. Attack surface you do not have cannot be exploited.
• Enable automatic updates for plugins, or at minimum subscribe to vulnerability alerts so you learn about critical flaws in days rather than months.
• Run file integrity monitoring. The fastest way to catch a web shell is to be told the moment a new PHP file appears where none belongs.
• If you find evidence of compromise, assume full compromise. Deleting the shell is not remediation. Rotate all passwords and salts, audit user accounts, restore from a known-clean backup taken before the intrusion, and only then update.

Takeaway

CVE-2025-1128 is a textbook example of how a small logic mistake — setting an error message but forgetting to actually stop — becomes a 9.8-severity site takeover. It also illustrates why defence in depth matters. A site running vulnerable Everest Forms but blocking PHP execution in its uploads folder was in a dramatically better position than one relying on the plugin to get validation right.

You cannot audit every plugin you install. What you can do is update quickly, keep your installed plugin count lean, remove features you do not use, and put guardrails in place so that when a plugin inevitably fails, the failure is contained. Patch fast, and build the site so that a single bug is never enough.