Trending Topics

Exploited AD FS Flaw Gives Attackers a Path Through Elevated Access

Microsoft's July 2026 Patch Tuesday disclosed CVE-2026-56155, an actively exploited privilege escalation vulnerability in Active Directory Federation Services.

What You Need to Know

CVE-2026-56155 is already being exploited in the wild, and it targets AD FS, the identity infrastructure that bridges on-premises Active Directory with cloud services like Microsoft 365 and Azure AD. A low-privilege user who already has network access can escalate to administrator level without triggering anything unusual. From there, they control authentication for every connected application. The July 14 patch detects the problem but does not fix it on its own, so admins need to take an additional manual step to confirm exposure.

What's Vulnerable

The flaw stems from Insufficient Granularity of Access Control, meaning AD FS fails to enforce precise permission boundaries between roles. Exploiting it lets an attacker read or manipulate keys they should never have access to and climb to administrator privileges. Once there, the attacker controls the server responsible for regulating authentication across every connected application. That means forged tokens, bypassed federated login, and lateral movement through both on-premises and cloud environments, all without tripping a standard credential alert.

0-Day Initiative flagged this as the only vulnerability among this month's AD FS patches with confirmed active exploitation, and warned that it pairs with remote code execution, raising the stakes considerably.

Why This Matters

Because the patch detects rather than fixes the underlying issue, applying the update is not the end of the process. AD FS sits at the center of federated identity for most enterprise environments, so a compromise here does not stay contained to one system. It cascades across every application that trusts that authentication server, on-premises and in the cloud alike.

What to Do

Apply the July 14 Patch Tuesday update, then check the AD FS Admin event log for Event ID 1132. Microsoft's update writes this event when it finds a misconfigured DKM container ACL on the server. If that event is present, treat the machine as having the vulnerable condition and prioritize remediation. Event ID 1132 does not confirm active exploitation on that specific machine, but it confirms the door is open, so don't wait for further evidence before acting.

An open door doesn't need someone to walk through it yet to be a problem.

Malware OkoBot Targets Cryptocurrency Wallets Across 25 Countries

Kaspersky's research team recently uncovered OkoBot, a sophisticated malware framework built to steal cryptocurrency wallets and credentials.

What You Need to Know

OkoBot has been active since at least April 2025 and runs more than 20 individual payloads through an encrypted SSH tunnel, making it one of the more elaborate crypto-targeting frameworks discovered recently. It reaches victims through two distinct paths, a fake browser error and trojanized developer tools on GitHub, and once installed it can harvest wallet files, open remote desktop access, and quietly persist on the machine. Anyone handling cryptocurrency, whether personally or as part of an organization's operations, should treat this as a live threat to watch for.

How the Attack Works

OkoBot spreads through two separate angles. The first is a ClickFix attack, where victims are shown a fake browser error and tricked into running a malicious PowerShell command to "fix" it. The second is trojanized software distributed through GitHub, disguised as legitimate developer tools. Both paths lead to the same place: a downloader called TookPS that installs SSH on the victim's machine and opens a tunnel to a server the attacker controls.

Once that tunnel is live, an automated bot takes over. It collects system information, harvests wallet files and credentials, opens RDP access for the attacker, and plants a scheduled task named Apple Sync to restore the SSH tunnel if it gets cut off. As part of enabling multiple concurrent RDP sessions, OkoBot also patches or replaces termsrv.dll on the infected system.

Why This Matters

The combination of a legitimate-looking delivery method, an innocuous scheduled task name, and a persistence mechanism that survives disconnection makes OkoBot difficult to catch through casual observation. A victim who dismisses a browser popup or installs what looks like a normal developer tool may not notice anything wrong until wallet funds are already gone.

What to Do

Monitor endpoints for unexpected SSH installations and outbound SSH or SFTP connections to unfamiliar servers. Watch for scheduled tasks with benign-sounding names, particularly one called Apple Sync, that were not created by an administrator. Check whether termsrv.dll has been patched or replaced on systems you're concerned about, since that's one of OkoBot's signature moves.

