Realtyna WPL EUVD-2026-51404

Exploitation requires that the Realtyna Organic IDX + WPL Real Estate plugin (≤5.2.0) is installed and active, and that the WPL I/O service endpoint is reachable over the network - both true by default. The attacker must supply valid api_key and api_secret values, but these are the plugin's own static migration-seeded defaults, identical across installs and publicly documented, so this is not a meaningful barrier unless a site operator has manually rotated them. The principal limiting factor is exactly that credential rotation: an installation that changed the default api_key/api_secret, or that fronts the I/O endpoint with a WAF blocking the upload action, breaks the unauthenticated path. A secondary limit is server hardening that forbids PHP execution in the upload directory, which prevents code execution even when the upload succeeds.

The signals align strongly toward high real-world risk. The CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H describes network-reachable, low-complexity, unauthenticated, no-interaction exploitation with full CIA impact - and the description independently corroborates each metric (public init hook = AV:N/PR:N, static documented credentials = AC:L, direct upload = C/I/A:H). Unlike many 9.8 ratings that hinge on non-default configurations, this one applies to default installations because the credentials are seeded by the plugin itself. No EPSS score, KEV status, SSVC decision, or POC was provided in the input, so quantitative exploitation-probability data is missing; this should not be read as low risk, since the technical barrier to exploitation is minimal. The main uncertainty is whether the static credentials are always left at their seeded defaults in production or are sometimes rotated - if a site changed them, the unauthenticated path is closed.

An attacker looks up Realtyna WPL's publicly documented default api_key and api_secret, then sends a crafted request to the WPL I/O set_property upload action carrying a small PHP webshell as the uploaded file. Because there is no capability check on the init-hook endpoint and no file-type validation, the shell is written to a web-accessible directory; the attacker then browses to it to execute commands as the web server user. Given AV:N/AC:L/PR:N/UI:N this requires no authentication and no victim interaction, and can be scripted against many sites.