The 9.3 Critical Vulnerability Microsoft Ignored: A Dependency Confusion Story

Note: This blog post was scheduled for disclosure prior to the recent reports regarding researcher "Nightmare-Eclipse" and their dispute with MSRC over Windows zero-day exploits. While my research is independent and the timing is coincidental, it reflects a similar pattern of challenges regarding transparency and vulnerability attribution within the MSRC reporting process.

The Discovery

While analyzing the JavaScript assets served on portal.azure.com, I discovered a classic, yet critical, misconfiguration: an internal NPM package reference left unclaimed on the public registry.

The asset contained a require statement for an internal module named FxInternal/NetDiagnostics. A quick search on the public NPM registry revealed something I honestly couldn't believe: neither the @fxinternal organization namespace nor the netdiagnostics package existed.

The adrenaline hit me immediately. Seeing a wide-open dependency confusion vector on a Microsoft property felt surreal, and it was sitting right there, completely unclaimed.

Because the dependency name was completely unclaimed, I immediately registered the namespace and published a placeholder package publicly.

The Exploit and Execution

Dependency confusion occurs when a build system or application environment implicitly trusts the public NPM registry to resolve internal dependencies without proper isolation or namespace reservation. I first began hunting these types of vulnerabilities with some early guidance from Shubs.

To test the impact, I published a higher version of the @fxinternal/netdiagnostics package containing a benign out-of-band (OOB) HTTP callback. Almost immediately after publishing, the package was automatically resolved, installed, and executed by a Microsoft-owned environment.

The execution was confirmed via an immediate OOB HTTP callback originating from AS8075 (Microsoft Corporation). The callback was incredibly detailed, exfiltrating the local node_modules path, a specific internal hostname (DESKTOP-*******), and even the username of the account running the process (J****). This was definitive proof: a Microsoft-controlled environment had pulled my code from the public registry and executed it.

The MSRC Experience

I don’t usually disclose reports or do public write-ups, but this case hit differently. It was one of those rare moments where the gap between the evidence on my screen and the response from the vendor was so wide that it actually made me feel like I didn’t understand how security worked anymore.

I promptly reported the vulnerability to the Microsoft Security Response Center (MSRC) as a clear breach of trust boundaries with remote code execution (RCE) impact.

The initial response from MSRC stated:

"We've been investigating this issue and found that the 'FxInternal/NetDiagnostics' dependency is resolved internally on portal.azure.com, which means this would be difficult to exploit as a security vulnerability."

I pushed back, pointing out that the vulnerability had already been successfully exploited inside a Microsoft-controlled environment, resulting in confirmed RCE.

After further review, MSRC closed the case, concluding:

"We determined that this behavior is not a vulnerability... Even though the out-of-band request originated from Microsoft IP space, our analysis concluded this was part of our automated security tooling, not a production build or runtime pipeline."

The Global Impact

While MSRC dismissed the execution as an automated internal security pipeline ingest, closing this case as "not possible to inject an alternate dependency" ignores the reality of the global software supply chain.

The moment I published this package to claim the namespace exposed in Microsoft's public-facing assets, it triggered immediate IPs coming from Microsoft, and a few more after 15-20 seconds.

The automated threat-intelligence alerts across the ecosystem kicked in after a week's time. Because this internal namespace was left completely unprotected on the public registry, security providers automatically flagged the package as an active supply-chain threat.

It was subsequently picked up and indexed under GHSA-83x6-432q-hpcf and added to the GitHub Advisory Database https://github.com/advisories/GHSA-83x6-432q-hpcf with a 9.3 Critical Severity rating for Embedded Malicious Code (CWE-506).

The Takeaway

MSRC’s argument that this was just a "security ingest" doesn’t change the fact that their systems executed my code without a single alert. The only reason the callbacks stopped was because I manually halted the payload after gathering enough proof, including internal hostnames and usernames, to demonstrate the impact.

The risk extends far beyond Microsoft’s internal build servers. Because these package names are baked into public Azure Portal assets, any external developer or partner system building against them would have automatically pulled the malicious dependency from the public registry.

Obscurity isn't a security control. If you don't own your internal namespaces on public registries, you're effectively outsourcing your supply chain security to the first person who decides to register the name.

Disclosure Timeline

• Jan 28, 2026: Discovered vulnerability, registered namespace, and verified RCE via out-of-band callback. Initial report submitted to MSRC.

• Jan 28, 2026: MSRC opens Case for investigation.

• Jan 29, 2026: Provided additional evidence of backend pipeline involvement (Azure ArisHttpClient validation requests).

• Feb 4, 2026: MSRC responds claiming the issue is difficult to exploit and the callbacks might be telemetry.

• Feb 4, 2026: Pushed back with concrete proof of successful exploit, including the payload, install paths, and IP attribution to Microsoft.

• Feb 7, 2026: MSRC forwards additional evidence to the service team.

• Mar 24, 2026: MSRC closes the case, stating no evidence ties the activity to Azure Portal's build or runtime pipeline, and denies dependency confusion.

• Mar 24, 2026: Formally appealed the closure, pointing out the specific internal identifiers and automated backend behavior.

• Apr 14, 2026: Followed up on the unanswered appeal.

• Apr 21, 2026: MSRC refuses to change their assessment, claiming the package was always loaded from an internal source and injection is not possible.

• May 19, 2026: Informed MSRC of the broader ecosystem impact (Critical severity rating by external databases) and intent to disclose publicly.

• Jun 2, 2026: Public disclosure.