How to Check SSH Vulnerability: What It Means and What to Do About It

New SSH flaws get disclosed every year, so articles written a year or two ago quickly stop answering the question. Here's the current, plain-English answer: an SSH vulnerability is a mistake in the software that runs the remote door into your server. Whether your machine is actually at risk depends on three things — what version you run, how it's configured, and whether it faces the internet. Checking that properly is called a version-and-exposure audit, and it's the first thing we do when someone brings us a server or site they're worried about.

Let's unpack what that means, what attackers actually do once they're in, and how to tell whether you need help.

What an SSH or PHP vulnerability actually is (in plain English)

SSH (Secure Shell) is how you remotely log in to a Linux server. If you have a VPS, a home server, a NAS box or a website host, SSH is almost certainly sitting there listening for a connection. It's the door.

PHP is the programming language most websites run on. WordPress, Joomla, Drupal, most e-commerce platforms — all PHP underneath. Of the websites that use a known server-side language, the large majority run PHP, which makes it a constant target for the bots that scan the web looking for a way in.

A vulnerability is a mistake in that software — a coding error that lets someone do something they shouldn't, like skip the password check, read files they shouldn't see, or run their own commands. Each one gets a catalogue number (a CVE — "Common Vulnerabilities and Exposures") so everyone can refer to it precisely.

The key distinction people miss: the flaw existing is not the same as your machine being exposed. A vulnerability in OpenSSH only matters to you if:

• you're running the affected version,
• your configuration allows the flaw to be reached, and
• the SSH service is actually reachable — usually straight at the internet.

That's why "how to check ssh vulnerability" doesn't have a one-line answer. It's not "run this command" — it's "what version are you on, what's turned on, and who can reach it." That's an audit, not a command.

And it's why the question comes up year after year. OpenSSH and PHP aren't broken products — they're actively maintained ones, and active maintenance means new CVEs get found and fixed constantly. It's a rolling problem, not a one-off.

The same version-and-exposure logic applies to your desktop Windows too — if your PC is stuck on an unsupported build like 24H2, it's stopped receiving security fixes entirely, so it's worth checking which machines can still upgrade to Windows 11 25H2 and which are end-of-life.

And being fully patched doesn't always save you either — this month's 4EverAble2Shell zero-day hit 19 systems out of 21 that were running the vendor's latest update.

What attackers actually do once they're in

Here's what a compromised server actually looks like. We see the aftermath regularly in the workshop, and it follows a pattern.

• Cryptocurrency miners. In our experience, the most common payload. Your server or PC slows to a crawl, fans run flat out, and if it's a VPS your bill creeps up as the attacker burns your CPU. The machine isn't "broken" — it's working for someone else.
• Ransomware and data theft. Website files encrypted, or customer data quietly copied off. On small business sites this is the one with real consequences, especially with UK GDPR obligations.
• Spam and phishing hosting. Your server sends junk or hosts phishing pages, your domain lands on blacklists, and suddenly your legitimate emails bounce.
• SEO spam injection. Junk links or redirects hidden inside your PHP files. This is often the first thing a customer notices — "my site redirects to a gambling site" — because everything else was running quietly in the background.

The last point matters most: attackers leave backdoors. A second admin account, a hidden script, a modified login page. That's why patching alone doesn't evict them — the machine needs a proper clean-up, and sometimes a rebuild.

If you think attackers take their time, this month's news says otherwise. The N-able "4EverAble2Shell" zero-day was exploited within hours of its proof-of-concept being published, with attackers deploying cryptocurrency miners on at least 21 systems. The detail that should stop you scrolling: 19 of those 21 were running the vendor's latest update. Fully patched is necessary, but it isn't the whole story — which is why a proper check looks at more than patch levels.

Why unpatched PHP is the entry point we see most often

When a small business or hobbyist site gets compromised, the route in is usually the same: an outdated WordPress plugin running on an old PHP version. It's the pattern we see again and again.

PHP versions have fixed support lifetimes. PHP 7.4 went end-of-life in November 2022, 8.0 in November 2023, and 8.1 in December 2025. End-of-life means no security fixes at all — ever. Not fewer fixes. None. A site running PHP 7.4 in 2026 is running software the makers stopped defending four years ago.

The classic pattern:

1. A site was built years ago with a theme and a dozen plugins.
2. One plugin got abandoned by its developer — no updates, ever.
3. The host left PHP on an old version "for compatibility."
4. A bot found the vulnerable plugin and walked in.

Shared hosting makes this worse because people assume the host updates PHP for them. Often they don't — or they deliberately leave you on an old version so your ancient site doesn't break. It's a reasonable choice from their side, but it leaves the door open.

