NuGet Package Manager Tampering / Spoofing Vulnerability ...

CVE-2019-0757 is a tampering vulnerability in the NuGet Package Manager that Microsoft disclosed and patched in April 2019. The flaw affects the Linux and Mac implementations of NuGet and allows an authenticated, low-privileged attacker on a shared or local system to modify the folder structure of a NuGet package after it has been downloaded but before it is fully trusted and consumed by the build process. Because NuGet is the default package manager for the .NET ecosystem, the bug touched a wide swath of .NET developers, DevOps pipelines, and CI/CD systems that pull dependencies during every build.

Although Microsoft classified CVE-2019-0757 under its "Tampering" bug category rather than "Spoofing," the practical effect blurs the line between the two: an attacker who can rewrite a package's on-disk layout can effectively spoof the integrity of a dependency that developers believe came untouched from a trusted feed. For a software supply chain security company like Safeguard, that distinction matters less than the outcome — a build machine can be tricked into trusting package contents that were altered after the fact.

What CVE-2019-0757 Actually Does

The vulnerability lives in how the NuGet client handles package extraction on non-Windows platforms. When NuGet restores a package on Linux or macOS, it did not adequately validate that the extracted folder structure matched what was expected from the signed or hashed package contents. An attacker with authenticated local access — for example, another user account on a shared build server, or a low-privileged process on a developer workstation — could manipulate files inside the package cache during the window between download and consumption. Because the toolchain later reads from that same cache when resolving references at build or restore time, the tampered content could be silently pulled into a compiled application without any warning to the developer.

This is a classic software supply chain integrity failure. It doesn't require compromising nuget.org, forging a package signature, or publishing a malicious package under a similar name (a "typosquatting" style attack). Instead, it exploits a gap in local trust boundaries: once a package lands on disk, the .NET package manager assumed the contents would remain intact, and that assumption turned out to be exploitable.

Affected Versions and Components

Per Microsoft's advisory and downstream vendor tracking (including Red Hat, which shipped its own fix), CVE-2019-0757 affects:

• NuGet client versions from 4.3.1 through 4.9.4
• .NET Core SDK 1.1, 2.1.500, and 2.2.100
• Visual Studio 2017 for Mac, which bundles the affected NuGet components
• Mono Framework 5.18.0.223 and 5.20.0

Critically, the issue is scoped to the Linux and Mac code paths of NuGet Package Manager — Windows-based NuGet clients were not described as vulnerable in the same way. Any team running .NET builds on Linux CI runners, macOS developer machines, or cross-platform Mono-based toolchains should treat this as directly relevant, even years after the initial disclosure, since legacy build images and pinned SDK versions have a habit of lingering in enterprise pipelines long past their patch date.

CVSS, EPSS, and KEV Context

Microsoft and NVD scored CVE-2019-0757 as follows:

• CVSS v3.1 Base Score: 6.5 (Medium) — Vector: AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
• CVSS v2 Base Score: 4.0 (Medium)

The vector reflects a network attack surface with low complexity, but it requires low-level privileges (PR:L) and no user interaction, with the impact concentrated entirely on integrity (I:H) — no confidentiality or availability loss is scored. That integrity-only profile is exactly what you'd expect from a package-tampering flaw: the danger isn't data theft or downtime, it's silently altered code entering a build.

The EPSS (Exploit Prediction Scoring System) score for CVE-2019-0757 sits at roughly 0.049, or under 5% probability of observed exploitation in the wild within the standard scoring window — consistent with a vulnerability that requires local/authenticated access rather than being remotely, trivially weaponizable. We found no indication that CVE-2019-0757 appears in CISA's Known Exploited Vulnerabilities (KEV) catalog, meaning there's no confirmed record of active exploitation driving an emergency remediation mandate. That said, low EPSS and absence from KEV should not be read as "safe to ignore" — supply chain tampering bugs are frequently exploited quietly, in targeted ways, well before they show up in mass-exploitation telemetry.

Timeline

• April 9, 2019 — Microsoft published the security advisory for CVE-2019-0757 as part of that month's Patch Tuesday release, alongside updated .NET Core SDK and NuGet client builds that corrected the folder-structure validation gap.
• Shortly after — Downstream distributions and vendors that bundle NuGet or Mono, including Red Hat (RHSA-2019:1259), issued their own errata to pull in the fixed packages for affected Linux distributions.
• Ongoing — The CVE remains catalogued in NVD and vendor vulnerability databases; because affected SDK versions (1.1, 2.1.500, 2.2.100) are long out of mainstream support, organizations still running them are considered exposed until they upgrade.

Remediation Steps

1. Update the .NET Core SDK. Move off SDK versions 1.1, 2.1.500, and 2.2.100 to a currently supported release that includes the corrected NuGet client. Microsoft's official Microsoft advisory for CVE-2019-0757 lists the specific fixed builds — confirm your CI images and developer environments match or exceed them.
2. Upgrade the NuGet client independently of the SDK where possible. Since NuGet ships both in-box with the SDK and as a standalone tool, verify the NuGet.exe / dotnet CLI version in every build agent, not just on developer laptops.
3. Patch Mono Framework installations. Teams using Mono 5.18.0.223 or 5.20.0 for cross-platform .NET workloads should upgrade to a release that incorporates the fix.
4. Update Visual Studio 2017 for Mac to a build that bundles the patched NuGet components.
5. Harden local trust boundaries on shared build infrastructure. Because exploitation requires authenticated local access, reducing the number of users/processes with write access to package caches and build directories meaningfully reduces the attack surface, independent of patch status.
6. Rebuild and re-verify packages restored before the patch was applied. If a shared or multi-tenant build machine ran an affected NuGet version prior to remediation, treat previously restored package caches as untrusted and force a clean restore.
7. Pin and verify package integrity end-to-end. Use lockfiles (packages.lock.json), enable package signature verification, and validate hashes as part of CI rather than trusting whatever sits in the local NuGet cache.

How Safeguard Helps

CVE-2019-0757 is a useful case study in why software supply chain security can't stop at "is the dependency itself malicious?" — it also has to answer "can the toolchain that fetches and restores that dependency be trusted?" A vulnerability in the .NET package manager's own handling of package contents sidesteps every control aimed purely at package provenance or registry-level scanning.

Safeguard is built for exactly this class of problem. Our platform continuously inventories the package managers, SDKs, and build tooling in use across your engineering organization — including NuGet client versions, .NET SDK versions, and Mono runtimes — and flags components running versions affected by known CVEs like CVE-2019-0757, well before they become the entry point for a tampered build. Rather than relying on developers to remember which SDK version fixed a five-year-old advisory, Safeguard maps your live software bill of materials against the CVE and Microsoft advisory data feeding NVD, vendor security bulletins, and KEV, so stale toolchains get surfaced automatically.

Beyond detection, Safeguard helps enforce the integrity controls that blunt tampering-class vulnerabilities even when a patch hasn't rolled out everywhere yet: verifying package hashes and signatures at restore time, alerting on unexpected changes to dependency contents between builds, and giving security teams visibility into which CI runners, build images, and developer machines still carry vulnerable NuGet or .NET package manager versions. For organizations managing large, polyglot dependency trees, that combination of continuous SBOM awareness and build-time integrity verification is what turns a vulnerability like CVE-2019-0757 from a lurking risk into a tracked, remediated line item.