For anyone handling cryptocurrency wallets directly, never enter a seed phrase into any application window that appears unexpectedly, and treat GitHub repositories distributing common developer tools like SSMS with a healthy dose of skepticism before running anything from them.

A convincing error message and a familiar-looking tool are still the easiest way in.

Two SonicWall SMA 1000 0-Days Actively Exploited, Patches Available Now

SonicWall has disclosed and patched two zero-day vulnerabilities in its Secure Mobile Access 1000 series appliances, both under active exploitation.

What You Need to Know

A CVSS 10.0 score is about as bad as it gets, and that's exactly what CVE-2026-15409 carries. It requires no credentials at all, letting a remote attacker force the appliance to make requests to arbitrary locations. A second, less severe flaw allows authenticated attackers to run arbitrary OS commands as an administrator. Patches are already out, and CISA has given federal agencies a hard deadline of July 17, 2026 to apply them. Anyone running SMA 1000 appliances needs to patch now and check for signs of prior compromise, not just assume the fix closes the door after the fact.

The Vulnerabilities and Who Found Them

CVE-2026-15409 is a server-side request forgery flaw that lets a remote, unauthenticated attacker force the appliance into making requests to arbitrary locations. The lack of any credential requirement is what pushes it to a maximum severity score. CVE-2026-15410, rated 7.2, is a post-authentication code injection bug in the Appliance Management Console. It allows a remote, authenticated attacker to execute arbitrary OS commands as an administrator under certain conditions.

SonicWall's own PSIRT discovered both flaws internally, with Volexity researchers Sean Koessel and Steven Adair credited for helping advance the investigation and identifying an additional indicator of compromise along the way.

Why This Matters

An unauthenticated, maximum-severity flaw in a remote access appliance is precisely the kind of vulnerability attackers move fast on, since it requires no foothold to begin with. Combine that with a paired post-auth flaw that hands over administrator-level command execution, and an SMA 1000 appliance becomes a strong target for anyone looking to establish a foothold in an organization's network. CISA adding both CVEs to the KEV catalog with a firm remediation deadline signals how seriously this is being treated at the federal level, and the same urgency applies well beyond federal agencies.

What to Do

Patch immediately to version 12.4.3-03453 or 12.5.0-02835 or higher. Don't stop at patching, though. Conduct a forensic review before assuming the environment is clean. Check conf.json for unexpected /api/login or /api/logout routes, since these URIs don't exist in legitimate configurations. Look for requests to /wsproxy with suspicious host parameters, and review ctrl-service.log for hotfix rollback entries with path traversal-style names.

If any of these indicators turn up, SonicWall recommends re-imaging physical appliances or redeploying virtual ones, resetting all credentials, and rotating MFA tokens. Patching closes the hole. It doesn't undo whatever already crawled through it.

Cursor 0-Day Lets Malicious Cloned Repos Execute Code Automatically on Windows

AI security firm Mindgard disclosed a zero-day vulnerability in the Windows version of Cursor, the popular AI-powered code editor, after the flaw sat unpatched for roughly seven months.

What You Need to Know

Opening an untrusted repository in Cursor on Windows could silently hand an attacker full code execution under the developer's own privileges, no clicks, no prompts, no warnings. Mindgard reported the issue to Cursor on December 15, 2025, but months of non-responses and an initially dismissed HackerOne submission led the firm to publish full details on July 14, 2026. Cursor says it addressed the issue on July 13, one day before disclosure, but no CVE or official security advisory existed at the time of reporting. Anyone who opens repositories from outside sources in Cursor on Windows should treat this as an immediate concern.

How the Flaw Works

The vulnerability comes down to how Cursor searches for Git executables when loading a project. Instead of limiting that search to trusted system paths, Cursor also looks inside the repository itself. That means an attacker can plant a malicious git.exe at the top level of a repository, and the moment a developer opens that repo in Cursor on Windows, the attacker's binary runs automatically with the logged-in user's full privileges.

