Summary
go-shiori's bookmark-fetching functionality accepts caller-supplied URLs and makes outbound requests without validating the resolved destination IP address. An authenticated user may use loopback, unspecified, or other internal destinations to access services, cloud metadata endpoints, or network-restricted resources reachable from the server.
Affected context
The vulnerability occurs in deployments where go-shiori processes bookmark URLs through DownloadBookmark() using a standard HTTP client without destination-IP validation. It may affect bookmark creation or update flows that allow an authenticated user to submit or modify a URL, including API routes such as /api/bookmark, /api/v1/bookmarks/cache, and /api/bookmarks/ext. Risk depends on the network access available to the go-shiori server and the protections applied to internal services and metadata endpoints.
Exploit preconditions
- Attack surface: Bookmark URL submission and update API endpoints
- Required access: Authenticated access sufficient to create or modify bookmarks
- Trigger point: Server-side fetching of the supplied bookmark URL
- Why exploitation is possible: The HTTP client does not apply custom dialing or validate whether the resolved destination is loopback, private, unspecified, or link-local
- Environmental dependency: The target internal resource must be reachable from the go-shiori server
Why this happens
The underlying bug is server-side request forgery caused by treating a user-controlled URL as a trusted outbound destination. The request path lacks network-aware controls that validate resolved addresses and prevent connections to loopback, private, unspecified, or link-local ranges. This maps to CWE-918: Server-Side Request Forgery, where an application can be induced to send requests to unintended resources from a privileged network position.
Potential impact
- Internal services may receive unauthorized requests from the go-shiori server
- Cloud instance metadata or other sensitive endpoint data could be disclosed
- Network-restricted administrative interfaces may be probed or accessed
- Requests could be used to trigger actions on trusted internal services
- Credentials, tokens, or configuration data may be exposed
General mitigation guidance
Mitigation generally focuses on reducing trust in user-controlled URLs and enforcing destination-aware outbound request policies.
Common defensive patterns include:
- Allowing only explicitly approved URL schemes, hosts, and ports where the use case permits
- Resolving hostnames and rejecting loopback, private, unspecified, link-local, and other restricted address ranges
- Rechecking the destination after redirects and preventing DNS rebinding
- Applying outbound network egress controls and isolated fetcher permissions
- Blocking access to cloud metadata services through platform and network policy
- Using short timeouts, response-size limits, and narrowly scoped credentials for outbound requests
- Separating URL fetching from sensitive application networks where practical
These controls reduce exposure even when an authenticated user can submit arbitrary bookmark URLs.
How teams detect issues like this
Detection approaches commonly include:
- Static analysis rules identifying HTTP clients that consume user-controlled URLs without destination validation
- Code review checks for missing loopback, private-range, link-local, and redirect handling
- Tests covering alternate IP representations, DNS resolution changes, redirects, and IPv4/IPv6 address classes
- Egress firewall or proxy policies that alert on application requests to internal ranges and metadata endpoints
- Runtime monitoring for unusual outbound requests from bookmark-processing components
- API audit logging that correlates authenticated users with submitted URLs and resulting destinations
Automated security review tools may help identify user-controlled URL flows, but network-level controls should provide an independent layer of protection.
