NVD API update process retries indefinitely with repeated request failures

[sakenalimbayev]

Precondition

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

Describe the bug
During the vulnerability database update phase, Dependency-Check repeatedly retries NVD API requests without providing enough information about the underlying failure.

Version of dependency-check used
Dependency-Check Core version 12.2.2

Log file
https://gist.github.com/sakenalimbayev/5559dca430a31defdd8cc3b506f2503c

To Reproduce
Steps to reproduce the behavior:

1. Run dependency-check.sh
2. See error

Expected behavior
Report generated successfully

[marcelstoer]

This is not a bug on our side and nothing we can do.

NVD updated their data yesterday. Hence, if ODC updates the local database it'll have to pull ~350'000 records from the NVD. As the NVD infrastructure apparently (still) isn't prepared to handle such load, it errors out with HTTP 503.

#11 93.79 [ERROR] Error updating the NVD Data
#11 93.79 org.owasp.dependencycheck.data.update.exception.UpdateException: Error updating the NVD Data
#11 93.79 	at org.owasp.dependencycheck.data.update.NvdApiDataSource.processApi(NvdApiDataSource.java:387)
#11 93.79 	at org.owasp.dependencycheck.data.update.NvdApiDataSource.update(NvdApiDataSource.java:128)
#11 93.79 	at org.owasp.dependencycheck.Engine.doUpdates(Engine.java:887)
#11 93.79 	at org.owasp.dependencycheck.Engine.doUpdates(Engine.java:859)
#11 93.79 	at org.owasp.dependencycheck.App.runUpdateOnly(App.java:444)
#11 93.79 	at org.owasp.dependencycheck.App.run(App.java:173)
#11 93.79 	at org.owasp.dependencycheck.App.main(App.java:88)
#11 93.79 Caused by: io.github.jeremylong.openvulnerability.client.nvd.NvdApiException: NVD Returned Status Code: 503
#11 93.79 	at io.github.jeremylong.openvulnerability.client.nvd.NvdCveClient._next(NvdCveClient.java:445)
#11 93.79 	at io.github.jeremylong.openvulnerability.client.nvd.NvdCveClient.next(NvdCveClient.java:356)
#11 93.79 	at org.owasp.dependencycheck.data.update.NvdApiDataSource.processApi(NvdApiDataSource.java:343)
#11 93.79 	... 6 common frames omitted

On June 17, 2026, the National Vulnerability Database (NVD) deployed an expansion to its vulnerability assessment metrics and data schema.
...
The deployment process affected approximately 95% of all existing vulnerabilities within the NVD. Consequently, every updated record now includes a new change log entry and an updated “lastModified” timestamp.

Source: https://www.nist.gov/itl/nvd#news-updates

We build the database daily like so (ODC CLI):

# Load the current NVD data and suppression files into the local ./data dir.
# First, get the cached feed files as a basis.
# They are force-updated every 24h, see https://github.com/dependency-check/DependencyCheck_Builder/blob/main/.github/workflows/cache.yml and https://github.com/dependency-check/DependencyCheck_Builder/tree/gh-pages.
# Then fetch the latest delta from the NVD API.
$ bin/dependency-check.sh --updateonly --nvdDatafeed=https://dependency-check.github.io/DependencyCheck_Builder/nvd_cache/nvdcve-{0}.json.gz && \
$ bin/dependency-check.sh --updateonly --nvdValidForHours=0 --nvdApiKey="$NVD_API_KEY"

This is not yet completely optimized but usually keeps us well shielded from NVD infra issues. However, the delta pull (2nd command) now has to pull all changes since 2026-06-16T20:58:59Z - that is the value nvd.api.last.modified has after updating the database from the feed files. Hence, all changes from June 17th would come through the NVD API.

[brampat]

So what is the solution for this?

Either use a different CVE source or use OWASP Dep. Track (easy to run locally using Podman / Docker) and instead of generating your CVE scan in the pipeline, upload / import your SBOM to Dep. Track. Extra points for setting up an OWASP Dep. Track server in your stack and auto-uploading them as part of the pipeline. Dep. track monitors ALL dependencies, and raises issues based on not just CVEs, but also licensing issues. You can set policies, like "should have no CVE's of 7+" and report on which apps are within policy and which are not. And obv. the graphs of CVEs over time is something mgnt will drool over(I hope... if numbers go down)

mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom

[chadlwilson]

https://www.nist.gov/itl/nvd#june-17-2026-nvd-deployment-update-ssvc-and-cve-affected-data-no

https://socket.dev/blog/federal-audit-finds-nist-wasted-funds-with-no-plan-to-clear-nvd-backlog

As @marcelstoer says, nothing this project can do. Wait for the load peak to pass, and properly cache updates, or use the data feed URL with the cache as noted at #8435 (comment) (which will likely be stale for the same reasons as noted here, but might be better than nothing).

Every time NVD make any change to their responses, their whole system goes down. Has been happening for years, and it will not change any time soon.

See #8435 (comment) or the literally dozens of duplicate threads.

[marrak]

What about any workaround by retry chunk in case of 503 524 520 errors?-
There are --nvdMaxRetryCount and --nvdApiDelay but not helping this case.
It generally works to 10-20% but after fail it needs starting from 0 what only increase nvd capability issue.
Nevermind, nvdMaxRetryCount works but requires huge value, 50 is not enough but works with 1000.

[chadlwilson]

@sellersj If people are OK using data feeds rather than the API, there are already two supported choices:

