Vuls: An Agent-less Vulnerability Scanner That Centralizes OS, Library, and WordPress Checks

The Problem Vuls Solves: Manual Vulnerability Tracking Overload

System administrators who avoid automatic package updates to prevent downtime face a tedious, error-prone routine. They must watch NVD and vendor advisories, map new CVEs to installed packages, and figure out which servers are affected. With many packages per host, this becomes impractical. Vuls addresses this by automating the detection of vulnerabilities related to the installed software and reporting which servers are affected. It is designed for administrators who manage multiple Linux or FreeBSD servers and want a scheduled, automated report, for example via CRON, instead of manual monitoring. The tool is agent-less, meaning you do not install software on each target; you run commands from a central Vuls server over SSH or collect data locally.

How Vuls Works: Data Collection, Vulnerability Matching, and Reporting

Vuls operates by connecting to target servers via SSH (remote scan mode) or by running commands on the target itself (local scan mode). It collects package lists, OS release information, and, in fast root scan mode, process-level details. The scanner then matches this data against a set of vulnerability databases. The README lists sources including NVD, JVN, OVAL feeds from Red Hat, Debian, Ubuntu, SUSE, and Oracle, security advisories from Alpine, Red Hat, Debian, Ubuntu, and Microsoft, plus package manager commands like yum, zypper, and pkg-audit. It also pulls PoC and exploit information from Exploit Database, Metasploit modules, and several GitHub collections, plus CISA KEV and VulnCheck KEV for known exploited vulnerabilities. The result is a report that tells you which vulnerabilities affect your systems and which servers are at risk. The tool also performs dynamic analysis by SSHing into the server to check, for example, whether a kernel update has been applied but the server has not been rebooted.

Getting Started: Installation and Basic Scan Commands

The README does not include explicit installation commands, but the project's typical usage is to download a prebuilt binary or build from source. The documentation referenced in the README, such as the architecture pages, likely contains the exact steps. Based on the repository layout, you would start by creating a config.toml file that defines target servers. A minimal config might list servers with host, port, user, and SSH key path. Then you run vuls init to fetch the vulnerability data, followed by vuls scan to collect information from the targets, and vuls report to generate the output. For fast scan mode, you do not need root or any dependencies on the target. For fast root scan, you need root privileges to detect processes affected by updates using yum-ps or checkrestart. The README emphasizes that the tool is nondestructive and requires no pre-authorization on AWS, which makes it suitable for CI pipelines.

Scan Modes and Their Trade-offs

Vuls offers three main scan modes: remote, local, and server mode. Remote scan mode is the classic approach: you set up one machine that SSHes into all target servers. This centralizes management but requires SSH access and credentials. Local scan mode is for environments where you do not want the central server to connect to each target; you run the scan on the target itself and then transfer results manually. Server mode is the most distinct: you start Vuls as an HTTP server, and on each target you issue Linux commands to collect software information, then send the result to the Vuls server via HTTP. This mode requires no SSH and no scanner installed on the target, only the ability to run commands and make HTTP requests. The trade-off is that you must manually trigger the collection on each target, which could be scripted but adds operational overhead. Fast scan mode runs without root and with almost no load on the target, but it cannot detect processes that need restarting. Fast root scan adds that capability but requires root and the corresponding package tools.

Non-OS Package Scanning: Libraries, WordPress, and Network Devices

Vuls extends beyond OS packages. It can scan programming language libraries using lockfile-based detection, which means you point it at a lockfile and it checks the versions against vulnerability data. It also integrates with GitHub Security Alerts, CPE-based scanning, and OWASP Dependency Check for automatic updates when libraries change. For WordPress, Vuls scans core, themes, and plugins using the WPScan API. Network devices are also listed as a target, though the README does not detail the mechanism. This breadth makes Vuls a one-stop scanner for a diverse environment. However, each integration has its own configuration and data source, so setting up all of them is not trivial. The README marks the OWASP integration as experimental, so you should treat that path with caution.

Limitations and Failure Modes

Vuls is not a real-time scanner; it is designed for periodic runs, so you will not get instant alerts unless you schedule it frequently. The README mentions offline mode but only for a specific set of distributions: CentOS, AlmaLinux, Rocky Linux, Debian, Oracle Linux, Red Hat, Fedora, and Ubuntu. If you run other distributions, offline scanning may not work, and you will need internet access to fetch vulnerability data. The tool relies on external databases and APIs, so if NVD or a vendor OVAL feed is down or changes its format, scans could fail or produce incomplete results. Also, the fast scan mode without root cannot detect running processes that need restarts, so you might miss a critical detail about a vulnerable process that is still running. The README does not describe any failure handling for when SSH connections fail or when a target is unreachable, so you should plan for that in your automation.

Alternatives and How They Differ

The most direct alternative is Trivy, an open-source scanner from Aqua Security. Trivy is also agent-less and scans containers, filesystems, and Git repositories, but it focuses on container images and infrastructure-as-code rather than live servers. Trivy uses a different data model: it scans a filesystem or image directly, whereas Vuls connects to a running system and queries package managers. For live server scanning, another alternative is Lynis, which is a security auditing tool that runs on the target itself; it is not agent-less in the same sense, but it does not require a central server. Lynis focuses on system hardening and compliance, not on CVE matching against NVD. The key difference is that Vuls centralizes vulnerability matching across many sources, while Trivy is more container-centric and Lynis is more audit-oriented. If your primary need is container image scanning, Trivy is likely simpler; if you need to cover a fleet of servers, Vuls is more appropriate.

Maintenance, Upgrade Cost, and Licensing

Vuls is actively maintained, with a recent release v0.40.1 pushed on 2026-07-30. The project is written in Go, so upgrades typically involve replacing the binary and re-running the data fetch. The vulnerability data sources are external, so you need to periodically run vuls init to refresh the local database; this is a recurring operational cost. The tool is licensed under GPL-3.0, which means if you distribute modified versions, you must make the source available under the same license. This is a consideration for organizations that embed Vuls in a commercial product. The README does not specify a database format or storage requirements, so you should verify disk space needs based on the number of CVEs and advisories fetched. The project's documentation, referenced throughout the README, is the place to check for upgrade notes and migration steps between minor versions.

Editorial conclusion

Adopt Vuls if you operate a mixed fleet of Linux, FreeBSD, or containerized systems and need a central, agent-less scanner that can run without root in fast scan mode. It is also a strong fit for teams that want to track non-OS packages, WordPress plugins, and known exploited vulnerabilities from one tool. Do not adopt Vuls if you need a fully agent-based solution with real-time continuous monitoring, or if your environment relies on unsupported OSes or package managers. Before deploying, verify that your target OSes are listed in the supported OS documentation, confirm that your SSH setup matches the remote scan mode requirements, and check whether the GPL-3.0 license aligns with your distribution policies. Also test offline mode on a non-Red Hat family OS, since the README only guarantees offline support for CentOS, AlmaLinux, Rocky Linux, Debian, Oracle Linux, Red Hat, Fedora, and Ubuntu.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes