Three characters from a broken homepage

The feature that looked fine

The plugin’s job was letting a site owner build forms — contact forms, submission forms, anything a visitor fills out on the front end. One field type accepted a file upload, and a convenience option let the site owner give the destination folder a name pulled from the form itself, so submissions could sort themselves: one folder per applicant, per order, whatever the form was for.

That is a reasonable feature. A folder name is not supposed to be dangerous input — it is a label, not a command — and treating it as harmless is exactly how a plugin ends up building a filesystem path out of a string a stranger typed, without anyone deciding that was a security-relevant thing to do.

Two small mistakes, chained

Neither half is exotic, which is exactly why it is worth writing about. First: the value passed through the plugin’s own text-cleaning step before it was used — but that step was built to strip dangerous HTML out of form submissions, not to validate a filesystem path. It left ../completely untouched, because nothing about three characters of punctuation looks like markup.

The second is WordPress’s own, not the plugin’s. Before writing to a new folder, core is supposed to refuse a path that climbs outside where it was told to work. That guard exists — but it runs after an earlier check for whether the target already exists on disk, and a traversal that resolves to a directory already there, such as the site’s own root, sails through before the guard gets a turn.

Put the two together and a folder-name field becomes a way to name any existing directory on the server, including the one WordPress itself lives in. From there the plugin’s own cleanup step removes two files it assumes are safe to touch: the .htaccess and index.php in whatever folder it just resolved. At the root, those are the files that keep the homepage answering. Delete them and the site does not go quiet — it goes from serving normally to returning 403, immediately, to every visitor.

How we know

A description is not a finding. Nothing here was reported on the strength of reading code: the engine built an isolated WordPress instance, installed the plugin’s official release untouched, and submitted the same public form a visitor would see. Nobody else’s site was involved at any point, and no person confirmed it by hand — RIA Labs performs no manual step, by design. What makes the finding admissible is the proof gate, which throws out a filing that has no working exploit code behind it.

It also ran the negative control a claim like this needs: submitting an ordinary folder name, the feature working as advertised, only ever touched files inside that one named folder. Everything else on the site was untouched before and after. That is what separates a traversal bug from a plugin that simply deletes things — the harness has to show the blast radius tracks the input, not just that files disappeared.

It went through WPScan’s own disclosure process. The 7.4 was scored by their reviewers rather than asserted by us, and that is the only reason it is worth anything as evidence. They are a CVE Numbering Authority, so the identifier was theirs to assign: the record sits in the public registry, not only in a database we could have written ourselves.

Three questions for your own stack

None of this is WordPress-specific. If anything in your product turns user input into a filesystem path — an upload destination, an export folder, a per-tenant directory — these are worth answering on whatever you are built on.

1. Does your sanitizer know it is looking at a path? A filter built to strip HTML or SQL syntax has no reason to touch ../, because nothing about it looks dangerous to that filter. Check what each cleaning step was actually written to catch, not just that one runs.
2. Does your existence check run before or after your traversal guard? If the order is wrong, a path that resolves to somewhere real can reach the operation before anything has asked whether it should be allowed to.
3. What does the fallback path do when nothing has been configured? The version of this code with a protective check sat behind a separate condition; the plain path had none. A feature gated by a setting almost always has a second, ungated version of itself somewhere in the same file.

None of that needs exotic tooling. It needs someone to read the code that shipped rather than the code you remember writing.

What it proves, and what it doesn’t

It proves the pipeline works a second time, on a different kind of bug: the first finding collapsed an authentication flow, this one deletes files no visitor should be able to reach. Two unrelated shapes are closer to what auditing an unfamiliar codebase actually turns up than one repeatable trick played twice would be.

It does not prove we would find every bug in your application, and two findings are not a track record. A plugin built by a small team is an easier read than a product with a security team and a decade of hardening.