CVE-2026-77066 in Omnivore
Summary
by MITRE • 08/20/2026
The scanFeedsResolver in packages/api/src/resolvers/subscriptions/index.ts passes the caller-supplied url straight to axios.get(url, rssParserConfig()) with no address validation. The same file guards the subscribe path with validateUrl(), which rejects private and reserved ranges through the private-ip library, and createPageSaveRequest applies the same check, so the omission is specific to this resolver. An authenticated user can direct the server to request arbitrary internal endpoints. The response is parsed as a feed or as HTML and the resolver returns the resulting url, title, description and type fields, so disclosure is limited to feed-shaped metadata and to link elements advertising RSS or Atom feeds; requests that do not parse still distinguish reachable ports from unreachable ones through the resulting error.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in the scanFeedsResolver function within packages/api/src/resolvers/subscriptions/index.ts represents a classic Server-Side Request Forgery (SSRF) flaw rooted in insufficient input validation on network destinations. The core technical defect lies in the direct pass-through of user-supplied URL parameters to an HTTP client, specifically axios.get(), without any prior sanitization or address verification logic. This stands in stark contrast to other endpoints within the same codebase, such as the subscribe path and createPageSaveRequest, which correctly implement a validateUrl function leveraging the private-ip library to reject requests targeting private IP ranges and reserved addresses. The inconsistency indicates that this specific resolver was overlooked during security hardening efforts, leaving it exposed to exploitation by authenticated users who can manipulate the target destination of server-initiated network connections.
From an operational perspective, this flaw allows an attacker to force the application server to make HTTP requests to arbitrary internal endpoints that are typically inaccessible from external networks. By crafting specific URLs pointing to localhost or private IP addresses associated with internal services such as database management interfaces, cloud metadata services, or internal microservices, an authenticated user can probe the network topology and access sensitive data residing behind firewalls or security groups. The impact is twofold: first, it enables information disclosure through the parsing of feed structures; second, it facilitates port scanning and service fingerprinting based on error responses when requests fail to parse as valid feeds. This dual nature transforms a simple SSRF into a powerful reconnaissance tool for mapping internal infrastructure.
The exploitation mechanism relies on the application's behavior in handling both successful and failed requests. When a request succeeds and returns data that can be parsed, the resolver extracts and exposes metadata fields including url, title, description, and type. This means that any publicly readable content from an internal service formatted as RSS or Atom feeds becomes accessible to the attacker. Even when the response cannot be parsed into these specific structures, the application distinguishes between reachable and unreachable ports through distinct error messages or timeout behaviors. This side-channel allows attackers to perform blind SSRF attacks where they can infer the existence of services on specific ports based on whether a connection is established or refused, effectively turning the server into an open proxy for internal network scanning.
This vulnerability aligns with CWE-918, which describes Server-Side Request Forgery (SSRF) flaws involving weak input validation against URL schemes and hostnames. It also maps to MITRE ATT&CK technique T1046, Network Service Discovery, as the attacker uses the vulnerable application to discover services running on internal networks. The lack of strict allow-listing for destination hosts is a critical deviation from secure coding practices recommended by OWASP in their SSRF prevention guidelines. To mitigate this risk, developers must implement robust server-side validation that restricts outgoing requests to a predefined list of allowed domains and explicitly blocks private IP ranges, loopback addresses, link-local scopes, and cloud metadata endpoints. Additionally, implementing network-level controls such as egress filtering on the application host can provide defense-in-depth by preventing outbound connections to internal subnets regardless of application-layer validation failures.