<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Mon, 28 Sep 2026 17:58:39 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-48119</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-48119</link>
      <description>&lt;p&gt;Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&amp;amp;M tool. From version 0.20.0 to before version 2.0.12, authenticated agents can forge service-monitor results for other users&amp;#39; services. This issue has been patched in version 2.0.12.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&amp;amp;M tool. From version 0.20.0 to before version 2.0.12, authenticated agents can forge service-monitor results for other users&amp;#39; services. This issue has been patched in version 2.0.12.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-48119</guid>
    </item>
    <item>
      <title>GHSA-4g6j-g789-rghm — Nezha's authenticated agents can forge service-monitor results for other users' services</title>
      <link>https://db.gcve.eu/vuln/ghsa-4g6j-g789-rghm</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/nezhahq/nezha&lt;/p&gt;
&lt;p&gt;#### Summary&lt;/p&gt;
&lt;p&gt;Nezha accepts service-monitor `TaskResult` messages from an authenticated agent based only on whether the reported service ID exists. The dashboard authenticates the agent and derives the reporter server ID from the gRPC stream, but the service-monitor result worker does not verify that the reporter server was selected for that service, belongs to the service owner, or was actually assigned that monitoring task.&lt;/p&gt;
&lt;p&gt;A low-privilege user with a valid agent secret and one registered agent can therefore submit forged monitoring results for another user&amp;#39;s service ID. This allows cross-tenant corruption of service-monitor history/current state, and can influence victim-owned service notifications with attacker-controlled result text.&lt;/p&gt;
&lt;p&gt;#### Details&lt;/p&gt;
&lt;p&gt;The agent task stream accepts inbound `TaskResult` messages after authenticating agent metadata:&lt;/p&gt;
&lt;p&gt;- `service/rpc/auth.go:23-60` validates `client_secret` and `client_uuid`.
- `service/rpc/auth.go:63-75` registers an unknown valid UUID as a server for the authenticated secret owner.
- `service/rpc/nezha.go:40-48` authenticates the `RequestTask` stream and binds it to `clientID`.
- `service/rpc/nezha.go:50-56` receives agent-controlled `TaskResult` messages.
- `proto/nezha.proto:60-65` defines attacker-controlled `TaskResult.id`, `type`, `delay`, `data`, and `successful`.&lt;/p&gt;
&lt;p&gt;For service-monitor task types, the result is dispatched directly to the service sentinel using the authenticated server ID as reporter:&lt;/p&gt;
&lt;p&gt;- `service/rpc/nez…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/nezhahq/nezha&lt;/p&gt;
&lt;p&gt;#### Summary&lt;/p&gt;
&lt;p&gt;Nezha accepts service-monitor `TaskResult` messages from an authenticated agent based only on whether the reported service ID exists. The dashboard authenticates the agent and derives the reporter server ID from the gRPC stream, but the service-monitor result worker does not verify that the reporter server was selected for that service, belongs to the service owner, or was actually assigned that monitoring task.&lt;/p&gt;
&lt;p&gt;A low-privilege user with a valid agent secret and one registered agent can therefore submit forged monitoring results for another user&amp;#39;s service ID. This allows cross-tenant corruption of service-monitor history/current state, and can influence victim-owned service notifications with attacker-controlled result text.&lt;/p&gt;
&lt;p&gt;#### Details&lt;/p&gt;
&lt;p&gt;The agent task stream accepts inbound `TaskResult` messages after authenticating agent metadata:&lt;/p&gt;
&lt;p&gt;- `service/rpc/auth.go:23-60` validates `client_secret` and `client_uuid`.
- `service/rpc/auth.go:63-75` registers an unknown valid UUID as a server for the authenticated secret owner.
- `service/rpc/nezha.go:40-48` authenticates the `RequestTask` stream and binds it to `clientID`.
- `service/rpc/nezha.go:50-56` receives agent-controlled `TaskResult` messages.
- `proto/nezha.proto:60-65` defines attacker-controlled `TaskResult.id`, `type`, `delay`, `data`, and `successful`.&lt;/p&gt;
&lt;p&gt;For service-monitor task types, the result is dispatched directly to the service sentinel using the authenticated server ID as reporter:&lt;/p&gt;
&lt;p&gt;- `service/rpc/nez…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-4g6j-g789-rghm</guid>
    </item>
  </channel>
</rss>
