HardBreacher and the Kaspersky Endpoint Zero Day Claim: What Is Verified, What Is Not, and How to Respond?

HardBreacher is a public proof-of-concept that claims a local privilege-escalation zero-day in Kaspersky Endpoint Security on fully patched Windows 11, and the most important fact about it is that the claim is unverified. As of early September 2026, Kaspersky has not publicly confirmed the issue, and no CVE has been assigned, and the proof-of-concept’s own author describes it as unstable. The measured response is to treat it as a signal to watch rather than a confirmed vulnerability: monitor Kaspersky’s advisories, review endpoint telemetry, and do not run the public code on production systems.

Hardbreacher Kaspersky Zero Day Claim At a Glance

• What it is: HardBreacher, a public proof-of-concept claiming a local privilege-escalation zero-day in Kaspersky Endpoint Security.
• Who claimed it: a researcher using the name MSNightmare, in a public code repository.
• Status: unverified, with no public confirmation from Kaspersky and no CVE assigned as of early September 2026.
• Claimed target: Windows 11 version 25H2 running Kaspersky Endpoint Security 14.0.0.504, focused on a Kaspersky user-interface process.
• Claimed impact: a low-privileged local user obtaining a file write inside the protected System32 directory, which could disrupt the security product.
• Reliability: the author reports the proof-of-concept is unstable, may fail, and can destabilize the system.
• What to do: monitor Kaspersky advisories, review endpoint telemetry, and do not test the public code on production endpoints.

A public exploit claim against a widely used security product draws immediate attention, and that attention is worth channeling into the right response rather than either panic or dismissal. This guide sets out what HardBreacher claims, what remains unconfirmed, why privilege escalation in security software matters so much, how to separate a verified vulnerability from an unverified claim, and the concrete steps a security team should take while the picture is still forming.

Key Takeaways on the HardBreacher Claim

The points below capture what is known, what is not, and how to act, before the detail.

• The claim is unverified. HardBreacher is a proof-of-concept that asserts a Kaspersky Endpoint Security zero-day, and Kaspersky has not confirmed it, and no CVE has been assigned.
• The proof-of-concept is described as unstable. Its own author reports that it may fail, can require multiple attempts, and can destabilize the operating system.
• The alleged impact is serious if real. The claim is that a low-privileged user could write into the protected System32 directory and disrupt the security product, which would cross a Windows security boundary.
• Do not test the public code on production systems. The author warns it can leave the operating system unstable, which creates operational and security risks during investigation.
• Verification is the deciding factor. A public proof-of-concept is a lead to investigate, and a confirmed, reproducible vulnerability with a vendor advisory or a CVE is a different thing that calls for patching.

What is Hardbreacher, And What Does it Claim?

HardBreacher is a proof-of-concept project, published on a public code repository by a researcher using the name MSNightmare, that claims a zero-day elevation-of-privilege vulnerability in Kaspersky’s enterprise endpoint product. According to the project’s own description, it was tested on Windows 11 version 25H2 with Kaspersky Endpoint Security version 14.0.0.504, and it focuses on the interaction between a local user and a Kaspersky user-interface process.

The specific claim is that successful exploitation lets the current user create a file inside the protected System32 directory and gain full permissions on it, which the author illustrates with a marker file the proof-of-concept writes. Because System32 is a protected location that a standard user cannot normally write to, a genuine write there would indicate that a low-privileged local user had gained access beyond their intended Windows security boundary. That is the core of the claim, and it is the part that would matter if it holds up.

Is the Kaspersky Zero-day Confirmed?

No. As of early September 2026, the Kaspersky zero-day described by HardBreacher is not confirmed. Kaspersky has not publicly acknowledged the issue, no CVE identifier has been assigned, and the only public source for the claim is the proof-of-concept repository itself. That places it in the category of an unverified security claim rather than a validated vulnerability.

The proof-of-concept’s own limitations reinforce that caution. The author states that the code is unstable, may terminate with errors, and often requires multiple attempts to run, and that a reboot was involved during testing. A proof-of-concept in that state can support an investigation, but it does not by itself establish that the behavior reproduces reliably across different builds, configurations, and deployments. Until an independent party reproduces the issue and the vendor confirms it, the responsible framing is a claim under investigation, not a known vulnerability.

