Most of the vulnerabilities we cover in this space come with a CVE number, a vendor advisory, and/or a clear patch to install. This one does not, and that's part of what makes it worth explaining carefully rather than skipping.
A researcher published a proof-of-concept exploit called HardBreacher in the last days of August 2026, claiming it can trick Kaspersky Endpoint Security for Windows, a security product many organizations rely on to protect their laptops and servers, into misbehaving badly enough that a low-privileged user could gain access they shouldn't have. There is no confirmed CVE, no independent reproduction, and no evidence of active exploitation. Kaspersky has told journalists the underlying issue is already fixed. In short: this is a credible but unverified research claim, the vendor says it's already handled, and the main action item is to confirm that's actually true on every managed endpoint, not to scramble for an emergency patch.
The longer version, including why this disclosure looks different from the CVE-backed flaws we normally write about, is below.
Who published this, and why that matters
HardBreacher comes from a researcher publishing under the handles Nightmare Eclipse, Chaotic Eclipse, and more recently MSNightmare. Reporting from The Register and others identifies the researcher as likely being a former Microsoft security employee who left the company in mid-2025 and, over the course of 2026, has released a string of weaponized Windows and Microsoft Defender zero-days directly to the public with no advance notice to the affected vendor. That pattern is a break from the coordinated disclosure process most researchers follow, where a vendor gets weeks or months to build a fix before anything becomes public.
The researcher has said the campaign began after growing frustrated with how Microsoft handled their vulnerability reports, including a dispute over account access and public attribution. Several of the resulting Windows and Defender zero-days, including ones dubbed RedSun, UnDefend, ShieldBreak, and RoguePlanet (most of which we have previously covered), went on to see real-world exploitation after release. HardBreacher, published to GitHub on August 30 to 31, 2026, marks the researcher's first publicized move away from Microsoft products and toward a third-party security vendor's software instead.
That history is useful context, not a verdict on this specific claim. It tells you the researcher has a track record of publishing exploits that turn out to be functional, which is a reason to take the report seriously. It also tells you the researcher publishes without vendor coordination or independent peer review, which is a reason the claim needs verification before anyone treats it as a confirmed, scoped vulnerability.
What HardBreacher claims to do
According to the project's own documentation, HardBreacher targets an interaction between a local Windows user and the Kaspersky Endpoint Security user-interface process. The researcher reports testing it against Kaspersky Endpoint Security for Windows version 14.0.0.504, running on a fully patched Windows 11 25H2 system.
The claim itself: by taking control of the Kaspersky UI process, an attacker can cause the security product to behave unpredictably, including incorrectly granting or denying access to files it's supposed to protect. When the proof of concept succeeds, it reportedly creates a file named MY_SNAKE_IS_SOLID.dll inside C:\Windows\System32, a directory that is normally off-limits to standard users, and grants the current user full permissions on that file. If that behavior is real and reproducible, it would mean a standard local account could write into a protected system directory it shouldn't be able to touch, which is the definition of a privilege escalation.
A few things temper that claim considerably:
This is a local, not remote, vulnerability. An attacker would already need some form of code execution or access on the target machine, through malware, a phishing-delivered payload, stolen credentials, or another vulnerability, before HardBreacher would be relevant at all. It is not something an attacker on the internet can point at your infrastructure directly.
The researcher describes the exploit as unreliable. The GitHub README calls the code "duct taped," states that it fails with errors and needs to be rerun repeatedly, and notes that in the researcher's own successful test, a system reboot was involved. This is not a polished, weaponized tool ready for broad use; it's an early-stage proof of concept that sometimes works.
No CVE has been assigned, by Kaspersky, MITRE, or any other authority, at the time of writing. No independent security researcher or firm has publicly reproduced the claimed behavior. Several outlets covering the release, including Cyber Security News and independent reviewers, have explicitly flagged this as a credible lead requiring validation rather than a confirmed zero-day.
What Kaspersky has said
Contacted directly by SecurityWeek, Kaspersky stated that the underlying issue has already been resolved, and that the fix is delivered through the product's automatic update mechanism or can be triggered with a manual database update. Kaspersky has not published a separate security bulletin or assigned its own internal advisory number for this issue as of this writing, and has not confirmed the technical details the researcher described.
This delivery model is worth understanding on its own terms, because it is different from the version-number patches we usually cover. Kaspersky Endpoint Security, like most modern antivirus and EDR products, receives frequent updates to its detection databases and internal protection logic separately from full application version upgrades. If Kaspersky's account is accurate, an endpoint can be running the same application build referenced in the PoC, version 14.0.0.504, and still be protected, provided its databases are current. Conversely, an endpoint that has fallen behind on database updates, whether because it's offline, misconfigured, or unable to reach Kaspersky's update infrastructure, could remain exposed even though nothing about its visible version number looks unusual.
That distinction is the main reason this write-up exists: "the vendor says it's fixed" is good news, but it shifts the verification burden from "did we install a patch" to "did every endpoint actually receive and apply the update," which is a less visible, easier-to-miss gap.
Who should pay attention
Organizations running Kaspersky Endpoint Security for Windows, particularly the enterprise/commercial product line referenced in the PoC, are the direct audience for this one. Kaspersky's home and consumer antivirus products are not what's described here.
Environments with weak update hygiene carry the most residual risk. If your Kaspersky-managed endpoints reliably phone home for database updates, this is very likely a non-event for you already. If you have offline, air-gapped, or intermittently connected endpoints, kiosk-style machines, or devices that have been sitting in a closet for a few months, this is worth a specific check.
Anyone already dealing with a foothold on an endpoint should treat this as one more reason that initial-access incidents deserve fast containment. HardBreacher is not a way in; it's a claimed way to go from "standard user on a compromised machine" to something more dangerous once an attacker is already there. Security products with deep OS-level access are attractive targets for exactly that kind of escalation, which is a useful reminder independent of whether this specific PoC ever matures into something reliable.
What should you do?
1. Confirm your Kaspersky database updates are current, fleet-wide
Since Kaspersky says the fix ships through routine database updates rather than a version upgrade, the practical priority is verifying that every managed endpoint has actually received and applied a recent update, not just that the application itself is installed and running.
For Kaspersky Security Center-managed environments, check the update status report across all managed devices and flag anything with a stale last-update timestamp:
Kaspersky Security Center console > Monitoring & Reporting >
Reports > "Report on protection status" and
"Report on database and application module updates"
For standalone endpoints, verify from the client itself:
Kaspersky Endpoint Security > Database Update > check "Last updated" timestamp
If you can trigger a manual database update fleet-wide through your management console, doing so removes any ambiguity while you continue investigating.
2. Investigate any endpoints that have missed updates or gone dark
Prioritize devices that are offline, air-gapped, on isolated network segments, or otherwise unable to reach Kaspersky's update infrastructure on a normal schedule. These are the machines most likely to still be running pre-fix databases regardless of what the fleet-wide average looks like.
# Example: query Kaspersky Security Center for devices with outdated databases
# (adjust to your KSC version and reporting interface)
klscflag -fset -pv klserver -n TraceFolder ... # consult KSC documentation
# or use the Security Center web console's built-in
# "Devices with outdated databases" report
3. Watch for the specific indicator, without expecting to find it
If you want to confirm no prior exploitation attempts succeeded, a narrow, low-noise check is reasonable: look for unexpected file creation events for MY_SNAKE_IS_SOLID.dll under C:\Windows\System32, or any unexplained DLL creation in that directory attributed to a non-standard process chain, particularly anything tied to the Kaspersky UI process behaving abnormally.
# Example Sysmon/EDR query pattern (adapt to your platform)
# Event: FileCreate
# TargetFilename: *\System32\MY_SNAKE_IS_SOLID.dll
Given the PoC's own stated unreliability and the absence of confirmed exploitation, we would not expect this search to turn anything up. It's a reasonable box to check, not a reason for alarm on its own.
4. Do not run the public PoC on production systems
The researcher's own documentation warns that a successful run can leave Kaspersky Endpoint Security malfunctioning and the underlying operating system unstable. If your team wants to validate the claim technically, do it in an isolated, disposable lab environment, not on anything connected to production data or your management infrastructure.
5. Keep watching for a formal advisory
Kaspersky has not yet published a dedicated public bulletin walking through the technical details, affected version ranges, or a CVE identifier for this issue. If one is published, it may narrow or widen the scope described here. Treat the current picture as provisional and revisit it if Kaspersky's public guidance changes.
A note on why this one reads differently
Every other advisory we've published this cycle has had a CVE, a CVSS score, and a vendor-confirmed patch to point to. This one doesn't, and we think that distinction is worth naming plainly rather than dressing the post up to look more definitive than the underlying facts support.
What we know with confidence: a researcher with a track record of publishing exploits that later prove functional released a proof of concept claiming local privilege escalation against a specific, named build of a widely deployed enterprise security product; the vendor was contacted directly and says the issue is already resolved through routine updates; and no independent party has reproduced the behavior or confirmed active exploitation. That's enough to warrant the verification steps above. It is not enough to warrant an "upgrade everything immediately" posture, because there is, as of this writing, nothing specific to upgrade to.
Summary
| Name | HardBreacher |
| CVE | None assigned as of this writing |
| Type | Claimed local privilege escalation (unconfirmed) |
| Component | Kaspersky Endpoint Security for Windows, UI process interaction |
| Tested against | KES for Windows 14.0.0.504 on fully patched Windows 11 25H2 |
| Attack vector | Local only; requires prior code execution or access on the target |
| Discovered/published by | Researcher known as Nightmare Eclipse / Chaotic Eclipse / MSNightmare |
| Disclosure type | Uncoordinated, direct public release; no vendor embargo |
| PoC reliability | Described by the author as unstable; requires repeated attempts |
| Independent reproduction? | None confirmed as of this writing |
| Active exploitation? | None confirmed as of this writing |
| Vendor response | Kaspersky states the underlying issue is resolved via automatic or manual database update |
| Recommended action | Verify database update currency fleet-wide; do not run the PoC on production systems |
If you need help confirming update status across a Kaspersky-managed fleet, investigating endpoints that may have fallen out of sync, or simply want a second set of eyes on how seriously to weigh an unconfirmed disclosure like this one, get in touch. Not every headline-grabbing PoC deserves the same response, and knowing which ones do is half the job.