# SploitScan for CVE, Exploit, and Scanner Research

> SploitScan combines CVE records, exploit signals, EPSS, CISA KEV, HackerOne reports, and optional AI analysis in a Python CLI. It fits security researchers who need triage evidence for known vulnerabilities, but it does not discover vulnerabilities or execute exploits.

**xaitax/SploitScan** — SploitScan is a sophisticated cybersecurity utility designed to provide detailed information on vulnerabilities and associated exploits.

- Repository: https://github.com/xaitax/SploitScan
- Stars: 1,434 · Forks: 180
- Language: Python
- License: GPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/xaitax-sploitscan

## SploitScan's CVE Triage Boundary

SploitScan addresses a specific gap between receiving a CVE identifier and deciding which public information deserves attention. It retrieves vulnerability details, checks Exploit Prediction Scoring System data, searches for public exploit references, checks CISA's Known Exploited Vulnerabilities catalog, and can look for related HackerOne reports. Its patching priority combines CVSS, EPSS, and available exploit information, but that rating remains a triage signal rather than evidence that exploitation will succeed against a particular system.

The intended users are cybersecurity professionals, vulnerability management teams, and researchers who already have known CVEs or scanner output. SploitScan does not scan hosts, discover unknown vulnerabilities, validate exploitability, or perform remediation. The repository describes it as a way to identify known exploits and their exploitation probability, while the source list names GitHub, ExploitDB, VulnCheck, Nuclei, and Metasploit. Public availability of an exploit does not mean that every matching installation is exposed or vulnerable.

The CLI also supports multiple CVEs, keyword searches across local and remote sources, and exports to HTML, JSON, or CSV. This makes it more useful as a research and reporting layer than as a single-purpose lookup command. Its scope is broad enough to answer several common triage questions, but the project does not document how conflicts between source records are resolved. That omission matters when two feeds disagree about severity, exploit references, or affected products.

## How SploitScan Combines Retrieval and Triage

The repository layout separates the top-level `sploitscan.py` entry point from the `sploitscan/` package. The package also supplies HTML templates and a default `config.json` through `package-data.sploitscan`. Packaging metadata registers the `sploitscan` console script as `sploitscan.sploitscan:cli`. The Dockerfile copies the package, entry-point script, license, and changelog into a Python 3.13 slim image, then starts `python sploitscan.py`.

The visible workflow is configurable retrieval. Users can select individual methods with `-m METHODS`, enabling or skipping sources such as CISA, EPSS, HackerOne, and AI according to the README's descriptions. Fast mode uses `-f` and is documented as reducing output to basic CVE information by skipping extra lookups. Multiple CVE IDs can be processed in one invocation, while scanner reports enter through `-i IMPORT_FILE` or directory batches through `--input-dir`.

Local CVE List V5 data can be cloned and updated for offline use. The README also documents keyword searches across the local database and remote CISA and Nuclei Templates sources. Configuration is selected once, not merged. SploitScan checks a path supplied through `--config` or `-c`, then `SPLOITSCAN_CONFIG_PATH`, followed by standard local and system locations. The first valid `config.json` found in that sequence is loaded, so administrators should account for precedence when diagnosing unexpected API-provider behavior.

AI assessment is optional and supports OpenAI, Google Gemini, Grok AI, and DeepSeek. VulnCheck also requires a free API key. The documentation does not specify prompt contents, provider selection precedence, timeout handling, retry policy, or whether returned recommendations are cached. Those are material gaps for an analyst who intends to treat generated mitigation advice as supporting evidence.

## Installing SploitScan and Inspecting the CLI

The simplest documented installation uses the published Python package. SploitScan requires Python 3.8 or newer according to `pyproject.toml`. After installation, the README documents invoking `sploitscan.py` with `-h` to inspect the available options. The command below reproduces the README's documented help invocation.

```bash
python .\sploitscan.py -h
```

The reader should see usage information for CVE identifiers, output selection, scanner import, AI provider selection, keywords, local mode, fast mode, method selection, input, configuration, and directory processing. The help text in the README shows these option forms: `-e {json,csv,html}`, `-t {nessus,nexpose,openvas,docker}`, `--ai {openai,google,grok,deepseek}`, `-k KEYWORDS`, `-local`, `-f`, `-m METHODS`, `-i IMPORT_FILE`, `-c CONFIG`, and `-d`.

A source checkout is documented for developers who want the repository files and dependencies:

```bash
git clone https://github.com/xaitax/SploitScan.git
cd sploitscan
pip install -r requirements.txt
```

The repository's README does not provide a complete first lookup command with a concrete CVE or report path. It does state that positional `cve_ids` accepts values in the `CVE-YYYY-NNNNN` form and that CVE IDs are optional when an import file is supplied through `-i`. That means users must supply their own identifier or organization-specific report rather than relying on example data embedded in the documentation.

Optional services require configuration before the corresponding methods can be expected to return provider-backed results. A typical `config.json` contains placeholders for five keys, although empty placeholders are not operational credentials:

```json
{
  "vulncheck_api_key": "",
  "openai_api_key": "",
  "google_ai_api_key": "",
  "grok_api_key": "",
  "deepseek_api_key": ""
}
```

Only the first valid configuration file in the documented search order is loaded. Keep credentials out of shared or exported files, and verify which local path takes precedence before debugging a provider connection.

## Scanner Imports and Export Workflows

SploitScan accepts reports from Nessus `.nessus`, Nexpose `.xml`, OpenVAS `.xml`, and Docker `.json`. This targets a common triage pattern: a scanner has already identified vulnerabilities, and the analyst now wants public exploitation context without researching each identifier separately. The `-t` option selects the report type, `-i` supplies an import file, and `--input-dir` supports batch processing across a directory of reports.