Mindgard demonstrated the issue safely by swapping git.exe for the Windows calculator, which launched repeatedly for as long as the repository stayed open. The firm confirmed the flaw was still present in Cursor 3.2.16 as of April 30, 2026, well after the initial report.

Why This Matters

A code editor that silently executes an attacker's binary just from opening a repository turns an everyday developer action into a full compromise vector. There's no phishing link to click and no permission prompt to notice, which means the usual instincts developers rely on to spot something wrong don't apply here. With no formally confirmed patched version or published advisory at the time of reporting, teams can't simply update and move on. They need to actively reduce exposure in the meantime.

What to Do

Until a patched version is formally confirmed, open untrusted repositories inside Windows Sandbox or a disposable VM rather than directly in Cursor on your primary machine. Enterprise teams should use AppLocker or Windows App Control to block execution of git.exe from developer working directories. Avoid relying solely on hash-based blocking, since an attacker can simply alter the binary's contents to slip past it.

Compromised AsyncAPI npm Packages Deliver Multi-Stage Botnet Malware

Four packages in the @asyncapi namespace on npm were found distributing a sophisticated multi-stage botnet loader, according to joint findings from OX Security, SafeDep, Socket, and StepSecurity.

What You Need to Know

The affected versions, @asyncapi/generator-helpers@1.1.1, @asyncapi/generator-components@0.7.1, @asyncapi/generator@3.3.1, and @asyncapi/specs v6.11.2 and v6.11.2-alpha.1, have all been unpublished from the registry, but any environment that loaded one of them during a build or developer workflow should be treated as potentially compromised. The attacker didn't steal an npm token. They gained push access to the repositories and used each project's own legitimate GitHub Actions release pipeline to publish the malicious versions, meaning the packages carried valid SLSA provenance attestations and appeared fully legitimate. The payload itself, a framework called Miasma, is built for persistence, credential theft, and self-propagation across multiple package ecosystems.

How the Attack Worked

Instead of compromising an npm token directly, the attacker gained push access to the source repositories and published malicious versions through npm's GitHub OIDC trusted-publisher integration, riding on each project's own legitimate release pipeline. This meant the packages came with valid SLSA provenance attestations attached. Provenance only proves that an authorized workflow published a package, not that the commits triggering that workflow were clean, and this attack exploited exactly that gap.

The malicious code also sidesteps a common detection pattern. Rather than firing through an install hook, which defenders commonly monitor, it activates when the poisoned module is loaded via require() during a normal build or CI job.

What the Payload Does

The delivered framework, Miasma, is built around 744 bundled modules and supports six separate command-and-control channels: HTTP, IPFS, BitTorrent DHT, Nostr relay, libp2p GossipSub, and an Ethereum smart contract. It's capable of credential theft, AI tool poisoning, lateral movement across local networks, and worm-like propagation across npm, PyPI, and Cargo registries.

Miasma also includes a dead man's switch that wipes local directories if a monitored stolen token gets revoked, and it actively avoids running on sandboxes, VMs, and systems with Russian locale settings or security tools from CrowdStrike, SentinelOne, Microsoft Defender, and others.

Why This Matters

This attack sidesteps two of the main things defenders lean on to trust a package: the absence of a suspicious install hook, and the presence of provenance attestation. Both looked clean here. That means teams relying purely on provenance checks or install-hook monitoring as their supply chain defense had a real gap, and the sandbox and security-tool evasion built into Miasma suggests the attacker anticipated exactly the kind of analysis environment defenders would use to catch it.

What to Do

Check whether your environment loaded any of the affected package versions during a build, CI job, or developer workflow, and treat any match as a potential compromise requiring investigation, not just a version bump. Review CI/CD pipelines for unexpected push access or unauthorized workflow triggers on projects you depend on. Don't treat SLSA provenance or the absence of an install hook as sufficient proof of safety on their own, since this incident demonstrates both can be present on a compromised package.

A legitimate pipeline publishing a package doesn't mean a legitimate person triggered it. If your team needs help auditing CI/CD pipeline access or supply chain exposure, Hunter Strategy can help. Get in touch with us here.