Yes. CISA added CVE-2020-8655 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. EyesOfNetwork contains an improper privilege management vulnerability that may allow a user to run commands as root via a crafted Nmap Scripting Engine (NSE) script to nmap7.
What “exploited in the wild” means for CVE-2020-8655
CISA’s KEV listing is the practical signal that matters here: it reflects confirmed active exploitation, not just a theoretical flaw. For EyesOfNetwork, the issue is an improper privilege management weakness that can let a user run commands as root through a crafted Nmap Scripting Engine script, so the core question is whether exposed systems are still reachable and operationally vulnerable.
For practitioners, the immediate task is exposure confirmation. Determine whether EyesOfNetwork is deployed anywhere you manage, whether it is internet-facing or reachable from user-accessible networks, and whether any workflow allows untrusted or semi-trusted users to submit or influence NSE scripts or similar command paths. If the answer is yes, treat it as an active-risk condition even before you confirm whether abuse has already occurred.
When a vulnerability reaches KEV status, patching or mitigation is no longer a routine backlog item. Use the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog for authoritative remediation details, then verify whether the exposed component is an administrative tool, a monitoring platform, or a management plane that may have broader reach than its label suggests.
Why privilege management flaws are especially dangerous in monitoring tools
An improper privilege management bug is not just a local software defect. In a system that can execute commands as root, the flaw can become a privilege escalation path, a persistence mechanism, or a fast route to full host compromise. That makes the issue materially different from a low-impact bug that only affects a single function or non-sensitive data path.
This is also why exploitation tends to matter operationally, not just technically. If the vulnerable platform already has access to logs, network devices, credentials, or configuration data, root execution can expand into lateral movement or follow-on access far beyond the original host. For broader context on active exploitation triage, the Zero-Day and Exploited Vulnerabilities Guide is useful when you need to turn KEV status into a response sequence.
The control lesson is simple: any management product that can execute privileged commands deserves a higher trust threshold than ordinary application software. If command execution is part of normal operation, the boundary between intended administration and attacker abuse must be tightly constrained, logged, and reviewed.
What to do if you cannot patch immediately
If patching must wait, reduce exposure rather than assuming compensating controls will fully contain the issue. Restrict network reachability to the smallest possible admin audience, remove unnecessary script or command execution paths, and monitor for suspicious use of the vulnerable function. If the platform is in a sensitive segment, isolation can be more valuable than broad detective controls that trigger only after a compromise.
Because the flaw allows root-level command execution, check for signs of earlier abuse before and after mitigation. Review authentication logs, command histories, scheduled jobs, unexpected script uploads or modifications, new accounts, unusual service restarts, and any change to config files that the management tool can touch. If the system had privileged credentials or secrets stored locally, assume they may have been exposed and rotate them where they could enable further access.
In practice, the best source for deeper operational response is the Vulnerability Management Guide, because KEV-class issues are about prioritisation, verification, and proof of remediation, not just ticket creation. The response should end with evidence, not with a claim that a fix was applied.
Risk and Threat Considerations
Once a flaw can turn a crafted input into root execution, the main risk is complete host compromise and whatever that host can reach next. For a management product, that often means the attacker does not need a second exploit path to become operationally dangerous.
Failure mechanism: A crafted NSE script can trigger privileged command execution through an authorization boundary that was expected to prevent ordinary users from running root-level actions. If the product is reachable by an attacker or abused by a legitimate but compromised account, the control failure becomes an escalation path.
Impact: The likely consequence is administrative takeover of the EyesOfNetwork host, followed by credential exposure, configuration tampering, persistence, or pivoting into adjacent systems that trust the platform or its administrators.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Root command execution shows why limiting privilege is central to this flaw. |
| IA-5 — Authenticator Management | If the platform exposure may reveal credentials, secret lifecycle control becomes relevant. | |
| Recommendation — Restrict privileged execution paths to the minimum access required. Rotate exposed credentials and secrets after confirming potential abuse. | ||
| CIS Controls v8 | CIS-5 — Account Management | Exploitation can hinge on excessive or lingering administrative access. |
| Recommendation — Review and remove unnecessary privileged accounts and access paths. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset Vulnerability Identification | KEV status requires identifying where the vulnerable asset exists and how exposed it is. |
| PR.AA-05 — Identity Management, Authentication, and Access Control | The issue is fundamentally about access being elevated beyond intended privilege. | |
| Recommendation — Identify all affected instances and prioritize them as actively exploited. Enforce access controls so users cannot reach root-level actions through normal workflows. | ||
Practitioner Guidance
What to verify: Confirm whether any EyesOfNetwork instance is still deployed, whether it is externally reachable, and whether privileged script execution is exposed to more users than intended. Treat any ambiguity about access scope as a finding, not as reassurance.
Decision rule: If the system can authenticate users and then let them influence privileged execution, prioritize containment and credential review alongside patching. If it is isolated but still operational, still verify whether it was used as a trust anchor for other administrative functions.
Practitioner takeaway: For KEV-listed privilege escalation issues, the meaningful question is not whether exploitation is possible in theory, but whether the affected platform can still be reached, abused, and trusted in ways that turn one root command into a broader compromise.
Related resources from NHI Mgmt Group
- CVE-2020-8655 (EyesOfNetwork Improper Privilege Management)
- CVE-2020-1938 (Apache Tomcat Improper Privilege Management)
- CVE-2020-0787 (Microsoft Windows Background Intelligent Transfer Service (BITS) Improper Privilege Management)
- Is CVE-2026-6973 (Ivanti Endpoint Manager Mobile (EPMM) Improper Input Validation) being exploited in the wild?