DEV Community: Fabio Baensch

Microsoft Just Admitted Windows Has a Tracking ID You Can't Turn Off

Fabio Baensch — Tue, 21 Jul 2026 08:55:21 +0000

Microsoft Just Admitted Windows Has a Tracking ID You Can't Turn Off

Telemetry has been the quiet background hum of the Windows conversation for years — the kind of topic that flares up around a big feature update and then fades. This month it stopped being background noise. A federal criminal complaint forced Microsoft to publicly confirm, for the first time, the existence of a persistent per-device identifier that survives Windows updates, that you can't view through any standard interface, and that — unlike almost everything else in the Privacy settings — has no off switch at all.

How a hacker's VPN stopped mattering

The identifier is called the GDID, short for Global Device Identifier, and it surfaced publicly because of how the FBI caught Peter Stokes, a 19-year-old alleged member of the Scattered Spider hacking group, over a 2025 ransomware attack against a US jewelry retailer. Stokes reportedly ran his operation behind VPNs, proxies, and infrastructure spread across multiple countries — the standard playbook for staying untraceable. None of it mattered, because his Windows PC was quietly reporting a persistent identifier back to Microsoft the entire time, regardless of which IP address or exit node was in front of it.

The unsealed 39-page complaint quotes a Microsoft representative describing GDID as a persistent, device-level identifier designed to uniquely identify a Windows installation across certain Microsoft services and scenarios — physical device or VM, doesn't matter. Once a court order compelled Microsoft to hand over records tied to that identifier, investigators got web activity timestamps, IP history, and infrastructure connections that stitched Stokes' VPN-shielded sessions back into a single, identifiable trail — including something as specific as the exact moment he signed up for an ngrok account.

What GDID actually is, technically

Outside this case, Microsoft has documented GDID exactly once, in the Azure Monitor reference for Delivery Optimization reporting, where a column called GlobalDeviceId gets one sentence: "an identifier used by Microsoft internally." Everything else about how it works came from independent reverse engineering after the complaint went public.

The chain starts the moment you sign into Windows with a Microsoft Account. A system service called wlidsvc talks to login.live.com and gets back a Device PUID — Passport Unique ID — a 64-bit value assigned server-side, not derived from any hardware fingerprint. It lands in your registry at HKCU\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties, formatted as g:<decimal>, and from there the Connected Devices Platform (cdp.dll) is what actually registers and propagates it across Microsoft's services. It survives feature updates and version upgrades. It does not survive a clean reinstall — but if you sign back into the same Microsoft Account afterward, Microsoft has every reason to link the new GDID right back to your old activity anyway, so a reinstall buys you less than it sounds like.

The part that should bother developers specifically

Here's the detail that's genuinely different from every other telemetry knob in Windows: there's no consumer-facing setting, policy, or registry flag that turns GDID generation off. Disabling it isn't offered because it's structurally tied to Windows activation and Microsoft Store functionality — killing it breaks things Microsoft doesn't consider optional. The only lever anyone's found is preventing the device from ever reaching login.live.com in the first place — network-level blocking, not a setting — and that's a fragile, all-or-nothing move that breaks plenty of legitimate functionality along with it.

Compare that to literally every other privacy-relevant identifier Windows exposes: the advertising ID, diagnostic data level, activity history, tailored experiences, Recall — all of them are toggleable through Settings or Group Policy, however deeply Microsoft buries the switch. GDID is the one identifier in the whole stack that was never designed with a toggle in mind, and the reason we know that now is a federal court filing, not a Microsoft disclosure.

What you actually can still control

Since GDID itself is off the table, the practical response most security writers have converged on is tightening everything around it: use a local account where setup still allows it, set diagnostic data to Required-only, kill the advertising ID and personalized-ads toggles, and turn off Activity History and Cloud Content Search so less gets tied to whatever identifier is already there.

I ended up automating exactly that second category — the telemetry surface that is actually toggleable — as part of a Windows cleanup tool I put together and pushed to GitHub today. It's aimed at the broader problem of AppX bloat and undocumented uninstalls (full package scanning, dependency-aware removal, a proper System Restore checkpoint via the native SRSetRestorePoint API before it touches anything), but the telemetry piece specifically flips the Advertising ID off, kills the Windows feedback pop-ups via the Siuf\Rules key, and disables CEIP through SQMClient\Windows — the three levers that are still actually yours to control, done in one pass instead of hunting through Settings submenus. It also has a local file-reputation check against VirusTotal's v3 API before you remove anything you're unsure about, with the API key kept encrypted at rest via DPAPI rather than sitting in plaintext next to the binary. Link's on my GitHub if anyone wants to poke at it — WinPurge-Windows 11 Component Cleaner.

