CVE-2026-91199 in Refly
Summary
by MITRE • 09/15/2026
Refly through 1.1.0 contains a server-side request forgery vulnerability in the POST /v1/misc/scrape endpoint that fetches caller-supplied URLs without validating the scheme, host, or resolved address. Authenticated attackers can make the backend issue requests to loopback, private, and link-local addresses including cloud metadata services to read page titles and descriptions of internal resources.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in Refly versions prior to 1.1.0 represents a critical server-side request forgery flaw located within the POST /v1/misc/scrape endpoint. This component is designed to fetch content from user-supplied URLs, likely for purposes such as generating previews or extracting metadata like page titles and descriptions. However, the implementation fails to perform adequate validation on the scheme, host, or resolved IP address of the target URL provided by the caller. In a secure architecture, any endpoint that accepts external input to initiate network requests must rigorously sanitize these inputs to prevent the server from being coerced into making connections to unintended destinations. The absence of such controls allows an attacker to manipulate the request destination entirely at will, turning the application itself into a proxy for internal reconnaissance and data exfiltration.
From a technical perspective, this flaw aligns with CWE-918, which classifies Server-Side Request Forgery (SSRF). The core issue lies in the lack of validation against private IP ranges, loopback addresses, and link-local networks. By supplying URLs that resolve to internal infrastructure, an authenticated attacker can force the Refly server to communicate with services that are typically inaccessible from the public internet. This includes cloud metadata endpoints such as AWS EC2 instance metadata service or Azure managed identity endpoints, which often contain sensitive configuration data, temporary credentials, and other secrets necessary for authenticating further attacks against deeper layers of the infrastructure. The vulnerability is particularly dangerous because it leverages the server's own network privileges and trust relationships to bypass perimeter security controls that would normally block direct external access to these internal resources.
The operational impact of this vulnerability extends beyond simple information disclosure. An authenticated attacker can use this SSRF vector to map out the internal network topology by probing various ports and services on private IP addresses. More critically, they can extract sensitive data from cloud metadata services, potentially gaining unauthorized access to other systems within the same environment. This capability effectively neutralizes network segmentation strategies that rely on restricting external access while trusting internal traffic. The attacker does not need direct network connectivity to these targets; instead, they exploit the application server's position as a trusted entity within the local network or cloud VPC. This can lead to full compromise of backend systems if combined with other vulnerabilities such as credential reuse or weak authentication mechanisms on those internal services.
This attack pattern is consistent with MITRE ATT&CK technique T1598, specifically Stealing Cloud Credentials via SSRF, and falls under the broader category of Server-Side Request Forgery (T1105). The exploitation requires authentication, which limits the scope to users who have valid credentials within the Refly application. However, given that many enterprise applications allow low-privilege accounts or even public registrations in certain configurations, this barrier may be easily surmounted. Once authenticated, the attacker can systematically enumerate internal resources and extract sensitive metadata without triggering typical intrusion detection systems that monitor for external-to-internal traffic patterns originating directly from outside the network perimeter.
To mitigate this vulnerability, immediate patching to version 1.1.0 or later is required as it addresses these validation gaps. For environments where upgrading is not immediately feasible, defensive measures should include implementing a strict allowlist of permitted URL schemes and hosts for the scrape endpoint. Additionally, deploying an egress firewall rule that blocks outbound connections from the application server to private IP ranges such as 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and link-local addresses like 169.254.169.254 can provide a layer of defense in depth. It is also advisable to implement DNS rebinding protections by resolving hostnames at request time rather than connection time or validating the resolved IP address against known private ranges before initiating the HTTP transaction. Regular security audits and code reviews focusing on network interaction functions are essential to prevent similar SSRF implementations in other parts of the application stack.