What the Flaw Would Mean if it is Reproducible?

If the behavior HardBreacher describes turns out to be reproducible, it would be a local privilege-escalation issue in a security product, and that is a serious category. Local privilege escalation matters because it is the step that turns a limited foothold into control. An attacker who already has code execution as a standard Windows user, through phishing or a first-stage payload, looks for exactly this kind of flaw to gain the elevated privileges needed to turn off protections, change security settings, reach protected data, establish persistence, or move deeper into a network.

The claimed impact goes further than a generic escalation, because the target is the security product itself. The author suggests that gaining control of the Kaspersky user-interface process could disrupt the product’s normal operation, lead to unexpected allow-or-block decisions about files, and leave the endpoint in an unstable state. In an enterprise, where endpoint security software runs with high privileges and enforces policy across many machines, a reliable version of such an issue would be a significant concern. The word to hold onto, though, is reliable, and that is what remains unproven.

Why is Privilege Escalation in Security Software a High Value Target?

Privilege escalation in security software is a high-value target because the software sits in a position of deep trust and broad access. Endpoint protection and detection tools run with powerful privileges, hook into the operating system, read and write across the file system, inspect processes, and enforce the policies that decide what is allowed to run. A flaw that lets an attacker subvert that tooling does two things at once: it removes a defense and it hands the attacker a privileged foothold.

This is why researchers probe security products so hard and why claims against them travel fast. A defensive tool that can be turned into an attack path is more useful to an attacker than an ordinary application because it is trusted by the rest of the environment. The same logic applies to any high-privilege agent on a host, which is a reminder that the software meant to protect an endpoint has to be held to the same testing standard as the software it protects.

How to Tell a Verified Vulnerability From an Unverified Claim

Telling a verified vulnerability from an unverified claim comes down to a short list of signals, and applying it keeps a security team from both overreacting to noise and missing a real issue. A claim earns confidence as those signals accumulate.

• Independent reproduction. Has anyone other than the original author reproduced the behavior on a clean, representative system, rather than a single unstable run?
• Reliability. Does the issue reproduce consistently, or does it depend on multiple attempts, specific timing, or a reboot, which suggests the behavior is not yet understood?
• Vendor confirmation or a CVE. Has the vendor acknowledged the issue or issued an advisory, and has a CVE been assigned through a recognized process?
• A named, accountable researcher and coordinated disclosure. Was the finding disclosed responsibly to the vendor, with a researcher standing behind it, rather than dropped as an anonymous, unstable script?
• A clear, described mechanism. Is the root cause explained and reproducible, or is the write treated as a black box that sometimes works?

This is the discipline that separates a headline from a fix, and it is the standard CredShields applies to its own work, where every finding is reproduced and verified before it is published and the report carries a named assessor. A worked example of what a verified, reproduced vulnerability looks like end to end is the broken access control flaw CredShields found in Google’s Site Kit, which moved through confirmation and a CVE rather than an unverified claim.

How Organizations Using Kaspersky Endpoint Security Should Respond

Organizations running Kaspersky Endpoint Security should respond to the HardBreacher claim as a monitored signal, without either dismissing it or destabilizing their own systems to test it. The goal in this window is to be ready to act quickly if the issue is confirmed while avoiding the risks the proof-of-concept itself carries.

• Monitor Kaspersky’s advisories and support channels for validation, a security bulletin, a patch, or a mitigation, and be prepared to apply an update quickly if one is released.
• Do not run the public proof-of-concept on production endpoints, because the author warns it can leave the operating system unstable, which creates operational and security risks.
• Review endpoint telemetry for the kinds of activity a real version of this issue would produce, using the signals in the next section.
• Reinforce the controls that limit what a local attacker can do after an initial foothold, since local privilege escalation only matters once an attacker is already running code as a user.
• Keep a record of your investigation so that, if the vendor confirms the issue, you can move straight to remediation rather than starting the assessment from scratch.

What to Watch For in Your Telemetry

While the claim is unconfirmed, the practical defensive move is to watch for the behavior a real exploit would leave behind, rather than the specific proof-of-concept. The useful signals are general and apply beyond this one claim.

