CVE-2026-95265 in Feehi
Summary
by MITRE • 10/06/2026
Feehi CMS 2.1.1 contains a Server-Side Request Forgery (SSRF) vulnerability in the UEditor catchimage endpoint. The private-IP validation does not block loopback or link-local addresses, allowing an attacker to make the server probe internal HTTP services through response differences.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/06/2026
The identified security flaw resides within Feehi CMS version 2.1.1, specifically targeting the UEditor catchimage endpoint which is responsible for fetching external images and processing them for content insertion. This component suffers from a Server-Side Request Forgery vulnerability due to insufficient validation of target URLs provided by the client. While the application attempts to mitigate SSRF risks by filtering out private IP address ranges, this implementation is flawed because it fails to account for loopback addresses such as 127.0.0.1 and link-local addresses like those in the 169.254.x.x range. This oversight allows an attacker to bypass the intended restrictions and force the server to initiate HTTP requests to internal services that are not exposed to the public internet but remain accessible via these specific address types.
From a technical perspective, the vulnerability stems from incomplete input sanitization logic within the image fetching module. When a user supplies a URL for an external resource, the backend script checks if the resolved IP falls into blocked private ranges. However, because loopback and link-local addresses are often treated as distinct categories or overlooked in standard private IP regex patterns, they slip through the validation filter. Once validated, the server proceeds to make an outbound request on behalf of the user. The attacker can then leverage response differences, such as variations in HTTP status codes, content length, or error messages, to infer information about internal services. This technique is particularly dangerous because it transforms a simple image upload feature into a powerful reconnaissance tool for mapping internal network topology and identifying vulnerable backend applications that may be running on non-standard ports or hidden behind firewalls.
The operational impact of this vulnerability extends beyond mere data exfiltration from the local machine. By probing internal services, an attacker can identify other web servers, database management interfaces, API endpoints, or cloud metadata services such as AWS EC2 instance metadata service which is often accessible via link-local addresses like 169.254.169.254. If these internal services have weak authentication or known vulnerabilities, the SSRF can serve as a pivot point for further exploitation. This could lead to unauthorized access to sensitive data stored in internal databases, manipulation of configuration files on backend servers, or even remote code execution if specific service endpoints are vulnerable to injection attacks triggered by the forged requests. The ability to bypass network segmentation effectively neutralizes perimeter defenses that rely on restricting external access to internal assets.
This vulnerability aligns with CWE-918 which classifies Server-Side Request Forgery as a critical weakness in web application security, specifically highlighting flaws where server-side code makes requests based on user-supplied data without proper validation of the destination. In terms of offensive tactics, this behavior corresponds to ATT&CK technique T1557.002 known as Adversary-in-the-Middle or more accurately in this context, it facilitates lateral movement and discovery through SSRF-based network probing which falls under the broader category of resource hijacking for internal reconnaissance. The lack of strict allow-listing for outbound connections is a common anti-pattern that exposes organizations to significant risk during initial compromise phases.
To mitigate this vulnerability, developers must implement a robust validation strategy that explicitly blocks not only private IP ranges but also loopback and link-local address spaces. It is recommended to use an allow-list approach where only specific trusted domains or IP addresses are permitted for external requests rather than relying on block lists which can always be bypassed through edge cases like the one observed here. Additionally, implementing network-level controls such as egress filtering at the firewall level can prevent the application server from initiating connections to internal subnets regardless of the URL provided by the client. Enforcing strict HTTP method restrictions and validating response content types can further reduce the attack surface by limiting the information an attacker can gather through differential analysis. Regular security audits focusing on input validation logic in file handling components are essential to prevent similar oversights in future updates or custom integrations involving third-party libraries like UEditor.