Microsoft Allegedly Dismissed Critical Dependency Confusion Flaw

Key Takeaways

• A security researcher identified a dependency confusion vulnerability in Microsoft’s Azure Portal.
• The flaw allowed the researcher to achieve remote code execution (RCE) within Microsoft’s infrastructure by publishing a public NPM package.
• Microsoft Security Response Center (MSRC) dismissed the reported vulnerability, stating it was not exploitable.
• The vulnerability was independently validated and assigned a critical severity rating (CVSS 9.3) by external security intelligence.

Microsoft Dismisses Critical Azure Portal Dependency Confusion Flaw Despite RCE Proof

The Microsoft Security Response Center (MSRC) is facing renewed scrutiny after allegedly dismissing a critical dependency confusion vulnerability affecting the Azure Portal. A security researcher claims MSRC closed the case, asserting that confirmed evidence of remote code execution (RCE) did not constitute an exploitable security issue.

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

Uncovering the Vulnerability

While examining bundled client-side code, Wahid Fayad identified a require statement referencing an internal NPM module named @FxInternal/NetDiagnostics. A check of the public NPM registry revealed that this scoped package name, along with its @fxinternal organization namespace, was entirely unclaimed.

Dependency confusion attacks exploit a fundamental trust boundary issue in package managers. When a build environment or package manager cannot differentiate between a private internal package and a public registry package with the same name, it may inadvertently resolve to the public version. This attack vector was notably popularized by researcher Alex Birsan in 2021 and has since been observed across various enterprise and cloud environments.

In this specific instance, the internal package name was not merely similar to an existing public package; it was completely absent from the public registry, leaving the namespace freely available for registration by anyone.

Wahid Fayad proceeded to register the @fxinternal namespace and publish a placeholder package to the public NPM registry to claim it and begin testing the extent of the exposure.

RCE via Out-of-Band Callback

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

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****. These details were consistent with a Microsoft-controlled developer or pipeline environment executing the package, providing confirmed, evidence-backed Remote Code Execution within Microsoft’s own infrastructure.

The disclosure timeline indicates that 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 and Dismissal

MSRC opened a case on January 28, 2026. The researcher provided additional evidence on January 29, including logs showing Azure ArisHttpClient validation requests that pointed to backend pipeline involvement. However, 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 countered 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. MSRC concluded 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. MSRC asserted the package was “always loaded from an internal source” and that injection was “not possible.”

Despite MSRC’s internal assessment, the package’s presence on the public registry triggered 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). This classification is applied to packages determined to contain or simulate malicious execution intent, independently validating 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 amidst 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, while distinct in nature—involving supply chain risk to third-party developers rather than Windows kernel exploitation—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 hold merit in an isolated internal context. However, this framing overlooks 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.

What You Should Do

• Review Dependencies: Developers should regularly audit all internal and external dependencies used in their projects, especially those referenced in public-facing assets.
• Claim Internal Namespaces: Proactively claim private package names on public registries (e.g., npm, PyPI, NuGet) to prevent malicious actors from squatting on them.
• Implement Private Registries: Utilize private package registries for internal dependencies to ensure they are never resolved from public sources.
• Supply Chain Security Tools: Employ software supply chain security tools to monitor for dependency confusion attacks and other package-related threats.
• Strict Build Environments: Configure build environments to explicitly block or warn about public package resolutions for known internal dependency names.

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.