NVD Is Falling Behind: How to Handle Vulnerability Scanning

On April 15, 2026, NIST announced that the National Vulnerability Database will no longer enrich most CVE submissions. After a 263% surge in CVE submissions between 2020 and 2025 — driven in part by AI-powered vulnerability discovery tools — NIST determined it can't keep pace despite enriching nearly 42,000 CVEs in 2025 (45% more than any prior year). The result: most newly reported vulnerabilities will now be marked as "Not Scheduled" for analysis, and all pre-March 2026 backlogged CVEs have been moved to that same category.

If you run servers, deploy web applications, or manage hosting infrastructure, this directly affects you. The NVD has been the default source of truth for vulnerability severity scores, affected product lists, and remediation guidance for decades. With NIST stepping back from routine enrichment, the security tools and scanning processes you rely on may have significant blind spots. Here's what changed, what it means for your infrastructure, and how to adapt.

What NIST Actually Changed

NIST is shifting to a risk-based enrichment model. Instead of analyzing every CVE submission, they will now focus analyst resources on three categories:

Already exploited vulnerabilities — CVEs listed in CISA's Known Exploited Vulnerabilities (KEV) catalog
Federal impact — CVEs affecting US government software systems
Critical infrastructure software — operating systems, web browsers, identity management systems, network protection products, endpoint security tools, and their open-source equivalents

Everything else — including vulnerabilities in web frameworks, hosting tools, CMS plugins, JavaScript libraries, and most application-level software — will receive a CVE number but no NVD enrichment. That means no NIST-generated severity score, no affected product enumeration (CPE), and no structured remediation guidance.

Key Operational Changes

No independent CVSS scores — NIST will defer to scores provided by CVE Numbering Authorities (CNAs) rather than generating their own assessments. Many CNAs don't provide scores, and when they do, quality varies significantly.
Pre-March 2026 backlog abandoned — CVEs published before March 1, 2026 that haven't been enriched will not receive enrichment
Email-based requests — organizations can request enrichment of specific CVEs via nvd@nist.gov, but review timelines are undefined

Why This Happened

The NVD has been struggling with capacity for years, but two factors pushed it past the breaking point:

AI-Driven Vulnerability Discovery

AI tools designed for security research are finding vulnerabilities faster than humans can analyze them. These tools can scan millions of lines of code, identify patterns that match known vulnerability classes, and generate CVE submissions at a pace that overwhelms human review. The 263% submission surge between 2020 and 2025 reflects this acceleration — and it's only going to increase.

Expanding Software Surface Area

The number of software packages, open-source libraries, and cloud services in active use keeps growing. Every new npm package, WordPress plugin, and containerized service adds to the total attack surface that needs vulnerability tracking. The NVD's human-analyst model simply can't scale to match.

What This Means for Your Hosting Infrastructure

If you manage web servers, databases, or web applications, here's what changes practically:

Your Vulnerability Scanner May Miss Things

Many vulnerability scanning tools depend on NVD data to match installed software versions against known vulnerabilities. Without NVD enrichment:

Scans may not flag vulnerabilities in application-level packages (npm, pip, Composer dependencies)
Severity scores may be missing or inconsistent for newly discovered CVEs
Affected version ranges may not be specified, making it impossible to determine if your installed version is vulnerable

WordPress and CMS Plugins Are a Blind Spot

Plugin vulnerabilities rarely qualify for NIST's priority enrichment categories. This is particularly concerning given the recent WordPress plugin supply chain attack where 31 plugins were bought and backdoored. If a similar vulnerability is discovered tomorrow, it may receive a CVE number but no NVD severity score or affected version information — making it harder for automated scanners to flag it.

Supply Chain Visibility Gets Worse

Between the WordPress supply chain attack, the Vercel breach via a compromised OAuth app, and now the NVD's reduced enrichment, 2026 is shaping up as the year supply chain security visibility took a significant step backward.

Alternative Vulnerability Databases to Use Now

Don't rely solely on the NVD anymore. These alternative sources provide vulnerability data independently:

OSV.dev (Open Source Vulnerabilities)

Google's open-source vulnerability database aggregates advisories from language-specific ecosystems — npm, PyPI, RubyGems, Packagist (PHP/Composer), Go, Rust crates, and more. It provides structured data with affected version ranges, making it particularly useful for application-level dependencies that the NVD will no longer enrich.

# Query OSV.dev API for a specific package
curl -s -X POST "https://api.osv.dev/v1/query" \
  -H "Content-Type: application/json" \
  -d '{"package": {"name": "laravel/framework", "ecosystem": "Packagist"}}' \
  | python3 -m json.tool | head -30

# Or query by a specific CVE
curl -s -X POST "https://api.osv.dev/v1/query" \
  -H "Content-Type: application/json" \
  -d '{"aliases": ["CVE-2026-XXXXX"]}' \
  | python3 -m json.tool

Trivy (Open-Source Scanner)

Trivy scans containers, filesystems, and git repositories for vulnerabilities. It pulls from multiple sources (NVD, OSV, GitHub Security Advisories, vendor databases) so it's not dependent on any single data source:

# Install Trivy
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh

# Scan your project directory for vulnerable dependencies
trivy fs /var/www/myapp

# Scan a specific Docker image
trivy image myapp:latest