The bigger picture

GDID isn't unique in concept — Apple has a hardware UUID and a DSID, Linux has a machine-id, every major platform maintains some notion of persistent device identity for licensing and abuse prevention. What's unusual is the combination Windows landed on: an identifier with real forensic power, presented with zero documentation, zero user visibility, and zero opt-out, discovered by the public only because it showed up as evidence in a criminal case. It caught a genuinely bad actor this time. The uncomfortable part is that the exact same properties — persistent, cross-VPN, tied to a real identity the moment you sign into an MSA — apply to all 1.6 billion Windows installs, not just the ones running ransomware operations.

Do you run local accounts on your dev machines, or has Microsoft made that enough of a hassle that most people just don't bother anymore?

Today's the Deadline: Three Separate CISA Patch Orders Just Collided on the Same Weekend

Fabio Baensch — Sun, 19 Jul 2026 09:58:59 +0000

It's July 19, 2026, and if you're running federal infrastructure — or honestly, infrastructure of any kind — this week handed you an unusually bad parlay. CISA issued three separate emergency patch orders in the space of four days, for three completely unrelated products, and the deadlines landed on top of each other: Oracle E-Business Suite by July 18, Microsoft SharePoint by today, and Fortinet FortiSandbox by tomorrow. All three are already being actively exploited. Here's the rundown, plus a quieter story about Cursor that's worth knowing regardless of what you patch.

Oracle E-Business Suite: an unauthenticated path to Oracle Payments

CVE-2026-46817 sits in the File Transmission component of Oracle Payments, and it's about as ugly as improper privilege management gets: an unauthenticated attacker with plain HTTP access can take over the component outright, in a low-complexity attack. Oracle actually shipped the fix back in its May 2026 Critical Patch Update — but as Oracle itself noted at the time, plenty of customers hadn't applied it. Threat intelligence firm Defused first spotted exploitation against their Oracle EBS honeypots in late June, weeks before any public proof-of-concept existed, which is the uncomfortable pattern for this one: the attackers found it before the researchers published anything to copy from. Shadowserver is currently tracking over 1,000 internet-exposed Oracle EBS instances, more than half of them in the US. CISA's federal deadline for this one was Saturday, July 18 — yesterday.

SharePoint: the deserialization bug that outlived its own product

CVE-2026-58644 is a critical deserialization-of-untrusted-data flaw (CVSS 9.8) in on-premises SharePoint Server, patched in this month's record-breaking Patch Tuesday and added to CISA's Known Exploited Vulnerabilities catalog on July 16. There's a genuinely rough coincidence buried in the timing: SharePoint Server 2016 and 2019 hit end of extended support on July 14 — the exact same day this CVE was published. So if you're still running either version, you're not just facing a patch deadline, you're facing a patch deadline for a product line Microsoft has simultaneously stopped supporting. CISA lumped it in with three other actively-exploited SharePoint bugs from earlier this month (CVE-2026-32201, CVE-2026-45659, and the AD FS privilege-escalation flaw from Patch Tuesday) in the same alert, which is a good reminder that "patched CVE-2026-58644" and "patched everything SharePoint needs this month" aren't the same checkbox. Federal deadline: today, July 19.

FortiSandbox: three command-injection bugs in the tool that's supposed to catch malware

This is the one with the sharpest irony, since FortiSandbox's entire job is analyzing suspicious files to protect everything else in a Fortinet deployment — FortiGate, FortiMail, FortiWeb all consume its verdicts. CVE-2026-39808 and CVE-2026-25089 are both unauthenticated OS command injection bugs (CWE-78, CVSS 9.1) reachable over HTTP, joining a third related flaw, CVE-2026-39813, that was already being exploited back in June. For CVE-2026-39808, the mechanism is almost insultingly simple: a GET parameter passed straight into a shell call without stripping metacharacters, so a pipe character and a follow-on command is genuinely all it takes — a single curl request gets root. A public PoC for that one has been sitting on GitHub since April. The newer CVE-2026-25089 doesn't have a confirmed working public exploit yet, though Defused reported it's already seeing exploitation attempts they describe as "vibecoded" — their term for exploit code that reads as AI-generated and somewhat sloppy, which is its own small sign of where automated exploit development is heading. CISA's deadline for this pair: tomorrow, Sunday July 20.

Three vendors, three root causes (improper privilege management, unsafe deserialization, command injection), three deadlines inside 48 hours. If your team touches any of the three, this weekend was not a good one to be on call.

