<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Nezha — CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/vendors/nezha/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Sat, 23 May 2026 00:19:38 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/vendors/nezha/feed.xml" rel="self" type="application/rss+xml"/><item><title>Nezha Monitoring Cross-Tenant RCE via Cron Task Injection</title><link>https://feed.craftedsignal.io/briefs/2026-05-nezha-rce/</link><pubDate>Sat, 23 May 2026 00:19:38 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-05-nezha-rce/</guid><description>A RoleMember in Nezha monitoring dashboard can achieve cross-tenant remote code execution by injecting arbitrary commands into cron tasks due to insufficient authorization checks, impacting all monitored hosts in the deployment.</description><content:encoded><![CDATA[<p>The Nezha monitoring dashboard is vulnerable to a cross-tenant RCE. A <code>RoleMember</code> (Role==1), even one self-registered via OAuth2, can exploit insufficient authorization checks in the cron task creation process (<code>POST /api/v1/cron</code> and <code>PATCH /api/v1/cron/:id</code>). The vulnerability stems from the cron routes being handled by <code>commonHandler</code> instead of <code>adminHandler</code>, and a vacuous-true bypass in the permission check for cron creation. By creating a scheduled cron task with <code>Cover=CronCoverAll, Servers=[]</code> and an arbitrary <code>Command</code>, the attacker can execute commands on every server in the global <code>ServerShared</code> map, which includes servers belonging to other tenants. This allows any <code>RoleMember</code> to gain pre-validated RCE on every Nezha-monitored host in the deployment. Affected versions include commit <code>50dc8e660326b9f22990898142c58b7a5312b42a</code> and earlier on the <code>master</code> branch.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>Attacker gains <code>RoleMember</code> access to the Nezha dashboard, either through admin-granted credentials or self-registration via OAuth2 if enabled.</li>
<li>Attacker obtains a JWT token by authenticating against the <code>/api/v1/login</code> endpoint using their <code>RoleMember</code> credentials.</li>
<li>Attacker creates a webhook notification via <code>POST /api/v1/notification</code> pointing to an attacker-controlled server (e.g., <code>https://attacker.example.com/exfil</code>).</li>
<li>Attacker creates a notification group via <code>POST /api/v1/notification-group</code> and associates the newly created webhook notification with this group.</li>
<li>Attacker crafts a malicious cron task payload using <code>POST /api/v1/cron</code> with <code>servers: []</code>, <code>cover: 1</code>, <code>push_successful: true</code>, and an arbitrary command (e.g., <code>id; hostname; cat /etc/shadow</code>) to be executed on all monitored servers. The <code>notification_group_id</code> field is set to the ID of the attacker&rsquo;s notification group.</li>
<li>The cron task is scheduled and, upon execution, the crafted command is sent to all monitored Nezha agents.</li>
<li>Each agent executes the command and sends the output back to the Nezha dashboard.</li>
<li>The Nezha dashboard, due to the <code>push_successful: true</code> setting, pushes the command output to the attacker-controlled webhook, allowing the attacker to collect sensitive information from all monitored hosts.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation allows any <code>RoleMember</code> to achieve cross-tenant RCE on every host monitored by the Nezha dashboard. This can lead to full compromise of all monitored systems, including data exfiltration, privilege escalation, and disruption of services. The vulnerability affects all deployments where <code>RoleMember</code> accounts are enabled, including those with OAuth2 self-registration. The impact is especially severe as the Nezha agent typically runs as root.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Immediately switch <code>/cron</code> write operations to <code>adminHandler</code> to restrict cron task creation and modification to administrators, mitigating unauthorized command injection (reference: <code>cmd/dashboard/controller/controller.go:131-135</code>).</li>
<li>Implement a per-server permission gate in the <code>CronTrigger</code> function to ensure that cron tasks are only executed on servers owned by the user or an administrator. This adds an additional layer of security (reference: <code>service/singleton/crontask.go:133-181</code>).</li>
<li>Reject cron task creation with empty <code>Servers</code> lists when <code>Cover=CronCoverAll</code> to prevent unrestricted command execution across all hosts (reference: <code>cmd/dashboard/controller/cron.go:45-85</code>).</li>
</ul>
]]></content:encoded><category domain="severity">critical</category><category domain="type">advisory</category><category>rce</category><category>privilege-escalation</category><category>cron</category><category>authorization</category><category>nezha</category></item></channel></rss>