Summary
H3C NX15 contains a command injection vulnerability in the Add function of the /api/esps endpoint. If an attacker can reach this endpoint and control the esps.filter.url argument, crafted input may be interpreted as an operating-system command.
Affected context
The vulnerability occurs in H3C NX15 V100R017 when the /api/esps API processes the esps.filter.url argument within the Add function. Risk depends on the endpoint being exposed to an attacker and on application logic passing the supplied value into a command or command interpreter without adequate separation from executable syntax.
Exploit preconditions
- Attack surface: The remotely accessible
/api/espsAPI endpoint - Required access: Network reachability and any access permitted by the endpoint's authentication and authorization controls
- Trigger point: Processing of the
esps.filter.urlargument by the Add function - Why exploitation is possible: User-controlled input may reach an operating-system command execution path without sufficient neutralization or argument separation
Why this happens
The underlying flaw is an unsafe boundary between externally supplied data and operating-system command construction. When a URL or filter value is concatenated into a shell command, or otherwise interpreted as command syntax, special characters can alter the intended operation. This behavior maps primarily to CWE-77: Improper Neutralization of Special Elements used in a Command, with CWE-74 describing the broader failure to properly neutralize special elements before passing data to a downstream interpreter.
Potential impact
- An attacker may execute commands with the privileges of the affected service
- The device could be compromised or disrupted
- Configuration, operational, or sensitive data may be exposed
- The attacker could establish persistence or use the device as a foothold for further network activity
- Availability and integrity of managed network services could be affected
General mitigation guidance
Mitigation generally focuses on removing shell interpretation from request-processing paths and reducing trust in externally supplied values.
Common defensive patterns include:
- Prefer structured APIs and direct process invocation with fixed argument boundaries instead of shell commands
- Apply strict allowlist validation for URL schemes, hosts, ports, paths, and supported filter formats
- Reject unexpected characters, encodings, delimiters, and control sequences before processing
- Avoid constructing commands through string concatenation or interpolation
- Enforce authentication, authorization, and network segmentation for administrative APIs
- Run services with the minimum operating-system and device privileges required
- Use read-only or restricted execution contexts where practical
How teams detect issues like this
Organizations commonly identify command injection risks through:
- Static analysis rules for shell invocation, command construction, and string interpolation involving request parameters
- Code review checks for subprocess, system, or interpreter calls receiving values derived from HTTP input
- Tests that verify strict input allowlists and confirm that metacharacters are treated as data rather than syntax
- API gateway or web-application firewall policies restricting access to administrative endpoints and recording anomalous parameter values
- Runtime monitoring for unexpected child processes, unusual command interpreters, or abnormal process behavior from the network service
Automated security review tools may help surface risky data flows, but findings should be confirmed against the actual execution path.
