CVE-2026-111720 in fish-island-backend
Summary
by MITRE • 10/16/2026
fish-island-backend through commit 7c61b78 contains an unauthenticated server-side request forgery vulnerability that allows remote attackers to make the server fetch attacker-supplied URLs via the url parameter of GET /api/web/parse. Attackers can target internal hosts, loopback services or cloud metadata endpoints through redirect-following OkHttp requests and read back page titles, meta descriptions and favicons.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in fish-island-backend prior to commit 7c61b78 represents a critical server-side request forgery flaw that stems from the improper validation of user-supplied input within an API endpoint. Specifically, the GET /api/web/parse route accepts a url parameter which is directly passed to an HTTP client library without sufficient sanitization or allow-listing mechanisms. This architectural oversight allows remote attackers to manipulate the destination address for outbound network requests initiated by the server itself. Unlike cross-site request forgery which targets user sessions, this vulnerability leverages the server's own identity and network privileges to perform actions on behalf of the application, effectively turning the backend service into a proxy for malicious reconnaissance or data exfiltration activities.
The technical mechanism relies on the behavior of the OkHttp library used by the application. When an attacker supplies a URL pointing to internal infrastructure, loopback services such as those running on 127.0.0.1, or cloud metadata endpoints like AWS EC2 instance metadata service at 169.254.169.254, the server processes these requests and follows redirects automatically. This redirect-following capability is particularly dangerous because it allows attackers to bypass simple IP-based filters that might block direct access to internal ranges but fail to detect indirect access via HTTP redirections. By crafting payloads that trigger multiple hops or utilize DNS rebinding techniques, an attacker can successfully route the server's outbound traffic toward sensitive internal resources that are otherwise inaccessible from the public internet.
The operational impact of this vulnerability is significant due to the specific data extraction capabilities enabled by the parse functionality. The application does not merely fetch raw content; it processes the response to extract structural elements such as page titles, meta descriptions, and favicons. This parsing behavior provides a reliable side-channel for attackers to confirm successful access to internal services. For instance, accessing an administrative dashboard on localhost will return its title or favicon, confirming both reachability and potentially revealing information about the underlying technology stack. Similarly, querying cloud metadata endpoints can yield sensitive configuration data, temporary credentials, or IAM role information if the server is running in a compromised cloud environment with overly permissive roles. This transforms the vulnerability from a simple network probe into a potent tool for lateral movement and privilege escalation within internal networks.
From a classification perspective, this flaw aligns closely with CWE-918 Server-Side Request Forgery (SSRF), specifically involving the lack of validation on user-controlled URLs that dictate outbound connections. It also relates to CWE-20 Improper Input Validation where the application fails to restrict the scheme, host, or port of the provided URL parameter. In terms of attack tactics, this behavior maps to MITRE ATT&CK technique T1571 Non-Standard Port and potentially T1098.004 SSH Authorized Keys Modification if used in conjunction with other exploits, but primarily it serves as a reconnaissance vector under T1590 Gather Victim Host Information or T1602 Indirect Command Execution depending on the ultimate goal of the attacker. The ability to read back specific metadata elements makes this an active exploitation scenario rather than just a denial-of-service risk.
Mitigation strategies must focus on implementing strict input validation and network-level controls at multiple layers. First, developers should enforce a whitelist approach for any URLs processed by backend services, allowing only known safe domains or IP ranges if external fetching is strictly required. If the application does not need to fetch arbitrary web content, this functionality should be removed entirely. Second, network segmentation policies must be applied to restrict outbound traffic from the server instance, blocking access to private IP ranges such as 10.x.x.x, 172.16.x.x through 172.31.x.x, and 192.168.x.x, as well as cloud metadata IPs like 169.254.169.254. Additionally, configuring the HTTP client to disable automatic redirect following can prevent attackers from bypassing simple IP filters through redirection chains. Finally, implementing egress filtering at the firewall or security group level ensures that even if application-level controls fail, the underlying infrastructure prevents unauthorized outbound connections to sensitive internal resources.