Threat Center

The Threat Center tab is the security inbox for a single host. It shows what TurboStack's security scanning (TurboRadar) found on that server: known weaknesses in your software, confirmed malware, and suspicious activity caught while the server is running.

You do not need to be a security specialist to use it. This page explains each finding type, what the scores mean, and - most importantly - how to decide what to fix first and what to do about it.

This tab covers:

• How scanning works - where the findings come from
• Reading the security scores - CVE, CVSS, EPSS, KEV and risk score
• How to decide what to fix first - a simple priority guide
• Vulnerabilities - known weaknesses in your software
• Indicators of compromise - confirmed malware
• Runtime detections - suspicious activity caught live
• Status and actions - heartbeat, rescan, export and clear

How scanning works

TurboRadar is TurboStack's security scanning. It runs on the host and reports its findings back to the platform, where they appear in this tab. It looks at three different things:

• Your software and its dependencies - to find publicly known weaknesses (see Vulnerabilities).

• Your files - to find malware such as web shells, backdoors and payment-page skimmers (see Indicators of compromise).

• The running system - to catch suspicious behavior as it happens (see Runtime detections).

Scans run automatically on a weekly schedule. You can also start one yourself at any time with Rescan now - do this after you apply a fix, to confirm the finding is gone. The status header shows when the last scan ran and whether the host is currently reporting.

Reading the security scores

A vulnerability finding can carry several scores. They answer different questions, and reading them together is what tells you how urgent a finding really is. Here is what each one means in plain language.

CVE - the identity of the weakness

A Common Vulnerabilities and Exposures (CVE) identifier is a public, unique name for one specific security weakness in a piece of software, written as CVE-2024-12345. Anyone in the world refers to that exact weakness by that ID, and the full description lives in a public database (the National Vulnerability Database). In the Threat Center, the CVE links to that advisory.

A CVE is only an identifier - it says which weakness was found, not how dangerous or likely it is. For that, read the scores below.

CVSS - how severe it is

The Common Vulnerability Scoring System (CVSS) is a severity score from 0.0 to 10.0. It rates how much damage the weakness could cause if an attacker exploits it - the technical impact. Higher is worse.

CVSS describes the worst case, not the chance it will happen. A weakness can score 9.8 and still almost never be attacked in practice. That is why you also need EPSS and KEV.

EPSS - how likely it is to be attacked

The Exploit Prediction Scoring System (EPSS) is a percentage from 0% to 100%. It estimates the probability that this weakness will be exploited by attackers in the next 30 days, based on real-world data. Higher means more likely.

• A high EPSS (for example 80% or more) means attackers are actively targeting this weakness right now, or are very likely to soon.

• A low EPSS means that, although the weakness exists, it is rarely attacked in practice.

When a finding is not yet confirmed as actively exploited but its EPSS is 80% or higher, the Threat Center shows a Likely exploited badge so you can spot it quickly.

KEV - confirmed to be exploited right now

Known Exploited Vulnerabilities (KEV) is a public catalogue, maintained by the United States cybersecurity agency (CISA), of weaknesses that are confirmed to be under active attack in the real world. This is the strongest possible signal: it is no longer a prediction.

A finding on this list shows an Exploited (KEV) badge. Treat these as urgent regardless of their other scores.

Risk score - the single number that ranks everything

Reading three scores for every finding is a lot of work. To save you that, TurboStack combines the signals above - whether it is exploited (KEV), how likely it is (EPSS), and how severe it is (CVSS) - into a single risk score, shown as a large number on the right of each finding. Higher means more urgent.

The vulnerabilities list is sorted by risk score, most urgent first, so the findings that need your attention are always at the top. The coloured severity label (Critical, High, Medium, Low, Info) is the priority band that the risk assessment puts the finding in; use the severity filter to focus on a band.

How to decide what to fix first

You rarely need to read every score. For each finding near the top of the list, ask three questions in order, and act on the first one that applies.

