If you received an email from me pointing you to this page, it is because your website appears to be running a version of Drag and Drop Multiple File Upload for Contact Form 7 (the WordPress plugin listed on WordPress.org under that name, by codedropz, which lives in your files at /wp-content/plugins/drag-and-drop-multiple-file-upload-contact-form-7/) that falls within the affected range of a known security issue. This page explains what the issue is, how to work out whether it applies to your site at all, how to read your version without being misled, and how to update.

Please note: this is not the WooCommerce version. The same author publishes a separate plugin, “Drag and Drop Multiple File Upload for WooCommerce” (folder drag-and-drop-multiple-file-upload-for-woocommerce), which is a different product on its own version numbering. If the plugin in your files is the WooCommerce one rather than the Contact Form 7 one, this page is not about it. Everything below concerns the Contact Form 7 add-on only.

Before anything else, the most important fact about this notice: a version in the affected range does not by itself mean your site is exposed. The issue below only comes into play on sites that have a particular kind of upload field, and I cannot see how your forms are configured from outside:

  • The issue only reaches a Contact Form 7 form that has one of this plugin’s drag-and-drop upload fields set to accept any file type.
  • A field that restricts what it accepts to specific types (for example images or PDFs) is not exposed to this issue, even on an affected version. Restricting accepted types is also the default when a field does not specify them.

I can read your plugin version from a public file, but I cannot read your form configuration, so this notice is a precautionary heads-up rather than a confirmed finding about your site.

The issue is CVE-2026-18781, an unauthenticated file-upload flaw in the plugin’s upload handling. It affects versions 1.3.9.3 through 1.3.9.8 and is fixed in 1.3.9.9. If you are running an affected version, update Drag and Drop Multiple File Upload for Contact Form 7 to 1.3.9.9 or later, and keep Contact Form 7 itself up to date as well.

A word on urgency, because this is a conditional notice. If none of your upload fields accept any file type, updating is ordinary plugin maintenance. If one of them does, please treat the update as a priority: in that configuration the flaw could let a visitor with no account at all save a file of their choosing onto your server, of a kind that the server might then run, which can lead to full control of the site.

This is a plugin flaw, not a WordPress core flaw, and it is separate from Contact Form 7 itself. A fully up-to-date WordPress, and an up-to-date Contact Form 7, do not protect you if this add-on is on an affected version.

Is this message legitimate?

Yes. This is a good-faith, responsible-disclosure notice from an independent security researcher. I am not asking you for money, passwords, or access to your site, and I have not attempted to break into it, submit any of your forms, or upload anything to it.

All I did was look at publicly visible files that your website serves to every visitor (the same way your homepage is public) and note the version number that the plugin publishes. I specifically did not submit any form, did not upload a file, and did not go near the plugin’s upload handler. Nothing about this check touches your data, your admin area, or any private part of your site (more detail under What I did and did not do below).

If you would like to verify who I am, see the contact details at the bottom of this page and the About page.

Why this matters

This plugin adds drag-and-drop file-upload fields to Contact Form 7 forms, so visitors can attach files when they submit a form: a job application, a support request, a photo. To keep that safe, the plugin is supposed to refuse dangerous file types.

In affected versions, that check could be slipped past. The plugin inspected the uploaded file’s name to decide whether the type was allowed, then adjusted the name, and saved the file without checking the adjusted name again. Because the name was changed after it had been approved, a name could be arranged so that the version that was checked looked harmless while the version that was actually saved was not, letting a disallowed file type land on the server. Where the server then treats that file as something it can run, the result is that a stranger’s file runs on your site.

Two things follow from that, and they pull in opposite directions. The first is that this only matters where a form has an upload field configured to accept any file type. Where every upload field is limited to a specific set of types, the disguised file does not match an allowed type and is turned away, so a site in that state is not reachable through this issue. The second is that where an “accept anything” field does exist, no account, no password, and no cooperation from anyone is required: the form is open to the public by design.

I am describing this at the level a site owner needs in order to act, and no further. I am not publishing the details that would let someone reproduce it, and I would ask you not to try it against your own site or anyone else’s. Reading your form configuration and your version number, as described below, tells you everything you need to decide what to do.

If my email cited this issue, it means the version your site reports falls within the affected range. I did not test whether your particular site is exploitable, and I cannot see how your forms are configured. All I observed is the version.

Am I affected?

Two questions decide it, in this order.

First: does any upload field accept “any file type”?

This is the deciding question, and only you can answer it. Checking your own forms is entirely safe and is the whole point of this page.

  1. Log in to your WordPress dashboard and open Contact (Contact Form 7) in the sidebar.
  2. Open each form that offers a file upload, and find the drag-and-drop upload field (this plugin’s field, added alongside the standard Contact Form 7 tags).
  3. Look at whether that field limits the file types it accepts.
  • If every upload field is restricted to specific types (for example jpg, png, pdf), this issue does not reach your site, even on an affected version. Updating is still worth doing as ordinary maintenance.
  • If any upload field is set to accept any file type, the issue applies to you, and you should update promptly. Restricting that field to the types you actually need is a sensible step in its own right, but the update is the fix.

Please do not try to reproduce the problem against your own site or anyone else’s; you do not need to in order to answer the question above.

Second: which version are you running?

You do not have to take my word for it. For this plugin there is one specific way of checking that will mislead you, so it is worth reading this part carefully.

