CVE-2026-46716 is an authorization flaw in Nezha Monitoring affecting versions 1.4.0 through before 2.0.8. A user with the RoleMember role can create a scheduled cron task configured with global coverage semantics and an empty server list while supplying an arbitrary command. On each scheduler tick, the dashboard dispatches that command to every server tracked in the global shared server map, including servers belonging to other tenants or higher-privileged users. The agents on those servers execute the command and return the output through the application's notification mechanism to an attacker-controlled destination. The vulnerability is caused by insufficient authorization and tenant-isolation checks in cron task creation and execution, allowing a lower-privileged authenticated user to cause command execution across servers outside their authorization scope.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This repository is a small lab and detection project for CVE-2026-46716 in Nezha Monitoring. It is not just a scanner: it contains both a reproducible Docker-based environment and a PoC trigger script, plus a Nuclei template for version-based detection. The main exploit capability described is a cross-tenant RCE path where any authenticated low-privilege member can create a cron task via POST /api/v1/cron using servers:[] and cover:1. Because CheckPermission performs no ownership validation on an empty server list, the cron is accepted; on vulnerable versions, CronTrigger then dispatches the command to all connected agents without verifying ownership. The included PoC uses a harmless echo command, but the vulnerability supports arbitrary shell command execution. Repository structure: docker-compose.yaml launches two local Nezha instances, one vulnerable (ghcr.io/nezhahq/nezha:v1.14.14 on port 8008) and one patched (built from commit d7526351cf97 via Dockerfile.patched, exposed on port 8009). scripts/01-setup.sh builds/starts the lab, logs into the vulnerable instance, and creates a member user. scripts/03-trigger-cve.sh logs in as the member, submits the crafted cron request to both instances, checks version via admin-only GET /api/v1/setting, and deletes the test cron. scripts/99-teardown.sh removes containers and data. The nuclei/CVE-2026-46716.yaml template is the framework artifact: it performs POST /api/v1/login and GET /api/v1/setting, then matches vulnerable version ranges (1.4.x through 1.14.14). Because both vulnerable and patched versions reportedly return HTTP 200 for cron creation, the template is detection-only and relies on version fingerprinting rather than exploit behavior. Overall, the repository’s purpose is to document, reproduce, and detect CVE-2026-46716. The exploit path is web/network-based against Nezha’s REST API, while the Nuclei template itself is a read-only authenticated detector requiring admin credentials.
7 sources tracked across advisories and community write-ups. News coverage will land here when it surfaces.
No news coverage yet. Advisories and community discussion only.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.