CVE-2021-40493

What it actually does

Zoho ManageEngine OpManager versions before build 125437 contain an unauthenticated SQL injection vulnerability in the support diagnostics module. The vulnerable getDataCollectionFailureReason API accepts user-controlled input through the pollingObject parameter and fails to safely constrain it before using it in database queries. Because the CVSS vector indicates network access, low complexity, no privileges, and no user interaction, a remote attacker may be able to manipulate backend SQL statements to read, modify, or delete database data and potentially affect application availability depending on database permissions and deployment configuration.

Why it matters to the business

Successful exploitation can expose sensitive monitoring data, device inventory, credentials or secrets stored by the application, and operational metadata about network infrastructure. It can also allow tampering with monitoring records or disruption of the OpManager platform, reducing visibility into outages and security events. Although this vulnerability is not listed in CISA KEV and no exploit maturity was provided, the high CVSS score and elevated EPSS probability mean internet-exposed or broadly reachable OpManager instances should be treated as high priority for remediation.

How an attack unfolds

An attacker identifies a reachable ManageEngine OpManager instance and sends crafted HTTP requests to the support diagnostics API endpoint associated with getDataCollectionFailureReason. The attacker places SQL control syntax in the pollingObject parameter to alter the intended database query. They may first use error-based or boolean/time-based probes to confirm injection behavior, then enumerate database structure, extract sensitive records, or perform write operations if the database account permits it. In a worst-case scenario, the attacker uses the database access to obtain credentials, alter application state, impair monitoring functions, or pivot further into the managed network using information stored in OpManager.

How to fix it

Upgrade Zoho ManageEngine OpManager to build 125437 or later. If immediate upgrade is not possible, restrict access to the OpManager web interface and API to trusted administrative networks, place the service behind VPN or strong access controls, and block untrusted access to the support diagnostics API. Apply least-privilege permissions to the application database account where feasible, ensure backups are current, and monitor for suspicious requests targeting getDataCollectionFailureReason or the pollingObject parameter. Temporary network mitigations should not be considered a substitute for upgrading because the flaw is in server-side input handling.

How to confirm the fix worked

Confirm the installed OpManager build is 125437 or later using the product UI, version files, or vendor-supported inventory methods. Verify that the vulnerable endpoint is not reachable from untrusted networks. Review web access logs and application logs for requests to getDataCollectionFailureReason containing the pollingObject parameter, especially requests with SQL metacharacters, encoded payloads, UNION SELECT patterns, stacked-query separators, comments, or time-delay functions. If safe and authorized, use a non-destructive vulnerability scanner or vendor-recommended check to confirm the endpoint no longer accepts SQL injection probes.

Typical attack path

1. Discover a reachable Zoho ManageEngine OpManager service.
2. Identify the vulnerable support diagnostics API function getDataCollectionFailureReason.
3. Send test requests containing SQL metacharacters or boolean/time-based payloads in the pollingObject parameter.
4. Confirm injection through database errors, response differences, timing delays, or abnormal application behavior.
5. Enumerate database information and application tables accessible to the OpManager database user.
6. Extract sensitive operational data, credentials, configuration details, or monitored asset information.
7. Optionally modify or delete records, create operational disruption, or use recovered information for lateral movement.

How to detect it

To determine whether exploitation already occurred, examine HTTP access logs from OpManager, reverse proxies, load balancers, and WAFs for requests containing getDataCollectionFailureReason and pollingObject. Prioritize requests with SQL syntax, URL-encoded quotes, comments, UNION queries, stacked query separators, database error triggers, or time-delay functions. Review OpManager application logs for database exceptions, abnormal support diagnostics errors, or unusual failures occurring immediately after such requests. Review database audit logs, if available, for anomalous SELECT, UPDATE, DELETE, schema enumeration, or time-delay activity from the OpManager application account. Investigate any suspicious requests followed by spikes in database CPU, slow queries, application crashes, monitoring outages, unexpected configuration changes, or credential access. If exploitation is suspected, preserve web logs, application logs, database logs, memory/process state where feasible, and any WAF events before remediation actions overwrite evidence.

• getDataCollectionFailureReason
• pollingObject=
• pollingObject=%27
• pollingObject='
• pollingObject=%22
• pollingObject="
• UNION SELECT
• UNION%20SELECT
• information_schema
• pg_sleep(
• SLEEP(
• WAITFOR DELAY
• benchmark(
• --
• %2D%2D
• /*
• %2F%2A
• OR 1=1
• %20OR%201%3D1
• AND 1=1
• %20AND%201%3D1

What your security team should do

• Prioritize upgrading all ManageEngine OpManager deployments to build 125437 or later, especially systems exposed to the internet or shared administrative networks.
• Immediately restrict inbound access to OpManager management interfaces to trusted administrators, VPNs, or jump hosts only.
• Search historical web, reverse proxy, WAF, and application logs for exploitation attempts against getDataCollectionFailureReason and pollingObject.
• Review database logs for unusual queries, errors, enumeration activity, time-delay functions, or access to sensitive application tables around suspicious HTTP request times.
• Rotate credentials stored in or used by OpManager if exploitation is suspected or cannot be ruled out.
• Validate that OpManager’s database account uses the minimum required privileges and cannot perform unnecessary administrative operations.
• Ensure WAF or reverse-proxy rules flag SQL injection payloads targeting pollingObject, while treating this only as compensating control.
• Preserve relevant logs before upgrading or rebuilding systems if compromise is suspected.