Bookmark and research tools often fetch URLs on behalf of users. That feature creates an outbound network path from the application server, and the fetcher may render pages with a browser. Access control is therefore linked to network placement: a user who can submit a URL can sometimes make the server reach a destination that the user cannot reach directly.
The external count
On 2026-11-06 08:47:08 +08:00, ZoomEye count-only queries used sub_type=all, page 1, and pagesize 1. app="Karakeep" returned 0, title="Karakeep" returned 1,183, and http.body="Karakeep" returned 6,101. The body query may include articles or directories that mention the product, so it is not a deployment total. The title count gives a candidate set for owner attribution.
The crawler trust warning
Karakeep's security guidance warns that access for untrusted users changes the risk of its crawler. It lists requests to sites the operator does not want contacted from the service's IPs, exposure of the origin IP through user-controlled sites, and access to internal endpoints from the server network. The guide recommends limiting access to trusted users, using a restricted VPN, moving the browser outside the network, or using a hosted browser service.
Karakeep says it has basic SSRF protections, but the same paragraph states that those checks mitigate only some risks. That is an important boundary. A URL validation routine can block obvious loopback or metadata addresses and still miss a redirect, alternate IP notation, DNS behavior, or protocol handler. The operating environment must assume that the crawler will make outbound requests.
Design the egress boundary
Place the crawler on a dedicated network segment. Allow outbound HTTP and HTTPS only through a controlled proxy if the product supports it. Block link-local metadata, internal management networks, database ranges, and the organization's sensitive service endpoints. Log destination host, resolved address, response class, and the user who submitted the bookmark without storing sensitive page content unnecessarily.
Review who can invite users or create accounts. If the instance is intended for one team, close self-registration and remove dormant accounts. Confirm that public bookmark sharing does not expose private lists, archives, screenshots, or PDFs. Separate stored research data from the browser runtime where practical, because a browser compromise is more valuable than a failed crawl.
Test containment
Use a lab instance and a controlled internal target. Try direct private addresses, redirects to private addresses, alternate encodings, and DNS names that resolve internally. Test the allowed public path at the same time. The goal is to verify the network policy, not to discover whether a single URL parser has every possible bypass.
For incident response, treat the browser process and the application as separate evidence sources. Preserve crawl jobs, outbound proxy logs, DNS logs, and browser artifacts. Then evict sessions, rotate credentials reachable from the runtime, and rebuild the browser container.
The external measurement shows where to look. The internal topology determines how far a crawl can travel.