Introduction: the official list it never made

In November 2021, the U.S. government opened a special catalog: every vulnerability “proven to be used in real attacks” would be recorded there, and federal agencies would be ordered to patch on a deadline. It’s called CISA KEV — the Known Exploited Vulnerabilities catalog. (For the terminology — what CVE/KEV actually mean and where they come from, see this site’s explainer.) As of the August 31, 2026 release, KEV holds 1,687 entries, 352 of them flagged as used by ransomware gangs.

Not one of them belongs to Nezha Monitoring (哪吒监控).

Not because Nezha is safe. Because the mass takeover that pushed it into the spotlight in January 2025 still has no official CVE to this day — and KEV is an evidence-gated list: no identifier, no entry. That fact alone is worth writing down: how an open-source server monitoring panel lets an attacker go from “able to see every server” to “able to control every server”, and how that same “panel fall = everything under it falls” logic has repeated itself across every other domain in history.

1. January 2025: a mass compromise with no CVE number

Nezha Monitoring is one of the most widely used open-source monitoring setups in the Chinese-speaking world: one dashboard, plus an agent on every server. Agents report status back to the panel; the panel displays it, alerts on it, and can push scheduled tasks. VPS resellers, datacenter admins and self-hosters love it — install one, and suddenly you can “see” dozens or hundreds of machines at once.

In late January 2025, bad news spread fast through the Chinese VPS community: a batch of internet-exposed Nezha panels had been seized with the same technique. Once inside a panel, the attackers pushed malicious scheduled tasks to every agent under it, planting crypto miners on machines they had never logged into directly. The community buzzed loudly — yet the official paper trail for this incident is strikingly thin: no CVE, no vendor advisory, no verifiable attribution report. What is traceable is the full timeline around it, spanning a year and a half:

• Jan 29, 2025: Nezha merged PR #971, adding forced authentication to “visitor routes” — the month’s only public hardening change on the auth front, a side hint that the community was busy closing unauthenticated-access doors. The Chinese botnet reports that month (e.g., QiAnXin XLab’s January briefs) were about Gayfemboy, AIRASHI and other industrial-router families — nothing to do with Nezha; CNCERT/CNVD had no advisory either.
• From August 2025: on 2025-10-08, Huntress disclosed a campaign it named “Crown Prince”: from August 2025 the attackers compromised 100+ servers (Taiwan worst hit at 22). The chain ran exposed phpMyAdmin → log poisoning → China Chopper/AntSword implants → a Nezha agent as persistence → the Ghost RAT trojan. Note the direction: Nezha was not a drowning victim here — the attackers deliberately conscripted it as a remote-control channel. iThome covered it with a security-daily roundup on 2025-10-13. In December 2025, Antiy, Ontinue and others flagged Nezha being abused as a RAT component — another entry in the “monitoring tool weaponized” file.
• From May–June 2026: GitHub ran a concentrated security audit of Nezha and rolled out 15 CVEs; in June 2026 the pre-auth path traversal (CVE-2026-53519, below) went wild — attackers bulk-scanned exposed panels (default port 8008), read the keys, and planted miners plus DDoS trojans; cloud providers such as 雨云 and 物语云 published emergency advisories, and a victim’s end-to-end retrospective on NodeSeek (around 2026-06-20) documented the full intrusion-to-cleanup process.

Three things about this incident are worth revisiting now:

First, the technique is structurally identical to what the official audit later convicted — but causality still hasn’t closed. GitHub’s concentrated 2026 audit produced the heaviest official verdict: a kill chain of “low-privilege user → malicious scheduled task covering all servers → gRPC fan-out to every agent → execution as root” — exactly the “take the panel, take every machine” story circulating in January 2025. But structural identity is not causal identity: that flaw (CVE-2026-46716) affects versions from 1.4.0 upward, and Nezha was already deep in its 1.x era at the time — the 0.17 branch ended with v0.17.10 on 2024-07-14, v1.0.0 shipped 2024-11-28, and the January 2025 mainline was v1.5.x. The version windows do overlap. That only proves the flaw could have existed then — not that it was the door the attackers used. No public information ties the January 2025 attacks to the cron privilege-escalation path, and the advisory claims no in-the-wild exploitation for that window; the contemporaneous community descriptions match an “exposure / unauthenticated access” profile far better, pointing the same direction as that month’s PR #971 hardening. Convicting the 2025 incident with the 2026 CVEs gets the arrow of causation backwards.