Meanwhile: Cursor quietly fixed the git.exe bug — with no advisory and no CVE

Quick update on the Cursor story from earlier this week: the vulnerability that let a malicious git.exe sitting in a repo root auto-execute the moment you opened the project appears to have actually been patched now — just not in the way you'd expect. There's no security advisory, no CVE assignment, and no changelog entry acknowledging what was fixed. Cursor's own count is 33 published security advisories to date, and this issue isn't in any of them. Mindgard, the firm that disclosed it, only confirmed the fix by testing it directly.

What makes this stranger is that a Dark Reading source says Cursor initially told them the report didn't meet the bar for their bug bounty program at all — "out of scope" — before apparently fixing it anyway following the public disclosure. Cursor's public statement calls the seven-month silence a process failure they're addressing, without naming a specific release or committing to retroactive advisory. If you're on a managed fleet, this is a good moment to double check your actual installed Cursor version rather than trusting that "no advisory" meant "no fix" — in this case it apparently means the opposite.

It's also not an isolated pattern. Security firm Cymulate documented the identical class of bug last month across GitHub Copilot CLI, Gemini CLI, and OpenAI's Codex desktop app — all of them resolving helper binaries by searching the working directory first. As of their reporting, GitHub had paid a bounty but downgraded severity to low, Google called it valid with no patch shipped, and OpenAI closed it as not applicable, on the reasoning that an attacker who can replace git.exe already has system access — which misses that cloning an untrusted repo is exactly how that binary gets there in the first place, with no prior access needed.

The shape of the week

Nothing here is a novel vulnerability class — auth bypass, deserialization, command injection, and unsafe binary resolution are all decades-old categories. What's notable is the compression: three federal deadlines landing in the same 48 hours, honeypot exploitation outpacing public PoCs, and a major AI IDE vendor fixing a severe bug while actively declining to say so. If you only have time to check one thing this weekend, check whichever of Oracle EBS, SharePoint, or FortiSandbox you actually run — the exploitation on all three is already confirmed, not theoretical.

Anyone else's on-call weekend get eaten by this particular trifecta?

A Windows Feature Can Blind Your EDR, and Cursor Will Run Whatever's Named git.exe

Fabio Baensch — Thu, 16 Jul 2026 13:48:39 +0000

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?

Patch Tuesday Just Broke Its Own Record, and Two Kernel Bugs Turned 15 in the Same Week

Fabio Baensch — Wed, 15 Jul 2026 20:14:30 +0000

If you blinked this week, you missed a lot. It's July 15, 2026, and the last seven days have quietly been one of the densest stretches in recent memory for anyone who cares about what's happening below the application layer: the biggest Patch Tuesday Microsoft has ever shipped, two Linux kernel vulnerabilities that have been sitting untouched since the early 2010s, and an OpenSSH release that looks boring right up until you read the second paragraph.

Here's the roundup, with the parts that actually matter to us as developers.

Microsoft's biggest Patch Tuesday ever

Tuesday's release is being called Microsoft's largest ever, and depending on whose count you trust — Microsoft's own release notes or Trend Micro's ZDI tracker — the tally lands somewhere between roughly 570 and 622 CVEs across Windows, Office, Exchange Server, SharePoint Server, SQL Server, Azure, and Visual Studio. Windows alone reportedly accounts for the bulk of it.

Three things stood out beyond the raw number:

Three zero-days. Two were already being exploited in the wild before patches landed: a SharePoint Server privilege-escalation flaw (CVE-2026-56164) that lets an unauthenticated attacker escalate over the network, and an Active Directory Federation Services bug (CVE-2026-56155). A third, a BitLocker bypass (CVE-2026-50661) that lets someone with physical access get past device encryption, was already public but hasn't been confirmed as actively exploited.

Kerberos RC4 support is finally, permanently gone. This has been a slow-motion rollout since January, when Microsoft started logging audit events for RC4 ticket usage. April flipped the default encryption type to AES for any account without an explicit override. This week's update removes the RC4DefaultDisablementPhase registry key that let administrators roll that back. If any service account in your environment is still requesting RC4 Kerberos tickets, it can start failing authentication the moment this update lands — worth auditing before it pages someone at 2am. The underlying issue (CVE-2026-20833) is a Kerberoasting vector: RC4-encrypted service tickets can be cracked offline once captured.

