Description

Glean is a self-hosted RSS reader and personal knowledge management tool. Prior to 0.2.6, POST /api/feeds/discover passes an attacker-supplied feed_url to discover_feed(feed_url), creates a subscription through FeedService.create_subscription(), and enqueues fetch_feed_task. The background path calls fetch_feed(feed.url) and parse_feed(), which assigns each RSS item link to ParsedEntry.url. The task then passes ParsedEntry.url to fetch_and_extract_fulltext(parsed_entry.url) without network-level validation in backend/packages/rss/glean_rss/extractor.py and backend/apps/worker/glean_worker/tasks/feed_fetcher.py. A malicious feed can therefore make the server request private, loopback, link-local, or cloud-metadata resources. The fetched response is stored in Entry.content and can be retrieved through GET /api/entries/{id}, producing non-blind server-side request forgery with full response disclosure. This can bypass network perimeters, probe internal services and ports, expose internal configuration or web content, and potentially disclose cloud metadata access tokens. This issue is fixed in version 0.2.6.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.7",
  "pubDate": "2026-09-17T21:17:15.123Z",
  "pubdate": "2026-09-17T21:17:15.123Z",
  "executiveSummary": "Glean versions prior to 0.2.6 are susceptible to a Server-Side Request Forgery (SSRF) vulnerability due to insufficient input validation during the RSS feed discovery process.\nThe vulnerability allows unauthenticated or authenticated attackers to force the Glean server to perform arbitrary HTTP requests to internal, loopback, or cloud-metadata endpoints.\nBy manipulating the 'feed_url' provided to the POST /api/feeds/discover endpoint, an attacker can cause the background worker to fetch sensitive internal data, which is subsequently stored in the application database.\nThis data can then be retrieved by the attacker via GET /api/entries/{id}, resulting in full response disclosure.\nThe impact is significant, potentially leading to unauthorized access to internal services, cloud environment metadata, and sensitive configuration information protected by network perimeters.\nExploitation does not require prior knowledge of the target's internal topology, as the server acts as an open proxy for the attacker's requests.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper handling of user-supplied URLs within the Glean RSS ingestion pipeline. When a user provides a 'feed_url' to the POST /api/feeds/discover endpoint, the application triggers a sequence of operations involving 'FeedService.create_subscription()' and the asynchronous 'fetch_feed_task'.\nWithin 'backend/apps/worker/glean_worker/tasks/feed_fetcher.py', the worker performs a 'fetch_feed()' call and subsequently parses the returned XML content using 'parse_feed()'. This function extracts 'link' attributes from RSS items and assigns them to 'ParsedEntry.url' objects. The critical failure occurs when the worker passes these extracted URLs directly to 'fetch_and_extract_fulltext()' in 'backend/packages/rss/glean_rss/extractor.py' without performing any network-level validation or denylisting of prohibited IP ranges.\nThe attack flow proceeds as follows: First, an attacker submits a malicious RSS feed URL to the Glean API. This feed contains specially crafted item links pointing to internal targets such as 'http://127.0.0.1:80', 'http://169.254.169.254/latest/meta-data/', or other RFC1918 addresses. Second, the Glean worker processes the feed, parses the malicious entries, and executes a request to the provided target URL.\nBecause the server follows the provided URLs without validating their destination, it treats the server's own network interface as the source of the request. The 'fetch_and_extract_fulltext' function retrieves the response from these internal endpoints—which may include sensitive configuration files, management interface pages, or cloud provider identity tokens—and stores the result in the 'Entry.content' database field. Finally, the attacker queries the GET /api/entries/{id} endpoint to retrieve the stored content, completing the full-read cycle of the SSRF.\nThis vulnerability effectively bypasses network segmentation, enabling an attacker to probe internal ports and bypass authentication mechanisms that rely on IP-based trust. The ability to exfiltrate cloud metadata tokens is particularly high-risk in cloud-hosted deployments, potentially allowing for privilege escalation within the broader cloud infrastructure environment."
}