IMPress for IDX Broker CVE-2026-54869

Exploitation requires an authenticated WordPress account with at least low-level posting privileges (PR:L - e.g., contributor or author able to submit content through an IMPress for IDX Broker input field), and it requires a victim (typically a higher-privileged user or administrator) to subsequently view the page where the malicious payload is rendered (UI:R). The payload must be stored and then served without output encoding. Limiting factors: this is NOT unauthenticated - an attacker must first have a valid low-privilege account on the target site; the stored script only fires when another user loads the affected page; and the plugin (through version 3.3.1) must be installed and active on the WordPress site.

This is a moderate-severity Stored XSS (CVSS 6.5, CWE-79) in the IMPress for IDX Broker WordPress plugin, reported by Patchstack. The CVSS vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L) indicates network-reachable exploitation with low attack complexity, but it requires low-level authentication (PR:L - typically a contributor/author-level account) and victim user interaction (UI:R). The scope-changed flag (S:C) reflects that injected script executes in the browser context of other users/admins, which is the typical escalation path for stored XSS in WordPress. No EPSS score, KEV listing, or public POC was provided in the input: exploitation status is 'no public exploit identified at time of analysis.' Taken together, the signals point to a real but conditional issue rather than a widespread, automatable threat - the authentication and user-interaction requirements meaningfully reduce real-world risk compared to an unauthenticated flaw. Absence of EPSS/KEV/POC data means exploitation likelihood cannot be quantified; this should be treated as a standard patch-cycle item unless an admin-targeting attack path is confirmed.

An attacker with a low-privilege authenticated WordPress account (e.g., contributor or author) injects a malicious script payload into a plugin-controlled input field that is stored and later rendered without proper neutralization. When an administrator or other user views the affected page, the stored script executes in their browser session, potentially enabling session hijacking or actions on their behalf. No public exploit code was identified at time of analysis.