ProGet pnpm audit reports no vulnerabilities

[Ashley]

Hi,

We are having issues with pnpm not picking up the package vulnerabilities when running pnpm audit. It always returns no vulnerabilities when pointing at ProGet, but returns correct results when querying the public npm registry.

It looks like npm audit does work as expected, so this is specific to whatever pnpm is expecting.

Looking at the response from npmjs and ProGet, the only real difference I can see is that ProGet is not always setting severity, and that there are some encoding issues in the vulnerable_versions and title fields.

registry.npmjs.org:

{
  "lodash": [
    {
      "id": 1120370,
      "url": "https://github.com/advisories/GHSA-xxjr-mmjv-4gpg",
      "title": "Lodash has Prototype Pollution Vulnerability in `_.unset` and `_.omit` functions",
      "severity": "moderate",
      "vulnerable_versions": ">=4.0.0 <=4.17.22",
      "cwe": ["CWE-1321"],
      "cvss": {
        "score": 6.5,
        "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L"
      }
    },
    {
      "id": 1115806,
      "url": "https://github.com/advisories/GHSA-r5fr-rjxr-66jc",
      "title": "lodash vulnerable to Code Injection via `_.template` imports key names",
      "severity": "high",
      "vulnerable_versions": ">=4.0.0 <=4.17.23",
      "cwe": ["CWE-94"],
      "cvss": {
        "score": 8.1,
        "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H"
      }
    },
    {
      "id": 1115810,
      "url": "https://github.com/advisories/GHSA-f23m-r3pf-42rh",
      "title": "lodash vulnerable to Prototype Pollution via array path bypass in `_.unset` and `_.omit`",
      "severity": "moderate",
      "vulnerable_versions": "<=4.17.23",
      "cwe": ["CWE-1321"],
      "cvss": {
        "score": 6.5,
        "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L"
      }
    }
  ]
}

ProGet:

{
  "lodash": [
    {
      "cvss": {
        "score": 7.9,
        "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:H/SI:H/SA:H/E:P"
      },
      "cwe": ["CWE-1321"],
      "id": "PGV-2605591:Contain",
      "severity": "critical",
      "title": "[Contain] PGV-2605591: Lodash has Prototype Pollution Vulnerability in \u0060_.unset\u0060 and \u0060_.omit\u0060 functions",
      "url": "https://PROGET-SERVER/vulnerabilities/vulnerability?vulnerabilityId=PGV-2605591",
      "vulnerable_versions": "\u003E=4.0.0 \u003C4.17.23"
    },
    {
      "cvss": {
        "score": 8.1,
        "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H"
      },
      "cwe": ["CWE-94"],
      "id": "PGV-262413Y:Monitor",
      "severity": null,
      "title": "[Monitor] PGV-262413Y: lodash vulnerable to Code Injection via \u0060_.template\u0060 imports key names",
      "url": "https://PROGET-SERVER/vulnerabilities/vulnerability?vulnerabilityId=PGV-262413Y",
      "vulnerable_versions": "\u003E=4.0.0 \u003C4.18.0"
    },
    {
      "cvss": {
        "score": 6.5,
        "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L"
      },
      "cwe": ["CWE-1321"],
      "id": "PGV-262413X:Monitor",
      "severity": null,
      "title": "[Monitor] PGV-262413X: lodash vulnerable to Prototype Pollution via array path bypass in \u0060_.unset\u0060 and \u0060_.omit\u0060",
      "url": "https://PROGET-SERVER/vulnerabilities/vulnerability?vulnerabilityId=PGV-262413X",
      "vulnerable_versions": "\u003C4.18.0"
    }
  ]
}

ProGet Info
Web UI: 2026.2 (Build 16)
DB Schema: 26.0.2.16
Database Server: Microsoft SQL Server 2022

[stevedennis]

Hi @Ashley ,

Thanks for the detailed information. I haven't set up an npm/pnpm environment to test this, but I wanted to share a few thoughts, and see if you can test something.

I doubt the encoding is an issue.

Idea 1: Different API Endpoints

There are two vulnerability APIs, and I think one is kind of deprecated? Anyway ProGet has never implemented that one.

If you haven't already, I'd make sure pnpm is calling the same endpoint.

Idea 2: Null Severity

In the example you provided, severity is only set on one of the three items. If this is the problem, then it would mean that pnpm is erroring when processing the resultset.

