<?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>Fri, 02 Oct 2026 05:40:49 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-47120</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-47120</link>
      <description>&lt;p&gt;Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&amp;amp;M tool. From version 1.4.0 to before version 2.0.8, a RoleMember can fire other users&amp;#39; cron tasks via AlertRule.FailTriggerTasks (no ownership check). This issue has been patched in version 2.0.8.&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 1.4.0 to before version 2.0.8, a RoleMember can fire other users&amp;#39; cron tasks via AlertRule.FailTriggerTasks (no ownership check). This issue has been patched in version 2.0.8.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-47120</guid>
    </item>
    <item>
      <title>GHSA-rxf6-wjh4-jfj6 — Nezha Monitoring: RoleMember can fire other users' cron tasks via AlertRule.FailTriggerTasks (no ownership check)</title>
      <link>https://db.gcve.eu/vuln/ghsa-rxf6-wjh4-jfj6</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;`createAlertRule` and `createService` (and their `update*` siblings) accept `FailTriggerTasks []uint64` and `RecoverTriggerTasks []uint64` — IDs of cron tasks to fire when the alert/service trips. The validation function only validates the alert&amp;#39;s `Rules.Ignore` server map; it never checks that the cron task IDs in `FailTriggerTasks` / `RecoverTriggerTasks` belong to the caller.&lt;/p&gt;
&lt;p&gt;When the alert fires, `singleton.CronShared.SendTriggerTasks(taskIDs, triggerServer)` (`service/singleton/crontask.go:113-127`) looks up those task IDs in the global cron registry and executes them via `CronTrigger`. For non-`AlertTrigger` cover modes, `CronTrigger` fans the command out to every server in `ServerShared.Range` with no ownership check.&lt;/p&gt;
&lt;p&gt;Net effect: a `RoleMember` can attach their alert rule (or service monitor) to **another user&amp;#39;s** cron task ID — including admin&amp;#39;s crons. When the alert trips, the admin&amp;#39;s cron command runs across every server (or every server in its allow/deny list).&lt;/p&gt;
&lt;p&gt;This is the same fanout/auth-bypass class as `NEZHA-002` (cron creation), but reachable by a different code path: even if `/cron` writes are restricted to admin, this `/alert-rule` and `/service` writes are member-reachable and let a member invoke pre-existing admin crons.&lt;/p&gt;
&lt;p&gt;## Affected versions&lt;/p&gt;
&lt;p&gt;Commit `50dc8e660326b9f22990898142c58b7a5312b42a` and earlier on `master`.&lt;/p&gt;
&lt;p&gt;## Reachability chain&lt;/p&gt;
&lt;p&gt;1. `POST /api/v1/alert-rule` (or `POST /api/v1/service`) is `commonHandler`-gated — any authenticated…&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;`createAlertRule` and `createService` (and their `update*` siblings) accept `FailTriggerTasks []uint64` and `RecoverTriggerTasks []uint64` — IDs of cron tasks to fire when the alert/service trips. The validation function only validates the alert&amp;#39;s `Rules.Ignore` server map; it never checks that the cron task IDs in `FailTriggerTasks` / `RecoverTriggerTasks` belong to the caller.&lt;/p&gt;
&lt;p&gt;When the alert fires, `singleton.CronShared.SendTriggerTasks(taskIDs, triggerServer)` (`service/singleton/crontask.go:113-127`) looks up those task IDs in the global cron registry and executes them via `CronTrigger`. For non-`AlertTrigger` cover modes, `CronTrigger` fans the command out to every server in `ServerShared.Range` with no ownership check.&lt;/p&gt;
&lt;p&gt;Net effect: a `RoleMember` can attach their alert rule (or service monitor) to **another user&amp;#39;s** cron task ID — including admin&amp;#39;s crons. When the alert trips, the admin&amp;#39;s cron command runs across every server (or every server in its allow/deny list).&lt;/p&gt;
&lt;p&gt;This is the same fanout/auth-bypass class as `NEZHA-002` (cron creation), but reachable by a different code path: even if `/cron` writes are restricted to admin, this `/alert-rule` and `/service` writes are member-reachable and let a member invoke pre-existing admin crons.&lt;/p&gt;
&lt;p&gt;## Affected versions&lt;/p&gt;
&lt;p&gt;Commit `50dc8e660326b9f22990898142c58b7a5312b42a` and earlier on `master`.&lt;/p&gt;
&lt;p&gt;## Reachability chain&lt;/p&gt;
&lt;p&gt;1. `POST /api/v1/alert-rule` (or `POST /api/v1/service`) is `commonHandler`-gated — any authenticated…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-rxf6-wjh4-jfj6</guid>
    </item>
  </channel>
</rss>
