Description

The WPeMatico RSS Feed Fetcher WordPress plugin before 2.8.27 does not perform a capability check or validate the destination of a user-supplied feed URL before fetching it server-side, allowing users with contributor-level access and above to make the server issue requests to internal-only resources and read the responses back.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.1",
  "pubDate": "2026-09-27T06:17:19.283Z",
  "pubdate": "2026-09-27T06:17:19.283Z",
  "executiveSummary": "The WPeMatico RSS Feed Fetcher plugin for WordPress, in versions prior to 2.8.27, is susceptible to a Server-Side Request Forgery (SSRF) vulnerability. This flaw arises from the plugin's failure to implement proper authorization checks and input validation when processing user-supplied feed URLs.\nBy design, the plugin allows users authenticated with at least contributor-level privileges to initiate server-side HTTP requests. Due to the lack of destination validation, an attacker can manipulate the plugin to fetch content from unauthorized internal network resources or local loopback addresses. This bypasses typical network perimeter defenses, effectively turning the web server into a proxy for internal network reconnaissance and data exfiltration.\nSuccessful exploitation permits an attacker to interact with internal services that are otherwise inaccessible from the public internet, potentially leading to the disclosure of sensitive internal configurations, local system information, or unauthorized interactions with internal APIs and cloud metadata services. The risk is considered high due to the potential for lateral movement and information gathering within a secured network environment.",
  "technicalDetails": "The vulnerability is rooted in the absence of server-side validation and capability checks within the WPeMatico RSS Feed Fetcher’s feed processing logic. When a user submits a URL to be parsed as an RSS feed, the application fails to verify the user's authority to initiate outbound requests or the legitimacy of the target destination.\nThe attack flow initiates when an authenticated user, holding at least contributor-level privileges, invokes the plugin's feed fetching functionality. The attacker injects a malicious, non-public URL—such as an internal IP address (e.g., 127.0.0.1, 10.0.0.x, or 169.254.169.254)—into the input parameter designed for standard RSS feed acquisition. Because the application logic does not perform allowlisting or validation on the destination URI, the server-side component proceeds to execute a request to the provided target.\nUpon processing, the plugin performs an HTTP GET request to the attacker-supplied URL from the server hosting the WordPress instance. If the target resource is reachable, the server processes the response and renders it back to the attacker, or inadvertently exposes it through the plugin's administrative or front-end interfaces. This behavior enables a 'blind' or 'non-blind' SSRF attack vector.\nIn a non-blind scenario, the application returns the contents of the response, providing the attacker with immediate access to internal data. In a blind scenario, the attacker can use the server as a pivot point to perform port scanning, identify internal network topology, or exploit internal services that trust requests originating from the web server's environment. The vulnerability effectively nullifies the protection provided by firewalls or network access control lists (ACLs) by using the server as a trusted proxy to reach resources within the application's internal network segment."
}