CVE-2025-69783
Bypass of OpenEDR 2.5.1.0 Self-Defense Enables Privilege Escalation
Publication date: 2026-03-16
Last updated on: 2026-03-20
Assigner: MITRE
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| xcitium | openedr | 2.5.1.0 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-250 | The product performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': "CVE-2025-69783 is a local vulnerability in OpenEDR version 2.5.1.0 where an attacker can bypass the software's self-defense mechanism by renaming a malicious executable to a trusted process name such as csrss.exe, edrsvc.exe, or edrcon.exe."}, {'type': 'paragraph', 'content': 'This renaming tricks OpenEDR into treating the malicious process as trusted, allowing unauthorized interaction with the OpenEDR kernel driver. This grants access to privileged functions like configuration changes, process monitoring, and IOCTL communication that should be restricted.'}, {'type': 'paragraph', 'content': "Although this vulnerability alone does not directly grant SYSTEM privileges, it breaks OpenEDR's trust model and enables further exploitation, including modifying the DLL injection path to inject malicious code into privileged processes, ultimately leading to full local privilege escalation."}] [1, 2]
How can this vulnerability impact me? :
[{'type': 'paragraph', 'content': "This vulnerability allows a local attacker to bypass OpenEDR's protections and gain unauthorized access to privileged kernel driver functionalities."}, {'type': 'list_item', 'content': 'Attackers can start or stop monitoring processes without proper privilege validation.'}, {'type': 'list_item', 'content': "They can modify OpenEDR's internal configuration parameters at runtime, including disabling self-protection."}, {'type': 'list_item', 'content': 'Attackers can manipulate the DLL injection path to inject malicious DLLs into high-privilege processes, leading to privilege escalation.'}, {'type': 'paragraph', 'content': 'Ultimately, this can result in full local privilege escalation, turning OpenEDR into a rootkit-like tool that attackers can abuse for persistence, unauthorized code execution, and potentially full system compromise.'}] [1, 2]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
Detection of this vulnerability involves monitoring for processes that have been renamed to trusted OpenEDR process names such as csrss.exe, edrsvc.exe, or edrcon.exe but are not legitimate system processes. Since the vulnerability allows a malicious executable to bypass self-defense by spoofing these names, checking running processes for unexpected instances of these names can help identify exploitation attempts.
Additionally, monitoring IOCTL communication with the OpenEDR kernel driver for unusual or unauthorized commands, especially those that start or stop monitoring or modify configuration parameters, can indicate exploitation.
Suggested commands to detect suspicious activity include:
- On Windows, use PowerShell or command prompt to list processes with trusted names and verify their paths and signatures, for example: `Get-Process csrss, edrsvc, edrcon | Select-Object Id, Path`
- Use tools like Sysinternals Process Explorer to inspect process properties and verify if the executable path matches expected system locations.
- Monitor kernel driver IOCTL calls using tools such as Sysinternals Process Monitor or specialized kernel debugging tools to detect unauthorized IOCTL commands.
Because the vulnerability involves bypassing trusted process checks by renaming executables, verifying the integrity and origin of these processes is critical.
What immediate steps should I take to mitigate this vulnerability?
[{'type': 'paragraph', 'content': "Immediate mitigation steps include restricting access to the OpenEDR kernel driver's IOCTL interface to only genuinely trusted processes with robust verification mechanisms, preventing unauthorized processes from interacting with privileged functionality."}, {'type': 'paragraph', 'content': 'Strengthen validation of the injected DLL path to prevent path traversal attacks and unauthorized DLL injection by ensuring only DLLs from protected system directories (e.g., WINDOWS\\SYSTEM32 or WINDOWS\\SYSWOW64) are accepted.'}, {'type': 'paragraph', 'content': 'Implement integrity checks on injected DLLs to prevent loading of malicious code.'}, {'type': 'paragraph', 'content': 'In the short term, monitor and audit processes named csrss.exe, edrsvc.exe, and edrcon.exe to detect suspicious renaming or unauthorized processes.'}, {'type': 'paragraph', 'content': 'Apply any available patches or updates from OpenEDR that address this vulnerability as soon as they are released.'}] [1, 2]