Labsec

ACT TONIGHT: Docker Engine: open API on 2375 and docker.sock in web-facing containers = root on host

2026-09-28T00:00:00Z

What: The Docker API is root on the host. Anyone who can talk to it (TCP 2375, or /var/run/docker.sock) can start a privileged container with / mounted and own the box. Bots do exactly that, nonstop. Carbonato (ThreatDown, disclosed Sept 2026, activity Oct 2024 to Aug 2026) hits unauthenticated 2375, launches a privileged container, drops SSH keys and cron/systemd persistence, steals AI API keys and SSH creds, and scans for the next daemon every five minutes. Earlier strains (Trend Micro, June 2025; Akamai, Sept 2025) mount /:/hostroot, drop XMRig, add keys to /root/.ssh/authorized_keys, and firewall 2375 so other gangs can't get in after them.

Who it hits:

dockerd started with -H tcp://0.0.0.0:2375 (a daemon.json hosts entry, a systemd override, or a leftover "enable remote API" tutorial). Port-forwarded, on a VPS, or anywhere the LAN is reachable.
2376 without --tlsverify. Using the TLS port number doesn't give you TLS.
Containers that are reachable from the web and mount docker.sock: Portainer, Traefik, Watchtower, Homepage/dashboards, "container manager" UIs. One bug or weak login in that app gives the attacker root on the host.
Anyone who trusts ufw to protect published container ports. It doesn't. Docker's own iptables rules divert published-port traffic before ufw sees it.

Check if you're affected:

# 1. Is the daemon listening on TCP? Any output here = look closer.
sudo ss -ltnp | grep -E ':2375|:2376'
systemctl cat docker | grep -n 'tcp://'
grep -n 'tcp://' /etc/docker/daemon.json 2>/dev/null

# 2. From OUTSIDE your network (phone hotspot, a VPS). JSON back = you're open to the world.
curl -s --max-time 5 http://<public-ip>:2375/version

# 3. Which running containers mount the socket?
docker ps -q | xargs -r docker inspect --format '{{.Name}} {{range .Mounts}}{{.Source}} {{end}}' | grep docker.sock
grep -rn --include='*compose*.y*ml' 'docker.sock' ~ /opt /srv 2>/dev/null

# 4. Which published ports listen on every interface (and skip ufw)?
docker ps --format '{{.Names}}\t{{.Ports}}' | grep -E '0\.0\.0\.0|\[::\]|:::'

# 5. Signs you're already hit (alpine matches plenty of legit images; look for ones you didn't start)
docker ps -a --format '{{.ID}}\t{{.Image}}\t{{.CreatedAt}}\t{{.Command}}' | grep -Ei 'alpine|base64|hostroot'
sudo cat /root/.ssh/authorized_keys; sudo crontab -l; systemctl list-timers --all

Do this:

