WPeMatico RSS Feed Fetcher CVE-2026-89004

Requires an authenticated WordPress account at contributor role or higher on a site running WPeMatico RSS Feed Fetcher before 2.8.26; no user interaction and no non-default configuration are needed beyond the plugin being active and campaigns existing. Exploitation is LIMITED by the need for at least contributor access (so sites without open registration or untrusted low-privilege authors face little exposure) and by the impact being read-only disclosure of campaign configuration and run logs - no modification or denial of service. The exposed data is other users' RSS campaign settings and execution logs, which is low-sensitivity, bounding the practical impact.

This is a low-severity information-disclosure issue that is NOT a real prioritization concern. All signals align on low urgency: the CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N, base 2.7) rates only Low confidentiality impact with no integrity or availability impact; EPSS is not provided; the CVE is NOT in CISA KEV; and SSVC scores Exploitation=none, Automatable=no, Technical Impact=partial - a 'Track' (not 'Act') disposition. The one elevating signal is a publicly available WPScan exploit, but POC availability is distinct from active exploitation and SSVC still records Exploitation=none. NOTE A CONFLICT: the vendor CVSS uses PR:H, yet the description explicitly says exploitation only requires 'contributor-level access and above.' Contributor is a low-privilege editorial role in WordPress, so PR:H appears overstated; PR:L is more defensible, which would raise the base score to ~4.3 but keep it firmly Medium/Low. Net: real-world risk is low - a self-registered or low-trust contributor can read (not alter) other users' RSS campaign settings and run logs.

An attacker who holds or obtains a contributor account on a WordPress site running WPeMatico (e.g. via open registration or a guest-author arrangement) calls the plugin's campaign configuration/run-log retrieval endpoint using another user's campaign ID. Because the plugin never checks ownership, it returns the full stored configuration and execution logs of campaigns owned by other users, including administrators. A public WPScan exploit reference exists, and the attack is a single authenticated request requiring no user interaction.