Vulnerability monitoring

#How it works

Monitoring has three steps:

1. Inventory: the panel reads installed packages, their versions and source package names from the server's package database (dpkg on Debian/Ubuntu, rpm on AlmaLinux/Rocky Linux/RHEL) and collects component versions.
2. Matching: the inventory goes to the Hub with the installation report. By default the Hub scans the inventories it holds every hour and finds vulnerabilities.
3. Results: the vulnerabilities found for this server come back in the response to the next installation report, are stored by the panel and, where needed, sent to administrators as a notification.

Only the server administrator can open the page. Account owners and resellers do not see this list.

#What goes into the inventory

#Distribution packages

For each package the name, version and, where available, the source package name and version are collected, and a SHA-256 digest of the list is computed. The package database is watched every minute by looking only at file status. Once an apt/dnf operation has finished, the database has been unchanged for a minute and no package job is running in the panel, the list is read again. Packages installed by hand are picked up this way too.

#Component versions

Besides distribution packages, versions of the following are sent: bipanel itself and the panel's Node.js, PHP versions, MariaDB/MySQL, PostgreSQL, Apache, Nginx, OpenLiteSpeed, restic, rclone, noVNC, Adminer, phpMyAdmin, Roundcube, SnappyMail, Composer, WP-CLI, and the Node.js and language runtimes offered to accounts. This list is cached for an hour and refreshed when a component job finishes.

#When it is sent

The inventory travels with the installation report, which is mandatory and cannot be turned off (the default interval is 2 hours). The full package list is sent only when the digest has changed, when the Hub asks for it or when the installation is not registered yet; other reports carry only the digest. When the inventory changes, the next report is brought forward. Show the data sent on Server Admin → Installation Report shows exactly what goes out; see Licensing for details.

#How the Hub finds vulnerabilities

On Debian, Ubuntu and Rocky Linux, matching uses the source package (for example libssl3 → openssl). Kernel vulnerabilities are checked only against the running kernel; header packages and older installed kernels are not counted. Different identifiers of the same vulnerability (CVE, GHSA, distribution advisories) are merged into a single row.

#The Vulnerabilities page

The page has four tabs: Vulnerabilities, Component versions, Installed packages (the list sent to the Hub) and History (recent checks). Refresh inventory at the top reads the inventory again right away; if it changed, the installation report is brought forward.

You can narrow the list with search and the Actively exploited, Has a fix, Severity and Status (Open, Ignored, Resolved (30 days), All) filters. Severity levels are Critical, High, Medium, Low and Unknown. A row's details show the package, installed version, fixed version, aliases, EPSS value, first and last seen times and an Open advisory link.

• Ignore: you can ignore a vulnerability that does not affect your server, with an optional reason of up to 300 characters. An ignored vulnerability triggers no notifications; the action is logged and can be undone.
• Resolved: a vulnerability that is no longer in the Hub's response counts as resolved and stays visible in the list for 30 days.
• Stale results: if no new results have arrived from the Hub for three days, the page says so and shows the last known results.

Urgent, actively exploited and critical vulnerabilities with a released fix are also summarised on the Server Status page.

#Notifications

New important vulnerabilities (critical or high severity, actively exploited or flagged urgent) produce a single panel notification to administrators, naming the six most important. For an important vulnerability with no fix yet, the notification is held back until a fix is released and then arrives as "fixes released". Actively exploited and urgent vulnerabilities are notified without waiting for a fix.

#Actively exploited vulnerabilities

Vulnerabilities in the CISA KEV catalog carry an Actively exploited label and are listed near the top. If a fix is out, do not delay the update. If the distribution has not released a fix yet, there is nothing to install; the Hub sees the fix in its hourly scan. Until then, give SSH and shell access only to accounts that need it and keep Shell Isolation on (see Account isolation).

#How fixes arrive

#Distribution packages

Apply security updates (native server installs only) starts an operating system update job. In the dialog you choose Security updates only (recommended) or All package updates; the packages that will change and the vulnerabilities the job closes are shown beforehand. Packages held with apt-mark hold are not updated. There is a Reboot the server after the job if required option; kernel fixes only take effect after a reboot. When the job finishes, the inventory is read again.

With automatic security updates on, vulnerabilities whose fix has been released are closed on their own every day in the chosen window.

#Components that ship with bipanel

Some vulnerabilities are in a component that ships with bipanel itself: the panel's npm dependencies, or restic, noVNC, Adminer, phpMyAdmin, Roundcube, SnappyMail and WP-CLI as pinned by bipanel. Operating system updates do not close these. When the release that contains the fix is known, it appears in the Fixed in bipanel field; update bipanel from the Updates page (see Updates). Security fixes in releases are listed in the changelog.

#Urgent vulnerabilities

The bipanel team can flag a vulnerability as urgent for affected servers. These are listed first with an Urgent label and notified immediately.

#By installation type

Where the package database cannot be read, no inventory is collected and the page says so.