SSRF Risks in Nezha's Webhook: A Call to Action for Developers

You self-host Nezha because Datadog wants $50 per server per month and you have eight $5 VPS boxes scattered across Hetzner and DigitalOcean. The install took 20 minutes from a Cursor session. You wired up the webhook feature so Discord pings you when disk usage hits 90% or a node goes dark. Done. The webhook field accepts any URL and the Nezha agent makes the outbound HTTP request from inside your server. GHSA-6x26-5727-rrm9 confirms what the design always allowed: the webhook handler does not validate the destination. Point it at http://169.254.169.254/latest/meta-data/iam/security-credentials/ and your EC2 instance hands back its IAM role credentials. Point it at http://127.0.0.1:6379 and you are talking to your unauthenticated Redis. Your monitoring tool is now a portal into your private network.

02The webhook field is an outbound HTTP client

Nezha's notification system has one job. When a rule triggers, it serializes the alert into the request body and POSTs to the URL you configured. That URL lives in the admin UI as a plain text field. No allowlist. No DNS validation. No check that the destination is not an internal IP. The advisory covers versions before the patched release and confirms the SSRF is exploitable by any authenticated dashboard user. That last part matters more than it sounds. Authenticated dashboard user includes you on a strong password, anyone who phished one cookie from your laptop at the coffee shop, anyone who guessed the default admin password you forgot to change, and anyone who found your panel on Shodan because you forwarded port 8008 so you could check stats from your phone. Run this check today. Open your Nezha admin, go to alert rules, and look at every configured webhook URL. Then check your version against GHSA-6x26-5727-rrm9. If you are on anything older than the patched release and your dashboard is reachable from the public internet, you are one weak password away from your IAM role. While you are there, ssh into the box and run curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ from a terminal. If that returns JSON instead of timing out, IMDSv2 is not enforced. That is the second half of the chain.

03What an attacker does on a Tuesday

The attack does not require sophistication. It requires a Tuesday afternoon and a list of exposed Nezha dashboards. Step one. They find your dashboard. Shodan indexes Nezha by its login page. Your panel is in the index whether you wanted it to be or not. Step two. They try admin:admin. Then admin:password. Then your first name from the GitHub commit history of the repo you cloned the install script from. If your dashboard sits behind real auth they move on. If not, they are inside. Step three. They create a new alert rule that triggers on CPU usage above 1%. The webhook URL points at http://169.254.169.254/latest/meta-data/iam/security-credentials/MyEC2Role. They wait thirty seconds. Step four. The alert fires. Nezha fetches the metadata endpoint and POSTs the response body, containing your temporary AWS access key, secret key, and session token, to the attacker's webhook receiver. They list every S3 bucket, find yourcompany-user-uploads, and start pulling. On Google Cloud the endpoint is http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token. On Hetzner you have no metadata service but you do have a private network with your Postgres on 10.0.0.5:5432. The same webhook field reaches it. The same SSRF pattern took down Capital One in 2019. The only difference is your monitoring tool wrote the request for you.

04The check you run before lunch

Three things, in order, before lunch. One. Upgrade Nezha to the version patched in GHSA-6x26-5727-rrm9. If you cannot upgrade right now, delete every webhook URL from the admin and disable the notification feature until you can. No Discord pings for a day. You will live. Two. Get the dashboard off the public internet. Put it behind a Tailscale node, a Cloudflare Access policy, or HTTP basic auth on your reverse proxy. The number of self-hosted ops tools that should be reachable from the open internet is zero. Your monitoring panel is not special. Three. Enforce IMDSv2 on every EC2 instance with hop limit 1. Run aws ec2 modify-instance-metadata-options --instance-id i-xxx --http-tokens required --http-put-response-hop-limit 1. This breaks the metadata half of the chain even if the webhook half survives. For GCP, scope service accounts down so the stolen token cannot reach your production bucket. Then audit the other tools you spun up in a Cursor session this quarter. Uptime Kuma, n8n, Grafana, anything with a webhook or URL field in the admin UI has the same problem if it does not validate destinations. Guardian fingerprints exposed Nezha panels from outside your network, matches the running version against GHSA-6x26-5727-rrm9, and probes the webhook field to confirm whether SSRF to internal addresses is reachable. You point us at your dashboard, we tell you whether an attacker can already walk to your IAM role.