# Crawl Plugin SSRF - Intranet Target In URL Parameter

- **Severity:** High
- **Signature ID:** `7c1f4b6a-3d2e-4a58-9b0c-5e8f2a94d17b`

## Summary

Some AI agent plugins let users supply a URL for the agent to fetch or crawl, then retrieve it without checking whether that URL points inside the organization's own network. An attacker can abuse this to make the server reach internal services, cloud metadata endpoints, or other systems it should never touch, using the trusted server as a proxy.

## How the attack works

A plugin (documented here as matching the FastGPT web-crawling plugin) accepts a request with a URL-shaped parameter such as url, target_url, fetch_url, callback, or redirect_uri. The attacker sets that parameter to an internal address instead of a public one: a loopback address, an RFC1918 intranet IP, a link-local or CGNAT address, or a cloud metadata service address. The plugin fetches that address on the attacker's behalf, without verifying it is external. This lets the attacker probe or pull data from internal-only services the attacker could not otherwise reach directly.

## Why it matters

An attacker can use the AI agent's server as a stepping stone into internal infrastructure, potentially reaching admin panels, cloud credentials via metadata endpoints, or other internal-only systems, leading to information disclosure or further compromise.

## What you can do

- Validate and restrict any URL-fetching plugin so it rejects loopback, RFC1918, link-local, CGNAT, cloud-metadata, and in-cluster (.svc.cluster.local) destinations by default.
- If internal fetches are a legitimate use case (e.g. crawling an internal wiki), maintain an explicit allowlist of approved internal hosts rather than allowing arbitrary user-supplied targets.
- Block outbound requests from agent/plugin infrastructure to the cloud metadata address and other sensitive internal endpoints at the network layer, independent of the plugin's own logic.
- Review logs for fetch/crawl requests where the URL parameter resolves to an internal address, and separately track expected exceptions like known dev/CI or internal-docs use to reduce noise.

## Known benign look-alikes

- Agent legitimately asked to crawl or summarise an internal wiki, Confluence, Jira or documentation site that is hosted on an RFC1918 address and passed as a url= parameter.
- Local development and CI - a developer exercising the crawl/fetch tool against a service running on 127.0.0.1 or 0.0.0.0 with an explicit port.
- Kubernetes-hosted agents fetching an in-cluster API via a *.svc.cluster.local URL passed to a generic fetch tool.
- Tailscale / CGNAT estates where 100.64.0.0/10 addresses are the normal way to reach internal services.
- Authorised SSRF regression suites and scanner payload corpora replayed through the agent (partly suppressed by filter_vuln_docs).
- Configuration or seed data blobs that embed example private-range URLs (suppressed by filter_cidr_doc and filter_template_placeholder).

## References

- https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/
- https://cwe.mitre.org/data/definitions/918.html

---
Source: https://www.netzilo.com/threats/crawl-plugin-ssrf-intranet-target