From the WordPress admin area (authoritative):

  1. In your WordPress dashboard, go to Plugins then Installed Plugins.
  2. Find Drag and Drop Multiple File Upload - Contact Form 7, the entry whose folder is drag-and-drop-multiple-file-upload-contact-form-7, and note the version shown beneath its name.

From the public manifest (no login needed): open yourdomain.com/wp-content/plugins/drag-and-drop-multiple-file-upload-contact-form-7/readme.txt in a browser. The Stable tag: line near the top is the version your install reports, and this is one of the public sources I read.

From your page source (no login needed): view the source of a page on your site and look for one of the plugin’s front-end assets at exactly these paths:

/wp-content/plugins/drag-and-drop-multiple-file-upload-contact-form-7/assets/css/dnd-upload-cf7.css?ver=...
/wp-content/plugins/drag-and-drop-multiple-file-upload-contact-form-7/assets/js/codedropz-uploader-min.js?ver=...

The ?ver= number attached to those files under that folder is the plugin’s own version. For this plugin it tracks the release exactly, which is why I treat it as a dependable reading.

The trap to avoid here. The author’s separate WooCommerce plugin ships a file with the same name, codedropz-uploader-min.js, under its own folder (drag-and-drop-multiple-file-upload-for-woocommerce) with an unrelated version number. If you read a version out of your page source, make sure the folder in the path is drag-and-drop-multiple-file-upload-contact-form-7 and not the WooCommerce one; otherwise you will be reading a different product’s version entirely.

Then apply this rule, noting that versions compare numerically, not alphabetically:

  • 1.3.9.3 through 1.3.9.8: potentially affected, subject to the upload-field question above. Update now.
  • 1.3.9.9 or newer: already fixed as far as this issue is concerned. Taking the latest available version is the best move.
  • Older than 1.3.9.3: not affected by this issue. The specific weakness described above was introduced at 1.3.9.3. That said, a release that old is far behind on everything else, and updating is worth doing on general grounds.

If you cannot get a readable version out of the checks above, that is not unusual: caching or optimisation plugins routinely strip the ?ver= value, and the assets only appear where the plugin loads. The admin screen in step one always has the answer.

How to upgrade

The safest path is to update through WordPress itself, and to back up first:

  1. Back up your site (files and database) before making changes. Most hosting providers offer one-click backups, or use a WordPress backup plugin.
  2. In the WordPress admin, go to Dashboard then Updates, or Plugins then Installed Plugins. If an update for this plugin is listed, install it from here.
  3. If you prefer the command line, WP-CLI does the same thing: wp plugin update drag-and-drop-multiple-file-upload-contact-form-7 (the command uses the folder name).
  4. If no update appears, you can get the latest release directly from the plugin’s page on the WordPress.org directory, Drag and Drop Multiple File Upload for Contact Form 7, and update via Plugins then Add New Plugin then Upload Plugin.
  5. After updating, confirm the new version number (1.3.9.9 or later) using the steps above, and check that your forms and file uploads still work normally.

While you are in there, it is worth confirming that WordPress core, Contact Form 7, and your other plugins are up to date, since the same principle applies to all of them.

After updating

Updating to 1.3.9.9 or later closes the issue, and for most sites that is the whole task. This page is a precautionary notice, not an incident report: I have no visibility into whether anything happened on your site, and I did not look.

One follow-up is worth considering, and it is conditional on the same upload-field question. If your site had a form with an “accept any file type” upload field while running an affected version, then it was at least theoretically possible for a file to have been placed on your server. Updating closes the hole, but it does not remove anything that may already have been saved, so in that case a few routine precautions are sensible:

  • Look through your uploads directory (typically under wp-content/uploads/) for files you do not recognise, especially any that are not the kind of documents or images your forms are meant to receive.
  • Review your administrator accounts, recent logins, and any active sessions for anything you cannot account for.
  • Reset the passwords on your administrator accounts. Regenerating WordPress’s secret keys and salts in wp-config.php is a sensible companion step (new values are one click away at the official secret-key generator, and swapping them signs every user out once).

If you find something that concerns you, treating it as you would any other suspected unauthorized access is the right response. If none of your forms had an “accept any file type” upload field, updating alone is enough.

What I did and did not do

To be fully transparent about the check behind my email: I only read files that your site already serves to every visitor, specifically the plugin’s public readme.txt, your homepage, and the asset addresses written into that page. I did not access your WordPress admin area, your database, or any private part of the site.

In particular, I never submitted any of your forms, never uploaded a file, and never touched the plugin’s upload handler. Nothing was submitted, tested, or exploited. That matters more here than on most of these pages, because uploading a file is the exact action this issue concerns, so “I did not touch it” is the whole difference between a disclosure and an intrusion.

I am also deliberately not publishing the details that would help someone act on this issue. The description above stops at the level a site owner needs, and I do not link any proof-of-concept code.

This is a version-based observation: your site reports a version in the affected range. It is not a statement that your site was exploitable at the time I checked. Because the issue depends on a form setting I cannot see, a site in that range may well not be exposed at all, and a site in that range may separately be protected by other means such as a web application firewall.

I do not have a webmaster / I am stuck

If you are not the person who maintains the site, please forward this page to whoever does (your web developer, agency, or hosting provider). They will recognize the steps above quickly.

If you are maintaining the site yourself and get stuck, I am happy to help point you in the right direction at no cost. Reach out using the contact details below.

Contact

Evan Harris, Security Researcher

I reach out about issues like this purely to help operators secure their sites. If you would prefer not to be contacted again, just let me know and I will honor that.

References

Official advisories and tracking

Vendor / plugin