vulscan is an nmap NSE module by scipag that turns nmap -sV version detection into an offline vulnerability lookup against bundled databases such as VulDB and CVE for authorized assessments.
| Tool | scipag/vulscan — a Lua-based nmap NSE script that correlates detected service versions with offline vulnerability databases |
| Category | Vulnerability scanning / service enumeration enrichment |
| Primary Use | Mapping nmap -sV fingerprinted services to known vulnerabilities during authorized network assessments and audits |
| Safe Use | Educational and documentary analysis; use only on systems you own or during explicitly authorized penetration tests, internal audits, and lab exercises |
| Telemetry Note | Generates the same version-detection probes and traffic as a standard nmap -sV scan against each target port; defenders will see Nmap-style service fingerprinting activity in firewall and IDS logs |
vulscan from scipag is one of those tools that quietly became a fixture in assessment workflows because it solves a boring problem elegantly: once you have service fingerprints from nmap, what do you actually do with them? Written in Lua as an nmap NSE script, it takes the output of nmap -sV version detection and correlates the identified product strings against offline copies of vulnerability databases. The result is that a routine port scan is upgraded into a derivative vulnerability scanner without sending any exploit traffic. With nearly 3,800 stars on GitHub, it remains one of the most recognizable community extensions in the nmap scripting ecosystem.
The architectural insight here is important to understand before relying on the output. vulscan performs no active verification whatsoever — the README's disclaimer is explicit that the existence of potential flaws is not confirmed with additional scanning or exploiting techniques. Everything hinges on three inputs: the confidence of nmap's version detection, the completeness of the vulnerability database, and the accuracy of pattern matching between the detected product string and database entries. This makes it a correlation engine, not a scanner in the Nessus sense, and treating its output as a prioritized research list rather than confirmed findings is the correct professional posture.
Installation follows the classic nmap script layout. The README instructs you to place the files under Nmap\scripts\vulscan\*, and on Linux the recommended approach is a git clone followed by a symlink into the scripts directory. Once in place, the minimal invocation is nmap -sV --script=vulscan/vulscan.nse www.example.com. That -sV flag is non-negotiable — without version detection there are no product strings to match, and the entire pipeline produces nothing useful. The tool is effectively a downstream consumer of nmap's fingerprinting engine.
What makes vulscan more interesting than a simple lookup table is the database ecosystem it ships with. The pre-installed sources include scipvuldb.csv from vuldb.com, cve.csv from CVE, securityfocus.csv covering BID entries, xforce.csv from IBM X-Force, exploitdb.csv from exploit-db.com, openvas.csv, plus the now end-of-life securitytracker.csv and osvdb.csv. Each database brings its own ID scheme, coverage profile, and link structure, which is why running against multiple sources matters — coverage gaps in one database are frequently filled by another. The end-of-life entries are worth noting, as they will age badly for current work.
Database freshness is handled through an update.sh script that pulls refreshed CSV files; the README recommends running it regularly so recently disclosed vulnerabilities are actually matched. Manual updates are also supported by downloading the CSVs from the project's download page and copying them into the /vulscan/ folder. This is an area where operators should build a habit: a stale database doesn't just miss new CVEs, it can also misrepresent patched products, so baking update.sh into your pre-engagement checklist is a defensible practice for authorized audit work.
Version granularity is where the tool offers its most tunable trade-off. When both nmap and the database entry contain version information, vulscan matches on it, which sharply reduces false positives. Disabling that with --script-args vulscanversiondetection=0 trades accuracy for recall — the README candidly notes this might introduce false-positives but eliminate false-negatives and slightly improve performance. It also warns that some databases lack conclusive version data, calling out Apache servers as a notorious source of noise. Knowing when to loosen the matching is a judgment call that comes from understanding your target environment.
Match prioritization follows a similar philosophy. By default the script displays only the best matches, and when nothing positive is found it surfaces the closest possible match, which may well be a false positive. Analysts who want exhaustive candidates for manual triage can enable --script-args vulscanshowall=1, accepting a much noisier output. There is also an interactive mode via --script-args vulscaninteractive=1 that lets you override nmap's version detection result per port — useful when you already know from configuration management or SSH banners what a service actually is, and the fingerprint is leading the tool astray.
The reporting layer is surprisingly flexible for an NSE script. Default output is one [id] title line per match, but --script-args vulscanoutput= accepts presets like details, listid, listlink, and listtitle, or a fully custom template string. Supported template tokens include {id}, {title}, {matches}, {product}, {version}, {link}, plus
and for formatting. Because every default database carries a URL, {link} resolves to a direct reference to the source advisory, which makes the output trivially consumable in markdown reports. Custom databases can define their own link pattern through vulscandblink=http://example.org/{id}.
Custom databases are a first-class feature rather than an afterthought. The file format is about as simple as it gets — <id>;<title> — and you point the script at your own file with --script-args vulscandb=your_own_database. The README invites the community to share homemade databases for inclusion upstream. In practice this means an organization could maintain an internal correlation set — say, matching against its own CVD or vendor advisory IDs — and use the same nmap workflow for asset intelligence without depending on external feeds.
From a defensive perspective, vulscan is just as useful on the blue side. Running it against your own asset inventory during internal audits produces exactly the kind of derivative vulnerability signal that feeds patch prioritization, and because it never exploits anything, it is safe for continuous or scheduled scanning of production ranges. Its telemetry footprint is worth internalizing: the network traffic it generates is indistinguishable from a standard nmap -sV scan, so security teams monitoring their own networks will see Nmap-style service probes in firewall and IDS logs — which is precisely what you want when validating detection coverage.
The licensing field on the repository reads NOASSERTION, which is a small but real operational consideration: anyone embedding vulscan into a commercial product or redistributed toolkit should verify redistribution rights before shipping it. The topics tagged on the repo — penetration-testing, security-audit, vulnerability-assessment, vulnerability-detection — accurately reflect its identity as an assessment-enrichment tool rather than an exploitation framework.
Taken together, vulscan earns its longevity by doing one thing well: converting service fingerprints into actionable vulnerability references, entirely offline, entirely within a tool most professionals already run. Its weaknesses — dependence on fingerprint quality, database staleness, pattern-matching noise — are all documented in its own README, which is a mark of an honest project. For authorized professionals who treat its output as a research queue rather than a findings list, it remains a cheap, quiet, and reliable addition to the enumeration phase of any scoped engagement.
scipag/vulscan.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.