HardBreacher targets Kaspersky Endpoint 14.0.0.504
HardBreacher is a privilege-escalation proof of concept for one Windows setup. The README says the author got it working on fully patched Windows 11 25H2 with Kaspersky Endpoint Security 14.0.0.504. Its claimed result is a file under C:\Windows\System32 that the current user can control. That is vulnerability evidence, not a health check an administrator should run across an endpoint fleet.
The source pairs an executable with a DLL and calls native Windows file, process, registry, and access-control APIs. Project files target C++20, and the code contains fixed references to Kaspersky 14.0.0 paths and its UI process. Those details narrow the claim. They do not establish which other product builds are affected, whether a vendor fix exists, or whether the behavior reproduces elsewhere.
The README warns that attempts fail and can disrupt Windows
The author calls the proof of concept duct-taped and says it may exit with an error until rerun. The README also warns that controlling the Kaspersky UI process can stop protection from working as expected and leave the operating system badly disrupted. A tool with that failure model belongs in a snapshot-backed lab where losing the guest is acceptable. It does not belong on the workstation being assessed.
Documentation stops after the claim and one screenshot. The 1,355-byte README gives no compilation procedure, cleanup steps, safe failure recovery, CVE, vendor case, patch status, affected-version range, or disclosure timeline. Zero day is the author's description; the repository does not link independent confirmation. Readers therefore have code and a claimed effect, without the evidence needed to turn either into remediation advice.
What happened when we ran it
The lab result for commit 647ac44 is NOT RUN. Our harness identified the project as C, an unsupported ecosystem for this sandbox workflow, and the repository has no Dockerfile defining a runnable environment. There is no measured installation time, build result, test result, dependency count, disk footprint, or vulnerability audit for this review. Numbers from another machine would not repair that evidence gap.
The missing run matters because the behavior depends on Windows 11 25H2 and a particular endpoint-security product. A Debian container cannot validate that claim. Proper reproduction needs a disposable, licensed target under explicit authorization, with snapshots and monitoring decided before any attempt. That is a separate security exercise, outside what MrKeyoor's standard language harness can measure.
Checked-in binaries do not count as our build result. The source tree includes an executable, DLLs, and program database files, but those artifacts do not record compiler inputs or the runtime outcome on our sandbox. Researchers should compile reviewed source where possible and compare outputs before assigning trust to a bundled program that manipulates security software.
Visual C++ v145 and an x86 DLL narrow the build path
The project files declare Visual C++ version 18.0, toolset v145, the Windows 10 SDK target, and C++20. Both Win32 and x64 configurations exist. A DLL source comment says that component must be compiled for x86 because the targeted Kaspersky process is not x64. The README never turns those settings into build instructions, so a researcher must already understand Visual Studio projects.
GitHub's latest-release endpoint returned no formal release. The repository instead stores a release executable, DLLs, and debugging symbols inside the source tree. There is no release page collecting checksums, notes, or a named supported artifact. That may suffice for rough research evidence. It is a poor distribution model for software that intentionally touches a protected Windows directory.
Safe evaluation requires a disposable Windows 11 guest
The README's claim points to Windows 11 25H2, Kaspersky Endpoint Security 14.0.0.504, and a machine with no valuable files or credentials. A responsible lab would isolate the guest, record the product build and policy, take a restorable snapshot, and decide what evidence to retain. These precautions contain the damage the author describes; they do not make the proof of concept reliable.
Reproduction and remediation are different jobs. HardBreacher may support a vendor report by supplying code and an observed effect, but it does not tell defenders which builds to patch or which telemetry proves an attempt. Kaspersky administrators need a vendor response before turning this repository into policy. The supportable conclusion stays narrow: the author claims one affected setup and says the code is unstable.
One August 2026 issue provides little outside validation
The repository was created on August 28, 2026 and last pushed on August 29. GitHub showed 272 stars and 1 open issue when fetched. That issue repeats the proof of concept's filename joke and has 2 comments; it does not report another reproduction, request a fix, or document another affected build. Recent dates show new code, while the issue record says little about support or independent testing.
There is no GitHub release history. A recent push and 272 stars can draw attention to a security claim, but neither substitutes for a disclosure record, vendor bulletin, or outside reproduction. Their absence does not prove the claim false. It is a reason to keep the conclusion narrow and avoid presenting the bundled binary as a finished security tool.
NOT RUN makes this research material, not a recommendation
Our only lab outcome is NOT RUN, and the README says repeated attempts may fail while a success can destabilize the system. HardBreacher may interest an experienced Windows exploit researcher working with the vendor on an isolated copy of Kaspersky Endpoint 14.0.0.504. Everyone else should use a documented assessment tool or wait for a vendor-backed advisory that defines affected versions and remediation.