[Security bug] LPE - OpenEDR <= v2.5.1.0

[ikerl]

Two critical vulnerabilities have been identified in OpenEDR that allow for local privilege escalation. These flaws, when combined, enable any non-privileged user to escalate their privileges to local administrator on a system where OpenEDR is installed. A functional exploit has been developed that takes advantage of these vulnerabilities, demonstrating how attackers can bypass OpenEDR’s security mechanisms to gain elevated access. Below are the details of each vulnerability:

• Bypassing Self-Defense by Renaming the Executable

The self-defense mechanism in OpenEDR can be easily bypassed by renaming a malicious executable to match one of the trusted process names, such as csrss.exe, edrsvc.exe, or edrcon.exe. This allows an attacker to interact with the OpenEDR driver’s privileged functionalities, including configuration modifications and process monitoring, without triggering any security measures.

An attacker can execute a malicious process with elevated privileges simply by renaming their executable to one of the trusted names, effectively bypassing the self-defense mechanism and gaining access to sensitive EDR features.

• Privilege Escalation via Malicious DLL Injection Path Modification

The vulnerability allows privilege escalation by modifying the injected DLL path used by OpenEDR to inject monitoring DLLs into processes. By crafting a custom IOCTL request, an attacker can redirect the DLL path to a location writable by non-privileged users. With this, they can inject a malicious DLL into high-privilege processes, resulting in privilege escalation.

An attacker can modify the DLL path to point to a location they control (e.g., c:\windows\system3../../st/st.dll -> c:\st\st.dll), allowing their malicious DLL to be injected into privileged processes (e.g., Windows Defender), leading to privilege escalation and potential system compromise.

Details
More details: https://scavengersecurity.com/posts/edr-as-rootkit-2/

Affected versions
All versions of OpenEDR as of December 13, 2025 are affected by these vulnerabilities.

[Cyber-idea12]

Hello,
Thank you for opening this issue and for documenting these vulnerabilities with such clarity. Unfortunately, what is described here goes far beyond a typical security bug and directly impacts the core trust model of OpenEDR as a kernel‑mode security product.
When an EDR solution:
can be abused via BYOVD,
effectively functions as a signed vulnerable driver,
allows self‑defense bypass through simple executable renaming,
and enables privilege escalation to SYSTEM,
this is no longer a partial weakness but a clear EDR-as-an-attack-surface scenario.
What is particularly concerning is not only the severity of these vulnerabilities, but the lack of response so far. Given that this issue describes a critical local privilege escalation and kernel‑level abuse, the absence of any acknowledgment or mitigation guidance from the maintainers is alarming. For a security product operating in ring 0, delayed or silent handling of such issues significantly increases risk for anyone deploying it in production.
Beyond the vulnerabilities themselves, there are broader warning signs:
slow and fragmented issue responses,
irregular update cycles,
previously broken documentation links and missing resources,
and no clear public roadmap for addressing kernel‑level security flaws.
OpenEDR is technically promising, but in its current state it appears to be losing active maintenance and priority, likely in favor of commercial offerings. This puts users in a dangerous position, as they continue to trust a component that runs with the highest possible privileges.
This comment is not meant to diminish the work done on the project, but to raise a serious concern: a security solution without timely maintenance and transparent handling of critical vulnerabilities can be more dangerous than having no security solution at all.
At minimum, users deserve a clear acknowledgment of the issue, a status update, or a warning about the current security posture. Silence is not an acceptable response in this context.