_explained / everest-forms-wordpress-plugin-file-read-delete-flaw
HIGH PLAIN ENGLISH 5 min read

A Popular WordPress Form Plugin Could Hand Hackers Your Site's Master Keys

A critical flaw in Everest Forms lets anyone on the internet read or delete sensitive files on your WordPress site — no login required.

💬
PLAIN ENGLISH EDITION

This article is written for general audiences — no security background needed. For the full technical analysis with CVE details, affected versions, and code-level breakdown, visit Intel Reports.

If your WordPress site uses contact forms, there's a chance a complete stranger on the internet can right now read the file that contains every password and database credential powering your website — without logging in, without guessing anything, and without leaving an obvious trace.

Who's at Risk and Why It Matters

Everest Forms is one of the most widely installed form-builder plugins in the WordPress ecosystem, used to power contact pages, survey forms, and registration flows on hundreds of thousands of websites worldwide. Any site running version 3.4.4 or earlier is currently vulnerable to a flaw that security researchers have tagged CVE-2026-5478 and rated 8.1 out of 10 (HIGH) on the industry-standard severity scale.

That's not a small pool of potential victims. WordPress powers roughly 43% of all websites on the internet. Plugins like Everest Forms sit on top of that, quietly handling millions of form submissions per day across small businesses, nonprofits, e-commerce stores, and personal blogs. The people running those sites are rarely security engineers — they're bakers, dentists, freelancers, and local retailers who trusted a plugin to handle a routine task. This vulnerability exploits exactly that trust.

What an Attacker Can Actually Do to Your Site

Here's the scenario in plain terms. When someone fills out a form on your WordPress site and uploads a file — say, attaching a résumé or an image — Everest Forms keeps track of that uploaded file in the background. The problem is that it does this by trusting information sent directly from the visitor's browser, essentially asking the visitor, "Hey, where did you put that file?" A normal user's browser sends back a legitimate answer. But an attacker's browser can send back a lie — a carefully crafted fake path designed to point the server toward files it was never supposed to touch.

Because the plugin converts that browser-supplied answer into a real location on the server's hard drive without properly checking whether the destination is actually a safe, permitted folder, an attacker can walk the server backward through its own directory structure — a classic technique called path traversal. The target of choice for most attackers would be wp-config.php, the single most sensitive file on any WordPress installation. That one file contains the database name, username, password, authentication secret keys, and hosting details for the entire site. With that file in hand, an attacker can often pivot to full database access, account takeover, and complete site compromise.

It gets worse. The same flaw that lets an attacker read files also lets them delete files. An attacker who wants to cause destruction rather than theft could silently wipe critical system files, corrupt a site's configuration, or delete core WordPress files — potentially taking the entire website offline. No account needed. No special tools. Just a crafted form submission sent from a browser, a script, or even a simple command-line tool.

The Technical Detail Security Researchers Need

The root cause lives in how Everest Forms processes the old_files parameter in public-facing form submissions. The plugin uses regex-based string replacement to convert attacker-supplied URLs into local filesystem paths — but critically, it performs no canonicalization and no directory boundary enforcement before acting on the result. This means path-traversal sequences (e.g., ../../) embedded in the old_files payload survive the transformation intact and resolve to arbitrary locations on the server filesystem. Because this parameter is accepted from unauthenticated HTTP requests, there is no authentication barrier of any kind between the public internet and the vulnerable code path. The vulnerability is classified under CWE-22 (Improper Limitation of a Pathname to a Restricted Directory), and carries a CVSS score of 8.1.

Has This Been Used in the Wild?

As of publication, there is no confirmed active exploitation in the wild. Security teams have not yet identified specific campaigns, threat actors, or known victims tied to this CVE. However, that window historically closes fast once a vulnerability of this class becomes public. Path-traversal flaws targeting unauthenticated endpoints are among the most reliably and rapidly weaponized vulnerability types — automated scanning tools can probe millions of sites for a known endpoint signature within hours of a proof-of-concept becoming available. The absence of confirmed exploitation today is not a reason to delay patching; it is a reason to patch before the exploits arrive.

The vulnerability was responsibly disclosed through coordinated channels, and the Wordfence threat intelligence team is credited with the discovery and analysis. A patch has been made available by the Everest Forms development team.

What You Need to Do Right Now

If you manage a WordPress site — or if you pay someone to manage one for you — here are three specific steps to take today:

  1. Update Everest Forms immediately to version 3.4.5 or later. Log into your WordPress dashboard, go to Plugins → Installed Plugins, find Everest Forms, and click "Update Now." If auto-updates are available for this plugin, enable them. The patched version addresses the file path handling flaw directly. Do not wait for your next scheduled maintenance window — this one is urgent.
  2. Audit your server for signs of unauthorized file access. Check your web server access logs (typically found in /var/log/apache2/ or /var/log/nginx/) for unusual POST requests to form submission endpoints containing sequences like ../, %2e%2e, or references to wp-config. If you use a managed WordPress host, contact their support team and ask them to review access logs on your behalf. Many hosts — including WP Engine, Kinsta, and SiteGround — offer log access through their dashboards.
  3. Rotate your WordPress database credentials and secret keys immediately. Even if you see no evidence of access, assume the worst and rotate. Update your database password in both your hosting control panel and your wp-config.php file. Then regenerate your WordPress secret keys and salts using the official generator at api.wordpress.org/secret-key/1.1/salt/ and replace the corresponding lines in wp-config.php. This invalidates any sessions or credentials an attacker may have already harvested.

The broader lesson here is one the security community repeats after every incident like this: plugins are code, and code has bugs. A contact form feels like furniture — boring, static, harmless. But every input field on your website is also a door, and sometimes those doors have broken locks. Keeping plugins updated isn't optional maintenance. It's the deadbolt on the front of your business.

// TOPICS
#arbitrary-file-read#arbitrary-file-deletion#path-traversal#wordpress-plugin#unauthenticated-attack
// WANT MORE DETAIL?

The technical analysis covers the exact vulnerability mechanism, affected code paths, attack chain, detection methods, and full remediation guide.

Read technical analysis →