Second, the incident left no official paper trail — and barely a first-hand record. As of August 31, 2026, there is no Nezha in KEV; the earliest Nezha CVEs only arrived with the May 2026 audit. A genuinely complete intrusion-to-cleanup retrospective didn’t appear in the community until after the June 2026 wave — written by a later batch of victims. An incident this widely discussed, hitting this many VPSes, is nearly invisible in the official archive — exactly the panel-class “recording gap” Section 4 explores.

Third, the panel-as-master-key structure is the root cause, not the malware. Crypto mining was just this round’s payload. Whoever holds a panel session simultaneously holds: the full inventory of monitored servers, a connection channel to each, and a “broadcast command execution” capability. Data, privileges, persistence — all intersect at this single point.

2. Turning the panel into an arsenal: two officially convicted flaws from 2026

Between June and August 2026, GitHub Security Advisories published a run of 15 CVEs for the Nezha project. Two of them spell out the “panel compromise” mechanics most clearly:

The first: CVE-2026-46716 (GHSA-99gv-2m7h-3hh9, CVSS 9.9). The authentication “gate” on the scheduled-task API was installed in the wrong place — write operations that only admins should reach (create/modify/manually trigger/bulk-delete tasks) were routed through a generic handler that any authenticated user could pass. And the per-server permission check on task creation had an empty-loop bug: when the task’s server list was empty (meaning “all servers”), the check loop executed zero times and returned “authorized” directly. Result: a freshly registered, rock-bottom-privilege user could submit a scheduled task that applies to every server. The panel’s cron scheduler, with no ownership gate, takes that task, walks the global server table, and fans the command out to every agent over the gRPC task stream — executed with the agent process’s identity, which on a standard systemd install is root. The end-to-end proof of concept attached to the official advisory showed roughly one second per agent to receive execution output; output could be exfiltrated through an attacker-created webhook notification group; it could even reach cloud IAM credentials via the instance metadata service (169.254.169.254). Affected: >=1.4.0 and <2.0.8; version 2.0.8 (released 2026-05-17) added admin gating in both scheduling and ownership (the v1 mainline was patched the same day); NVD recorded the CVE on 2026-06-12.

The second: CVE-2026-59155 (GHSA-ww5p-j6cj-6mqq, CVSS 5.5). The list endpoints for DDNS and notification configs returned the entire config object with zero field stripping — including Cloudflare API tokens, Tencent Cloud SecretKeys, and the Slack/Discord/Telegram bot tokens and Authorization headers habitually embedded in notification URLs. Any logged-in user who read the list walked away with every third-party plaintext credential stored in the panel, able to tamper with DNS records or impersonate notification bots. The endpoint had carried this flaw since its introduction in October 2024; 2.2.5 (2026-06-20) nulled out the sensitive fields one by one.

One flaw grants execution rights over every machine; the other grants read rights over every third-party credential. Together they are the full blast radius of a fallen panel. The same audit rolled out 13 more advisories, including: a pre-auth path traversal — crafting a path like /dashboard../data/config.yaml to bypass the prefix check and read the config.yaml sitting in the data directory, which holds the jwt_secret_key and other core keys (CVE-2026-53519, CVSS 9.1, fixed in 2.0.13, NVD recorded 2026-06-12); SSRF (CVE-2026-46717/47268); CSRF triggering scheduled tasks (CVE-2026-49396); and more.

Put the three sections together and the structural risk of panel-class products is clear: centralized authentication (one login point), a broadcast command channel (the control link from panel to every agent), task execution capability (scheduled tasks/script pushdown). Breach any one and it amplifies as “one privilege × N machines”.

3. The historical ledger of sibling panels: one machine managing many, and the entry point is always what breaks

Nezha is neither the first nor the last. Line up the historical records of mainstream panel/monitoring products — from the hosters’ favorites BT and 1Panel to the enterprise-grade Zabbix, JumpServer, Webmin and cPanel — and two things become visible immediately: what breaks is almost always the entry point (authentication, sessions, permission gates), and the official record for this category lags far behind the real battlefield.

(“KEV entry date” values verified one by one against the official CISA KEV feed snapshot of 2026-08-31; Zabbix/1Panel/BT details cross-checked from multiple sources — see Sources at the end.)

This table holds two counterintuitive conclusions:

First, the recording gap sits exactly on the Chinese-language mainstream. Nezha, BT, 1Panel, JumpServer — the four products with predominantly domestic user bases — have zero KEV entries, while the well-documented ones are Zabbix, Webmin and CyberPanel, which all have formal CVE numbers. The reason is unglamorous: KEV is an evidence-gated catalog that only admits vulnerabilities proven exploited in the wild and carrying an identifier. BT’s August-2020 mass incident, comparable in scale to many KEV entries, will never enter the list because it never got a number — same for the Nezha incident of January 2025. Not listed ≠ not hit — treating KEV as a complete ledger of “who got attacked” systematically underestimates the real-world risk of Chinese-market panels.

Second, the pathology of panel-class flaws is the mirror image of the global average. Worldwide, memory-safety defects top the KEV/CWE distribution; in the table above, the failure concentrates in authentication and authorization design: unauthenticated ports, default credentials, session forgery, gates installed on the wrong side of the door. For this product category, defense doesn’t hinge on the “wall” (memory safety) but the “door” (keeping the entry points closed) — which is why item one of the checklist in Section 6 is “never expose your panel to the public internet.”

4. The same logic, replaying in every other domain: a classification of major vulnerabilities

The “one entrance governing a fleet of systems” failure mode is hardly exclusive to panels. Cross-referencing the KEV catalog with the annual lists published by CISA/NSA/FBI and the Five Eyes partners (AA24-317a, the Top 15 routinely exploited vulnerabilities of 2023), a few domains recur constantly:

Network perimeter & VPN. The thickest thread in the 2023 Top 15: NetScaler’s CVE-2023-3519 / CVE-2023-4966 (the latter known as CitrixBleed — a buffer overflow leaking session tokens; patched 2023-10-10, into KEV 10-18, exploited by ransomware groups), Cisco IOS XE’s CVE-2023-20198/20273, FortiOS SSL VPN’s CVE-2023-27997. Going back further: CVE-2018-13379 (FortiOS SSL VPN path disclosure), CVE-2019-11510 (Pulse Connect Secure), CVE-2020-5902 (F5 BIG-IP), CVE-2024-3400 (PAN-OS), CVE-2024-21887 (Ivanti Connect Secure)… Gateways are the throat of all network traffic: take the gateway, walk straight into the intranet. That’s why they dominate year after year.

Email systems. Exchange is the disaster zone’s disaster zone: ProxyLogon (CVE-2021-26855), the ProxyShell trio (unauthenticated path confusion CVE-2021-34473 → Exchange-Admin impersonation CVE-2021-34523 → arbitrary file write CVE-2021-31207; chained, these equal unauthenticated RCE — Qualys walkthrough). Five years after release, gangs were still scanning for ProxyShell as recently as April 2026. Zimbra (16 KEV entries) and Roundcube (11) are in the same hall of pain.

File transfer & collaboration. MOVEit Transfer’s CVE-2023-34362 was the benchmark incident of 2023, touching tens of millions of people: one SQL injection for sysadmin privileges plus a deserialization for RCE, and the CL0P ransomware gang started exploiting before disclosure. CISA joint advisory. Same family: Barracuda ESG, Zoho ManageEngine, Confluence, ownCloud, PaperCut, TeamCity — file-transfer servers come pre-loaded with the “everyone else’s files are in here” amplification effect.

General-purpose components & foundations. Log4Shell (CVE-2021-44228) embedded itself in thousands of products worldwide, stayed a fixture of most-exploited lists into 2023, and VulnCheck counted 31 threat groups using it. EternalBlue/SMBv1 (CVE-2017-0144, the engine of WannaCry), BlueKeep, Netlogon (CVE-2020-1472), PrintNightmare. On the supply-chain side, SolarWinds Orion (CVE-2020-10148) is the template for converting the software-update channel into a compromise channel.

2025–2026: the new battlefield, same old faces. The densest wild exploitation of the last two years still concentrates on perimeter devices: in January 2025, Fortinet FortiOS auth-bypass (CVE-2024-55591, into KEV on the 14th, flagged ransomware-used) and Ivanti Connect Secure RCE (CVE-2025-0282, into KEV on the 8th, with about 1,700 devices reported compromised early on) were exploited almost simultaneously; Palo Alto PAN-OS auth-bypass CVE-2025-0108 followed into KEV on Feb 18; Apache Tomcat session deserialization CVE-2025-24813 entered KEV on Apr 1. The application-framework side was just as busy: Next.js middleware auth-bypass (CVE-2025-29927) saw bulk probing the week it was disclosed, and JetBrains TeamCity’s CVE-2025-63077 was targeted by multiple ransomware crews’ scanners — neither of those two has ever entered KEV. “Not in KEV” doesn’t stop a flaw becoming mass-attack ammunition; the boundary of the official catalog is exactly what this post keeps underlining.

