Medium risk Port 22 SSH · Port 80/443 web server

Outdated OpenSSH or Apache found: what it means and how to fix it

By Stephane Meus, CEH, PenTest+ · Updated 11 October 2026 · 7 minute read

What the finding means

When anything connects to SSH on port 22 or to a web server on port 80 or 443, the server usually announces its software and version. For example:

SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.13
Server: Apache/2.4.7 (Ubuntu)

FreshScanSentry's scan uses Nmap to read that announcement, then matches the version against the vulners.com database of published vulnerabilities. The report summarises the result:

Those numbers look alarming. Two things decide how worried you should be: whether the flaws are really unpatched on your server, and how exposed the service is.

Why it matters

• Attackers automate this. Internet-wide scanners read the same version banners and match them to public exploits. Old versions get attacked more because the exploit code is freely available.
• Some OpenSSH flaws are serious. For example, "regreSSHion" (CVE-2024-6387) allowed remote code execution on many Linux OpenSSH servers without a password. CVE-2023-38408 affected ssh-agent forwarding, and "Terrapin" (CVE-2023-48795) weakened SSH connection security.
• Some Apache flaws are serious too. CVE-2021-41773 let attackers read files outside the website, and run commands on some setups, on one specific Apache version. Many others cause crashes or bypass access rules.
• Old versions usually mean an old operating system. If OpenSSH and Apache are years out of date, the rest of the server probably is too.

Step 1: check whether it's really unpatched

This step saves the most time. Linux distributions such as Ubuntu, Debian, Red Hat, Rocky and AlmaLinux "backport" security fixes. They patch their own build of OpenSSH or Apache but keep the original version number. So OpenSSH 6.6.1p1 Ubuntu-2ubuntu2.13 can contain fixes released long after 6.6.1 came out.

Log in to the server and check:

Ubuntu or Debian

# Installed package versions
dpkg -l openssh-server apache2

# Which CVEs the installed packages already fix
apt changelog openssh-server | grep -o 'CVE-[0-9]*-[0-9]*' | sort -u
apt changelog apache2 | grep -o 'CVE-[0-9]*-[0-9]*' | sort -u

# Are updates waiting?
sudo apt update && apt list --upgradable

Red Hat, Rocky, AlmaLinux or CentOS

rpm -q openssh-server httpd
rpm -q --changelog openssh-server | grep -o 'CVE-[0-9]*-[0-9]*' | sort -u
sudo dnf check-update

Then check the operating system release itself. If it is past its end of life (for example Ubuntu 14.04 or 16.04, Debian 9, or CentOS 7 without paid extended support), no more fixes are coming, and the finding should be treated as real.

If the server says nothing about a distribution, for example just Apache/2.4.7, it was probably installed or compiled by hand, and the version number is likely accurate.

Step 2: update

If the operating system is still supported

# Ubuntu / Debian
sudo apt update
sudo apt install --only-upgrade openssh-server apache2

# Red Hat family
sudo dnf upgrade openssh-server httpd

Then restart the services (sudo systemctl restart ssh apache2, or sshd httpd on Red Hat). Turn on automatic security updates so this doesn't happen again (unattended-upgrades on Ubuntu and Debian, dnf-automatic on Red Hat).

Before updating SSH on a remote server, keep your current session open and test a second login after the restart. That way a configuration problem can't lock you out.

If the operating system is end of life

Updating single packages won't help. Plan a move to a supported release, either an in-place upgrade or, often safer, a new server you migrate the site to. Until then, reduce exposure (step 3).

If someone else runs the server

For shared hosting, a managed server, or a device like a NAS, router or firewall that has OpenSSH or Apache built in, the fix is a firmware or platform update from the vendor. Send your provider the finding and ask which version you're on and when it will be updated.

Step 3: reduce exposure

• Don't leave SSH open to the whole internet if only your team uses it. Allow it only from your office IP address or over a VPN, using your firewall or your cloud provider's security group.
• Use SSH keys instead of passwords. Set PasswordAuthentication no in /etc/ssh/sshd_config once key login works, and keep PermitRootLogin no.
• Hide version details after updating. Apache: ServerTokens Prod and ServerSignature Off. On Debian and Ubuntu, DebianBanner no removes the distribution suffix from the SSH banner. This doesn't fix anything. It only makes your server a less obvious target.

Step 4: re-scan

Run another scan after updating. If the version number changed, the CVE count should drop or the finding should disappear. If you confirmed in step 1 that a distribution build is already patched, the finding may stay, because the version number didn't change. Note that in your records, and keep automatic security updates on.

Common questions

Why did the scan list over 100 vulnerabilities for one program?

The database lists every published CVE that applies to that version, including many low-severity and duplicate entries. The count shows how far behind the software is. It isn't a list of 100 separate open doors. The report shows the most severe rating so you can judge urgency.

Why is this rated Medium and not High?

Because it's based on the version number alone. The scan doesn't try to exploit anything, and backported fixes are common. Findings Nmap confirms directly, such as a check that reports "VULNERABLE", are rated High.

Is it safe to just run the updates?

Security updates within the same operating system release are designed to be safe to install, and they are much safer than leaving known flaws in place. Take a backup or snapshot first if the server is important, and update outside business hours.

Sources: NVD: CVE-2024-6387 (regreSSHion) · NVD: CVE-2023-38408 · NVD: CVE-2023-48795 (Terrapin) · NVD: CVE-2021-41773 · OpenSSH security advisories · Apache httpd 2.4 vulnerabilities · Ubuntu security notices