If you received an email from me pointing you to this page, it is because your website appears to be running a vulnerable version of Realtyna Organic IDX plugin + WPL Real Estate (the WordPress plugin real-estate-listing-realtyna-wpl, by Realtyna). You may know it as WPL or as the Organic IDX plugin. This page explains why that matters and how to fix it.

This notice concerns CVE-2026-13714, an unauthenticated arbitrary file upload leading to remote code execution. In plain terms: someone who is not logged in, and who needs no account and no special configuration on your site, can write a script file into your site’s uploads area and then run it. That is full control of the site’s server-side code. It affects releases 4.0.0 through 5.2.0 and is fixed in 5.3.0, released 30 June 2026. Releases before 4.0.0 do not contain this flaw. If you are running an affected version, update the plugin to 5.3.0 or later as soon as you can, and then read If you were running an affected version below.

This is a plugin flaw, not a WordPress core flaw. A fully up-to-date WordPress does not protect you if this plugin itself 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, upload anything, or exploit anything.

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 in its public readme.txt file. I specifically did not send anything to the affected upload interface. Nothing was uploaded, tested, or exploited, and nothing about this check touches your data, your admin area, or any private part of your site.

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

The plugin ships a “mobile application” I/O interface, a set of commands that an external client can call over the web. One of those commands saves an uploaded file under the name the uploader chose, with no check on the file type. A file that ends in a script extension therefore lands in the site’s uploads area as a script, where it can be requested over the web and executed by the server.

Two things stop that from being a theoretical problem:

  • The interface is switched on in a default installation. No setting has to be enabled and no feature has to be in use for the endpoint to answer.
  • The key pair that is supposed to authenticate calls to it is seeded to the same fixed value in every installation of the plugin, and the admin interface marks it read-only, so an operator cannot change it even if they want to. A secret that is identical everywhere and public in the source is not a secret, so the gate is not really a gate.

Taken together, that means an unauthenticated visitor can place executable code on the server. Once code runs on your server it can do anything your website can do: read the database, add administrator accounts, modify or replace pages, send mail from your domain, or install a persistent back door.

I am deliberately not publishing the request format, the parameter names, or a working example, and I would ask that you do not either. The description above is the shape of the problem, which is what you need in order to decide how urgently to act.

No CVSS severity score has been published for this issue by the assigning authority, so this page does not quote one. The issue is not listed in CISA’s Known Exploited Vulnerabilities catalog, and I have no evidence that it is being exploited in the wild or that any particular site has been attacked through it. What can be said plainly is what the flaw allows: unauthenticated, no configuration required, ending in code execution.

One more thing worth knowing, because it makes the update look optional when it is not: the vendor’s changelog for 5.3.0 does not mention security. It reads “Removed deprecated mobile_application”. That entry is the fix: the vulnerable subsystem was deleted outright. An operator scanning release notes for a security advisory will not find one.

The good news: updating to the fixed version closes the hole, and the update is straightforward.

Am I affected?

You do not have to take my word for which version you are running.

From the WordPress admin area (this is the authoritative check):

  1. Log in to your WordPress dashboard (usually at yourdomain.com/wp-admin).
  2. Go to Plugins then Installed Plugins.
  3. Find Realtyna Organic IDX plugin + WPL Real Estate and note the version shown beneath its name.

From the public manifest (no login needed): open yourdomain.com/wp-content/plugins/real-estate-listing-realtyna-wpl/readme.txt in a browser. The Stable tag: line near the top is the version your install reports. This file ships inside the plugin folder, so it reflects what is actually installed, and it is the same public file I read.

Then apply this rule:

  • 4.0.0 through 5.2.0: affected, update now.
  • 5.3.0 or newer: already fixed, nothing to do for this issue.
  • Older than 4.0.0: not affected by this issue. The unvalidated upload code does not exist in those releases. Public write-ups describe the affected range as “all versions before 5.3.0”; that is not correct, and if you are on a 3.x release you have no reason to treat this as an emergency. It is still a very old release, so updating remains sensible for other reasons.

Do not read the version off an asset URL. If you look at your page source and see something like realtyna.min.js?ver=5.2.21, that number is not the plugin version. This plugin does not pass its own version to WordPress when it registers its stylesheets and scripts, so WordPress fills in your WordPress core version instead. We have seen live sites on plugin 4.3.2 serving a ?ver= of 4.9.9, and sites stamping 5.2.21, which is a WordPress core release number that happens to look exactly like a plugin version just below the 5.3.0 boundary. Reading it as the plugin version can tell you the opposite of the truth. Use wp-admin, or readme.txt.

How to fix it

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 the plugin is listed, install it from here.
  3. If you prefer the command line, WP-CLI does the same thing: wp plugin update real-estate-listing-realtyna-wpl.
  4. If no update appears, you can get the latest release directly from the plugin’s page on the WordPress.org directory, Realtyna Organic IDX plugin + WPL Real Estate, and update via Plugins then Add New Plugin then Upload Plugin.
  5. After updating, confirm the new version number (5.3.0 or later) using the steps above, and check that your site loads normally.

If you genuinely cannot update right away, the interim step is to switch the plugin’s I/O interface off in its own settings, which closes the route to the upload command. Treat that as a stopgap that buys you time, not as a substitute for updating: only 5.3.0 removes the vulnerable code.

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

If you were running an affected version

Because this issue allows a file to be uploaded and then run, updating closes the hole but does not undo anything that may already have been done through it. If your site was running an affected version while it was reachable from the internet, it is worth checking. You (or your webmaster) should look at your own site for:

  • Script files in the uploads area that do not belong. Look under wp-content/uploads/ for files with a .php extension (or other executable extensions) sitting among the property images and documents. Legitimate uploads for a real estate listing are images, PDFs, and similar; a .php file among them is not normal.
  • Files with recent or odd timestamps. Sort by modification date and look for anything you cannot account for, including in the plugin’s own upload folders.
  • Your administrator accounts. In Users then All Users, filter by Administrator and remove any account you do not recognize. Adding a new admin user is a common way to keep access.
  • Recently installed or modified plugins and themes. Look for anything you did not install yourself, and for plugins with generic or unfamiliar names, since a rogue plugin or theme is a common way to plant a back door.
  • Other signs. Unexpected new content or pages, changes to the admin email or site URL settings, unfamiliar scheduled tasks, or outbound spam complaints are all worth investigating.

If you find evidence of unauthorized access, treat the site as compromised: remove the files, rotate your credentials (WordPress admin, database, and hosting panel), and consider restoring from a known-good backup taken before the intrusion. If your organization has an IT security team, loop them in.

I want to be clear: I have not checked your site for any of these indicators, and I do not know whether your site was affected. This list is here so you can check for yourself. A site in the affected version range may also already be protected by other means (a web application firewall, a hosting-level backported fix, or the I/O interface switched off); this notice is a version-based observation, not a statement that your site was exploitable at the time I looked.

What I did and did not do

  • I read the plugin’s public readme.txt and your homepage, both of which your site serves to every visitor.
  • I did not access your WordPress admin area, your database, or any private part of your site.
  • I did not send anything to the affected upload interface. Nothing was uploaded, and nothing was tested or exploited. When the flaw itself is an open upload endpoint, not touching it is the whole difference between a disclosure and an intrusion.
  • The finding is therefore a version-based observation, and it is one you can reproduce yourself from the same public file.

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