Updated: August 29, 2025
Elastic has been directly engaging with the independent researcher. After evaluating additional information provided by the researcher, our original assessment still stands. To confirm we are responsibly assessing this report and providing an unbiased perspective, we are engaging a neutral third-party to review the finding. For users of Elastic Defend, no action is required.
On August 23rd, Elastic received additional data from the original researcher in the form of crash dumps and a proof of concept (PoC) involving an executable and a kernel driver. Since then, Elastic has been directly engaging with the researcher.
The crash dumps were caused by a known stability issue in the 8.17.0 Elastic Defend driver which was first reported by a customer in April. We take such reports seriously, so we released a fix a week later in versions 8.17.6, 8.18.1, and 9.0.1 on May 6th, one month before the researcher’s initial bug report. A description of the bug is available in our release notes (IRQL_NOT_LESS_OR_EQUAL bugcheck). While primarily observed in the presence of Trellix, the bug could be reached through other third-party software or conditions.
The PoC does not reproduce the bug detailed above nor does it demonstrate any new security bugs or vulnerabilities as stated in the researcher's updated blog. Rather, it leverages administrator rights to enable test signing, reboot the system, then load a custom unsigned kernel driver. The driver unsuccessfully attempts to modify a non-writable region of our kernel driver's memory at offset 0x120DD using the ExAcquireFastMutex function. Memory page protections block this attempt, resulting in a BSOD/bugcheck with a separate ATTEMPTED_WRITE_TO_READONLY_MEMORY error code. Because the non-writable address resides within our kernel driver’s memory range, the resulting blue screen unfortunately names our driver. With administrator rights being used to load a custom unsigned kernel driver, this approach can be used to target any driver on the system. In summary, the crash resulting from the researcher’s kernel driver PoC was due to a bug in the PoC code, and was unrelated to Elastic Defend.As with all software, we recommend users stay up to date with release notes and apply updates when they are available. We also recommend users practice least-privilege principals to minimize the prevalence of unnecessary administrator rights and to enable standard mitigations like Secure Boot and Hypervisor-Protected Code Integrity (HVCI). For users of Elastic Defend, no further action is required.
To confirm we are responsibly assessing this report and providing an unbiased perspective, we are engaging a neutral third-party to review the finding. Elastic will continue to investigate any new reports received and provide updates should we discover any valid security issues.
Updated: August 19, 2025
Elastic has reviewed additional evidence shared in a blog post on August 19th. Our prior assessment stands. For users of Elastic Defend, no action is required.
On August 16, 2025, Elastic’s Information Security team became aware of a blog and social media posts suggesting an alleged vulnerability in Elastic Defend.
Having conducted a thorough investigation, Elastic’s Security Engineering team has found no evidence supporting the claims of a vulnerability that bypasses EDR monitoring and enables remote code execution. While the researcher claims to be able to trigger a crash/BSOD in the Elastic Endpoint driver from an unprivileged process, the only demonstration they have provided does so from another kernel driver.
Elastic will continue to investigate and will provide updates for our customers and community, should we discover any valid security issues. We request that any detailed information that demonstrates the ability to crash the driver from an unprivileged process be shared with us at security@elastic.co.
Background
Elastic values its partnership with the security community. We lead a mature and proactive bug bounty program, launched in 2017, which has awarded over $600,000 in bounty payments.
The security researcher making the claim submitted multiple reports to Elastic claiming Remote Code Execution (RCE) and behavior rules bypass for Elastic EDR. The reports lacked evidence of reproducible exploits. Elastic Security Engineering and our bug bounty triage team completed a thorough analysis trying to reproduce these reports and were unable to do so. Researchers are required to share reproducible proof-of-concepts; however, they declined.
By not sharing full details and publicly posting, the conduct of this security researcher is contrary to the principles of coordinated disclosure.
The Elastic Secure Software Development Framework (SSDF) ensures Elastic software is developed securely to minimize the security risks to our customers, Elastic Products, and our software supply chain. The framework is aligned with best practices for secure software development, including NIST SSDF, OWASP SAMM, and BSIMM. Our product security testing program requirements include in-house and third-party testing for Software Composition Analysis (SCA), Static Secure Code Analysis (SAST), Dynamic Application Security Testing (DAST), Third-party Pentesting, Red Team Adversarial Attack Simulation, and other tests.
Elastic implements procedures to receive, analyze, respond to, and remediate vulnerabilities disclosed to us from all sources. Vulnerability impact assessments are performed to review and validate security findings, determine if Elastic products are affected, rate the severity, and perform remediation in accordance with the impact.
For issues that have a significant security impact on Elastic products, an Elastic Security Advisory (ESA) is published to notify our users of the issue and remediations. As a CNA, Elastic assigns both a CVE and an ESA identifier to each advisory. Advisories are announced in the Security Announcements forum and published to Mitre/NVD.