CVSS v4 data is missing for source NPM in HTML and JSON reports

[thomasredlin]

Precondition

• I checked the issues list for existing open or closed reports of the same problem.

Describe the bug

This occurs with Vite JS 6.3.5 and GHSA-g4jq-h2w9-997c

When the source of a vulnerability is NPM, there is no CVSS data like cvssv3 or cvssv4 in the vulnerabilities section and also not in the suppressed vulnerabilities section of the HTML as well as the JSON report.

It also shows as unscored and severity Low although it has a CVSS v4 score of 2.3. We also have an automatic suppression rule for everything below 7 that doesn't work in this case. IMHO it's probably all for the same reason.

under vulnerabilities:

            "vulnerabilities": [
                {
                    "source": "NPM",
                    "name": "GHSA-g4jq-h2w9-997c",
                    "unscored": "true",
                    "severity": "low",
                    "cwes": [
                        "CWE-22",
                        "CWE-284",
                        "CWE-200"
                    ],
                    "description": "### Summary\nFiles starting with the same name with the public directory

after adding a manual suppression, under suppressed vulnerabilities:

                {
                    "source": "NPM",
                    "name": "GHSA-g4jq-h2w9-997c",
                    "cwes": [
                        "CWE-22",
                        "CWE-284",
                        "CWE-200"
                    ],
                    "description": "### Summary\nFiles starting with the same name

There is however data for source NVD (under suppressed vulnerabilities):

                {
                    "source": "NVD",
                    "name": "CVE-2025-58751",
                    "cvssv3": {
                        "baseScore": 5.3,
                        "attackVector": "NETWORK",
                        "attackComplexity": "LOW",
                        "privilegesRequired": "NONE",
                        "userInteraction": "NONE",
                        "scope": "UNCHANGED",
                        "confidentialityImpact": "LOW",
                        "integrityImpact": "NONE",
                        "availabilityImpact": "NONE",
                        "baseSeverity": "MEDIUM",
                        "version": "3.1"
                    },
                    "cvssv4": {
                        "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:N/V:X/RE:X/U:X",
                        "source": "security-advisories@github.com",
                        "type": "Secondary",
                        "version": "4.0",
                        "attackVector": "NETWORK",
                        "attackComplexity": "LOW",
                        "attackRequirements": "PRESENT",
                        "privilegesRequired": "NONE",
                        "userInteraction": "PASSIVE",
                        "exploitMaturity": "NOT_DEFINED",
                        "modifiedAttackVector": "NOT_DEFINED",
                        "modifiedAttackComplexity": "NOT_DEFINED",
                        "modifiedAttackRequirements": "NOT_DEFINED",
                        "modifiedPrivilegesRequired": "NOT_DEFINED",
                        "modifiedUserInteraction": "NOT_DEFINED",
                        "safety": "NOT_DEFINED",
                        "automatable": "NOT_DEFINED",
                        "recovery": "NOT_DEFINED",
                        "valueDensity": "NOT_DEFINED",
                        "vulnerabilityResponseEffort": "NOT_DEFINED",
                        "providerUrgency": "NOT_DEFINED",
                        "baseScore": 2.3,
                        "baseSeverity": "LOW"
                    },
                    "cwes": [
                        "CWE-22",
                        "CWE-284",
                        "CWE-200"
                    ],
                    "description": "Vite is a frontend tooling framework for JavaScript. Prior to versions 7.1.5, 7.0.7, 6.3.6, and 5.4.20, files starting with the same name

Version of dependency-check used
The problem occurs using version 12.1.5 of the gradle plugin

Expected behavior
There should be correct CVSS data in the reports.

[chadlwilson]

ODC uses some sort of NPM audit API which is possibly legacy: https://registry.npmjs.org/-/npm/v1/security/audits. This API is returning a zero score with low severity and omits the vector string.

So... this is either broken on NPM or (more likely) they don't support use of this API for these vulns now. I'm not sure of the Audit API is/was intended for use outside the CLI, as it doesn't seem to be properly documented that I can find.

"1107324": {
      "findings": [
        {
          "version": "6.3.5",
          "paths": [
            "vite"
          ]
        }
      ],
      "found_by": null,
      "deleted": null,
      "references": "- https://github.com/vitejs/vite/security/advisories/GHSA-g4jq-h2w9-997c\n- https://nvd.nist.gov/vuln/detail/CVE-2025-58751\n- https://github.com/lukeed/sirv/commit/f0113f3f8266328d804ee808f763a3c11f8997eb\n- https://github.com/vitejs/vite/commit/09f2b52e8d5907f26602653caf41b3a56692600d\n- https://github.com/vitejs/vite/commit/4f1c35bcbb5830290c694aa14b6789e07450f069\n- https://github.com/vitejs/vite/commit/63e2a5d232218f3f8d852056751e609a5367aaec\n- https://github.com/vitejs/vite/commit/e11d24008b97d4ca731ecc1a3b95260a6d12e7e0\n- https://github.com/advisories/GHSA-g4jq-h2w9-997c",
      "created": "2025-09-09T20:55:56.000Z",
      "id": 1107324,
      "npm_advisory_id": null,
      "overview": "### Summary\nFiles starting with the same name with the public directory were served bypassing the `server.fs` settings.\n\n### Impact\nOnly apps that match the following conditions are affected:\n\n- explicitly exposes the Vite dev server to the network (using --host or [`server.host` config option](https://vitejs.dev/config/server-options.html#server-host))\n- uses [the public directory feature](https://vite.dev/guide/assets.html#the-public-directory) (enabled by default)\n- a symlink exists in the public directory\n\n### Details\nThe [servePublicMiddleware](https://github.com/vitejs/vite/blob/9719497adec4ad5ead21cafa19a324bb1d480194/packages/vite/src/node/server/middlewares/static.ts#L79) function is in charge of serving public files from the server. It returns the [viteServePublicMiddleware](https://github.com/vitejs/vite/blob/9719497adec4ad5ead21cafa19a324bb1d480194/packages/vite/src/node/server/middlewares/static.ts#L106) function which runs the needed tests and serves the page. The viteServePublicMiddleware function [checks if the publicFiles variable is defined](https://github.com/vitejs/vite/blob/9719497adec4ad5ead21cafa19a324bb1d480194/packages/vite/src/node/server/middlewares/static.ts#L111), and then uses it to determine if the requested page is public. In the case that the publicFiles is undefined, the code will treat the requested page as a public page, and go on with the serving function. [publicFiles may be undefined if there is a symbolic link anywhere inside the public directory](https://github.com/vitejs/vite/blob/9719497adec4ad5ead21cafa19a324bb1d480194/packages/vite/src/node/publicDir.ts#L21). In that case, every requested page will be passed to the public serving function. The serving function is based on the [sirv](https://github.com/lukeed/sirv) library. Vite patches the library to add the possibility to test loading access to pages, but when the public page middleware [disables this functionality](https://github.com/vitejs/vite/blob/9719497adec4ad5ead21cafa19a324bb1d480194/packages/vite/src/node/server/middlewares/static.ts#L89) since public pages are meant to be available always, regardless of whether they are in the allow or deny list.\n\nIn the case of public pages, the serving function is [provided with the path to the public directory](https://github.com/vitejs/vite/blob/9719497adec4ad5ead21cafa19a324bb1d480194/packages/vite/src/node/server/middlewares/static.ts#L85) as a root directory. The code of the sirv library [uses the join function to get the full path to the requested file](https://github.com/lukeed/sirv/blob/d061616827dd32d53b61ec9530c9445c8f592620/packages/sirv/index.mjs#L42). For example, if the public directory is \"/www/public\", and the requested file is \"myfile\", the code will join them to the string \"/www/public/myfile\". The code will then pass this string to the normalize function. Afterwards, the code will [use the string's startsWith function](https://github.com/lukeed/sirv/blob/d061616827dd32d53b61ec9530c9445c8f592620/packages/sirv/index.mjs#L43) to determine whether the created path is within the given directory or not. Only if it is, it will be served.\n\nSince [sirv trims the trailing slash of the public directory](https://github.com/lukeed/sirv/blob/d061616827dd32d53b61ec9530c9445c8f592620/packages/sirv/index.mjs#L119), the string's startsWith function may return true even if the created path is not within the public directory. For example, if the server's root is at \"/www\", and the public directory is at \"/www/p\", if the created path will be \"/www/private.txt\", the startsWith function will still return true, because the string \"/www/private.txt\" starts with  \"/www/p\". To achieve this, the attacker will use \"..\" to ask for the file \"../private.txt\". The code will then join it to the \"/www/p\" string, and will receive \"/www/p/../private.txt\". Then, the normalize function will return \"/www/private.txt\", which will then be passed to the startsWith function, which will return true, and the processing of the page will continue without checking the deny list (since this is the public directory middleware which doesn't check that).\n\n### PoC\nExecute the following shell commands:\n\n```\nnpm  create  vite@latest\ncd vite-project/\nmkdir p\ncd p\nln -s a b\ncd ..\necho  'import path from \"node:path\"; import { defineConfig } from \"vite\"; export default defineConfig({publicDir: path.resolve(__dirname, \"p/\"), server: {fs: {deny: [path.resolve(__dirname, \"private.txt\")]}}})' > vite.config.js\necho  \"secret\" > private.txt\nnpm install\nnpm run dev\n```\n\nThen, in a different shell, run the following command:\n\n`curl -v --path-as-is 'http://localhost:5173/private.txt'`\n\nYou will receive a 403 HTTP Response,  because private.txt is denied.\n\nNow in the same shell run the following command:\n\n`curl -v --path-as-is 'http://localhost:5173/../private.txt'`\n\nYou will receive the contents of private.txt.\n\n### Related links\n- https://github.com/lukeed/sirv/commit/f0113f3f8266328d804ee808f763a3c11f8997eb",
      "reported_by": null,
      "title": "Vite middleware may serve files starting with the same name with the public directory",
      "metadata": null,
      "cves": [
        "CVE-2025-58751"
      ],
      "access": "public",
      "severity": "low",
      "module_name": "vite",
      "vulnerable_versions": ">=6.0.0 <=6.3.5",
      "github_advisory_id": "GHSA-g4jq-h2w9-997c",
      "recommendation": "Upgrade to version 6.3.6 or later",
      "patched_versions": ">=6.3.6",
      "updated": "2025-09-09T20:55:57.000Z",
      "cvss": {
        "score": 0,
        "vectorString": null
      },
      "cwe": [
        "CWE-22",
        "CWE-200",
        "CWE-284"
      ],
      "url": "https://github.com/advisories/GHSA-g4jq-h2w9-997c"
    },

[chadlwilson]

After a further look, the newer "bulk" API also returns incomplete values below, so this either seems a GHSA or NPM Audit issue or weakness to me.

$ http POST https://registry.npmjs.org/-/npm/v1/security/advisories/bulk \
    Content-Type:application/json \
    vite:='["6.3.5"]'
HTTP/1.1 200 OK
CF-Cache-Status: DYNAMIC
CF-Ray: 9832c3c669b73dd1-SIN
Connection: keep-alive
Date: Mon, 22 Sep 2025 15:16:40 GMT
Server: cloudflare
Set-Cookie: _cfuvid=Fu4DhnvqaDJFvFBcJn84p4UTXLCjAll2rkJCRmM7j3k-1758554200322-0.0.1.1-604800000; path=/; domain=.npmjs.org; HttpOnly; Secure; SameSite=None
Transfer-Encoding: chunked
Vary: Accept-Encoding

{
  "vite": [
    {
      "id": 1107324,
      "url": "https://github.com/advisories/GHSA-g4jq-h2w9-997c",
      "title": "Vite middleware may serve files starting with the same name with the public directory",
      "severity": "low",
      "vulnerable_versions": ">=6.0.0 <=6.3.5",
      "cwe": [
        "CWE-22",
        "CWE-200",
        "CWE-284"
      ],
      "cvss": {
        "score": 0,
        "vectorString": null
      }
    },
    {
      "id": 1107328,
      "url": "https://github.com/advisories/GHSA-jqfw-vq24-v9c3",
      "title": "Vite's `server.fs` settings were not applied to HTML files",
      "severity": "low",
      "vulnerable_versions": ">=6.0.0 <=6.3.5",
      "cwe": [
        "CWE-23",
        "CWE-200",
        "CWE-284"
      ],
      "cvss": {
        "score": 0,
        "vectorString": null
      }
    }
  ]
}

Since even NPM Audit npm audit --json doesn't return a score, I conclude this is not supported and exposed upstream, and there is probably nothing ODC can do. Perhaps they are yet to add CVSSv4 support to the audit APIs?

{
  "auditReportVersion": 2,
  "vulnerabilities": {
    "vite": {
      "name": "vite",
      "severity": "low",
      "isDirect": true,
      "via": [
        {
          "source": 1107324,
          "name": "vite",
          "dependency": "vite",
          "title": "Vite middleware may serve files starting with the same name with the public directory",
          "url": "https://github.com/advisories/GHSA-g4jq-h2w9-997c",
          "severity": "low",
          "cwe": [
            "CWE-22",
            "CWE-200",
            "CWE-284"
          ],
          "cvss": {
            "score": 0,
            "vectorString": null
          },
          "range": ">=6.0.0 <=6.3.5"
        },
        {
          "source": 1107328,
          "name": "vite",
          "dependency": "vite",
          "title": "Vite's `server.fs` settings were not applied to HTML files",
          "url": "https://github.com/advisories/GHSA-jqfw-vq24-v9c3",
          "severity": "low",
          "cwe": [
            "CWE-23",
            "CWE-200",
            "CWE-284"
          ],
          "cvss": {
            "score": 0,
            "vectorString": null
          },
          "range": ">=6.0.0 <=6.3.5"
        }
      ],
      "effects": [],
      "range": "6.0.0 - 6.3.5",
      "nodes": [
        "node_modules/vite"
      ],
      "fixAvailable": {
        "name": "vite",
        "version": "6.3.6",
        "isSemVerMajor": false
      }
    }
  },
  "metadata": {
    "vulnerabilities": {
      "info": 0,
      "low": 1,
      "moderate": 0,
      "high": 0,
      "critical": 0,
      "total": 1
    },
    "dependencies": {
      "prod": 12,
      "dev": 0,
      "optional": 49,
      "peer": 0,
      "peerOptional": 0,
      "total": 60
    }
  }
}

[thomasredlin]

Thank you for the fast analysis @chadlwilson !

After writing up the issue, I came to the conclusion that the missing CVSS v4 values are not the bigger problem here but rather the false positives due to this, as we have to manually add suppressions in our project - even though we already have a general suppression for everything below 7 in place.

So anyway, it really seems to be the missing CVSS v4 support, compare for example GHSA-xcj6-pq6g-qj4x and GHSA-g4jq-h2w9-997c (output shortened and for Vite version 3.1.0):

curl -X POST "https://registry.npmjs.org/-/npm/v1/security/advisories/bulk" \
  -H "Content-Type: application/json" \
  -d '{"vite":["3.1.0"]}'

{
    "vite": [
        {
            "id": 1104201,
            "url": "https://github.com/advisories/GHSA-xcj6-pq6g-qj4x",
            "title": "Viteallows server.fs.deny to be bypassed with .svg or relativepaths",
            "severity": "moderate",
            "vulnerable_versions": "<4.5.12",
            "cwe": [
                "CWE-200",
                "CWE-284"
            ],
            "cvss": {
                "score": 5.3,
                "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N"
            }
        },
        {
            "id": 1107323,
            "url": "https://github.com/advisories/GHSA-g4jq-h2w9-997c",
            "title": "Vite middleware may serve files starting with the same name with the public directory",
            "severity": "low",
            "vulnerable_versions": "<=5.4.19",
            "cwe": [
                "CWE-22",
                "CWE-200",
                "CWE-284"
            ],
            "cvss": {
                "score": 0,
                "vectorString": null
            }
        }
    ]
}

[thomasredlin]

GitHub API supports CVSS v4... see GET https://api.github.com/advisories/GHSA-g4jq-h2w9-997c

There are also these blog posts:
https://github.blog/changelog/2024-09-13-github-security-advisories-support-cvss-4-0/
https://github.blog/changelog/2025-03-27-deprecation-of-cvss-field-in-security-advisories-api/

[chadlwilson]

I understand that. The data source here you are referring to here is the "NPM" data source. That is from the NodeAuditAnalyzer.

That comes from the NPM Audit API, which is independent of GitHub Security Advisories and predates it by many years. You are possibly confused because when NPM was bought by microsoft they merged the backend into GHSA and reassigned identifiers. But the API still exists as an independent product, and npm audit still relies on an independent API. Just because values are modelled within GHSA doesn't mean they are modelled/exposed within the NPM Audit APIs.

ODC does not have direct GHSA integration or support, so that is an entirely different topic - see #6540

[chadlwilson]

I am not sure if it is deliberate of them to not support CVSSv4 in the NPM Registry/NPM Audit API responses. It does seem it could be an oversight, but possibly they are worried that if they started returning CVSSv4 strings certain npm CLI versions would break, depending on how they were originally written.

You might want to try and contact them directly via https://www.npmjs.com/support, as I can't find a GitHub repo that is directly related nor any discussion within the npm GitHub org.

[thomasredlin]

Thank you for the hint! I sent a mail to them via the contact form. Let's see.