• Use ODC's own data feed built from the API (will likely be a bit stale due to current load issues): --nvdDatafeed=https://dependency-check.github.io/DependencyCheck_Builder/nvd_cache/nvdcve-{0}.json.gz
• Use NVD's 2.0 data feeds: --nvdDatafeed=https://nvd.nist.gov/feeds/json/cve/2.0/nvdcve-2.0-{0}.json.gz

The reason they are not generally recommended as a default is that it uses a lot more bandwidth, and one should probably cache or proxy downloads locally to avoid either getting throttled by GitHub or putting more load on the NVD. Additionally worth noting that a few months ago NVD's own feeds went completely stale for two weeks without any explanation - before being silently fixed.

[chadlwilson]

For what it’s worth, at time of writing neitehr of these two options are working very well.

The ODC "Builder" data feed link above is now very stale as it has not got through a successful NVD API update since 17 June. https://github.com/dependency-check/DependencyCheck_Builder/actions?query=workflow%3A%22nvd%20cache%22 - it will "work", but will be missing data.

The direct NVD 2.0 data feed modified file has grown to over 100MB and now downloads fail to respond at all for long periods (usually hitting long read timeouts).

• Sometimes starts transferring and then gets stuck
• Sometimes eventually completes after 15 minutes, or as long as 60 minutes
• Sometimes downloading at hideously slow rates (like 30-40kB/s) - usually dies part way through.

  nvdcve-2.0-modified.json.gz     10%[=>                 ]  10.62M  37.9KB/s    eta 55m 23s
  

• After it has died, will give 401 unauthorised errors or 404 errors (probably due to some undocumented load mgmt technique or some issue with cache invalidation on Cloudflare when the feed files are being updated every 2 hours). Even when being used via a caching proxy.

  HTTP/1.1 401 Unauthorized
  CF-RAY: a114a55a3d595fb8-LAX
  Connection: keep-alive
  Content-Length: 0
  Date: Thu, 25 Jun 2026 14:26:12 GMT
  Server: cloudflare
  access-control-allow-credentials: false
  access-control-allow-headers: accept, content-type, origin, x-requested-with
  access-control-allow-methods: GET, POST, HEAD
  access-control-allow-origin: *
  cf-cache-status: DYNAMIC
  content-security-policy: frame-ancestors 'self'; base-uri 'self'; object-src 'self'; connect-src 'self' *.google.com *.googletagmanager.com *.google-analytics.com; img-src 'self' data: *.google-analytics.com *.googletagmanager.com; frame-src 'self' https://challenges.cloudflare.com; default-src 'self'; style-src 'self' 'unsafe-inline' unpkg.com; script-src 'self' 'unsafe-eval' 'unsafe-inline' *.google-analytics.com *.googletagmanager.com https://challenges.cloudflare.com https://static.cloudflareinsights.com unpkg.com;
  set-cookie: REDACTED; HttpOnly; SameSite=None; Secure; Path=/; Domain=nist.gov
  strict-transport-security: max-age=31536000
  x-content-type-options: nosniff
  x-frame-options: SAMEORIGIN

Since it is often not just "slow", it is getting stuck and not returning any data for long periods

• most connections will read timeout in these periods (ODC default is 60 seconds, increasing to 2 minutes didn't reliably help)
• caching proxies will give you 504 gateway timeout long before then with this type of bad behavior, as most will not hold connections open for longer than 60-120s with no data

So NVD have broken the data feeds too, right now.

[marcelstoer]

Thanks for documenting this behavior. I've seen most of those cases myself.

So NVD have broken the data feeds too

They have a real talent to break what they touch. I can't complain, though. Not my tax $ they burn.

What I don't understand... They already sit behind Cloudflare (server: cloudflare, cf-ray: a1169eab5e74efa7-EWR) but they treat the feed files as dynamic content, not cached by Cloudflare - even the pre-2026 files (cf-cache-status: DYNAMIC). Even a TTL of a few hours would likely improve the situation a lot.

[chadlwilson]

Yes, I can't see any reason other than total technical incompetence compounded over years.

I suspect

• they are using CF for DDoS protection and some rate limiting but have not configured their backends appropriately for caching or core CDN capabilities at all
• their feed generation and publishing process is atrocious (no other explanation for updating and publishing metadata minutes before the actual files are available and then yielding 401s and 404s for more than ms)

I really have no idea how you make such a hash of a 100MB gzipped file in 2026....

[duttonw]

For those who are not using command line but via maven:

While NVD Api is being flaky.

Don't put this as always for CICD systems. See why at this comment: #8633 (comment)

Add the below to your pom.xml and then use mvn validate -Powasp-manual-data-feed-update to collect the latest.

<profile>
            <!-- Once off - Manual fallback to refresh local NVD (not for CICD automation): mvn validate -Powasp-manual-data-feed-update -->
            <id>owasp-manual-data-feed-update</id>
            <build>
                    <plugins>
                        <plugin><groupId>org.owasp</groupId><artifactId>dependency-check-maven</artifactId><version>12.2.2</version>
                            <configuration>
                                <skip>false</skip>
                                <nvdDatafeedUrl>https://dependency-check.github.io/DependencyCheck_Builder/nvd_cache/nvdcve-{0}.json.gz</nvdDatafeedUrl>
                            </configuration>
                            <executions>
                                <execution>
                                    <phase>validate</phase>
                                    <goals><goal>update-only</goal></goals>
                                </execution>
                            </executions>
                        </plugin>
                    </plugins>
            </build>
        </profile>

Do note that this will blat the database so use with caution.

[WARNING] NVD cache last checked not present; updating the entire database. This could occur if you are switching back and forth from using the API vs a datafeed or if you are using a database created prior to ODC 9.x