Fixing a vulnerability

Most vulnerabilities are fixed by updating the affected software to a version that is no longer vulnerable. Each finding shows the package and its installed version, and - when a fix exists - the Fixed in version (in green).

1. Note the package and the Fixed in version.

2. Update that package to the Fixed in version (or newer). How you do this depends on the component - for example through your application's dependency manager, or by updating the platform, theme or extension that includes it.

3. Publish the change if it is part of your host configuration.

4. Run Rescan now to confirm the finding is gone.

If there is no fix available yet, reduce your exposure in the meantime: keep the Web Application Firewall and TurboShield enabled, and restrict access to the affected area where you can. Re-check after the next scan.

Understanding false positives (backported patches)

Some findings - often around system packages such as OpenSSH - are false positives. Linux distributions like Debian fix security issues by backporting the patch into the existing version without changing the version number. A scanner that only compares version numbers to a CVE database then flags a package (for example OpenSSH_8.0p1) as vulnerable even though the specific CVE is already fixed.

TurboStack applies security updates automatically (once a day), so these packages are kept patched. To confirm a specific case over SSH:

dpkg -l | grep openssh     # the installed package (and its patched build)
ssh -V                     # the running OpenSSH version

You can then check whether the CVE is already patched in the distribution's security tracker. If it is, dismiss the finding; if you are unsure, contact support.

Vulnerabilities

Known weaknesses found in your software and its dependencies. Filter by severity (Critical, High, Medium, Low, Info). Each finding shows:

• The title and the CVE identifier, linked to the public advisory (or a signature name when there is no CVE).

• The affected package or application type, and the installed version.

• The Fixed in version, when a fix is available.

• The scores and badges described above: CVSS, EPSS, Exploited (KEV) or Likely exploited, and the combined risk score.

• When it was first and last detected, and which scanner found it.

See How to decide what to fix first for how to act on these.

Indicators of compromise

An Indicator of Compromise (IoC) is evidence that your host has already been breached - most often a malicious file found on disk, such as a web shell, a backdoor, or a skimmer that steals payment details. These are not predictions: the malicious file is present. Every IoC is treated as Critical, and a red banner appears when any are found.

Each entry shows the detection, the affected application type, the scanner, and the file path of the suspicious file.

After cleaning up, run Rescan now to confirm the file is gone.

Runtime detections

Runtime detections are suspicious actions caught while the server is running, rather than found by scanning files. Examples are a web process starting a command shell, or a program running from a temporary folder - patterns that often indicate an intrusion in progress.

Each detection shows a severity (for example CRITICAL or WARNING), the rule that matched, the source or container it came from, a timestamp, and the command or file path involved.

Unlike vulnerabilities, these are a live stream of events and can include occasional false alarms (for example a maintenance script doing something unusual). Review each one:

• If you recognise it (for example it matches a deploy or a task you ran), it is expected.
• If it is unexpected, treat it like a possible compromise and follow the steps under Indicators of compromise.

Status and actions

The header shows the host's reporting status and the controls for the tab.

• TurboStack Heartbeat - whether the host is currently sending data. A fresh heartbeat (within a few minutes) confirms the scanning is connected. "No signal yet" means the host has not reported recently; if it persists, contact support.

• Last scan - when the most recent scan finished, or "never" if none has run yet.

• A findings summary: total vulnerabilities (with the Critical count), indicators of compromise, and runtime events.

Available actions:

• Rescan now - start a fresh scan immediately. Progress is shown as each scanner finishes. Use this after applying a fix to confirm the finding is resolved.

• Export - download the current list as a CSV (comma-separated values) file, for example to share with a developer or track in a spreadsheet.

• Clear all - clear the findings in the current list (asks for confirmation). You can also dismiss findings one at a time.

Related

• Security overview (how protection works)
• Security (configuration)
• Backups
• Glossary
• Hosts