This will be trivial to verify: can you (temporarily) override the assessment of PGV-262413Y and PGV-262413X to be Contain? Then, run it again. You should see a "critical" serverity in the results then.

That being said, this is a bug. These vulnerabilities should be suppressed and not show up in the results at all; we'll fix that via PG-3317.

Idea 3: Nonnumeric Id

The other possibility; ProGet is using a string identifier, but npm is using an integer identifier. I suspect that npm used to do CVEs that field, but who knows. None of this is documented.

I'm not really sure how how test this without some kind of proxy/MITM interception, or reverse-engineering their source code.

Maybe this is a GitHub issue on the pnpm repository?

Thanks,
Steve

[Ashley]

Hi,

Thanks for the speedy reply! We investigated your ideas and can confirm that both the npm and pnpm CLIs are calling the newer /bulk endpoint that ProGet implements.

We decided to build a simple mock API that implements the audit endpoint. That we can easily play around with the JSON response to see what is causing the issues.

pnpm

Reproduction steps:

1. Setup a simple web server to respond to any POST request with a json payload.
2. Test pnpm against the payload from registry.npmjs. Works as expected.
3. Stringify the existing ids. No known vulnerabilities found.

Outcome:
It is the the non-numeric IDs that are causing the issue with pnpm. You can see in pnpm source that they have typed the ID field response as a number, I didn't look any further in the source code and just assume that there is some validation/catch to handle non-numeric ids.

The lack of a formal schema from GitHub really doesn't make this easy to implement - so no wonder there are issues with other npm clients! It appears the general sentiment is to follow the npm-cli source code for the endpoint schema which it looks like you have done, although it is Javascript and not typed or obvious what each field is meant to contain .

It does however look like the limited unit tests for the audit command are only using numbers for the id field - which may implicitly reference that the field is meant to only contain a number.

To ensure consistency with the public npm registry, would it be possible to change ProGet to use a number for the id field on the audit response? The public npm registry appears to be the only "standard" and so to prevent issues with future npm releases/clients - can I please get your thoughts on this?

Yarn & Bun

We also test Yarn and Bun to see how they behave...

Neither of them appeared to care about the id being a string, however the results were still not consistent.
Bun: Shows 3/3 Vulnerabilities, correct ️
Yarn (v2+): Shows 1/3 Vulnerabilities, incorrect ️. I assume this is because 2 out of 3 have null for the severity field value.

Thanks!
Ashley

[stevedennis]

Hi @Ashley ,

Amazing, thanks for this investigation! This is very helpful.

You've also captured the exact issue we have with a lot of these APIs; no real specs (or worse... wrong specs), which involves a reverse engineering effort. This quote is wonderful:

In summary, due to the lack of an official JSON schema and potential changes between npm versions, it's crucial to treat the npm audit --json output structure as subject to change. Relying solely on the npm CLI source code for the most accurate and up-to-date information is recommended, along with implementing robust version checks and testing in your development processes.

Wouldn't it be nice if we could build our products like that! Anyway, I was curious and I asked internally, and the original engineer is almost certain that npmjs used to have the CVE number there, which we also used to emit until changing to PGVD number in ProGet 2023. But that is consistent with their position of "we don't do specs, just read the latest commit to figure it out.

But it doesn't really matter, that's what we have now...

To ensure consistency with the public npm registry, would it be possible to change ProGet to use a number for the id field on the audit response?

If you discovered this in ProGet 2025, we'd just change it in ProGet 2026 and not worry about it. But we need to be super-careful making API changes in a maintenance release. We can't quite get away with Microsoft/GitHub levels of quality :)

Seemingly harmless changes lead to broken builds, which are really painful to debug; for example, we recently added upload-time to PyPI API. That caused older versions of the pip client to break due to a bug in how they parsed dates.

There are probably too many client/versions to answer the question "what is this field even used for and what are the consequences of changing it?"

Perhaps an easier route is to just get pnmp to change to a string, like the rest of them? Or, just ignore it and "let it be"?

Over time, if you follow our recommend best practices, these audits will show fewer and fewer vulnerabilities. We plan to continuously refine the PVRS algorithm to better combat both "vulnslop" (i.e. AI-discovered and AI-generated vulnerabilities that cannot be exploited in any real-world scenario nor would cause any real-world harm if so) and misreporting.

Thanks,
Steve