Patching Ivanti Connect Secure Isn’t Enough This Time

Attackers are exploiting an authentication-bypass 0-day in Ivanti Connect Secure appliances, and CISA wants more than a patch. We cover the affected versions and post-exploitation activity, then walk through CISA’s recovery steps.

What You Need to Know

CISA is urging organizations to update Ivanti Connect Secure (ICS) after confirming active exploitation of CVE-2026-104935. It’s an authentication bypass rated CVSS 8.6 that lets remote, unauthenticated attackers execute arbitrary commands. Attackers are using it to steal credentials and exfiltrate data, so this is an incident response problem as well as a patching priority. Federal Civilian Executive Branch (FCEB) agencies have until October 16, 2026, to apply fixes.

What’s Vulnerable

CVE-2026-104935 affects these ICS versions, each within its own release branch:

• 25.1.1.1 and earlier
• 25.1.2.2 and earlier
• 22.8R2.4 and earlier

CISA added the flaw to its KEV catalog with an October 16 deadline for FCEB agencies. Version 22.8 also reaches end-of-life on January 31, 2027, which adds a complication for organizations still on that branch.

What Happened

Two separate streams of activity have been reported.

As of October 14, Previdian had recorded 105 exploitation attempts against its honeypots from 50 unique IP addresses. The attempts used the X-DSCGI-PATH header to reach an internal CGI handler and upload Perl scripts disguised as ZIP files. The scripts returned unique markers to confirm command execution.

Volexity separately observed exploitation starting October 3 by a previously undocumented actor tracked as UTA0576. The actor chained the vulnerability with a privilege escalation flaw to get unauthenticated root-level code execution. Once inside, it:

• extracted appliance credentials
• exfiltrated limited Active Directory metadata
• deployed tooling for Kerberoasting and credential testing
• searched for administrator passwords and BitLocker recovery keys

It also modified logs and removed temporary artifacts.

Why This Matters

The honeypot probes and the Volexity intrusions tell you different things. Most of the payloads Previdian captured tested whether exploitation worked rather than deploying malware. UTA0576 went straight for credentials and directory data, and that pattern is what changes the response.

Stolen credentials may remain usable after patching, while exfiltrated AD metadata can support follow-on targeting. Log tampering also makes it harder to determine what happened before an upgrade. Patching closes the vulnerable entry point, but it does not revoke stolen credentials or establish that an intrusion has been contained.

What to Do

Upgrade affected appliances using Ivanti’s upgrade and migration guidance. If you’re on 22.8, plan your move off that branch before January 31, 2027.

Run a compromise assessment alongside the upgrade, because a successful update doesn’t prove the environment is clean. CISA specifically calls for network and memory forensics. The investigation should look for credential access, directory reconnaissance and evidence tampering, as well as suspicious files on the appliance.

If you find compromise, CISA recommends this sequence:

1. Back up the configuration.
2. Perform a factory reset.
3. Upgrade to the latest version.
4. Restore the configuration.

Rebuild and upgrade cloud and virtual deployments. Then:

• reset domain, administrator and local account passwords
• revoke and reissue stored certificates
• reset stored API keys and license server credentials

A Malicious Server Can Corrupt curl Clients Through HTTP/2 Uploads

curl’s newest High-severity bug runs the usual threat model in reverse: the server attacks the client that uploads to it. Exploiting it takes a long list of conditions, which we walk through below along with the fix.

What You Need to Know

The curl project released version 8.23.0 on October 14 to fix CVE-2026-92392, a High-severity use-after-free in curl and libcurl versions 8.12.0 through 8.22.0. An attacker-controlled server receiving an HTTP/2 upload can corrupt memory on the client. The researcher who reported it demonstrated client-side code execution in a proof of concept. The project moved its release up two weeks to ship the fix.

What’s Vulnerable

The bug is in libcurl’s upload handling. That puts any application built on the shared library in scope, along with the command-line tool.

Exploitation requires all of the following:

• The client uploads roughly 135 KB to a server the attacker controls.
• That server’s certificate passes the client’s validation checks.
• The client’s build supports HTTP/2, and HTTP/2 is negotiated for the connection.

Builds without HTTP/2 support can’t reach the affected code path.

How the Exploit Works

The server manipulates HTTP/2 flow control and resets an upload stream while keeping the underlying connection open. During cleanup, curl marks the transfer as finished before it flushes the remaining upload data.

The server can read specially structured bytes in that data as a new request. That creates a stream holding a pointer to the original transfer object, known as an easy handle. Once curl retries the transfer and the application frees that handle, the original connection still references the freed memory. Further traffic from the server then triggers the use-after-free.

The researcher’s exploit leaked local memory addresses to bypass address space layout randomization, then overwrote a function pointer to redirect execution.

