The vulnerability identified as CVE-2025-3775 is a Server-Side Request Forgery (SSRF) flaw present in the ShopLentor – WooCommerce Builder for Elementor & Gutenberg plugin, formerly known as WooLentor, which is widely used to build WooCommerce stores on WordPress. The issue exists in the woolentor_template_proxy function, which improperly handles user-supplied input to make HTTP requests from the server. Because the plugin does not authenticate or restrict these requests, an unauthenticated attacker can leverage this function to send arbitrary HTTP requests originating from the web server hosting the WordPress site. This can be exploited to access internal network resources that are not otherwise exposed externally, such as internal APIs, metadata services, or other sensitive endpoints. The attacker may also modify information on internal services if those services accept such requests. The vulnerability affects all versions up to and including 3.1.2. The CVSS v3.1 base score is 6.5, reflecting a medium severity with network attack vector, low attack complexity, no privileges required, and no user interaction needed. The impact includes limited confidentiality and integrity loss but no direct availability impact. No patches were listed at the time of reporting, and no known exploits have been observed in the wild. The vulnerability was reserved and published in April 2025, with enrichment from CISA indicating its recognized importance. Given the plugin's integration with popular page builders Elementor and Gutenberg, and its role in WooCommerce storefronts, the vulnerability poses a notable risk to e-commerce websites relying on this plugin for their online sales infrastructure.

The SSRF vulnerability allows attackers to abuse the web server as a proxy to access internal systems that are typically inaccessible from the internet. This can lead to unauthorized disclosure of sensitive information such as internal APIs, cloud metadata services (e.g., AWS, Azure, GCP), or backend databases. Attackers might also manipulate internal services if they accept HTTP requests, potentially altering data or configurations. For e-commerce sites, this could result in exposure of customer data, payment information, or business-critical internal services. While the vulnerability does not directly impact availability, the confidentiality and integrity risks can facilitate further attacks, including privilege escalation or lateral movement within the victim's network. Organizations worldwide using this plugin in their WordPress WooCommerce setups face increased risk of data breaches and operational disruption if exploited. The lack of authentication and user interaction requirements makes exploitation easier and more likely, especially if attackers scan for vulnerable sites. The absence of known exploits in the wild currently reduces immediate risk but does not eliminate the threat, especially once exploit code becomes publicly available.

1. Immediately monitor and restrict outbound HTTP requests from the WordPress server, especially those initiated by the ShopLentor plugin or related processes, using firewall rules or web application firewalls (WAFs). 2. Implement strict allowlists for outbound connections to prevent unauthorized internal or external requests. 3. Disable or restrict the woolentor_template_proxy function if possible, or apply custom code to validate and sanitize all inputs used in proxy requests. 4. Regularly audit web server logs for unusual or unexpected outbound requests that may indicate exploitation attempts. 5. Keep the ShopLentor plugin updated and apply security patches promptly once released by the vendor. 6. Employ network segmentation to limit the WordPress server’s access to sensitive internal services, reducing the impact of SSRF exploitation. 7. Use security plugins or tools that detect SSRF patterns and block suspicious traffic. 8. Educate site administrators about the risks and signs of SSRF exploitation to enable faster incident response. 9. Consider deploying runtime application self-protection (RASP) solutions that can detect and block SSRF attacks in real time. 10. If patching is delayed, consider temporarily disabling the vulnerable plugin or replacing it with alternative solutions until a secure version is available.