CVE-2026-89005 in WPeMatico RSS Feed Fetcher Plugin
Summary
by MITRE • 09/24/2026
The WPeMatico RSS Feed Fetcher WordPress plugin before 2.8.26 does not sanitise and escape one of its campaign configuration fields when a certain feature is enabled, which allows users with the Contributor role and above to perform Stored Cross-Site Scripting attacks that execute in the session of any higher-privileged user who later views the campaign.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified in WPeMatico RSS Feed Fetcher versions prior to 2.8.26 represents a significant security flaw within the WordPress ecosystem, specifically targeting the plugin's handling of campaign configuration data. This issue stems from an insufficient sanitization and escaping mechanism applied to specific input fields during the creation or modification of campaigns. When certain features are enabled that utilize these unsanitized inputs for rendering content on the frontend or in administrative interfaces, the application fails to properly validate or encode user-supplied data before it is stored in the database and subsequently outputted back to the browser. This lack of proper input validation creates a direct pathway for malicious actors to inject executable scripts into legitimate web pages viewed by other users.
From a technical perspective, this flaw classifies as an Injection vulnerability under Common Weakness Enumeration standards, specifically CWE-79: Improper Neutralization of Input During Web Page Generation known commonly as Cross-Site Scripting (XSS). The severity is exacerbated because the vulnerability allows for Stored XSS rather than Reflected XSS. In a stored attack scenario, the malicious payload is permanently saved within the target application's database or storage mechanism. Consequently, every time an administrator or user with higher privileges accesses the affected campaign view, the browser executes the injected script in their context. This persistence distinguishes it from transient attacks and increases the potential for widespread compromise if multiple high-privilege users interact with compromised campaigns over time.
The operational impact of this vulnerability is substantial due to its privilege escalation characteristics. Although the initial injection point requires only Contributor-level access or higher, which are roles often granted to content creators rather than full administrators, the execution context occurs within the session of any user who views the campaign. If an administrator, editor, or other high-privileged individual opens a page displaying the compromised campaign data, the malicious script executes with their elevated privileges. This can lead to complete account takeover, allowing attackers to manipulate site settings, create new administrative accounts, exfiltrate sensitive data such as cookies and session tokens, or deface the website. The ability to act within an admin's session effectively bypasses many standard security controls that rely on role-based access restrictions for initial entry points.
This vulnerability aligns with several tactics in the MITRE ATT&CK framework, particularly those related to Initial Access and Persistence through web application attacks. Attackers can leverage this flaw as part of a broader campaign where they first gain low-level access via Contributor roles, often through social engineering or compromised credentials, and then escalate their influence by exploiting stored XSS against higher-privileged users. The attack chain typically involves crafting a malicious payload that exploits the specific rendering behavior of the plugin's feature set, storing it within the campaign configuration, and waiting for an administrative user to trigger its execution by viewing the affected content.
Mitigation strategies must focus on immediate remediation through software updates and enhanced input validation practices. Users running versions of WPeMatico prior to 2.8.26 should upgrade to version 2.8.26 or later, where this specific sanitization issue has been addressed by the developers. For organizations unable to update immediately due to compatibility constraints, implementing a Web Application Firewall (WAF) with rules designed to detect and block XSS payloads in POST requests related to campaign configurations can provide temporary protection. Additionally, enforcing strict Content Security Policy headers that restrict script execution sources can mitigate the impact of any successfully injected scripts by preventing them from executing unless they originate from trusted domains. Regular security audits focusing on input validation across all user-facing forms are also recommended to prevent similar injection flaws in other plugins or custom code within the WordPress environment.