Tonight: close 2375. Remove tcp://... from /etc/docker/daemon.json (hosts) and from any ExecStart in /etc/systemd/system/docker.service.d/*.conf, then sudo systemctl daemon-reload && sudo systemctl restart docker. Delete the router port-forward too.
Need remote control? Use SSH, not TCP. docker context create lab --docker host=ssh://you@labbox then docker --context lab ps. If you really need TCP, use TLS on 2376 with --tlsverify and client certs. Never plain 2375.
Take the socket out of web-facing apps. If an app only needs to read container state (Traefik's Docker provider, Homepage, most dashboards), put tecnativa/docker-socket-proxy in front with CONTAINERS=1 and POST=0 (the default). Put it on an internal network, never published. Mounting the socket :ro does not make the API read-only: it still accepts every call. Apps that must write (Portainer, Watchtower) stay off the public internet. Put them behind a VPN (Tailscale/WireGuard) or Cloudflare Access.
Stop trusting ufw for container ports. Anything behind a reverse proxy or tunnel should be published as 127.0.0.1:8080:80 (compose: "127.0.0.1:8080:80"), or not published at all and reached over a shared Docker network. On Docker older than 28.0.0, machines on the same L2 segment can still reach localhost-published ports, so upgrade.
Verify. Re-run checks 1–4. curl http://<public-ip>:2375/version from outside must time out.

If you were already hit: Treat the host as owned. They had root. Rebuild it. Before you do, rotate everything that lived on it (SSH keys, cloud creds, AI provider API keys, tokens in .env files) because Carbonato goes after exactly those.

Why this level: An open 2375 or an internet-facing app holding docker.sock gives root with no auth, and live worms are scanning 2375 right now (the mass-scanning override applies). That's 5/5 on the rubric. act-tonight.

ACT TONIGHT: Ollama / vLLM / LiteLLM: inference API open to the internet with no auth

2026-09-28T00:00:00Z

What: Ollama, vLLM and LiteLLM don't have auth turned on by default. If the port is reachable, anyone can run your models on your GPU, pull or push models, and read what the API exposes. People are actively scanning for these. SentinelLABS and Censys counted about 175,000 exposed Ollama hosts (Oct 2025 to Jan 2026). Nearly half of them advertised tool calling. Pillar Security found a marketplace ("Operation Bizarre Bazaar") that resells access to hijacked endpoints. Between March and June 2026, Sysdig and Zenity caught attackers using exposed Ollama and LiteLLM backends as the brain of automated attack tools.

Who it hits: You're affected if any of these is true:

OLLAMA_HOST=0.0.0.0 with 11434 port-forwarded, tunneled or on a VPS.
docker run -p 11434:11434 ollama/ollama on a box with a public IP. Docker's published ports get around ufw.
vllm serve on its defaults, which bind all interfaces. --api-key only guards /v1-style paths. /invocations, /score, /pooling and a few others stay open.
A LiteLLM proxy on 0.0.0.0:4000 with no master_key. Anyone can then spend the upstream OpenAI or Anthropic keys it holds.

Ollama versions below 0.17.1 add CVE-2026-7482 ("Bleeding Llama", CVSS 9.1). It takes three unauthenticated API calls (/api/create then /api/push) to leak heap memory: prompts, env vars and API keys. Versions below 0.1.34 also have Probllama (CVE-2024-37032), an RCE through /api/pull.

Check if you're affected:

# On the box: anything on 0.0.0.0 / [::] / * here is listening on every interface
ss -ltnp | grep -E ':(11434|8000|4000)\b'
# From OUTSIDE your network (phone hotspot, VPS). Any JSON back means you're exposed:
curl -s -m 5 http://YOUR_PUBLIC_IP:11434/api/tags

Do this:

Tonight: stop Ollama listening on every interface. Run sudo systemctl edit ollama, set Environment="OLLAMA_HOST=127.0.0.1:11434", then run sudo systemctl daemon-reload && sudo systemctl restart ollama. For Docker, publish it as -p 127.0.0.1:11434:11434. Start vLLM with --host 127.0.0.1.
Remove the router port-forward. If other LAN machines need the API, only let the LAN in, e.g. sudo ufw allow from 192.168.1.0/24 to any port 11434, and deny the rest. Or reach it over Tailscale or WireGuard instead.
If you need it reachable from outside, put an auth proxy in front: Caddy or nginx with basic auth or forward-auth, or Cloudflare Tunnel with Cloudflare Access. For vLLM, only allow the paths you use through the proxy. Don't rely on --api-key.
LiteLLM: set LITELLM_MASTER_KEY=sk-<long random> (it must start with sk-) and give clients virtual keys. Rotate every upstream provider key the proxy held if it was ever open.
Upgrade Ollama to 0.17.1 or newer: ollama -v.
Confirm the fix: from outside, the curl above should time out. The ss line should show only 127.0.0.1 or your LAN or tailnet IP.

If you were already hit: Look in the Ollama logs for unfamiliar /api/create, /api/push or /api/pull calls, and for models you didn't pull (ollama list). Rotate any keys that were in the process env or passed through LiteLLM. Check GPU usage history for load you didn't cause.

Why this level: It answers yes on all five rubric questions: commonly port-forwarded or tunneled, exploited in live campaigns, a core lab AI tool, big blast radius (keys, prompts, free compute, tool-calling agents), and no auth by default. Mass scanning of 11434 with live LLMjacking campaigns also triggers the act-tonight override.

ACT TONIGHT: Grafana and Prometheus: admin/admin, anonymous access, and unauthenticated metrics/pprof endpoints

2026-09-28T00:00:00Z

What: Out of the box, Grafana listens on all interfaces with admin/admin. Prometheus (:9090) and node_exporter (:9100) have no auth at all, and both serve /debug/pprof. Aqua Nautilus found about 40,000 Prometheus servers and 296,000 exporters open to the internet in Dec 2024. Their metrics and labels were leaking credentials, tokens, API keys and internal hostnames. Anyone can hit pprof to pull out runtime details or tie up the host's resources. On top of the bad defaults, Grafana keeps shipping CVEs:

CVE	What	Needs	Fixed in
CVE-2021-43798	Path traversal, reads files off the host	Nothing (unauth)	8.3.1 / 8.2.7 / 8.1.8 / 8.0.7. In CISA KEV since 2025-10-09. GreyNoise logged 110 IPs trying it on 28 Sep 2025
CVE-2025-4123 "Grafana Ghost"	Open redirect + path traversal leading to XSS/account takeover. Full-read SSRF if Image Renderer is installed	Victim clicks a link. Works with anonymous access on	10.4.18, 11.2.9, 11.3.6, 11.4.4, 11.5.4, 11.6.1 (all `+security-01`), 12.0.0+security-01
CVE-2024-9264	SQL Expressions command injection/LFI (CVSS 9.9)	Viewer account, plus `duckdb` binary in Grafana's PATH	11.0.5/11.1.6/11.2.1 `+security-01` (and later)
CVE-2026-27876	sqlExpressions file write leading to RCE/SSH on the host (CVSS 9.1)	Viewer account, plus the `sqlExpressions` feature toggle	12.4.2, 12.3.6, 12.2.8, 12.1.10, 11.6.14
CVE-2026-27880	Crashes Grafana by exhausting memory	Nothing (unauth)	Same as above

The Viewer-level bugs are why anonymous access matters. With anonymous on, every visitor gets Viewer by default. Grafana published more fixes in Aug and Sep 2026, so check the advisories page for your version.

Who it hits:

Grafana on :3000 port-forwarded, or put on the internet through a Cloudflare Tunnel or reverse proxy, that is still on admin/admin, has [auth.anonymous] enabled = true, or runs an unpatched version.
Prometheus :9090 or any exporter (:9100, cAdvisor, etc.) reachable from outside your LAN. Docker's -p 9090:9090 publishes on every interface and skips ufw, so a host firewall doesn't save you.

Check if you're affected:

# What is listening, and on which address (0.0.0.0 / [::] = every interface)
ss -ltnp | grep -E ':(3000|9090|9093|9100)\b'

# Grafana version (compare against the table / advisories page)
curl -s http://HOST:3000/api/health

# Default creds still work? 200 + JSON = yes, 401 = no
curl -s -o /dev/null -w '%{http_code}\n' -u admin:admin http://HOST:3000/api/user

# Anonymous access on? 200 with a list = yes, 401 = no
curl -s -o /dev/null -w '%{http_code}\n' http://HOST:3000/api/search

# Run these from OUTSIDE (phone hotspot / a VPS) against your public IP or hostname.
# Any 200 means strangers see it too.
curl -s -o /dev/null -w '%{http_code}\n' http://PUBLIC:9090/api/v1/targets
curl -s -o /dev/null -w '%{http_code}\n' http://PUBLIC:9090/debug/pprof/
curl -s -o /dev/null -w '%{http_code}\n' http://PUBLIC:9100/metrics
curl -s -o /dev/null -w '%{http_code}\n' http://PUBLIC:9100/debug/pprof/

Do this:

Tonight: delete any port-forward for 3000, 9090, 9093 or 9100 on the router. Never forward Prometheus or exporter ports. If you need to reach them remotely, use a VPN (Tailscale/WireGuard).
Change the Grafana admin password: docker exec -it grafana grafana cli admin reset-admin-password 'LONG-RANDOM' (or change it in the UI under Profile, then Change password). GF_SECURITY_ADMIN_PASSWORD only takes effect on first start and does not change an existing database.
Lock down grafana.ini (or the matching GF_* env vars) and restart: ini [auth.anonymous] enabled = false [users] allow_sign_up = false [server] http_addr = 127.0.0.1 ; if only a local reverse proxy talks to it Use Grafana's public dashboards feature to share a single dashboard, not anonymous access.
Upgrade Grafana to at least the fixed version for your branch in the table, and preferably the newest patch release listed on the advisories page. If you can't upgrade yet: turn off the sqlExpressions feature toggle, make sure duckdb is not in Grafana's PATH, and remove Image Renderer unless you use it.
Keep Prometheus and exporters on localhost or the LAN. Use --web.listen-address=127.0.0.1:9090 (or your LAN IP). In compose, use "127.0.0.1:9090:9090", or leave out ports: and let Prometheus scrape over the Docker network.
Add basic auth on Prometheus and node_exporter with --web.config.file=web.yml: yaml basic_auth_users: prom: $2y$10$... # bcrypt hash, e.g. htpasswd -nBC 10 "" | tr -d ':\n' node_exporter has no flag to turn off /debug/pprof (upstream closed that request as not planned). Auth or network restriction is the only fix.
Verify: rerun the outside curls. Every one should time out or return 401.

If you were already hit: Treat every data source credential and token stored in Grafana as leaked, along with any secrets that showed up in Prometheus labels. Rotate them, check the Grafana users and API/service-account tokens for ones you didn't create, and rebuild the host if you were on a version vulnerable to the RCE bugs.

Why this level: It hits all five: the ports are commonly forwarded, Grafana is actively scanned (GreyNoise, CISA KEV), it's core lab software, it leaks secrets or gives RCE, and the defaults need no credentials. If nothing answers from outside, treat it as this-week.

ACT TONIGHT: Open WebUI: 150+ advisories in 2026, and an admin login means Python on your server

2026-09-28T00:00:00Z

What: Open WebUI has published 165 GitHub security advisories: 1 in 2024, 6 in 2025 and 158 so far in 2026. Most are stored XSS, session-token theft, SSRF and access-control bugs. They all end the same way: steal an admin's session, then use Functions or Tools to run Python on the server. That's by design, not a bug. Admin, or workspace.tools permission, equals code execution on the host. The newest batch (fixed in 0.11.4, advisories out Sep 27-28) includes GHSA-vpq8-f445-hcq7. In 0.7.0 to 0.11.3, any website you visit while logged in can steal your session token, with community sharing on (the default). In June 2025 Sysdig caught an attacker on an internet-facing Open WebUI with auth turned off. The attacker uploaded a malicious Tool and dropped XMRig, T-Rex, process hiders and a Windows infostealer. Sysdig counted over 17,000 instances on Shodan at the time.

Who it hits: You're affected if any of these is true:

WEBUI_AUTH=False. Every visitor is signed in as the admin@localhost admin. With the port reachable, anyone can run Python on your box. This is the setup Sysdig saw exploited.
A fresh install exposed before you create your account. The first signup becomes admin, whoever does it. Signup turns itself off after that.
Signup turned back on with DEFAULT_USER_ROLE=user. Strangers get working accounts, and most of the 2026 bugs only need a normal user account.
Older versions, even behind a login. Examples:
CVE-2025-64496 (≤ 0.6.34): Direct Connections, malicious model server runs JS, token theft.
CVE-2025-46719 (0.6.5): stored XSS in chat, admin token, RCE via Functions.
CVE-2026-45395 (< 0.9.5): a user with write access to one tool gets code execution.
CVE-2026-59214 (< 0.10.0): Pyodide in a shared chat, RCE when an admin clicks Run.
CVE-2026-44551 (≤ 0.8.12): LDAP with an empty password logs in as anyone, on OpenLDAP defaults.
Ollama published next to it on 0.0.0.0:11434. Even if the UI is locked down, the raw API is open. See the exposed-inference-APIs card.

Check if you're affected:

# Version + auth state, no login needed. Want: version >= 0.11.4, auth true,
# enable_signup false, and no "onboarding": true (that means nobody has claimed admin yet).
curl -s http://localhost:3000/api/config | jq '{version, onboarding, auth: .features.auth, enable_signup: .features.enable_signup, ldap: .features.enable_ldap}'
# Same check from OUTSIDE your network (phone hotspot, VPS) against your public hostname/IP.
# Any JSON back means the UI is reachable from the internet.
# Env set on the container (UI changes override these after first boot, so trust /api/config):
docker inspect open-webui --format '{{.Config.Image}}{{range .Config.Env}}{{"\n"}}{{.}}{{end}}' | grep -E 'open-webui:|WEBUI_AUTH|ENABLE_SIGNUP|DEFAULT_USER_ROLE|ENABLE_DIRECT_CONNECTIONS'
# Is Ollama exposed next to it? Want 127.0.0.1 only.
ss -ltnp | grep -E ':(11434|3000|8080)\b'

Do this:

Tonight: upgrade to 0.11.4 or newer. Pin the tag instead of :main so you know what you're running: docker pull ghcr.io/open-webui/open-webui:v0.11.4, then recreate the container with the same volume (-v open-webui:/app/backend/data). pip installs: pip install -U open-webui.
If features.auth is false, turn auth back on: remove WEBUI_AUTH=False and set a password on the admin account. If it's reachable from outside, take it offline first. Never run no-auth Open WebUI on anything but 127.0.0.1.
Claim the admin account before exposing a new install. Better: set WEBUI_ADMIN_EMAIL and WEBUI_ADMIN_PASSWORD on first boot, which creates the admin and turns signup off.
Admin Panel > Settings > General: signup off unless you need it, and Default User Role pending. Only give Tools/Functions access to people you'd trust with a shell on the host. If you don't use plugins, set ENABLE_PLUGINS=false. Also turn off Direct Connections, community sharing, and code execution/interpreter unless you use them.
Don't port-forward 3000/8080. Reach it over Tailscale or WireGuard, or put it behind Cloudflare Access or another forward-auth layer. Publish Ollama as 127.0.0.1:11434:11434.
Confirm: re-run the curl. It should show the new version, auth: true, and enable_signup: false. From outside it should time out or hit your auth proxy first.

If you were already hit: In Workspace > Tools and Admin > Functions, look for anything you didn't install. Check Admin > Users for unknown admins. Inside the container, look for cryptominers (docker exec open-webui ps aux). Rotate WEBUI_SECRET_KEY (this logs out every session) and every provider API key stored in Connections. Assume the host is compromised if an unknown Tool or Function ran, and rebuild it.

Why this level: Four yeses: often exposed through tunnels and port-forwards, exploited in the wild (Sysdig) with public PoCs in the advisories, a core lab AI tool, and admin access means Python on the host. No-friction is "no" because a default install creates the first admin, turns signup off, and sets new users to pending. Most current bugs need an account or a click. The patch is 7 days old, so no auto-update downgrade.

ACT TONIGHT: MikroTik RouterOS: unauthenticated SSH takeover chain ("MikroTrick") exploited since Sept 2

2026-09-03T00:00:00Z

What: Attackers are taking full admin on MikroTik routers over SSH with no password and no key. The chain ("MikroTrick", named by CERT Polska): CVE-2026-67279 lets an unauthenticated client skip SSH auth by asking for a rekey mid-login. CVE-2026-86060 then feeds the username -2 to the login helper and gets full admin rights. Attacks started 2026-09-02, one day before MikroTik shipped fixes. Both chain CVEs are in CISA KEV. The same release also fixes CVE-2026-67276, where the SSH RSA public-key check ignores the exponent, and CVE-2026-67277, an unauthenticated bandwidth-test (btest) kernel memory leak and crash (also in KEV). Seen after break-in: a new full-admin user ops, plus scripts, scheduler jobs, proxies and tunnels, and file transfers to attacker hosts that look like config theft.

Who it hits: A MikroTik (hAP, RB, CCR, CRS, CHR) on RouterOS below 7.24.2 / 7.23.4 / 6.49.21 where SSH (port 22, or wherever you moved it) is reachable from the internet. That includes a VPS running CHR, and a "temporary" WAN rule allowing SSH that never got removed. MikroTik says the default config doesn't expose SSH on WAN. Scans on 2026-09-05 still found about 122,500 devices with SSH open to the internet. Only the SSH users are exposed to the full chain. A btest server (port 2000) open to the internet is exposed to the leak and the crash.

Check if you're affected:

# From a LAN box: installed version (vulnerable if below 7.24.2, 7.23.4 on long-term, 6.49.21 on v6)
ssh admin@192.168.88.1 '/system resource print' | grep -i version
# From OUTSIDE your network (phone hotspot, VPS): does SSH answer on your WAN IP?
nc -vz -w 5 YOUR_PUBLIC_IP 22

Do this:

Tonight: shut SSH off to the internet. In the RouterOS terminal: /ip service set ssh address=192.168.88.0/24 (use your LAN or VPN subnet), or /ip service disable ssh if you don't use it. Do the same for www, www-ssl and winbox. Then /tool bandwidth-server set enabled=no.
Upgrade: /system package update check-for-updates then /system package update install. You want 7.24.2 or newer on stable, 7.23.4 on long-term, or 6.49.21 on v6. Then /system routerboard upgrade and reboot again so the firmware matches.
Look for signs you were hit: /user print (look for ops or any user you don't know), /log print where message~"-2" (look for login failure for user -2 or added by ssh:-2@), /system script print, /system scheduler print, /ip proxy print, /interface print (look for tunnels you didn't make).
Confirm the fix: /system resource print shows the fixed version, and the nc check from outside times out.
Remote management from now on should go over WireGuard or Tailscale, not an open port.

If you were already hit: Pull the WAN cable. Save /export and the logs for evidence, then netinstall or factory-reset to a fixed version. Rebuild the config by hand; don't restore the backup. Change every password, and rotate every key and WireGuard/VPN secret the router held. It was your gateway, so treat LAN traffic in that window as seen.

Why this level: It answers yes on all five rubric questions: SSH is exposed on WAN on six-figure numbers of devices, three CVEs are in KEV with confirmed attacks, MikroTik is a home-lab router staple, owning the gateway means owning the LAN, and no credentials are needed. It is also an unauthenticated takeover under active exploitation, which triggers the act-tonight override.

THIS WEEK: Cloudflare Tunnel: public hostnames with no Access policy, leaked tunnel tokens, and origins still port-forwarded

2026-09-28T00:00:00Z

What: A tunnel only moves traffic. It does not add a login. Cloudflare's own docs say it plainly: "If you do not have an Access application in place, the published application will be available to anyone on the Internet." Three mistakes keep showing up in labs. You publish Proxmox, Portainer or Grafana through a tunnel with no Access policy. You commit the tunnel token to a public repo or compose file, and "Anyone with the token can run the tunnel." Or you leave the old port-forward open, so the origin can still be reached without going through Cloudflare. A separate issue: throwaway *.trycloudflare.com Quick Tunnels are a documented malware delivery channel. Proofpoint has tracked it since February 2024, Securonix reported SERPENTINE#CLOUD in June 2025, and Cofense reported a 2025 peak in March 2026.

Who it hits:

Any public hostname on your tunnel that has no matching Access application. This is worst for admin UIs: Proxmox (8006), Portainer (9443/9000) and Grafana (3000). Their own login page becomes the only thing between the internet and your hypervisor or Docker socket.
TUNNEL_TOKEN=eyJ... or tunnel run --token eyJ... in a docker-compose.yml, .env, or Ansible file that has ever been pushed to GitHub or a public Gitea/Forgejo, including git history. Anyone holding it can run a connector for your tunnel and take a share of your traffic.
Routers that still forward 443, 8006 or 9443 to the box after you moved to a tunnel, and UPnP mappings too. Your Access policy does nothing on that path.
Anyone using cloudflared tunnel --url ... Quick Tunnels to "just share something". Cloudflare says they are "intended for testing and development only."

Check if you're affected:

# 1. For EVERY hostname in Zero Trust > Networks > Tunnels > <tunnel> > Public hostnames:
#    open it in a private window. You must see a Cloudflare Access login, not the app.
#    Scripted version: a protected host answers with a redirect to <team>.cloudflareaccess.com.
for h in proxmox.example.com portainer.example.com grafana.example.com; do
  printf '%s -> ' "$h"
  curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' "https://$h/"
done
# 200, or a redirect to the app's own /login  = NOT protected by Access

# 2. Tunnel tokens in files and in git history (tokens start with eyJhIjoi)
grep -rEn 'TUNNEL_TOKEN|--token[ =]|eyJhIjoi' ~/ --include='*.yml' --include='*.yaml' \
  --include='*.env' --include='.env' --include='*.sh' 2>/dev/null
for r in $(find ~ -name .git -type d -prune 2>/dev/null); do
  git -C "${r%/.git}" log -p --all 2>/dev/null | grep -q 'eyJhIjoi' && echo "TOKEN IN HISTORY: ${r%/.git}"
done

# 3. Is the origin reachable directly? Run this from OUTSIDE your LAN (phone hotspot):
nmap -Pn -p 22,80,443,3000,8006,9000,9443 <your-WAN-IP>
#    Any "open" port is bypassing the tunnel. Also check the router's port-forward and UPnP pages.

# 4. Stray cloudflared / quick tunnels on your boxes
pgrep -a cloudflared; docker ps --format '{{.Names}} {{.Image}}' | grep -i cloudflared
#    Any "--url" / trycloudflare process you don't recognise = investigate.

Do this:

Put Access in front of every admin hostname. Go to Zero Trust > Access controls > Applications > Create new application > Self-hosted, and add the public hostname. Attach an Allow policy for your own email or IdP group only. Access is deny by default, so anyone not matched gets nothing. Do this before you add new tunnel routes, not after.
If a token was ever public, rotate it and kill live connectors. In the dashboard, go to Networking > Tunnels > your tunnel > Refresh token. Some doc pages call the button "Rotate token". Then reinstall/restart cloudflared everywhere with the new token. Refreshing blocks new connections with the old token, but existing connectors stay up until restarted. That includes one an attacker is running. Drop them all: curl -X DELETE "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/cfd_tunnel/$TUNNEL_ID/connections" -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" Then check the tunnel's Connectors list shows only your hosts.
Get the token out of compose. On cloudflared 2025.4.0 or newer, use --token-file / TUNNEL_TOKEN_FILE pointing at a file that is not tracked by git, or keep TUNNEL_TOKEN in a gitignored .env. Scrubbing git history does not un-leak a token. Rotate it anyway.
Close the side door. Delete every router port-forward to the tunnelled services and turn off UPnP. cloudflared only makes outbound connections, so the host needs no inbound ports at all. Firewall inbound to deny.
Don't use Quick Tunnels for anything real. If nothing in your lab uses them, add trycloudflare.com to a Pi-hole/AdGuard blocklist, or at least alert on it. On a lab network, a lookup for it usually means malware staging or someone's test tunnel you forgot about.
Verify. Re-run checks 1–3. Every admin host should redirect to cloudflareaccess.com, grep should come back empty, and the outside nmap should show all ports filtered/closed.

Why this level: Reachable, common and high blast radius: a Proxmox or Portainer panel is the hypervisor or the Docker socket. That is 3 yes answers, so this-week. It is not higher because the app's own login still stands in the way, and no documented campaign (as of 2026-09-28) targets unprotected lab tunnel hostnames. The Quick Tunnel abuse is real but targets phishing victims, not your tunnel. If you run Portainer/Proxmox with default or reused creds behind an unprotected hostname, treat it as act-tonight.

THIS WEEK: MCP servers: unauthenticated dev proxies, backdoored packages, and tool poisoning in your agent setup

2026-09-28T00:00:00Z

What: An MCP server is code your agent runs with your user's permissions, and the model obeys whatever text it hands back. Four documented ways this goes wrong:

Unauthenticated dev tools. MCP Inspector below 0.14.1 ran a proxy on port 6277 with no auth. It would spawn any command it was told to (CVE-2025-49596, CVSS 9.4). A web page you visit can reach it through 0.0.0.0 or DNS rebinding, so it doesn't have to be port-forwarded. Oligo found instances exposed to the internet. mcp-remote 0.0.5 to 0.1.15 executes a shell command hidden in a malicious server's OAuth authorization_endpoint (CVE-2025-6514, CVSS 9.6).
Backdoored packages. postmark-mcp on npm was a copy of the real Postmark server. It behaved for 15 versions, then 1.0.16 added one line that BCC'd every sent email to the attacker. In February 2026 the SANDWORM_MODE worm (typosquats like claud-code and cloude-code) wrote a rogue MCP server into Claude Code, Claude Desktop, Cursor, Continue and Windsurf configs. That server used prompt injection to pull SSH keys, AWS creds, npm tokens and .env files.
Tool poisoning and prompt injection. Tool descriptions can hide instructions that the model reads and the UI doesn't show. Invariant Labs used this to make Cursor leak ~/.cursor/mcp.json and ~/.ssh/id_rsa. A server can also change its descriptions after you approve it (a "rug pull"). A README, issue or web page the agent reads works the same way.
Over-broad file and shell servers. The official filesystem server could be escaped via symlinks and prefix tricks (CVE-2025-53109/53110). The official git server had path traversal and argument injection (CVE-2025-68143/68144/68145). Prompt injection can reach those bugs, and chained with the filesystem server they give code execution.

Who it hits: You're affected if any of these is true:

You ran npx @modelcontextprotocol/inspector (or mcp dev) on an old version, or left it running.
Your Claude Code, Cursor or Claude Desktop config launches servers with npx -y <pkg> or uvx <pkg> and no version, so every restart pulls whatever was published last.
You have a filesystem server rooted at ~ or /, or a shell or git server, and you auto-approve its tools. It's worse if a fetch, browser or email server sits in the same session.
You installed an MCP server from a random npm or PyPI name instead of the vendor's own repo.

Check if you're affected:

# Inspector / MCP HTTP servers listening. Anything on 0.0.0.0, [::] or * is reachable off-box
ss -ltnp | grep -E ':(6274|6277)\b|node|python|uvx'
# Every MCP server your clients will launch. Look for unpinned npx/uvx and names you don't recognise
claude mcp list
jq '.mcpServers, (.projects[]?.mcpServers)' ~/.claude.json 2>/dev/null
jq '.mcpServers' ~/.cursor/mcp.json .mcp.json 2>/dev/null
# Installed versions of the known-bad packages, plus the typosquats
npm ls -g --depth=0 2>/dev/null | grep -Ei 'mcp|inspector|postmark|claud-code|cloude'
uv tool list 2>/dev/null | grep -i mcp; pip list 2>/dev/null | grep -i mcp

Do this:

Kill any Inspector that's running and upgrade. Use npx @modelcontextprotocol/inspector@latest (0.14.1+ needs a session token and checks Origin). Run it only while you're debugging.
Upgrade: mcp-remote to 0.1.16+, server-filesystem to 0.6.3 / 2025.7.01+, mcp-server-git to 2025.12.18+. If postmark-mcp (npm) or any SANDWORM_MODE typosquat turns up, remove it and rotate everything it could reach: mail, SSH keys, cloud and npm tokens, and LLM API keys.
Pin versions in the config (npx -y some-mcp@1.2.3, uvx some-mcp==1.2.3) and install from the vendor's own repo. Re-read the tool descriptions when you bump a version.
Delete servers you don't use. Point filesystem servers at one project directory, never ~. Keep ~/.ssh, ~/.aws and .env outside every allowed root.
Don't auto-approve shell, filesystem-write, git or email tools. Don't put a server that fetches untrusted content (web, issues, mail) in the same session as one that can write or send.
Any MCP server that speaks HTTP should bind to 127.0.0.1 and never be port-forwarded or tunneled without an auth layer in front. Running the agent plus its servers in a container or VM with only the project mounted caps the blast radius.
Confirm: ss shows nothing on 6274/6277, and claude mcp list shows only servers you meant to add, each with a pinned version.

Why this level: Three yes. It's exploited (a backdoored MCP package and a worm writing rogue MCP configs in the wild, plus public PoCs). MCP is in the lab AI stack. The blast radius is your shell, SSH keys and API keys. Reachable is no because most MCP servers are stdio and not exposed. No-friction is no because most paths need you to install a bad package or have the agent read attacker content. If you run an old Inspector or a 0.0.0.0-bound MCP server, treat it as act-tonight.