Your host or a scanner reported a vulnerability: what to do

Updated November 2026

A vulnerability report is a warning, not proof of a break-in. Work through it in order: confirm whether your server is really affected (many scanner findings ignore backported fixes), decide how urgent it is using CISA’s Known Exploited Vulnerabilities catalog and the EPSS score, patch or mitigate, and then tell the reporter what you did.

Do this first.

Write down exactly what was reported: the CVE number, host, port, package and version the scanner saw.
Check whether the CVE is in CISA’s Known Exploited Vulnerabilities (KEV) catalog. If it is, and the service is reachable from the internet, patch or block it today.
Reply briefly to say you received the report and are looking at it.
If the report says the flaw has already been used against you, treat it as an incident: see Incident response.

Where reports come from

Your hosting provider or cloud platform, which scans its address ranges and may set a deadline before it restricts the server.
A compliance scan, for example a payment-card (PCI) scan, or your own scanner such as OpenVAS or Nessus.
A security researcher who emails you or uses the address in your security.txt file.
Unsolicited mass emails that list minor issues and ask for a reward. Check the finding the same way; you do not have to pay for a report you did not ask for.

Step 1: verify the finding

Most scanners decide by version number. Stable distributions such as Debian, Ubuntu and RHEL usually backport fixes: they patch the version they already ship instead of moving to the new upstream release. Red Hat warns that tools which judge “solely on the version number” produce false positives because they ignore backported fixes. Debian’s security FAQ says to compare your exact package version with the one in the advisory. The full method is in Check installed versions.

# Debian / Ubuntu: installed vs available version, and the changelog
apt-cache policy openssh-server
apt-get changelog openssh-server | grep CVE-YYYY-NNNNN
# Debian: list known CVEs for installed packages (use your code name)
debsecan --suite trixie --format detail | grep CVE-YYYY-NNNNN

# RHEL, Rocky, AlmaLinux, Fedora
rpm -q openssh-server
rpm -q --changelog openssh-server | grep CVE-YYYY-NNNNN
dnf updateinfo list --cve=CVE-YYYY-NNNNN              # fix available, not installed
dnf updateinfo list --installed --cve=CVE-YYYY-NNNNN  # fix already installed

Then open the CVE page of your distribution’s tracker (security-tracker.debian.org, ubuntu.com/security, access.redhat.com/security/cve). It shows the fixed version for each release, or says “not affected” or “will not fix”. Also check what the scanner actually saw: a banner from a load balancer, a different virtual host or an old server behind the same IP can all produce findings that do not apply to the machine you are checking.

Step 2: decide how urgent it is

KEV comes first; EPSS and exposure decide the rest. Every path ends with a reply and a re-check.

CISA KEV catalog: A list of vulnerabilities known to have been exploited in the wild. CISA says organizations should use it as an input to their prioritization. If your CVE is listed, it is being used by attackers now.
EPSS (Exploit Prediction Scoring System): A daily score from FIRST that estimates the probability, from 0 to 1, that a CVE will be exploited in the next 30 days. Most scores are near zero; FIRST notes that a probability of 0.10 already sits around the 95th percentile. EPSS does not measure damage or whether your setup is affected, and FIRST says KEV should take precedence when a CVE is listed there.
CVSS: A severity score from 0 to 10. Useful for impact, but a high CVSS score alone does not mean anyone is exploiting the flaw.

Both lists can be checked from the shell (needs curl and jq):

# Is it in CISA KEV?
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq -r '.vulnerabilities[] | select(.cveID=="CVE-YYYY-NNNNN")
           | "\(.cveID) added \(.dateAdded), ransomware use: \(.knownRansomwareCampaignUse)"'

# EPSS probability and percentile
curl -s "https://api.first.org/data/v1/epss?cve=CVE-YYYY-NNNNN" | jq '.data'

Finally, weigh exposure. A flaw in a service listening on the internet matters far more than the same flaw in a library nothing uses. Check with sudo ss -tulpn. The vulnerability list on this site shows KEV and EPSS data for current server flaws.

Step 3: patch or mitigate

# Debian / Ubuntu: update just the affected package, or everything
sudo apt update
sudo apt install --only-upgrade openssh-server
sudo apt upgrade
# Ubuntu: fix one CVE, including through Ubuntu Pro if needed
sudo pro fix CVE-YYYY-NNNNN

# RHEL family (DNF 4)
sudo dnf upgrade --cve=CVE-YYYY-NNNNN
sudo dnf upgrade --security

An update is not active until the running process uses it. Restart the affected service, or reboot for kernel and glibc fixes (these restart services or the machine):

sudo needrestart -r l          # Debian/Ubuntu: list what needs restarting
sudo needs-restarting -r       # RHEL family: is a reboot needed?
sudo systemctl restart ssh     # Debian/Ubuntu service name; "sshd" on RHEL

If there is no fix yet, reduce the risk: block the port with the firewall, limit it to known IP addresses, turn off the affected feature or module as the vendor advisory suggests (a mitigation), or stop the service. Write down what you did and check the advisory daily until the fix ships. More in Emergency patching and Restarts and reboots.

Step 4: reply to the reporter

The NCSC’s vulnerability disclosure toolkit advises: do not ignore the report, thank the finder, tell them the issue is being managed, send updates if the fix takes time, and let them know when it is done so they can retest. You do not have to share technical detail or commit to dates. A short reply is enough:

Subject: Re: [your ticket or subject]

Thank you for the report about CVE-YYYY-NNNNN on host.example.com.
We have confirmed it and installed the vendor fix (package-version)
on [date]. The service was restarted at [time UTC]. Please re-scan
and let us know if you still see the issue.

For a hosting provider’s notice, answer inside their ticket before any deadline, even if only to say when you will patch.

False positives

If the installed version already contains the fix, reply with the evidence: the package version, the distribution advisory or tracker page that lists that version as fixed, and the changelog line naming the CVE. Most scanners let you mark the finding as an accepted exception with that note. Debian’s FAQ points questions about scanner results to the scanner’s vendor. Keep these notes: the same finding usually returns on the next scan.

Confirm it is fixed

The installed version is equal to or newer than the fixed version in your distribution’s advisory.
The service has been restarted (or the server rebooted) since the update.
A re-scan no longer shows the finding, or you have documented why it is a false positive.
The reporter has been told.

Prevent the next one

Turn on automatic security updates so most findings are already fixed when they arrive.
Subscribe to your distribution’s advisories (Security advisories).
Publish a security.txt file at /.well-known/security.txt (RFC 9116). It must contain Contact: and Expires:; the NCSC suggests an expiry less than a year ahead.
Run your own scans first (Vulnerability scanning).

When to get help

Ask your host or a security professional if the flaw is in KEV and you cannot patch or block it, if the vendor has no fix, if logs suggest it was already exploited, or if a compliance deadline is close and you cannot prove the fix.