Why This Matters

No attacks had been reported at disclosure, and reliable code execution is hard to get. An attacker would need to know the target’s curl version, architecture, memory allocator and heap layout. They would also need carefully timed parallel transfers and a tightly constrained payload. curl’s maintainers consider a crash the more likely result of an attempt.

Those requirements explain the High rating rather than Critical, though the memory corruption itself has been demonstrated. The bigger practical problem is knowing where you’re exposed. libcurl is embedded in a long list of applications that don’t advertise it, so checking the curl binary alone will undercount your exposure.

What to Do

Upgrade to curl 8.23.0, or apply the upstream fix to any local builds you maintain. Include applications that link libcurl in your exposure assessment.

Where you can’t update yet, avoid HTTP/2:

• Command-line users can pass --http1.1.
• Applications can set CURLOPT_HTTP_VERSION to CURL_HTTP_VERSION_1_1.

The application setting isn’t a guarantee, because an existing connection using another HTTP version may be reused. Validate actual connection behavior instead of trusting the configuration.

Start with upload workflows that connect to untrusted or externally controlled destinations. The release also fixes 23 other CVEs, all rated Low, which is reason enough to upgrade.

October Patch Tuesday Sets a Record, and One Fix Can’t Wait

Microsoft’s October release is big enough that triage matters more than usual. One Windows Shell flaw is under active attack, and two publicly disclosed bugs have very different prerequisites.

What You Need to Know

Microsoft’s October 2026 Patch Tuesday addresses 1,413 vulnerabilities, a record monthly total. The immediate priority is CVE-2026-96951, an actively exploited Windows Shell security feature bypass rated CVSS 8.8. It lets attackers get around Mark of the Web (MOTW). Flaws in .NET Framework and MessagePack-CSharp were also publicly disclosed, though neither is reported as exploited.

The Actively Exploited Flaw

MOTW is the protection that warns users about potentially unsafe downloaded files, and CVE-2026-96951 lets attackers bypass it. Exploitation requires user interaction, such as clicking a link or opening a specially crafted attachment sent by email or instant message.

The Publicly Disclosed Flaws

CVE-2026-108398, also rated 8.8, is an untrusted search path issue in .NET Framework. It lets an authorized attacker bypass a security feature locally. The feature is Windows Defender Application Control (WDAC), which organizations use to restrict unauthorized applications. Successful exploitation could let applications run that WDAC policy would otherwise block.

CVE-2026-92707, rated 5.3, affects MessagePack-CSharp, a component applications use to serialize and deserialize compact data. An unauthenticated remote attacker can send specially crafted MessagePack data that exhausts memory in affected applications. Exposure depends on whether a service processes attacker-controlled data through the vulnerable library.

Why This Matters

Bypassing MOTW doesn’t mean every malicious attachment will execute. Still, confirmed exploitation puts the Shell flaw ahead of anything whose risk is still theoretical. The other two are publicly known, with no evidence of attacks so far.

The three also have different prerequisites:

Sorting by those conditions is a far better basis for triage than treating 1,413 fixes as equal. Microsoft has attributed its rising patch volumes to growing use of AI to find and fix defects, so expect prioritization to matter more each month.

What to Do

Deploy the Windows Shell fix first. Then look at where .NET Framework application-control protections and MessagePack-CSharp dependencies add exposure.

On individual Windows systems:

1. Open Settings, select Windows Update, and choose Check for updates.
2. Install what’s available and complete any required restart.
3. Check Windows Update again afterward, because a downloaded update isn’t necessarily installed.

Enterprise teams need to close the confirmed exploitation path and also make sure separately maintained application dependencies get remediated. A Windows update won’t fix a vulnerable library bundled inside your own applications.

One Malformed DFS Response Can Crash Windows Server

A bug in a Windows kernel driver lets an attacker blue-screen Windows Server, provided they can first coerce the target into connecting to them. We cover how the attack works and what detection looks like.

What You Need to Know

CVE-2026-70111 affects Windows Server 2019, 2022 and 2025. An attacker first coerces the target into connecting to an attacker-controlled SMB server. From there, the attacker can crash it by delivering a malformed Distributed File System (DFS) referral response.

Microsoft fixed it in the October 2026 updates. The impact is denial of service, and researchers reported no evidence of active exploitation at disclosure.

What Happened

Corelight disclosed CVE-2026-70111 on October 13. Its researchers were testing RPC interfaces and DFS APIs for authentication coercion. These techniques force systems to make outbound connections and can expose NTLM authentication to capture or relay. Instead of the authentication behavior they expected, they got a blue screen.

