New Windows RasMan zero-day flaw gets free, unofficial patches

Brownie2019

Level 23
Thread author
Verified
Well-known
Forum Veteran
Mar 9, 2019
910
4,299
2,168
Germany
Free unofficial patches are available for a new Windows zero-day vulnerability that allows attackers to crash the Remote Access Connection Manager (RasMan) service.

RasMan is a critical Windows system service that starts automatically, runs in the background with SYSTEM-level privileges, and manages VPN, Point-to-Point Protocol over Ethernet (PPoE), and other remote network connections.
Full Story here:
 
Full Story here:
Interesting find, thanks for sharing.

From what’s described, this looks like a denial-of-service type issue (crashing RasMan) rather than remote code execution, which is serious but not quite as critical as full SYSTEM compromise.

What this vulnerability means in practice
  • RasMan runs as SYSTEM and handles VPN, PPPoE, and other remote connection features.
  • If an attacker can reliably crash RasMan, they can:
    • Kill or disrupt VPN connections
    • Potentially cause repeated service restart loops
    • Impact remote access / connectivity for users or services that rely on it
  • On typical home systems, this is more of a stability / availability issue.
  • On corporate systems that depend on VPN for access, this can be more disruptive.

About the “unofficial patches”
These are almost certainly coming from 0patch (they frequently appear in BleepingComputer articles about zero-days):

  • They inject “micropatches” into memory without replacing system files.
  • They can be useful as a stop‑gap for high‑risk environments that can’t wait for Microsoft.
  • They are not Microsoft-official, so:
    • You should test them on non‑production systems first.
    • Enterprises need to consider change control and support implications.

What to do as a regular/home user
  • If you don’t use VPN/PPPoE via Windows’ built‑in tools, risk is relatively low in everyday usage.
  • Keep Windows fully updated and watch for this being fixed in a future Patch Tuesday.
  • If you’re not comfortable installing third‑party patches, it’s perfectly reasonable to just wait for Microsoft’s official fix.

What to do in an enterprise / admin context
  • Evaluate whether RasMan is actually exposed in ways attackers in your environment could exploit (e.g. local users, RDS servers, VPN gateways, etc.).
  • If you rely heavily on Windows-based VPN:
    • Consider testing the 0patch fix on a staging environment.
    • Monitor Microsoft’s advisories and Patch Tuesday notes for an official patch.
  • If you don’t use RasMan on certain systems, you can consider:
    • Disabling or restricting the service on those specific machines (after confirming no dependencies).

In short: this is mainly an availability issue (crashing a critical networking service), not obviously a “your machine is instantly owned” scenario. For most users, staying updated and waiting for Microsoft’s fix is fine; admins of sensitive or VPN-heavy environments might look at 0patch as an interim mitigation after proper testing.
 
  • Like
Reactions: Victor M
The issue reported in the thread is a critical vulnerability that demands attention, specifically in environments reliant on remote access services. The verdict is not an active, widespread breach, but an immediate need for mitigation to close a dangerous vector.

The core of the issue is a newly discovered Denial-of-Service (DoS) zero-day flaw impacting the Windows Remote Access Connection Manager (`RasMan`) service across all currently supported and some unsupported Windows versions, including Windows 7 through 11 and Windows Server 2008 R2 through Server 2025. The `RasMan` service runs with `SYSTEM`-level privileges. The technical vulnerability stems from a coding error in how the service processes circular linked lists, leading to a null pointer dereference that causes the service to crash.

While a direct Denial-of-Service attack (D.o.S.) itself is severe, potentially crippling VPN/PPPoE connections and causing service restart loops on critical corporate systems, the actual severity lies in its ability to be weaponized. This DoS flaw, by reliably crashing the `RasMan` service, enables threat actors to bypass the mitigation implemented for a separate, previously disclosed Elevation-of-Privilege (EoP) vulnerability (CVE-2025-59230), exploiting that vulnerability during the subsequent service restart or initialization phase. Microsoft has acknowledged the DoS component but noted they plan to address it in a future fix, reaffirming that the October patch for the EoP flaw provides protection against the EoP itself.

The Remediation/Action Plan

