research

Detection Guidance: Auditing Your Homelab for Exposed MCP Servers

Hands-on checklist for homelab operators: detect, fingerprint, and harden exposed MCP endpoints running on Ollama, Claude Code agents, or custom self-hosted AI services. Based on Trend Micro research documenting ~1,500 unauthenticated servers in 2026.

Glenn Fryklund

Glenn Fryklund

— 7 min read
Share

The Problem

The Model Context Protocol (MCP) was designed for capability, not security. When self-hosted agents expose endpoints on your network, they can be discovered and abused. Censys telemetry identified more than 21,000 publicly accessible MCP endpoints as of May 2026 (up from 12,520 services on April 28, 2026). Trend Micro's April 2026 follow-up scan counted 1,467 exposed servers with no client authentication or traffic encryption, nearly triple its July 2025 count of 492. This guidance is a hands-on checklist for homelab operators running Ollama, custom MCP servers, or agent orchestration frameworks locally.

1. Auditing Your Own Network for Exposed MCP Endpoints

Start by mapping which services are listening on which ports, then cross-reference against known MCP implementations.

List local listeners:

ss -tlnp | grep -E ':(11434|8080|8765|3000)'
nmap -sT -p 1-65535 localhost

MCP servers can bind to any port. Check ollama serve, Docker Compose ports mappings, systemd service files for OLLAMA_HOST environment variables, and reverse proxy configs (Caddy, Traefik).

Check external exposure:

nmap -sT <your-public-ip> --top-ports 1000

If port 11434 is reachable publicly, you have a critical exposure. Every open MCP endpoint without authentication is effectively a credential-free entry point; attackers can query your agents and execute tool calls with full system access.

Audit Docker containers:

docker ps --format "table {{.Names}}\t{{.Ports}}" | grep -iE 'ollama|mcp|agent'

Many Docker Compose files default to binding all interfaces (0.0.0.0) when no interface is specified, making services network-wide without explicit intent.

2. Port Scanning and Service Fingerprinting for MCP Targets

Once you know which ports are open, fingerprint what's running on them.

Identify Ollama instances:

curl -s http://<host>:11434/api/tags | jq '.models[].name'

A model list confirms an active instance, and arbitrary model execution without authentication (CVE-2025-15063, CVSS 9.8).

Identify Anthropic/Claude agent endpoints:

# Check for local Claude agent deployments (common ports)
for port in 11434 3001 8765; do curl -s "http://localhost:${port}/v1/models"; done
# Search config files for Anthropic API keys
grep -r "sk-ant-" /etc/ollama/.env ~/.config/claude-code/ 2>/dev/null

Identify custom MCP servers (LangChain, LiteLLM):

nmap -sV --script=http-headers <host> -p 11434,8080,8765,3000
curl -N http://<host>:8765/sse   # SSE endpoint check

If the server returns event: message or event: text, you've found an active MCP Server-to-Client (S2C) SSE endpoint.

Check for credential leakage:

find /etc/ollama ~/.config -name "*.env" -o -name "config.json" | xargs grep -lE "(API_KEY|SECRET)" 2>/dev/null
docker exec <container> cat /.env 2>/dev/null

48% of scanned MCP configurations store secrets in plaintext (Trend Micro, August 2025; re-cited in the April 2026 follow-up). If you find API keys exposed, your network is only as secure as your local machine, which is dangerous if it also serves web traffic or runs developer tools that enable lateral movement.

2026 MCP Vulnerabilities

Seven 2026 CVEs (plus one 2025 client-side RCE) landed in MCP servers and proxies this cycle. All are unauthenticated remote code execution unless stated otherwise. Patch first, then audit for prior exploitation.

WeKnora CVE-2026-30861 (CVSS 9.8, published Mar 2026)

Unauthenticated RCE via MCP stdio configuration validation. Affected versions 0.2.5 through 0.2.9; patched in 0.2.10. A crafted -p flag bypass in the validation logic allows arbitrary command execution. Review logs for exploitation since 0.2.5; assume breach if compromise is suspected.

Source: GitHub Advisory GHSA-r55h-3rwj-hcmg

Chainlit CVE-2026-45018 (CVSS 9.8, published Aug 2026)

Unauthenticated RCE via POST /mcp when features.mcp.enabled = true. Affected 2.4.0rc0 through 2.12.0; fixed in 2.12.0. MCP support has been disabled by default since Chainlit 2.7.0, which limits exposure to deployments that explicitly enabled it. If an immediate upgrade is not possible, set features.mcp.enabled = false in .chainlit/config.toml. Related: CVE-2026-45019 (SSRF, 7.2).

Source: IONIX threat center

Grafana MCP Server CVE-2026-15583 (CVSS 8.6, fixed v0.17.2)

Confused-deputy flaw: an unauthenticated attacker can exfiltrate the server's environment-configured Grafana service-account token by supplying a crafted X-Grafana-URL request header. Also enables SSRF against arbitrary internal services, including cloud metadata endpoints. Fixed in mcp-grafana v0.17.2. Follow-up CVE-2026-19516 (CVSS 9.1, fixed v1.1.0, Aug 2026) closed the remaining SSRF gap; the v0.17.2 fix only stopped credential forwarding, not destination restriction.

Source: Grafana Labs advisory

Penpot CVE-2026-45805 (CVSS 8.8, fixed 2.15.0, published May 2026)

The MCP module's ReplServer binds to 0.0.0.0:4403 and exposes an unauthenticated /execute endpoint that runs arbitrary JavaScript on the server. Anyone on the network can POST code, and it executes with server privileges. Fixed in 2.15.0.