The documented attack requires network access and a way to make the victim request a DFS referral from attacker infrastructure. After that, one malicious response triggers the crash. The attacker doesn’t need administrative privileges or access to a legitimate domain controller.

The Technical Details

The bug is in mup.sys, the Windows kernel driver that resolves DFS paths. The crash happens when the driver processes a specially crafted DFS_REFERRAL_V3 response containing a NameList referral. A missing validation check lets an offset referencing an empty WCHAR string reach unsafe processing, which causes a kernel null-pointer dereference.

Corelight reproduced the crash in all 11 tests on Windows Server 2022 and all three tests on Windows Server 2019. Windows 10 retained the relevant validation checks and wasn’t affected.

Why This Matters

An attacker can’t take down any reachable server with an unsolicited packet, and the bug doesn’t allow remote code execution. Availability is the whole job of servers like these, though, and that’s what this attacks.

Repeated triggering could keep a server down even with automatic restarts. Coordinated attacks on domain controllers could cause authentication failures across an environment.

Researchers also caution that DFS is one known route into the vulnerable driver and may not be the only one. Limiting remediation to systems with visible DFS activity would leave gaps.

What to Do

Apply the October security updates to every affected Windows Server version. Start with DFS-active systems and infrastructure that supports authentication or shared-file access, but patch beyond the systems where you’ve already seen suspicious DFS activity.

Detection requires visibility into internal SMB2 traffic, not just perimeter monitoring, because the attack relies on coerced connections and malicious referral responses.

Windows System event IDs 41 and 6008 flag unexpected shutdowns. They don’t prove exploitation and may not produce a useful minidump.

Corelight recommends combining malformed-response signatures with Zeek connection evidence, including clusters of S1, RSTR or RSTRH states involving the same server. Those patterns may reflect a crash-and-recovery cycle, so correlate them with other telemetry before drawing conclusions.

Docker Hub’s GhostPat Flaw Let Attackers Act as Other Users

GhostPat sat in Docker Hub for more than two years before two researchers caught it in a feature for converting personal accounts into organizations. We cover how it leaked registry access, what Docker’s investigation turned up, and what to check on your own account.

What You Need to Know

Docker has fixed CVE-2026-105445, a critical Docker Hub vulnerability called GhostPat. It let attackers impersonate other users at the container registry level. Depending on token permissions and the victim’s privileges, an attacker could download private images, upload malicious ones, or delete repository images. The bug existed from August 26, 2024, until the fix, and Docker found no evidence it was exploited.

What Happened

Researchers Peter Molnar and Krisztian Hozak reported CVE-2026-105445 on September 30, 2026, and Docker deployed a production fix less than four hours later. Docker disclosed it publicly on October 12.

The flaw was in Docker Hub’s process for converting a personal account into an organization while keeping existing repository names. During conversion, the user designated an existing account as the organization’s owner. Docker then reassigned the original account’s personal access tokens (PATs) to that owner without rotating or revoking the underlying secrets.

That opened up a simple attack:

1. The attacker creates a throwaway account and generates a PAT.
2. The attacker converts the account into an organization, naming the victim as owner.
3. The victim doesn’t have to approve and isn’t notified.
4. The attacker keeps a token that authenticates as the victim.

The researchers demonstrated access to private repositories and image uploads in the victim’s namespace and in organizations the victim’s account could reach.

The exposure was limited to registry access. The flaw gave no access to Docker’s web interface and couldn’t be used to change passwords, email addresses or MFA settings.

Docker’s Investigation

Docker reviewed every account conversion during the exposure window using registry authentication logs, usage data and identity records. Investigators examined roughly 304,000 image pushes involving transferred tokens and found no evidence of exploitation. Static analysis of the highest-risk public images found no malware or tampering.

Logs couldn’t catch everything, so Docker also used conversion history to identify potentially affected credentials. It notified affected users and organization owners on October 2. On October 8 it deactivated transferred PATs unless owners explicitly opted out.

The fix stops tokens from transferring during conversion. Docker plans to add ownership consent, notifications and auditable token ownership histories as further safeguards.

Why This Matters

Registry-only access sounds limited, but it was enough to publish modified images through a trusted namespace. Those images would reach every downstream system that pulls them, which makes GhostPat a software supply chain problem as much as an account security one.

Docker’s clean findings are reassuring, with one limit: a transferred token that was never used leaves no authentication activity. Logs alone couldn’t surface every exposed credential, which is why the conversion-history review and forced deactivation matter. Docker says users who didn’t receive a notification weren’t exposed.

What to Do

• Check your PATs for anything you don’t recognize, and revoke credentials you don’t need.
• Move organizational automation from personal access tokens to organization access tokens.
• If you got Docker’s notice and opted out of automatic deactivation, those transferred tokens are still active and need a close look.