# Output as JSON for automated processing
trivy fs --format json --output results.json /var/www/myapp

Snyk

Snyk maintains its own vulnerability database with proprietary research. It covers npm, pip, Composer, Maven, and other ecosystems. Snyk's database often has vulnerability data before it appears in the NVD, making it a useful complement:

# Install Snyk CLI
npm install -g snyk

# Authenticate
snyk auth

# Test your project for known vulnerabilities
cd /var/www/myapp && snyk test

# Monitor for new vulnerabilities continuously
snyk monitor

GitHub Security Advisories

If your code is on GitHub, enable Dependabot alerts. GitHub maintains its own advisory database (GHSA) and will notify you when dependencies in your repository have known vulnerabilities — regardless of NVD enrichment status.

Practical Scanning Setup for Hosting Environments

Here's how to set up vulnerability scanning on your server that doesn't depend solely on NVD data:

Step 1: Audit Your System Packages

# Debian/Ubuntu — check for available security updates
apt list --upgradable 2>/dev/null | grep -i security

# Check which packages are installed and their versions
dpkg -l | grep -E "nginx|mysql|php|node" | awk '{print $2, $3}'

# For CentOS/AlmaLinux
yum check-update --security

Step 2: Scan Application Dependencies

# PHP/Composer projects (Laravel, WordPress plugins)
cd /var/www/myapp && composer audit

# Node.js projects
cd /var/www/myapp && npm audit

# Python projects
pip install pip-audit && pip-audit

These package-manager-level audits pull from their own advisory databases (Packagist, npm, PyPI) and don't depend on NVD enrichment.

Step 3: Set Up Automated Scanning

#!/bin/bash
# /home/user/security-scan.sh — run weekly via cron
# 0 8 * * 1 /home/user/security-scan.sh

LOG="/var/log/security-scan-$(date +%Y%m%d).log"

echo "=== Security Scan $(date) ===" > "$LOG"

# System packages
echo "--- System Updates ---" >> "$LOG"
apt list --upgradable 2>/dev/null >> "$LOG"

# Application dependencies
for dir in /var/www/*/; do
  echo "--- Scanning $dir ---" >> "$LOG"
  if [ -f "$dir/composer.json" ]; then
    cd "$dir" && composer audit 2>&1 >> "$LOG"
  fi
  if [ -f "$dir/package.json" ]; then
    cd "$dir" && npm audit 2>&1 >> "$LOG"
  fi
done

# Check for suspicious file changes
echo "--- File Changes (last 7 days) ---" >> "$LOG"
find /var/www -name "*.php" -mtime -7 -type f >> "$LOG"

# Alert if vulnerabilities found
if grep -qiE "critical|high|vulnerability found" "$LOG"; then
  echo "VULNERABILITIES DETECTED — check $LOG" | mail -s "Security Alert" admin@yourdomain.com
fi

This script runs system update checks, audits Composer and npm dependencies, monitors for unexpected file changes, and sends email alerts if anything critical is found. You can run it weekly via cron on any server with SSH access.

Running this kind of automated scan requires terminal access to your server — which means SSH. On DeployBase, SSH access is available on every hosting plan, along with direct database access (MySQL/MariaDB, PostgreSQL) for auditing database-level security configurations.

The CISA KEV Catalog: Your New Priority List

With NVD enrichment reduced, CISA's Known Exploited Vulnerabilities catalog becomes even more important. These are vulnerabilities confirmed to be actively exploited in the wild — the ones that absolutely must be patched immediately.

# Download the current KEV catalog
curl -s "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json" \
  | python3 -c "
import json, sys
data = json.load(sys.stdin)
print(f'Total KEV entries: {len(data[\"vulnerabilities\"])}')
# Show the 5 most recent
for v in sorted(data['vulnerabilities'], key=lambda x: x['dateAdded'], reverse=True)[:5]:
    print(f\"  {v['dateAdded']} | {v['cveID']} | {v['vendorProject']} — {v['shortDescription'][:80]}\")
"

If a CVE appears in the KEV catalog, patch it immediately — regardless of whether the NVD has enriched it with a severity score.

Key Takeaways

NVD enrichment is no longer comprehensive — most CVEs will get a number but no severity score, affected products, or remediation guidance from NIST
Application-level vulnerabilities are most affected — web frameworks, CMS plugins, and language-specific packages won't get priority enrichment
Use multiple data sources — OSV.dev, Trivy, Snyk, and GitHub Security Advisories provide vulnerability data independently of the NVD
Package manager audits still work — composer audit, npm audit, and pip-audit pull from their own advisory databases
Automate your scanning — weekly cron-based security scans on your server catch vulnerabilities regardless of NVD status
Prioritize KEV catalog items — CISA's known exploited vulnerabilities list is the most actionable dataset when NVD coverage is incomplete
SSH access is essential — running security audits, scanning dependencies, and monitoring file integrity all require terminal access to your server

The NVD's reduced enrichment doesn't mean vulnerability scanning is broken — it means you need to diversify your data sources and take a more active role in scanning your own infrastructure. The tools exist and most are free. Set them up today before the next critical vulnerability goes unscored.

NVD Is Falling Behind: How to Handle Vulnerability Scanning When NIST Can't Keep Up