<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-02T03:31:19.403115+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-47268</id>
    <title>fkie_cve-2026-47268</title>
    <updated>2026-10-02T03:31:19.426186+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&amp;M tool. From version 0.20.0 to before version 2.0.10, an authenticated Nezha dashboard user can create or update a DDNS profile with provider webhook and configure an arbitrary webhook_url, HTTP method, request body, and headers. When DDNS is triggered for a server that uses that profile, the dashboard process sends the configured request with utils.HttpClient without the SSRF protections used by notification webhooks. This allows a low-privileged authenticated user who controls an owned server/DDNS profile to make the dashboard host issue HTTP requests to loopback or internal network services. The response body is not returned to the attacker in the confirmed path, so this is a blind SSRF / internal state-changing request primitive. This issue has been patched in version 2.0.10.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-47268"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-6x26-5727-rrm9</id>
    <title>GHSA-6x26-5727-rrm9 — Nezha's authenticated DDNS webhook configuration allows blind SSRF from the dashboard host</title>
    <updated>2026-10-02T03:31:19.426314+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: github.com/nezhahq/nezha, Go: github.com/naiba/nezha</p>
<p>#### Summary</p>
<p>An authenticated Nezha dashboard user can create or update a DDNS profile with provider `webhook` and configure an arbitrary `webhook_url`, HTTP method, request body, and headers. When DDNS is triggered for a server that uses that profile, the dashboard process sends the configured request with `utils.HttpClient` without the SSRF protections used by notification webhooks.</p>
<p>This allows a low-privileged authenticated user who controls an owned server/DDNS profile to make the dashboard host issue HTTP requests to loopback or internal network services. The response body is not returned to the attacker in the confirmed path, so this is a blind SSRF / internal state-changing request primitive.</p>
<p>#### Details</p>
<p>The DDNS API is available to authenticated users, not only administrators:</p>
<p>- `cmd/dashboard/controller/controller.go:137` registers `GET /api/v1/ddns`.
- `cmd/dashboard/controller/controller.go:139` registers `POST /api/v1/ddns`.
- `cmd/dashboard/controller/controller.go:140` registers `PATCH /api/v1/ddns/:id`.</p>
<p>The create and update handlers copy attacker-controlled webhook fields directly from JSON request bodies into `model.DDNSProfile`:</p>
<p>- `cmd/dashboard/controller/ddns.go:47-74` accepts `model.DDNSForm` and stores `WebhookURL`, `WebhookMethod`, `WebhookRequestType`, `WebhookRequestBody`, and `WebhookHeaders`.
- `cmd/dashboard/controller/ddns.go:112-145` updates the same fields after profile ownership is checked.
- `model/ddns_api.go:11-15` exposes these fie…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-6x26-5727-rrm9"/>
  </entry>
</feed>
