Researcher Claims Microsoft MSRC Dismissed Dependency Confusion

A researcher claims the Microsoft Security Response Center (MSRC) dismissed a dependency confusion vulnerability affecting Microsoft’s Azure Portal. MSRC reportedly closed the case, claiming confirmed remote code execution evidence did not constitute an exploitable security issue.

The vulnerability was uncovered by Security researcher Wahid Fayad in January 2026 during a routine analysis of JavaScript assets served on portal.azure.com.

While inspecting bundled client-side code, Wahid Fayad identified a require statement referencing an internal NPM module named @FxInternal/NetDiagnostics a scoped package name that, upon checking the public NPM registry, was entirely unclaimed.

Neither the @fxinternal organization namespace nor the netdiagnostics package existed on the public registry.

Dependency confusion attacks exploit a fundamental trust boundary flaw: when a package manager or build environment cannot distinguish between a private internal package and a public registry package sharing the same name, it may silently resolve to the public version.

The attack technique was notably popularized by researcher Alex Birsan in 2021 and has since been documented across major cloud and enterprise environments.

In this case, the internal package name was not merely similar to an existing public package it was entirely absent from the registry, leaving the namespace freely claimable by anyone.

Wahid Fayad registered the @fxinternal namespace and published a placeholder package to the public NPM registry to claim it and begin testing the scope of the exposure.

RCE via Out-of-Band Callback

To validate exploitability, the Wahid Fayad published a higher-version @fxinternal/netdiagnostics package containing a benign out-of-band (OOB) HTTP callback payload a standard proof-of-concept technique used to confirm code execution without causing harm. The callback fired almost immediately after publishing.

The execution was confirmed via an HTTP callback originating from AS8075 (Microsoft Corporation), the autonomous system number assigned exclusively to Microsoft’s infrastructure.

The OOB data exfiltrated during the callback included a local node_modules installation path, an internal hostname matching the pattern DESKTOP-*******, and a username beginning with J**** — all consistent with a Microsoft-controlled developer or pipeline environment executing the package. This constitutes confirmed, evidence-backed Remote Code Execution within Microsoft’s own infrastructure.

The disclosure timeline shows the initial report was filed with MSRC on January 28, 2026, the same day the vulnerability was discovered and the namespace was registered.

MSRC’s Response

MSRC opened a case on January 28, 2026, and the researcher provided additional evidence on January 29 — including logs showing Azure ArisHttpClient validation requests that pointed to backend pipeline involvement. On February 4, 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.”

Wahid Fayad pushed back with proof: the payload, install paths, and IP attribution to Microsoft. MSRC forwarded the evidence to its service team on February 7, but on March 24, 2026, formally closed the case, concluding that the OOB callback originated from “automated security tooling, not a production build or runtime pipeline.”

The researcher formally appealed that same day, followed up on April 14, and received a final refusal on April 21, with MSRC asserting the package was “always loaded from an internal source” and that injection was “not possible.”

Regardless of MSRC’s internal assessment, the package’s presence on the public registry set off automated threat-intelligence pipelines across the broader security ecosystem. Within approximately one week of publication, security monitoring services flagged the @fxinternal/netdiagnostics package as an active supply-chain threat.

The package was subsequently indexed in the GitHub Advisory Database under GHSA-83×6-432q-hpcf, receiving a 9.3 Critical severity rating under CWE-506 (Embedded Malicious Code) a classification applied to packages determined to contain or simulate malicious execution intent.

The advisory’s existence independently validates that third-party security systems treated the event as a genuine, high-severity supply chain threat, irrespective of Microsoft’s internal determination.

Pattern of MSRC Friction in 2026

This disclosure arrives amid heightened scrutiny of MSRC’s vulnerability handling processes. The Nightmare-Eclipse (also known as Chaotic Eclipse) researcher saga which involved six Windows zero-days including BlueHammer (CVE-2026-33825), RedSun (CVE-2026-41091), UnDefend (CVE-2026-45498), YellowKey (CVE-2026-45585), GreenPlasma, and MiniPlasma similarly centered on disputes over attribution and process failures within MSRC. Three of those vulnerabilities were actively exploited in the wild before patches were available.

Microsoft has publicly defended its Coordinated Vulnerability Disclosure (CVD) framework while simultaneously facing legal scrutiny and researcher backlash over inconsistent credit and case closure practices.

The dependency confusion case is distinct in nature — it involves supply chain risk to third-party developers rather than Windows kernel exploitation but shares the same core friction: a researcher presenting empirical execution evidence that MSRC declined to classify as a confirmed vulnerability.

MSRC’s classification of the OOB callback as “automated security ingest” may have merit in an isolated internal context. However, this framing omits a critical downstream risk: the @FxInternal/NetDiagnostics package reference is embedded in public-facing Azure Portal JavaScript assets.

Any external developer, partner environment, or CI/CD pipeline that mirrors, bundles, or builds against Azure Portal assets would automatically resolve this dependency from the public NPM registry — pulling whatever code the namespace owner publishes.

Microsoft’s own security blog, published in May 2026, documented a separate campaign involving 33 malicious NPM packages abusing dependency confusion to harvest reconnaissance data from developer and build environments, underscoring that this threat vector is actively exploited.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.