RoguePlanet got its official fix folded in. This is the Windows Defender / Malware Protection Engine privilege-escalation bug (CVE-2026-50656) that let a local attacker win a race condition against an NTFS reparse point and land a SYSTEM shell. Microsoft actually shipped the fix out-of-band on July 8–9, ahead of this week's cumulative update, after a public proof-of-concept circulated. If you manage air-gapped or manually-updated fleets, it's worth double-checking that engine version 1.1.26060.3008 (or later) actually reached those machines — the automatic channel doesn't always cover everything.

Two kernel bugs that are old enough to have a mortgage

The Linux side of the week was arguably wilder, mostly because of how long these bugs had been hiding.

Januscape — a 16-year-old KVM escape

CVE-2026-53359, named Januscape, is a use-after-free in the shadow MMU code that KVM uses on x86 hosts. Researcher Hyunwoo Kim found that a malicious guest VM can drive KVM into reusing a stale shadow page-table entry, corrupting host memory in the process. It's the first known guest-to-host KVM escape that works on both Intel and AMD, which makes it a real problem for multi-tenant cloud environments running nested virtualization.

The bug traces back to a commit from August 2010 and was only patched upstream in June 2026 — sixteen years in the wild. Kim originally demonstrated it as a zero-day submission to Google's kvmCTF bounty program, which pays up to $250,000 for a full guest-to-host escape. The public proof-of-concept reliably panics the host; a complete code-execution exploit reportedly exists but hasn't been released.

GhostLock — 15 years in the locking code

CVE-2026-43499, GhostLock, lives in the kernel's real-time mutex code, in the cleanup path for futex priority inheritance. A cleanup routine was clearing the wrong thread's bookkeeping, leaving a dangling reference that an unprivileged local user can turn into root — and it works from inside a container to escape to the host, since the only prerequisite (CONFIG_FUTEX_PI) is on by default nearly everywhere.

It was introduced in kernel 2.6.39 back in 2011 and wasn't fixed until version 7.1. The security firm that found it, Nebula Security, discovered it with an internal AI-assisted scanning tool while chaining it to a Firefox JIT bug for a full browser-to-root exploit chain. Their write-up reports a 97% reliable exploit that gets root in about five seconds, and it earned them a $92,337 bounty through Google's kernelCTF program.

Two vulnerabilities, three-plus decades of combined kernel history, both found this year. Worth checking your kernel version if you're running anything KVM-based or multi-tenant.

The boring update that isn't: OpenSSH 10.4

Released July 6, OpenSSH 10.4 rolled up eight security fixes and got framed by most outlets as routine hygiene. Two are worth knowing about: a malicious SFTP or SCP server could previously redirect where downloaded files land or write into the parent directory of your target path — both now closed. There's also a client-side use-after-free (CVE-2026-60002, CVSS 7.7) triggered when a server swaps its host key mid-session.

The more interesting part is buried further down: OpenSSH now has experimental support for a composite post-quantum signature scheme combining ML-DSA-44 and Ed25519. It's opt-in for now, but it's a good reminder that post-quantum-hybrid key exchange has quietly been the default in OpenSSH since April 2025 — most of us have been using it for over a year without noticing.

The pattern underneath all of it

Two of this week's headline bugs — GhostLock and, separately, Microsoft's own comments about its Windows codebase — point at the same thing: AI-assisted tooling is now finding vulnerabilities that sat untouched for over a decade of manual review. Microsoft has publicly said it expects more security updates going forward specifically because it's leaning on AI to hunt for flaws in its own code. That cuts both ways — the same tooling lowers the bar for attackers, too — but it's probably a big part of why patch counts keep setting records month over month.

None of this changes what you actually need to do this week: patch Windows, audit any service accounts still pinned to RC4 before they break, check your kernel version if you run KVM or containers, and update OpenSSH. But it's a decent snapshot of where things are headed — bugs that survived fifteen-plus years of human eyes are now getting found in weeks, on both sides of the fence.

What's your patch queue looking like this week? Anyone else still finding RC4-dependent service accounts they forgot existed?

DaFuzz?!

Fabio Baensch — Thu, 05 Feb 2026 19:12:53 +0000

DaFuzz is a comprehensive, custom-built fuzzing framework designed to support offensive security operations, specifically within red teaming and penetration testing contexts. Developed primarily in C#, DaFuzz operates as both a graphical user interface (GUI) and a console-based application, providing flexibility depending on the engagement environment and user preference. At its core, the tool is engineered to facilitate vulnerability discovery in software and network services by systematically injecting malformed, unexpected, or deliberately corrupted inputs into target programs.

It is my first real "big" project I've made. I know its not perfect, but I would love to get some reviews and aknowledge some improvement ideas by you guys :) Here we go