The tell-tale signs we see when these sites come to us: sudden redirect spam, admin logins from countries the owner has never visited, and PHP files with recent modification dates the owner never touched.

SSH compromises are a bit different. The OpenSSH software itself is rarely the problem — in practice, SSH breaches usually come down to weak passwords or reused keys. Different root cause, same outcome: someone else is logged in.

Quick signs your server or site might be exposed

These are honest, non-technical red flags you can check yourself tonight:

• You can't remember the last time you updated — the server OS, the PHP version, or the CMS core and plugins. If you don't know, assume it's overdue.
• Your PHP version is 7.x, 8.0 or 8.1. All end-of-life. This is one of the most common findings we make.
• Logins that shouldn't exist — unknown user accounts, SSH keys you didn't add, admin accounts in your CMS you don't recognise.
• Odd behaviour — pages redirecting, sudden slowness, files appearing, outbound traffic spikes, or your host suspending your account "for malware."
• Password reuse — the same password on your server that you use elsewhere. If any other site leaked it, your server is next.

Be clear-eyed about this: these are red flags, not a diagnosis. A clean-looking site can still be compromised — good attackers leave no visible traces — and a slow site might just need an SSD. Confirming either way takes proper tools and someone who knows what the fingerprints look like. Don't guess, and don't patch blindly — find out what's actually exposed first. It's the same diagnostic mindset we apply to Wi-Fi faults: establish what's actually wrong before you start changing things.

What a professional vulnerability check involves

So what do we actually do when someone brings in a compromised machine or asks us to look at a server? Here's the shape of it, without the step-by-step.

Version and exposure audit. What software is running, what versions, what's end-of-life, and what's actually reachable from the internet. This is the "how to check ssh vulnerability" part done properly — it answers the question for your machine rather than in general.

Log and file analysis. Looking for the attacker's fingerprints: login times that don't fit, files modified when you weren't working, code injected into legitimate files. This is skilled work — the traces are subtle and attackers actively try to hide them.

Malware and backdoor scanning. On the machine itself: miners, web shells, rogue accounts, scheduled tasks set to reinstall the malware after you delete it.

Verdict and options. You leave knowing which of three outcomes you're facing — patch, clean, or rebuild — and what each costs in time and money.

For websites and servers we can't physically collect, we do the assessment remotely: you give us controlled access, we audit, report back, and fix. The same skills that power our virus and spyware removal service apply directly — a compromised server is just a malware infection with a network cable.

Patch, clean, or rebuild — the three realistic outcomes

Every case lands in one of three buckets. Knowing which one you're in before you spend money is most of the battle.

1. Patched early, never touched. The audit finds no compromise — just outdated software. A straightforward update and configuration fix. Cheapest outcome by far, and the reason checking before something goes wrong pays for itself.

2. Compromised but caught quickly. Clean-up plus patching. This is the most common outcome for the sites we see — the attacker got in, but hadn't had time to entrench deeply.

3. Long-compromised or badly hit. Rebuild. It sounds drastic, but it's often cheaper and safer than cleaning, because you can never be certain every backdoor is gone from a machine that's been in someone else's hands for months. Rebuilding on a clean, current platform with your data restored from a known-good backup is frequently the faster route to something you can actually trust.

If files have been encrypted or deleted, recovery may still be possible — that's our data recovery and backup territory.

The blunt advice, because it's the mistake we see most often: don't just patch a compromised box and hope. Updating the software doesn't remove the backdoor the attacker installed while they had access. You'll feel safe for a fortnight, then find they're still in.

How to stop it happening again (the short version)

Not a tutorial — just what good hygiene looks like, so you know what to ask for:

• Everything on supported versions. OS, PHP, CMS core, plugins. Automated updates where they're safe; a human checking monthly where they're not.
• Updates as a process, not an event. Monthly attention beats annual panic. This month's zero-day proves the window between "flaw disclosed" and "flaw exploited" can be hours.
• Backups that are tested and offline. The difference between an incident and a disaster. A backup you've never restored from is a hope, not a backup.
• Strong, unique credentials, and key-based SSH instead of passwords. This closes the most common SSH route in entirely.

We can set all of this up as ongoing maintenance so it's not on your to-do list — that's genuinely the point of handing it over.

Worried your machine or site is exposed? Bring it to us

We check, clean and harden compromised laptops, desktops and servers, and we advise on websites and VPS setups — remotely where we can't collect. If this month's zero-day news has you second-guessing an old server, that instinct is usually right: it's worth an hour of checking to know which of the three outcomes you're facing.

We collect and deliver across Portsmouth and the surrounding areas for £10 each way, or you can drop the machine at the workshop on Durham Street. Students and NHS staff get a discount, and every repair carries a 6-month labour warranty. Give us a ring on 02392 733174.

Questions people ask