Import support does not mean every scanner finding is a CVE. The documentation does not state how plugin identifiers without a CVE, duplicate findings, malformed reports, or contradictory records are handled. It also does not promise that imported results can be written back into the original report formats. The documented output formats are HTML, JSON, and CSV, selected with `-e`. JSON is the most direct option for another script, while HTML is intended for presentation through the package templates. CSV supports tabular processing, although the README does not define column stability as a public contract.

Method selection can reduce unnecessary external calls when a report contains many identifiers. This is useful in restricted networks, but it can also produce incomplete triage if an analyst selects only a narrow subset of signals. The README does not enumerate the complete grammar or accepted values for `METHODS`, so users should consult `-h` and the installed version's own documentation before automating every possible method combination.

## Limitations of Public Exploit and AI Evidence

The largest limitation is the difference between aggregation and verification. SploitScan can associate a CVE with public exploit material, CISA KEV status, EPSS, HackerOne reports, and framework references. It does not claim that a referenced proof of concept applies to the exact product version, configuration, network path, or authentication state present in an organization. Metasploit and Nuclei names can also be useful leads without constituting a tested exploit path for a particular asset.

AI assessment introduces another boundary. Generated explanations and mitigation ideas depend on external providers and API keys, which can introduce cost, availability, and data-handling concerns. The README does not document whether vulnerability identifiers, descriptions, or report contents are sent to those providers. Organizations should review that omission against their disclosure policy before enabling `--ai` on sensitive material.

Offline use is limited to maintaining a local CVE List V5 repository and using local database operations. The feature list does not promise complete offline coverage for every exploit database, AI service, CISA lookup, EPSS request, HackerOne search, or Nuclei query. An offline copy of CVE records should not be interpreted as a frozen copy of all enrichment sources.

## SploitScan Compared with Manual Source Research

The practical alternative is manual research across the same public sources. An analyst can search CISA KEV, EPSS, GitHub, ExploitDB, HackerOne, Nuclei Templates, and Metasploit separately, then record results in a spreadsheet or internal case system. That approach takes more repeated work and makes consistent multi-CVE processing harder, but it leaves the analyst in control of each source query and evidence record.

SploitScan takes a different approach by normalizing several retrieval paths behind one command-line workflow, adding method selection, scanner imports, patching priority, optional AI commentary, and file exports. Its advantage is consistency and throughput for known vulnerabilities. The trade-off is dependency on source availability, API configuration, undocumented conflict handling, and a larger set of Python packages.

Compared with an internal vulnerability data platform, SploitScan is a small command-line utility rather than a documented service with shared storage, authentication, audit trails, or scheduled ingestion. The repository does not document those enterprise controls. The choice therefore depends on whether a team values a local CLI and batch exports more than access control and a persistent system of record.

## SploitScan Maintenance, Packaging, and GPL Costs

The repository is not archived, and its last push was on 2026-10-16. The latest listed release is v0.14.3 from 2025-11-02, after v0.14.2 on 2025-10-18 and v0.14.0 on 2025-10-07. This indicates recent repository activity and a newer push than the listed release, but the README does not explain what changed after v0.14.3.

Maintenance costs include Python dependency upgrades and checking remote-source changes. The project pins exact versions for `requests`, `jinja2`, `openai`, `google-genai`, `GitPython`, and `tqdm`. Pinning improves reproducibility for installation at that release, while also requiring deliberate updates when APIs or dependencies change. The Dockerfile additionally upgrades `pip` and `setuptools` during image construction and uses a `python:3.13-slim-trixie` base image, which introduces a separate base-image update path.

SploitScan is licensed under GPL-3.0. Teams embedding or redistributing modified code should review how that license applies to their distribution model, while users running the unmodified package still need to follow applicable license notices and source terms. This is a license boundary to examine, not legal advice. There is no documented compatibility statement for packaging SploitScan inside a proprietary product.

## Conclusion

Adopt SploitScan when your team needs a repeatable way to combine CVE records with public exploitation signals, especially after importing Nessus, Nexpose, OpenVAS, or Docker Scout reports. Do not treat it as a vulnerability scanner, exploitation engine, or authoritative patch decision system. Before adoption, verify that every remote source and optional AI provider is acceptable for your data policy, confirm whether VulnCheck access will be required, and inspect the repository's exact behavior at version v0.14.3.

## FAQ

### Does SploitScan scan systems for unknown vulnerabilities?

No. The documented scope starts with CVE identifiers or imported scanner reports and then retrieves public vulnerability and exploit information. It is not documented as a host scanner or an exploitation engine.

### Which scanner reports can SploitScan import?

The README lists Nessus `.nessus`, Nexpose `.xml`, OpenVAS `.xml`, and Docker `.json` reports. Batch processing from a directory is supported with `--input-dir`.

### Which API keys does SploitScan support?

The configuration supports keys for VulnCheck, OpenAI, Google Gemini, Grok AI, and DeepSeek. VulnCheck is documented as requiring a free API key, while the other services are optional AI assessment providers.

### Can SploitScan work with a local CVE database?

The README says it can maintain and clone the local CVE List V5 repository for local searches and offline use. It does not state that every remote enrichment source works fully offline.

### Which output formats does SploitScan support?

The CLI documents HTML, JSON, and CSV output through the `-e` option. The README does not promise that CSV columns or HTML templates will remain unchanged across releases.

## Sources

- [Issues](https://github.com/xaitax/SploitScan/issues)
- [License: GPL-3.0](https://github.com/xaitax/SploitScan/blob/main/LICENSE)
- [README](https://github.com/xaitax/SploitScan/blob/main/README.md)
- [Releases](https://github.com/xaitax/SploitScan/releases)
- [xaitax/SploitScan on GitHub](https://github.com/xaitax/SploitScan)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xaitax-sploitscan