Source: GitHub Advisory GHSA-22qr-rp27-j9wm

MCPJam Inspector CVE-2026-23744 (CVSS 9.8, fixed 1.4.3, NVD published Jan 16, 2026)

MCPJam Inspector listens on 0.0.0.0 by default with no authentication on its server-management endpoint. A crafted HTTP request can install an MCP server and execute arbitrary code on the host. No user interaction required. Affects versions 1.4.2 and earlier.

Source: NVD entry

LiteLLM CVE-2026-30623 (CVSS 9.8, NVD published Jul 15, 2026)

RCE in the MCP server-creation functionality. LiteLLM 1.18.10 accepts a JSON configuration with arbitrary command and args values when registering a new MCP server, and executes them on the host without validation. Follow-up: CVE-2026-42271 (MCP test endpoints) chained with CVE-2026-48710 (Starlette "BadHost" Host Header validation bypass) achieves unauthenticated RCE.

Source: GitHub Advisory GHSA-gw7c-8jfv-4mj2

mcp-remote CVE-2025-6514 (CVSS 9.6, NVD published Jul 2025)

OS command injection in mcp-remote when connecting to an untrusted remote MCP server. A crafted authorization_endpoint response URL triggers command injection and arbitrary code execution on the client machine. Affects 0.0.5 through 0.1.15; fixed in 0.1.16. A 2025 CVE, included because it remains the most impactful client-side MCP proxy RCE.

Source: JFrog blog

OX Security systemic STDIO flaw (April 2026)

OX Security disclosed a systemic architectural flaw in the MCP STDIO transport: the command is executed regardless of whether the server process starts successfully. Pass in a malicious command, receive an error, the command still runs. No sanitization, no warnings. Affects 150M+ package downloads across Python, TypeScript, Java, and Rust MCP SDKs. 7,000+ servers on public IPs with STDIO transport active; an estimated 200,000 total vulnerable instances. 10+ High/Critical CVEs produced across LiteLLM, LangFlow, Flowise, Windsurf, Langchain-Chatchat, Bisheng, and others. Anthropic confirmed the behavior is by design and declined to modify the protocol.

Source: OX Security blog

3. Authentication Hardening Steps

MCP assumes a trusted local environment. That breaks when agents are exposed beyond localhost.

Bind to localhost where possible:

OLLAMA_HOST=127.0.0.1 ollama serve

For remote access, use SSH tunneling instead of opening ports directly:

ssh -L 11434:localhost:11434 user@homelab-host

Ollama-specific hardening:

  • Enable HTTPS with self-signed or Let's Encrypt (supported since v0.5)
  • Add reverse proxy authentication for externally accessible endpoints
  • Set OLLAMA_ORIGINS to restrict which hosts can connect
  • Use OLLAMA_API_KEY to require authentication for API requests

Anthropic/Claude agents:

  • Rotate any exposed API keys; assume compromised if endpoint was open to LAN
  • Use per-project tokens instead of master keys with broad permissions
  • Enable request logging and usage quotas to detect unauthorized queries

Custom agent deployments:

  • Wrap MCP servers behind reverse proxies requiring authentication (basic, token, OAuth)
  • Drop external traffic at the firewall before it reaches service ports
  • Use system prompts that reject tool calls from unauthenticated sessions

Credential management:

chmod 600 /etc/ollama/.env ~/.config/mcp-server/config.json
chown ollama:ollama /etc/ollama/.env

Use a secrets manager (pass, Docker secrets) instead of plaintext configs. The goal is not perfection; it is raising the cost of casual credential theft.

4. Network Segmentation Recommendations

The most robust protection is network-level isolation: keep agents in their own segment.

Isolate agent services on a separate VLAN or Docker network:

nft add rule inet firewall forward iif docker-agents oif docker-agents accept
nft add rule inet firewall forward iif lan oif docker-agents drop
nft add rule inet firewall forward iif docker-agents oif wan drop

Even if a service binds to 0.0.0.0, firewall rules block external traffic before it reaches the agent.

Use Docker bridge instead of host network mode:

Many homelab operators use network_mode: host for simplicity. This bypasses all Docker isolation. Use explicit port mappings only when needed:

services:
  ollama:
    ports:
      - "127.0.0.1:11434:11434"   # Loopback-only
    network_mode: bridge

The 127.0.0.1: prefix prevents external access even if the port is listed in docker ps. This single change is one of the most impactful hardening steps for Ollama operators.

Implement egress filtering:

nft add rule inet firewall forward oif docker-agents ip daddr ! 192.168.0.0/16 drop "no external access for agents"

A compromised agent that can call AWS/GCP APIs poses far more risk than one running local prompts only.

Practical Checklist Summary

  • [ ] Verify Ollama isn't open externally: curl -s http://localhost:11434/api/tags
  • [ ] Change Docker containers from 0.0.0.0:<port> to 127.0.0.1:<port> where external access isn't required
  • [ ] Audit configs for leaked API keys (.env, JSON, systemd files)
  • [ ] Add reverse proxy auth or SSH tunneling for remotely accessible MCP endpoints
  • [ ] Implement firewall rules denying external-to-agent traffic
  • [ ] Use separate Docker networks/VLANs instead of host network mode
  • [ ] Restrict egress from agent containers to only needed services

Taken From

Original lab-note draft reviewed and published after technical review. Key sources:

The takeaway: the convenience that made MCP attractive (zero-config, local-first) also makes it trivially exploitable. Bind to localhost where possible, segment your network, and audit credentials. Every step raises the cost for casual exploitation.

Topics:

Read more