MindsDB: unauthenticated SSRF via the web crawler (default-open allowlist, no private-IP filter)

[geo-chen]

Short description of current behavior

reported via email on 13 June 2026 - no response.
may I share details here please?

Video or screenshots

No response

Expected behavior

No response

How to reproduce the error

No response

Anything else?

No response

[geo-chen]

Affected Versions: confirmed on v26.1.0 (commit 86be14b)

CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (7.5 nominal; effective ~5.0-6.0 Medium given prerequisites)

CWE: CWE-918 Server-Side Request Forgery (insecure default)

Summary

The MindsDB web crawler handler fetches caller-supplied URLs and returns the page text, with the only SSRF control being a web_crawling_allowed_sites allowlist that defaults to empty (open) and no private-IP/loopback filtering at all. The crawler is reachable over the unauthenticated HTTP API (default http_auth_enabled=False, binds 0.0.0.0 in Docker). An unauthenticated attacker can make the server fetch internal-only services and cloud-metadata endpoints and read the response body. Confirmed against the shipped CrawlerTable.list(): an internal-only secret was fetched and returned. Honest prerequisites: the [web] extra is not in the default Docker image, and the allowlist exists as the documented SSRF control; this is an insecure-default, not a guard bypass.

Details

Sink: mindsdb/integrations/handlers/web_handler/web_handler.py:50-65 (CrawlerTable.list):

allowed_urls = config.get("web_crawling_allowed_sites", [])   # DEFAULT = []
if allowed_urls and not validate_urls(urls, allowed_urls):     # falsy when [] -> guard skipped
    raise ValueError(...)
...
result = get_all_websites(urls, ...)                           # fetches ANY url, returns body

Source/flow: attacker-supplied url from SELECT * FROM <web_engine>.crawler WHERE url='...' over the unauthenticated /api/sql/query endpoint (the same crawler is also reached via the KB endpoint insert_web_pages -> kb_data["urls"]). The fetched text_content is returned to the caller (full readback). urlcrawl_helpers.get_all_websites does no loopback/link-local/private-IP filtering. Default config: auth.http_auth_enabled=False (config.py:197); the HTTP API binds 0.0.0.0 in Docker (config.py:177); web_crawling_allowed_sites defaults to []; is_cloud=False. Unlike the file-upload path, the web crawler has no is_private_url check at all (not even the cloud-gated one).

The boundary crossed is an unauthenticated network attacker reaching internal services / cloud metadata. Honest caveats: (1) docker/docker-bake.hcl ships [agents,kb,mysql,...] but not [web], so the crawler is not installed out-of-box (document_loader.py:74-78 errors "Web crawling requires ... pip install mindsdb[web]"); the SSRF fires once an operator installs the common, documented web extra. (2) web_crawling_allowed_sites is the documented SSRF mitigation; the defect is that it defaults open and the crawler adds no private-IP filtering. This is net-new (distinct from the patched CVE-2023-49795 file upload, CVE-2024-24759 is_private_url rebinding, CVE-2026-27483 path traversal), landing as an insecure default.

PoC

POST /api/sql/query   (no auth)
{ "query": "SELECT * FROM web_engine.crawler WHERE url = 'http://169.254.169.254/latest/meta-data/...'" }
-> response includes the fetched internal body in text_content

Validated by installing mindsdb (editable) + web deps into a venv and calling the unmodified shipped CrawlerTable.list() with the exact FilterCondition(column="url", op=EQUAL, value=...) the SQL layer produces, pointed at a local HTTP server impersonating an internal metadata service (git diff confirmed web_handler.py/security.py/config.py byte-for-byte unchanged):

config web_crawling_allowed_sites default = []
config is_cloud = False
Attacker-supplied url: http://127.0.0.1:47999/latest/meta-data/iam/security-credentials/
Returned text_content: 'iam-role-creds: INTERNAL-ONLY-SECRET-TOKEN-169254-METADATA-ab12cd34'
SSRF CONFIRMED: internal-only secret fetched and returned to caller.

Impact

On a default-auth-disabled MindsDB with the web extra installed (a common, documented configuration), an unauthenticated network client makes the server fetch internal-only services and cloud instance-metadata endpoints and reads the response, enabling internal reconnaissance and cloud-credential theft. Severity is gated by the [web]-extra prerequisite and the documented-allowlist mitigation, hence the effective Medium rating.

Remediation

In CrawlerTable.list (and get_all_websites), reject URLs resolving to loopback/link-local/private/reserved ranges unconditionally (independent of web_crawling_allowed_sites), resolve-then-pin the IP to defeat DNS rebinding, and ship a non-empty safe default or fail closed when no allowlist is configured.

[akshatmalik-bruh]

hey i would like to work on this issue !