• Unexpected file creation or writes inside protected system directories, especially System32, by processes that should not have that access.
• Anomalous DLL creation or loading associated with unusual parent processes.
• Unusual activity involving Kaspersky processes, including crashes, restarts, or the security service failing or stopping.
• Changes to security configuration or policy that were not made through an approved administrative channel.
• A low-privileged process spawning or manipulating a higher-privileged one, which is the shape of an escalation attempt regardless of the specific flaw.

These are worth alerting on as standing detections, because they catch a broad class of privilege-escalation and defense-tampering activity, not only the scenario HardBreacher describes.

Recommended read: the broken access control flaw CredShields found in Google’s Site Kit, which shows what a reproduced and verified vulnerability looks like, in contrast to an unconfirmed proof-of-concept claim.

Claim Versus Confirmed Status, Side By Side

The table below separates what HardBreacher asserts from what has been established, which is the clearest way to hold the current picture.

Aspect	What HardBreacher claims	What is established
Vulnerability	A zero-day privilege escalation in Kaspersky Endpoint Security	Not confirmed by Kaspersky, and no CVE assigned
Reliability	A working proof-of-concept	The author reports it is unstable and may fail
Impact	A file write in protected System32 that disrupts the product	Unverified, and dependent on reproducibility
Scope	Windows 11 25H2 with Kaspersky Endpoint Security 14.0.0.504	Not established across other builds or configurations
Response	Treated by the author as a proof-of-concept	Treat as a signal to monitor, not a confirmed vulnerability

Frequently Asked Questions (FAQs) About the Hardbreacher Kaspersky Claim

The questions below cover what security teams ask most often about the HardBreacher claim.

Q1. What is HardBreacher? 

HardBreacher is a public proof-of-concept, published by a researcher using the name MSNightmare, that claims a local privilege-escalation zero-day in Kaspersky Endpoint Security on fully patched Windows 11. It focuses on a Kaspersky user-interface process and asserts that a low-privileged user could write into the protected System32 directory.

Q2. Is the Kaspersky zero-day confirmed? 

No. As of early September 2026, Kaspersky has not publicly confirmed the issue, and no CVE has been assigned. The only public source is the proof-of-concept itself, whose author describes it as unstable, so it should be treated as an unverified claim under investigation.

Q3. How serious would this be if it is real? 

If reproducible, it would be a local privilege-escalation flaw in a security product, which is a serious category, because it could let an attacker who already runs code as a user gain elevated privileges, disable protections, or destabilize the endpoint. The severity depends entirely on whether the behavior reproduces reliably.

Q4. Should we uninstall Kaspersky Endpoint Security? 

There is no confirmed vulnerability to react to yet, so removing a working security control based on an unverified claim would trade a known protection for an unproven risk. The better step is to monitor Kaspersky’s advisories, watch telemetry, and be ready to patch quickly if the vendor confirms and fixes an issue.

Q5. Can we test the proof-of-concept to see if we are affected? 

Not on production systems. The author warns the code can destabilize the operating system, which creates operational and security risks. Any testing should be confined to an isolated lab environment, and for most organizations, waiting for vendor validation is the safer path.

Q6. What should we monitor for in the meantime? 

Watch for unexpected writes into protected system directories such as System32, anomalous DLL creation, crashes or failures of Kaspersky processes and the security service, and unauthorized changes to security configuration. These signals catch a broad class of privilege-escalation and defense-tampering activity.

Q7. Why do attackers target security software specifically? 

Endpoint security software runs with high privileges and deep access to files, processes, and policy enforcement, so a flaw in it removes a defense and provides a privileged foothold at the same time. That combination makes defensive tooling a high-value target and is why claims against it draw attention quickly.

Q8. How do we know when to move from monitoring to patching? 

Move when the signals of a verified vulnerability appear: independent reproduction, reliable behavior, vendor confirmation or a CVE, and an available patch or mitigation. Until those exist, the appropriate posture is preparation and monitoring rather than emergency change.

If you want an independent, reproduced assessment of whether a claimed weakness affects your environment, rather than a script of uncertain reliability, you can scope a penetration test with a team that verifies and names every finding.