# A simple form on my site became the way in

> A contact, quote or price calculation form stays an area where anyone can write whatever they like, with no account and no password: that is why forms sit among the most attacked components in the WordPress ecosystem.

- Source canonique : [https://allaux.fr/en/securite/formulaire-du-site-utilise-comme-porte-d-entree](https://allaux.fr/en/securite/formulaire-du-site-utilise-comme-porte-d-entree)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Identify which extension runs the form and its exact version, then compare it with the vendor latest release. Next, look at the folder where the form stores uploaded attachments: a .php file should never be there. A form that computes a total or hides fields depending on answers interprets visitor input, and deserves closer scrutiny than a plain message field.

## A form field is an unauthenticated entry point by nature

A public form is the one place on your site where anyone, with no account and no password, writes data your server will process. The back office is behind a login, the API asks for a key, FTP asks for credentials. The contact form is open by definition — that is its whole purpose. Merchants file it mentally under content, next to a text block or an image, when it actually belongs with executed code.

That mental filing explains what follows. The form is not on the list of sensitive components, it is not updated first, its version is not tracked. Yet Patchstack's figures for 2025 attribute 91% of WordPress ecosystem vulnerabilities to plugins, against 9% to themes and only six to the core. And Wordfence's annual report on 2024 puts missing authorisation flaws at 73% of vulnerabilities exploitable without authentication. In short: most of what gets exploited without an account comes down to an absent access check — precisely the check a public form does not have by design.

## What should worry you around a form

- An administrator account you never created shows up in the user list.
- Unknown PHP files appear in the uploads folder or in the form plugin's own folder.
- The site sends emails you did not write.
- Logs show repeated requests to the form's processing endpoint, at a rate no human visitor produces.
- An advanced form feature — a calculation, a condition — behaves differently from before.
- The form returns errors or blank pages although nothing was changed.

## Simple form versus form with logic

A simple form collects strings, emails them and stores them. A form with logic does more: it works out a total, applies conditions, shows or hides fields depending on answers, builds a quote on the fly. To do that it has to interpret what the visitor typed, and that interpretation is where the risk comes from. The more a plugin evaluates input instead of merely storing it, the wider the exposed surface.

Everest Forms Pro illustrates it precisely. CVE-2026-3300, CVSS score 9.8: unauthenticated arbitrary PHP code execution through the complex calculation feature. Form data was sanitised with sanitize_text_field(), which does not escape characters meaningful to PHP syntax; the result was then evaluated by eval(). Versions 1.9.12 and earlier are affected.

The timeline teaches as much as the flaw. Reported by researcher h0xilo in February 2026. Patch released on 18 March 2026. Active exploitation from 13 April 2026. Wordfence blocked more than 29,300 exploitation attempts, and an indicator of compromise was published: an administrator account named diksimarina. Nearly a month separates the patch from mass exploitation. That is time handed to any merchant who follows updates — provided they know which version is actually running.

## What I check on a site after a disclosure like this

1. **Identify the form plugin and its version** — The exact name and version number, not "the contact form". Plenty of sites carry two form plugins, one shipped by the theme and never used. That is the one that causes trouble, because nobody updates it.
2. **Confirm the installed version postdates the patch** — With Everest Forms Pro the line is clear: versions 1.9.12 and earlier are affected, the fix is dated 18 March 2026. Watch Pro editions, updated through a separate channel often tied to an expired licence: the plugin can report itself as up to date without being so.
3. **List the advanced features actually in use** — Calculations, conditional fields, file uploads, dynamic logic. Whatever is unused can nearly always be switched off, and a disabled feature narrows the exposed surface even when a flaw targets it directly.
4. **Read the logs across the exposure window** — I take the patch date as the boundary and go back further if the plugin was already behind. I look for repeated requests to the form endpoint, account creations, and files written into the uploads folders.
5. **Review privileged accounts and dropped files** — I compare the administrator list against what is expected, then look for recent PHP files in the uploads and plugin folders. A patch applied after exploitation never removes what was dropped before: updating shuts the door, it does not tidy up.

## The question to ask of every form

> "Do I genuinely need this feature?" A live price calculation, conditional fields or a file upload are sometimes justified. More often they were enabled during a testing phase and simply stayed, because nobody questioned them again. Any feature that interprets visitor input rather than storing it needs a real use case; otherwise I switch it off, and the flaw that will one day affect it will not affect me.

## Related reading

- **Tracking flaws that affect your store** — Where to follow disclosures so you spot the ones hitting your own plugins. ([/securite/surveiller-les-failles-qui-concernent-ma-boutique](/securite/surveiller-les-failles-qui-concernent-ma-boutique))
- **Checking whether my site is compromised** — The checks to run when a published flaw affects a plugin you use. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))
- **Abandoned modules and extensions** — Why the component nobody updates remains the real number one vector. ([/securite/modules-et-extensions-abandonnes](/securite/modules-et-extensions-abandonnes))
- **Checking plugins before an update** — How to apply a security patch without breaking the live site. ([/wordpress-woocommerce/mise-a-jour/verifier-extensions-avant-mise-a-jour](/wordpress-woocommerce/mise-a-jour/verifier-extensions-avant-mise-a-jour))

## FAQ

### My contact form is basic — does this concern me?

The risk depends on the installed plugin, not on how simple the visible form is. A plugin offering calculations and conditional fields ships that code whether you use it or not. The real question is: which plugin, which version, which features are enabled.

### How do I know whether my site was exploited before I updated?

I read the logs across the exposure window, compare the administrator list against what is expected, and look for recent PHP files in the uploads folders. For Everest Forms Pro there is a public indicator: an administrator account named diksimarina.

### I have updated the plugin — is that enough?

Not if exploitation already happened. The update closes the flaw but removes neither the accounts created, nor the files dropped, nor the secrets exposed. After confirmed exploitation, updating is the first step, not the last.

### Should I disable calculations and conditional fields?

If they do nothing for your site, yes. A feature that interprets visitor input rather than storing it deserves a real justification. If it is genuinely useful, keep it and treat its updates as a priority.

### How long do I have to apply a patch like this?

Less than the Everest Forms Pro case suggests. There, nearly a month passed between the fix on 18 March 2026 and active exploitation from 13 April 2026, but that gap is never guaranteed: I treat a security patch on a public-facing component as same-day work.