A proof-of-concept exploit named HardBreacher, published by researcher Nightmare Eclipse and reported on August 31, creates a file inside C:WindowsSystem32 from an unprivileged account on a fully patched Windows 11 25H2 machine running Kaspersky Endpoint Security. Kaspersky has issued no confirmation and no CVE.
Key Takeaways
- Nightmare Eclipse published HardBreacher on GitHub, a proof-of-concept claiming an unpatched privilege escalation flaw in Kaspersky Endpoint Security.
- Kaspersky Endpoint Security 14.0.0.504 on Windows 11 25H2 is the only configuration the researcher reports testing.
- The exploit creates MY_SNAKE_IS_SOLID.dll in C:WindowsSystem32 and grants the current user full permissions on that file.
- No CVE identifier has been assigned, Kaspersky has not commented, and no outside researcher has reproduced the result.
- Huntress observed attackers running this researcher’s earlier Defender exploits during a live corporate intrusion.
What We Know?
The HardBreacher repository describes itself as a “Kaspersky Antivirus For Endpoint ZeroDay Elevation of Privileges Vulnerability” and names a single tested configuration: Kaspersky for Endpoint 14.0.0.504 on Windows 11 25H2. The repo holds four commits, no CVE reference, no disclosure timeline, and no sign of vendor contact.
What the code demonstrably does is narrow. On a successful run it writes MY_SNAKE_IS_SOLID.dll into C:WindowsSystem32 and gives the logged-in standard user full permissions on that object, which Windows access controls should never allow.
The researcher attributes the behavior to control over the product’s own interface process. The README states that “Kaspersky completely loses it when you take control over the UI process,” and that this can stop the product functioning and make it “grant/block access to files its not supposed to.” Nightmare Eclipse also concedes the tooling barely works: the exploit “will fail to run with error so you just have to keep rerunning it.“
A PoC/exploit has been discovered for vulnerability in Kaspersky Endpoint Security
— dbugs (@ptdbugs) August 29, 2026
Vendor: Kaspersky
Product: Kaspersky Endpoint Security
Description: A local privilege escalation issue in Kaspersky Endpoint Security allows a local attacker to abuse privileged application…
What We Don’t Know?
The gap between file creation and full compromise is where this sits, and the researcher has not closed it. Writing a DLL into a trusted directory signals broken privilege boundaries; a repeatable chain ending in code running as SYSTEM is different evidence, and nobody has published one.
Five questions stay open in the public record:
- Does the technique work against builds other than 14.0.0.504, or against consumer Kaspersky products?
- Does it need a specific policy configuration, or does it fire against Kaspersky’s shipping defaults?
- Can the created DLL actually be loaded by a privileged process, which is what would turn a write into an execution primitive?
- Has any second party reproduced the result on independent hardware?
- Has Kaspersky received a report through any channel, and when?
Because none of these have public answers, the list of affected versions is currently a guess.
An EDR Flaw Without the EDR Disclosure Process
The useful comparison here is procedural. When CrowdStrike patched two Falcon Windows sensor flaws that let an attacker with existing code execution delete files, the process produced CVE-2025-42701 and CVE-2025-42706, CVSS scores, patched builds, and a statement on exploitation. HardBreacher arrives with a GitHub repo and a filename joke, so defenders inherit the attack surface without the artifacts that normally make it manageable.
The author’s history is why this warrants attention. Huntress documented an April 20, 2026 intrusion in which a threat actor deployed three Nightmare Eclipse tools, BlueHammer, RedSun and UnDefend, after a likely FortiGate SSL VPN compromise.
Every attempt failed on the technical merits, with Huntress recording that “RedSun did not achieve TieringEngineService.exe overwrite in the System32 folder” and that “BlueHammer did not successfully extract SAM credentials.” The attacker even misspelled a command flag. Unreliable code still reached a live corporate network.
Administrators already running 14.0.0.504 have work that does not wait on a patch. Inventory which endpoints hold that exact build and record their policy configuration before anything changes. Alert on file creation and permission changes under C:WindowsSystem32 by accounts that are not SYSTEM. Baseline the legitimate Kaspersky process tree, then watch for unexpected child processes spawned by the interface component, service stops, and unauthorized configuration changes. Do not run the public PoC on a production host.
SQ Magazine’s Takeaway
The weight of this claim comes from a property of endpoint agents that has nothing to do with Kaspersky specifically. Antivirus and EDR software runs with deep kernel privileges, intercepts file operations, and carries trust that ordinary applications never receive. A failure in rights handling inside that layer gives an attacker a far shorter path to SYSTEM than a bug in a user application would, which is why an unverified claim against a supported enterprise build still earns monitoring. Calling it a confirmed vulnerability would be wrong; calling it noise would be worse.
What happens next depends almost entirely on Kaspersky. The realistic sequence runs vendor advisory, affected-build list, CVE assignment, patched release, and nothing published so far shows where in that sequence the company sits. Independent reproduction is the other trigger worth watching, since a second researcher confirming the write, or extending it into SYSTEM execution, would move this from a claim to an incident.
Until either lands, strict local access controls and monitoring of protected system paths help reduce risk, and security teams should test their threat monitoring assumptions against what Kaspersky telemetry is actually reporting.
