Microsoft MSRC Faces Scrutiny After Researcher Claims Azure Portal Dependency Confusion Report Was Dismissed

Microsoft’s vulnerability handling process is facing new scrutiny after security researcher Wahid Fayad claimed the Microsoft Security Response Center dismissed a dependency confusion report involving Azure Portal assets. The case centers on an internal-looking npm package reference, @FxInternal/NetDiagnostics, which Fayad says appeared in JavaScript served from portal.azure.com.

According to Fayad’s public disclosure, the public npm registry did not contain the @fxinternal scope or the netdiagnostics package when he checked it in January 2026. He then registered the namespace and published a controlled proof-of-concept package to test whether any Microsoft-controlled system would retrieve it.

The researcher claims the package generated an out-of-band callback from Microsoft-owned infrastructure, with limited execution context such as a local node_modules path, a machine name pattern, and a username. Microsoft reportedly told the researcher that the activity came from automated security tooling rather than a production build or runtime pipeline.

Why the Report Raises Supply Chain Concerns

Dependency confusion attacks exploit the gap between private package names and public package registries. If an internal dependency name is visible but not reserved publicly, an attacker can register the same name on a public registry and hope a build system, developer machine, or automated tool resolves the wrong package.

The technique became widely known after researcher Alex Birsan published his 2021 dependency confusion research, which showed how public packages could be used to reach major enterprise environments. The Azure Portal claim follows the same broad risk model, although Microsoft’s reported position disputes the production impact.

The core question is not only whether Azure Portal customers were directly exposed. It is also whether a Microsoft-controlled environment pulled and executed third-party code from a package name that should have been protected. That distinction matters for cloud vendors, CI/CD pipelines, and downstream developers that depend on trusted package resolution.

What Happened in the Microsoft Dependency Confusion Case

Item	Details
Researcher	Wahid Fayad
Reported target	Azure Portal JavaScript assets served from portal.azure.com
Package name	@fxinternal/netdiagnostics
Reported issue	Unclaimed public npm namespace matching an internal-looking dependency reference
Researcher claim	A controlled package triggered an out-of-band callback from Microsoft-owned infrastructure
Microsoft’s reported position	The callback came from automated security tooling, not a production build or runtime pipeline
Third-party ecosystem signal	The package later appeared in the GitHub Advisory Database as malware
Broader threat context	Microsoft later reported an active campaign involving 33 malicious npm packages using dependency confusion

MSRC Reportedly Closed the Case After Review

Fayad says he submitted the report to MSRC on January 28, 2026, and provided more evidence in the following days. The researcher claims Microsoft first said the dependency was resolved internally on portal.azure.com, making the issue difficult to exploit as a security vulnerability.

After further exchanges, MSRC reportedly closed the case on March 24, 2026. The reported conclusion said the callback came from automated security tooling rather than a production pipeline. Fayad says he appealed the decision, but MSRC maintained that the package was loaded from an internal source and that injection was not possible.

That leaves two different readings of the same event. Microsoft’s reported view focuses on whether the tested path created a production security boundary issue. Fayad’s view focuses on proof that a Microsoft-controlled environment fetched and executed code from a public package namespace that matched an internal-looking dependency reference.

GitHub Advisory Database Flagged the Package as Malware

The @fxinternal/netdiagnostics package was later indexed in the GitHub Advisory Database under GHSA-83×6-432q-hpcf. GitHub’s advisory labels the package as malware and says any computer that installed or ran it should be treated as fully compromised.

That advisory does not settle the dispute over Microsoft’s internal exposure. It does show that public security tooling treated the published package as dangerous once it appeared in the npm ecosystem.

The difference is important. A vendor may decide that a callback came from a contained scanning environment. A package-security platform may still classify the artifact as malware because any other machine that installs it could execute untrusted code.

Microsoft’s Own Research Shows the Same Attack Class Is Active

The dispute comes as Microsoft’s threat intelligence team has warned that dependency confusion is still being used in real attacks. In a May 29 report, Microsoft said attackers published 33 malicious npm packages under scopes that mirrored real internal corporate namespaces.

The Microsoft Security Blog said those packages used install-time execution to collect reconnaissance data from developer and build environments. Microsoft said the packages impersonated internal names across multiple organizational scopes and used obfuscated payloads.

That research does not confirm Fayad’s Azure Portal claim, but it strengthens the broader point. Internal package names exposed to public registries can become a real supply-chain risk when package managers, build tools, or automation resolve dependencies incorrectly.

What Dependency Confusion Means for Developers

Dependency confusion remains dangerous because it can turn ordinary package installation into code execution. Many package ecosystems support lifecycle scripts, which can run automatically during install or build steps.

Birsan’s original research showed that internal package names can create risk when companies mix private dependencies with public registries. In modern environments, the same issue can affect cloud build workers, developer laptops, automated scanners, test systems, and CI/CD runners.

For Microsoft, the allegation also touches the credibility of vulnerability triage. MSRC’s public Coordinated Vulnerability Disclosure process says researchers give vendors time to investigate and prepare fixes before detailed public disclosure. In disputed cases, the hardest question often becomes whether the vendor’s impact assessment matches the researcher’s evidence.

Key Defensive Steps for Organizations

Security teams do not need to wait for a vendor dispute to settle before reducing their own exposure. Any organization that uses private packages should assume public namespace squatting is a realistic threat.

• Claim internal package scopes on public registries before attackers can register them.
• Configure package managers to use explicit private registries for internal dependencies.
• Block public registry fallback for private package scopes.
• Pin dependency versions and use lockfiles in CI/CD pipelines.
• Review install scripts, preinstall hooks, postinstall hooks, and build scripts before allowing packages into production pipelines.
• Monitor public registries for packages that match internal naming patterns.
• Rotate secrets if a suspicious package ran on a developer workstation or build runner.

Microsoft’s 33-package investigation found that attackers used package metadata, internal-looking names, and install hooks to make dependency confusion more convincing. The same behaviors should trigger alerts in enterprise package monitoring and software supply chain controls.

Why the MSRC Dispute Matters

The report does not publicly prove that Azure Portal production systems were compromised. It does, however, highlight a recurring tension in vulnerability response: researchers often focus on demonstrated execution, while vendors focus on whether that execution crosses a defined customer-impacting security boundary.

Both views can matter. A contained automated scanner may reduce customer risk, but execution inside any corporate environment can still expose secrets, hostnames, usernames, build paths, or internal architecture clues if controls fail.

The practical lesson is clear. Companies should not rely on internal naming conventions as a security control. If a private dependency name appears anywhere in public-facing code, documentation, logs, bundles, or build artifacts, the matching public namespace should be reserved and protected.

What Microsoft and Other Vendors Can Learn

Large vendors can reduce future disputes by separating three questions during triage: did third-party code execute, where did it execute, and what customer or internal risk resulted. A closure notice that addresses only one of those points can leave researchers and defenders with unanswered questions.

MSRC’s Coordinated Vulnerability Disclosure framework gives Microsoft a formal process for handling reports, but high-friction cases show why transparent impact explanations matter. Vendors do not need to reveal sensitive infrastructure details to explain whether an observed callback came from a sandbox, scanner, build worker, or customer-facing service path.

Microsoft’s own dependency confusion research shows that attackers understand this class of supply-chain weakness. That makes namespace reservation, strict registry scoping, and clear disclosure handling important for Microsoft and every other organization that builds software at scale.

FAQ