CVE-2025-13176: Local Privilege Escalation in ESET Inspect EDR

[Khushal]

Content source

https://labs.infoguard.ch/advisories/cve-2025-13176_eset-inspect_edr_local-privilege-escalation/

Need a SYSTEM shell? Just ask your EDR!CVE-2025-13176: ESET Inspect Connector looks for an OpenSSL config in a user-writable path. It’s an easy LPE that loads your payload directly into the EDR process.

• Affected Product: ESET Inspect Connector for Windows (versions prior to 3.0.5765)
• Vulnerability Type: Local Privilege Escalation (LPE)
• Severity: High (CVSSv4.0 8.4)
• CVE: CVE-2025-13176
• Privileges Required: Low Privileged User
• Configuration Requirement: None/Default
• Fixed Version: ESET Inspect Connector 3.0.5765

Description​

A Local Privilege Escalation (LPE) vulnerability was identified in the ESET Inspect Connector for Windows, a component of ESET’s XDR solution. The vulnerability exists due to the ElConnector.exe process (running as SYSTEM) attempting to load an OpenSSL configuration file (openssl.cnf) from a non-existent path that can be created by a low-privileged user.

An attacker with local access can create the directory structure C:\src\vcpkg\packages\openssl_x64-windows-static\ and place a malicious openssl.cnf file along with a payload DLL. When the ElConnector service restarts or initializes OpenSSL, it loads the malicious configuration, which in turn loads the attacker’s DLL into the SYSTEM process, achieving privilege escalation.

Additionally, because the code execution occurs within the context of the EDR agent itself, this technique can be used to bypass security protections and telemetry, or maintain persistence with high privileges while appearing legitimate.

CVE-2025-13176: Local Privilege Escalation in ESET Inspect EDR - InfoGuard Labs

Local Privilege Escalation (LPE) in ESET Inspect Connector for Windows via OpenSSL configuration (openssl.cnf).

labs.infoguard.ch

 

[Bot]

Based on what you quoted, the issue is a classic “user-writable path + SYSTEM service” Local Privilege Escalation: a SYSTEM-run component (ElConnector.exe) allegedly attempts to load an OpenSSL config from a path a standard user can create, and OpenSSL config directives can be abused to load a DLL into that SYSTEM process.

I can’t independently verify the CVE details from here (I’m only seeing the forum quote, not the full vendor advisory / ESET bulletin), but the remediation and hardening steps are straightforward.

What this means (if the advisory is accurate)

• A low-privileged local user could potentially get code execution as SYSTEM by planting an OpenSSL config + DLL in the searched path.
• Because execution happens inside an EDR/XDR component, it may reduce visibility or complicate detection compared to “normal” LPEs.

Recommended action (best option)

• Update ESET Inspect Connector for Windows to 3.0.5765 or newer (the quoted “fixed version”).
• Treat this as urgent on endpoints where untrusted local users can run code (shared workstations, VDI, RDS, labs).

Temporary mitigations (if you cannot patch immediately)

• Pre-create and lock down the referenced path so standard users cannot create/modify it (at minimum C:\src\ and below), with ACLs restricted to Administrators and SYSTEM.
• Monitor for creation of the directory tree and for any “openssl.cnf” appearing under it; that should be rare/abnormal on most fleets.
• If your environment supports it, use application control (WDAC/AppLocker) to prevent unsigned/unapproved DLLs from being loaded from user-writable locations. This won’t “fix” the bug, but can reduce exploitability.

Detection / triage ideas (practical checks)

• Look for unexpected existence of: C:\src\vcpkg\packages\openssl_x64-windows-static\ (and especially openssl.cnf).
• Check for unusual restarts of the ESET Inspect Connector / ElConnector service around suspicious directory creation.
• If you have Sysmon/EDR telemetry: review DLL load events for ElConnector.exe, focusing on non-standard paths and recently written DLLs.

Bottom line
If you run ESET Inspect Connector on Windows, the safest move is to patch to 3.0.5765+ promptly, and (until then) lock down the referenced path and monitor for its creation to reduce LPE risk on endpoints.