The classification table:

(Every entry in this table, apart from the proxy-chain naming, was verified one by one against the official KEV feed.)

5. Which domain breaks most often: let the data speak

The hardest single conclusion first: exploit-based initial access is the fastest-growing entry route in every mainstream report’s methodology. The most striking change comes from Verizon’s DBIR 2026 (19th edition, published 2026-05-19, covering 2025 data): vulnerability exploitation accounted for 31% of initial access (up from 20%, +55%), overtaking credential abuse (13%) as the number-one entry route for the first time since the series began. The same report carries a pair of mirror-image numbers: the median time to fully remediate a known-exploited vulnerability stretched to 43 days (from 32), while the complete-remediation rate fell to just 26% (from 38%) — saying we care while dragging our feet. Mandiant M-Trends 2026 agrees: exploits were 32% of initial infection vectors, first place for a sixth consecutive year; initial-access brokers hand off access on underground markets in a median of just 22 seconds (over 8 hours in 2022), while median dwell time rebounded to 14 days from 11 — attacks are getting faster, dwell is getting longer. The identity side hasn’t let up either: Microsoft’s Digital Defense Report 2025 (built on 100+ trillion daily signals) recorded +32% identity attacks in H1 2025, over 97% of them mass password attacks. On the Chinese side, QiAnXin’s mid-2025 vulnerability threat landscape report counts 23,351 new vulnerabilities in H1 2025 (+14.0%), with high/critical severity at 43.5% and Chinese domestic software accounting for 9.3%, OA systems and network gear the prime targets.

Solid, officially sourced numbers:

• By vendor: of KEV’s 1,687 entries, Microsoft’s 386 (~23%) take the crown, followed by Cisco 96, Apple 94, Adobe 80, Google 72 — the top five sum to 728 (~43%).
• By product: Windows alone has 170 entries; Chromium V8 39, IE 36, Flash Player 33 — “what everyone installs” is the main battlefield.
• By domain (vendor-bucket aggregation, 2026-08-31 snapshot; see chart below): network & perimeter devices ≈277 (≈300 counting unclassified network vendors), OS & desktop foundations 673, middleware & dev frameworks 109, email ≈47 (bucket 30 + Microsoft Exchange product line 17), IT management & supply-chain tools 55.
• By weakness class: CISA’s Vulnerability Review FY2024-2025 (published 2026-08) classifies FY2024 KEV entries: memory safety 19.8%, injection 10.1%, improper input validation 8.1% as the top three; the most-exploited remain CWE-20 (improper input validation), CWE-22 (path traversal), CWE-78 (command injection) — classic weaknesses that are “long-standing and widely known”, in the report’s own words.
• The coexistence of zero-day framings: the Five Eyes annual list notes that most top-exploited vulnerabilities of 2023 started as zero-days (in 2022, under half did); Google TAG/Mandiant counted 97 in-the-wild zero-days in 2023 vs 62 in 2022. But the same CISA review stresses that most real intrusions are not zero-days — they’re opportunistic criminals scanning the internet for simple, known flaws.
• Status of the Five Eyes lists: the latest joint “Top Routinely Exploited Vulnerabilities” remains the 2023 edition (AA24-317a, published 2024-11-12); Top lists for the 2024 and 2025 data years have not been published. For the last two years, this post substitutes KEV yearly additions: 2025 added 245 entries, an all-time annual record; Jan-Aug 2026 already added 203 (monthly trend in chart 2 below).
• The precise utilization rate: of the vulnerabilities disclosed in 2025, about 884 were proven first-exploited in the wild (derived from KEV intake data, up ~15% from 768 in 2024) — about 1.8% of all CVEs newly disclosed that year. Out of tens of thousands of new flaws, the few that become battlefield ammunition are a minority — but that minority is where all the damage comes from. The reverse view is more striking: Mandiant counted 90 in-the-wild zero-days in 2025 (78 in 2024); Google’s threat-intel team’s review of 2024 zero-days showed the median “exposure day” of exploited flaws landed 7 days before the public PoC — most attacks started before details went public. And the fastest record Cloudflare measured: from PoC publication to scan-driven exploitation of TeamCity (CVE-2024-27198) in just 22 minutes.
• Evidence that old holes live long: as of February 2026, over 270,000 systems remained exposed to SMBGhost (CVE-2020-0796) — a six-year-old flaw.