The recommended course of action depends entirely on whether your systems rely on the functionality provided by the Remote Access Connection Manager.

1. If the service is NOT used (Recommended for most home/non-VPN-dependent users)

The most effective defense is eliminating the attack surface. Disable the service via the Services snap-in by running `services.msc`.

Locate the Remote Access Connection Manager service. Set its "Startup type" to `Disabled`. Click "Stop" if the service is currently running.

2. If the service IS used or if a manual patch is necessary (Enterprise/High-Risk Environments)

The current official mitigation is ensuring the patch for CVE-2025-59230 is applied, which protects against the privilege escalation that the DoS flaw facilitates.

For unpatched Windows versions (including EOL versions) or environments that require immediate mitigation against the DoS risk, consider utilizing the free, unofficial micropatches provided by vendors like 0patch (ACROS Security) as an interim solution.

It is critical to treat these unofficial patches as a temporary, high-risk fix and test them thoroughly on staging systems before production deployment.

Monitor Microsoft’s advisories for the official vendor patch that addresses the underlying DoS flaw.

Prevention and Sanity Check

The best defense is continuous patching (for the underlying EoP flaw) and minimizing the attack surface by only running necessary services. For the immediate future, maintain vigilance for signs of unexpected system crashes or loss of VPN/remote connectivity.

As a final verification that no immediate persistence mechanisms were missed in the thread analysis, run the following command (which can be safely executed on any machine) and review its output.

`powershell.exe -NoProfile -Command "Get-CimInstance -ClassName Win32_StartupCommand | Select-Object Name, Command, Location"`
 
Last edited:
fwiw chatGPT 5.2 is telling me this zero-day is "fixed" with 0patch and pointed me to their blog page that discusses this. hope it's not hallucinating ;)
 
fwiw chatGPT 5.2 is telling me this zero-day is "fixed" with 0patch and pointed me to their blog page that discusses this. hope it's not hallucinating ;)
Clarification

0patch's Micropatch is an effective solution. The third-party company 0patch created a tiny binary patch that corrects the flawed code logic (the null pointer issue in the circular linked list traversal) in memory, effectively preventing the crash and stabilizing the system. This allows Windows users to be protected without waiting for Microsoft.

It is still a "Zero-Day" until Microsoft releases a patch. In the security world, a zero-day remains officially "unfixed" and unassigned a CVE until the original vendor (Microsoft) releases its own security update. Microsoft has confirmed they are working on it for a "future fix."
 
Last edited:
  • Thanks
Reactions: simmerskool
Not sure about 0-patch
Exactly, why complicate your Windows patch if you don't need too.

If you don't use the service
I don't even know if I am "using" the service. "Remote Access Connection Manager" startup type is set to "Manual" but it has been "started". What is starting it? I guess I'll disable it and wait to see what breaks.
 
Not sure about 0-patch, something about paying for patches that MS should release for free and release quickly rubs me wrong.
now that I use 0patch with win10_EOL, I'm liking it much better than paying MS more money for its extended 1 year EOL support. I'm happier with 0patch than using some unofficial "hacked" bypass to install win11 on my otherwise solid hardware.
 
now that I use 0patch with win10_EOL, I'm liking it much better than paying MS more money for its extended 1 year EOL support. I'm happier with 0patch than using some unofficial "hacked" bypass to install win11 on my otherwise solid hardware.
If I was still using Windows personally I would not install any 3rd party patches, I would just disable the service until MS pushed an official one.
 
If I was still using Windows personally I would not install any 3rd party patches, I would just disable the service until MS pushed an official one.
yeah but related issue in my mind, that is exactly (or more or less) what's being suggested to install win11 on "non-compliant" hardware. use this to bypass that... :unsure:
 
  • Like
Reactions: Dave Russo
yeah but related issue in my mind, that is exactly (or more or less) what's being suggested to install win11 on "non-compliant" hardware. use this to bypass that... :unsure:
I'm funny that way, I wouldn't use a third party company to patch holes in Microsoft. I'd either get a new system or that system would no longer be Microsoft but one of the beautiful versions of Linux. As for above i'd most certainly disable that service until a patch comes out, although this particular service, I would just leave disabled as it's certainly a security risk.
 

You may also like...