A form notification should send you an enquiry, perhaps with an uploaded document. It shouldn’t attach a private file from your web server.
That’s the problem behind CVE-2026-115483 in Everest Forms. Under a particular combination of add-ons, form fields and email settings, a notification can include a server file such as wp-config.php. If the notification goes to an address supplied by the visitor, that file could reach the wrong person.
Not every Everest Forms site has that combination. But updating to 3.6.3 isn’t enough for this issue, either. You need core Everest Forms 3.6.4 or a newer supported release.
What the attachment bug actually does
Wordfence published its advisory on 10 November 2026, describing an unauthenticated arbitrary file read affecting Everest Forms through version 3.6.3, with a CVSS score of 7.5.
The fault sits in attach_entry_files, the function that gathers files for notification emails. In the affected branch, it accepts field values associated with a meta key containing signature_ after checking whether the file exists. What’s missing is a restriction keeping that file inside an allowed location.
In plain English: checking that a file exists doesn’t establish that a form submission is allowed to email it.
A readable wp-config.php may expose database credentials and WordPress authentication salts. Serious information. Still, possession of those details doesn’t automatically allow a remote database connection, and it isn’t proof that someone took over the site.
Which forms need a closer look?
The conditions matter together. A basic contact form running only the free plugin shouldn’t be described as automatically leaking server files.
Check these four things:
- The Pro functionality is present. The affected setup involves the Everest Forms Pro add-on providing signature and file email attachment functionality.
- A relevant field uses a matching internal key. The code checks for
signature_in the field’s meta key. Even a text field with a matching key can matter; don’t check only whether the form visibly contains a signature box. - The notification has Attach Files enabled. Inspect each notification attached to the form, rather than assuming they all share the same settings.
- The attachment can reach a visitor-supplied address. For the file to reach an attacker through this route, the notification must be sent to an address they control, such as the email entered in the form.
For a hypothetical equipment-hire business, that might mean checking the confirmation email sent back to someone requesting a projector. Does it include attachments? Is its recipient taken from the enquiry form? Those are useful questions, not evidence that anything happened.
If you can’t find internal field keys in the editor, ask your developer to inspect the configuration. The visible label alone won’t settle it.
The version numbers are easy to mix up
| Core Everest Forms version | What to know |
|---|---|
| 3.6.2 or earlier | Affected versions include both the attachment file-read issue and the separate deletion issue, each with its own conditions. |
| 3.6.3 | Fixes the separate deletion issue. Still affected by the attachment file-read issue. |
| 3.6.4 or later | 3.6.4 is the minimum release identified as fixing the attachment issue. Prefer a newer supported version where available. |
Patchstack’s primary advisory explicitly identifies 3.6.4 as patched. The vendor changelog, dated 5 November 2026 for that release, records improved handling of signature files in email notification attachments.
There’s a source mismatch to flag: Wordfence’s generic remediation box still says no patch. The update recommendation here follows Patchstack’s patched-version statement and the vendor’s changelog, not a claim that Wordfence confirms the fix.
And the deletion issue?
That’s CVE-2026-120513, affecting versions through 3.6.2 and fixed in 3.6.3. The Wordfence CNA record carried by NVD describes missing path validation in remove_csv_file_after_email_send.
It requires the Save-and-Continue add-on and the target form’s Disable storing entry information setting. Deletion normally concerns uploads, with effects beyond that area possible in rare circumstances. Calling it unrestricted deletion of anything on every server would overstate it.
Update, then test the actual notification
Before you update take a fresh backup of the database and site files, and check that you know how to restore it. Use staging if you have it, particularly where forms handle payments or bookings.
I recomend updating core Everest Forms to at least 3.6.4. Check the supported Pro and add-on versions too; don’t assume an old paid add-on will work happily with every newer core release.
Then submit a harmless dummy enquiry using an email address you control and, where needed, a small test document containing no private information. Check delivery, recipients, attachments and whether the submission appears where expected. Never test this by trying to send wp-config.php or another secret file.
If updates tend to sit untouched because you’re busy running the business, WordPress maintenance can put backups, compatibility checks and form testing on a regular schedule.
While you’re arranging the update
Temporarily disable Attach Files on affected notifications. Also remove visitor-controlled destinations from notifications that carry attachments, checking confirmation emails as well as staff alerts.
Keep ordinary enquiry delivery working where you can. Sending a plain confirmation without files is usually less disruptive than switching off the entire form.
These are temporary risk reductions, not substitutes for updating. And stronger logins won’t repair this unauthenticated bug. Our WordPress login security guide covers useful downstream protection, but it’s a different layer.
If a private file may already have been sent
Preserve evidence before clearing logs or deleting suspicious entries. Review notification settings, available mail metadata and delivery logs, unfamiliar administrator accounts, and unexpected file changes. Mail records may show recipients and timing without retaining attachment contents; missing records don’t prove there was no exposure.
Our hacked WordPress cleanup guide explains the wider investigation. If you need help, arrange authorized hacked site cleanup rather than making blind changes.
Suspected credential exposure calls for a planned review and, where appropriate, replacement with the owner’s authorization. Coordinate database changes with the site configuration to avoid an outage. Changing an admin password alone doesn’t patch this flaw.
Today’s check is specific: open your form notifications, inspect Attach Files and their recipients, then confirm core Everest Forms is running 3.6.4 or newer.