Two charts (data from the official KEV feed’s 2026-08-31 snapshot, reproducible via the blog repo script):

6. Eight things you can actually do if you run your own VPS

1. Never expose the panel naked to the internet. BT, Nezha — management planes should only be reachable from trusted origins (fixed IPs / internal VPN / datacenter-to-datacenter links). The common thread of the Jan-2025 victims was a panel sitting directly on the public internet.
2. Patch the panel itself, and patch it faster than your business apps do. Fixes like 2.0.8 and 2.2.5 are management-plane-level flaws: patching a month late means the management plane ran naked for a month.
3. Isolate third-party credentials. Everything the panel stores (DDNS tokens, notification-bot tokens) leaks in one go; use least-privilege sub-accounts where possible and rotate after any incident (the lesson of CVE-2026-59155).
4. Put a second line of defense on high-risk actions: if scheduled tasks and bulk commands aren’t business-critical, disable registration, drop low-privilege roles, or at minimum audit/alert on task dispatch.
5. Don’t run the agent as root. Half the blast radius of CVE-2026-46716 comes from “the agent process is root”. Run it de-privileged and a fallen panel loses an order of magnitude of damage.
6. Subscribe to KEV updates and project security advisories. Watch the GHSA/security advisories for Nezha/BT-class management-plane products; when a wild-exploited flaw enters KEV, CISA gives federal agencies a deadline — individuals can use the same list as a patching-priority order.
7. Alert on unexpected server egress. A crypto miner’s first fingerprint is outbound connections to mining pools / abnormal CPU. A read-only anomaly detector next to the panel (outbound domains, CPU spikes) catches miners far faster than post-hoc forensics.
8. Back up, but check the egress path. The panel holds the exit for all your data; once panel trust is broken, your backups are inside the attacker’s field of view too. Keep cold backups with off-box verification, never within the panel’s reach.

7. Coda: the ops plane is the privilege plane

The selling point of a monitoring panel — one entrance to manage a hundred machines — is also its fatal flaw: the attacker only needs that one entrance. This isn’t Nezha’s problem; it’s the structural fate of the entire category. BT, JumpServer, Zabbix, and every future ops platform live under the same fate. The only difference is that some products get their ledger kept meticulously in KEV, while others suffer major incidents and don’t even get a number.

Three things to remember: don’t expose the panel to the public internet; patch the management plane ahead of business apps (2.0.8/2.2.5-class fixes first); treat every credential the panel holds as “leaks-all-at-once” and isolate accordingly.

Sources

1. Nezha official security advisories: GHSA-99gv-2m7h-3hh9 (CVE-2026-46716), GHSA-ww5p-j6cj-6mqq (CVE-2026-59155), GHSA-5c25-7vpj-9mqh (CVE-2026-53519)
2. NVD entries: CVE-2026-46716 / CVE-2026-59155 / CVE-2026-53519
3. CISA KEV catalog and JSON feed (catalogVersion 2026.08.31, 1,687 entries; all KEV numbers and charts in this post derive from it — the reproduction script lives in the blog repo at tools/gen_nezha_charts.py)
4. CISA/NSA/FBI & Five Eyes joint advisories: AA24-317a (2023 Top 15 routinely exploited) and the AA21-209a / AA22-117A / AA23-215A series
5. CISA Vulnerability Review, Fiscal Years 2024-2025 (2026-08)
6. Verizon DBIR 2026 (2026-05-19) and DBIR 2025 (2025-04)
7. Mandiant M-Trends 2026 (2026-03; dwell time and 22-second hand-off figures also cross-checked via Help Net Security)
8. Microsoft Digital Defense Report 2025 (2025-10-16)
9. QiAnXin mid-2025 vulnerability threat landscape report (2025-08)
10. Nezha incident timeline and disclosures: NodeSeek 2026-06 victim retrospective, Huntress’s 2025-10-08 disclosure (via The Hacker News), iThome coverage and iThome security daily (2025-10-13), Nezha PR #971 (forced auth on visitor routes, 2025-01-29); Antiy and Ontinue’s December 2025 reports on Nezha being abused as a RAT component
11. Adjacent panels: BT official announcements Aug-2020 pma incident and CVE-2025-12914 fix notes; Zabbix official security advisories; 1Panel CVE-2024-39907 see the vulhub reproduction environment; CVE-2025-54424 see the NVD entry
12. Historical case analyses: Rapid7 on MOVEit CVE-2023-34362, Qualys ProxyShell walkthrough, CISA guidance on CitrixBleed