Two stories broke this week that have nothing to do with each other on the surface — one's about endpoint security research, the other's about an AI code editor — but they share the same root cause: software that trusts a name or a path instead of re-checking what's actually behind it. Here's what happened, and why both are worth ten minutes of your attention.
## Bitdefender just showed how to blind an EDR without touching a single exploit
Windows has a legitimate, documented feature called bind links, implemented by the kernel-level Bind Filter driver (bindflt.sys). It's what Windows Store apps, Windows Sandbox, and Windows containers use to transparently redirect a virtual path onto a real backing path. Nothing sketchy about it on its own — until Bitdefender researchers showed this week that it can be turned into a near-perfect blind spot for endpoint detection and response tools.
They demonstrated three progressively nastier techniques:
-
File-Binding — redirect a trusted DLL path to attacker-controlled content. Their example: quietly hijacking
amsi.dll, so PowerShell believes it loaded the real Antimalware Scan Interface while a fake DLL with identical exports actually runs. - Process-Binding — same trick against executables. Windows reports that a trusted binary is running while the redirected path is actually executing something else entirely.
- Silo-Binding — the sharp one. Using a Windows silo (the isolation primitive behind Windows containers), an attacker gets two separate filesystem views at once: inside the silo, a trusted-looking process runs the payload; outside it, every tool that re-opens the same path — your EDR, AppLocker, Sysmon, a forensic scanner — sees the clean, legitimate file. Nothing on disk gets deleted or replaced. The kernel just hands different callers different answers to the same question.
To make the point concrete, they ran Invoke-Mimikatz under a trusted process identity with silo-binding active. Detected without it, invisible with it. They also used the same underlying primitive to bypass AppLocker, Windows Firewall rules, and Sysmon logging along the way, and separately reported a Docker Desktop bug where a non-admin member of the docker-users group could ride bind links to SYSTEM.
Microsoft's take: low severity, because it requires local administrator access first. Bitdefender's pushback is the same argument the industry eventually accepted about BYOVD (bring-your-own-vulnerable-driver) attacks — "requires admin" describes the starting point of a ransomware playbook, not a reason to wave it through. Their actual technical point is sharper than a severity rating: any control that treats a pathname as a durable identity — checked once at process creation and trusted from then on — is exposed to this class of deception. The fix isn't really "patch this CVE," because there isn't one; it's re-checking the file at the moment you act on it, not just at the moment you first saw its name.
## Cursor will run whatever's sitting in your repo root named git.exe
**
This one's simpler to explain and, honestly, more alarming. Security firm Mindgard found that when Cursor — the AI-powered IDE with north of 7 million active users — opens a project, it searches several locations for a Git binary, including the **workspace root itself. If a repository has a file named git.exe sitting at the top level, Cursor executes it. Automatically. No click, no prompt, no dialog telling you executable content is about to run — and it keeps re-executing on a cadence for as long as the project stays open.
Mindgard's proof of concept was about as blunt as it gets: they renamed Windows Calculator to git.exe, dropped it in a repo root, and opened the folder in Cursor. Calculator windows started stacking up on their own. Swap Calculator for an actual payload and you get silent, repeated code execution with the privileges of whoever opened the project — no prompt injection, no jailbreak, no agent reasoning involved. Cloning the repository is the entire attack surface.
What makes this one sting is the timeline. Mindgard reported it to Cursor on December 15, 2025. Seven months and over 190 shipped releases later, it was still there when they published on July 14. Cursor's CISO invited them into the HackerOne bug bounty program in January, the report was reproduced and confirmed, and then communication reportedly went quiet. Mindgard called publishing full technical detail "the nuclear option," used only once every other path had failed.
There's also a pointed bit of history here: this is functionally the same class of bug as CVE-2020-26233 in Git Credential Manager Core from 2020 — a malicious git.exe at a repo's top level, exploited because Windows checked the current directory before %PATH%. That one got fixed. This one, in a tool an order of magnitude more people now use daily, hasn't been — and per the researchers, Cursor is the third or fourth vendor shown the same class of workspace-executable trick, with reactions ranging from "shipped a fix" to "doesn't count as a vulnerability."
If you use Cursor on Windows: until there's a patch, don't open untrusted or freshly-cloned repositories directly on your host. Use a disposable VM or Windows Sandbox instead. On managed fleets, Mindgard suggests AppLocker or Windows App Control rules that deny execution by path (something scoped to your workspace directories) rather than by file hash, since an attacker-controlled binary's hash is meaningless — it changes every time.
## Quick hits
- Zoom, CVE-2026-53412, CVSS 9.8 — an unauthenticated, network-reachable account takeover in the Windows desktop client, VDI client, and Meeting SDK, all before version 7.0.0. No technical details published, no known exploitation yet, but "no auth required, no user interaction, over the network" is about as bad as an input-validation bug gets. Update now if you haven't.
- JetBrains Hub, CVE-2026-50242, CVSS 10.0 — unauthenticated admin access via direct database-level access, plus CVE-2026-56141 (predictable account-restore codes, CVSS 9.8) in the same component. Hub is the SSO layer sitting in front of YouTrack and TeamCity for a lot of shops, so a compromised Hub instance means a compromised CI/CD pipeline. Fixed in Hub 2026.1.13757; separately, IntelliJ IDEA 2026.1.1 closes a guest-user command execution path in Code With Me.
## The thread connecting all three
Look past the specifics and it's the same failure, three times: a system makes a trust decision at one moment (a path resolves, a filename matches, a request looks well-formed) and then never checks again before acting on it. EDR sensors trusting the image path from process creation. An IDE trusting that a file named git.exe in a repo root is, in fact, git. A client trusting input that never got validated in the first place. None of these are exotic memory-corruption bugs — they're all "the check happened at the wrong time" bugs, which is exactly why they keep showing up in completely unrelated products in the same week.
What's everyone's take on Cursor's seven months of silence — reasonable triage backlog, or a bug bounty program that's mostly there for show?
