Back to Articles

vulnx: How ProjectDiscovery Built a CLI That Makes Vulnerability Research Feel Like grep

[ View on GitHub ]

vulnx: How ProjectDiscovery Built a CLI That Makes Vulnerability Research Feel Like grep

Hook

Most security teams spend hours navigating clunky CVE websites with pagination and limited filters. vulnx lets you query the entire vulnerability landscape with a single command line expression—no web browser required.

Context

Vulnerability management has traditionally been a game of fragmented data sources and awkward tooling. The National Vulnerability Database (NVD) offers a web interface with basic search, but researchers often need to answer complex questions: "Show me all critical WordPress vulnerabilities from 2023 with public exploits that aren't in KEV." Answering this requires multiple queries, manual filtering, and often scripting against APIs that weren't designed for exploratory analysis.

ProjectDiscovery, the team behind Nuclei and other offensive security tools, recognized this friction. They built vulnx as a modern CLI that treats vulnerability data like a search engine index rather than a database to query. The tool acts as a client to ProjectDiscovery's vulnerability aggregation service, which normalizes data from NVD, GitHub advisories, vendor feeds, and their own research. The result is a grep-like experience for vulnerability intelligence—fast, composable, and designed for security researchers who live in the terminal.

Technical Insight

vulnx's architecture is deceptively simple: it's a Go binary that translates user queries into HTTP requests against ProjectDiscovery's backend API, then formats the responses for consumption. The real power lies in the query language and data model they've exposed.

The tool supports a rich query syntax with field-specific filters and boolean logic. A basic search might look like this:

vulnx search "wordpress && cvss_score:>7.0 && year:2023"

This query demonstrates the core pattern: natural language terms combined with field filters. The && operator chains conditions, while the colon syntax targets specific fields. Range queries use comparison operators (>, <, >=, <=) for numeric fields like CVSS scores. You can also use || for OR conditions and parentheses for grouping complex logic.

What makes vulnx particularly powerful is the breadth of searchable fields. Beyond obvious metadata like CVE IDs and descriptions, you can filter on EPSS (Exploit Prediction Scoring System) scores, KEV (Known Exploited Vulnerabilities) status, CISA catalog inclusion, PoC availability, and whether a Nuclei template exists. This last field creates a tight integration with ProjectDiscovery's ecosystem—you can find vulnerabilities and immediately know if you have automated testing available:

vulnx search "apache && nuclei:true && epss_score:>0.5"

The output defaults to a human-readable table format, but JSON mode (-json flag) enables pipeline integration. Each result includes comprehensive fields: CVE ID, CVSS vector strings, CWE mappings, affected product CPEs, reference URLs, and exploit metadata. This makes vulnx suitable both for interactive research and automated workflows.

Authentication is handled through a simple API key mechanism. Running vulnx auth stores credentials locally, and subsequent commands automatically include them in requests. The free tier works without authentication but has rate limits; authenticated users get higher quotas and faster response times.

One of vulnx's standout features is the analyze command, which performs faceted aggregation across vulnerability datasets. Want to know which vendors had the most critical vulnerabilities last year?

vulnx analyze -field vendor_name -filter "year:2023 && severity:critical" -limit 10

This returns aggregated counts, turning raw vulnerability data into actionable intelligence. You can facet on any field—product names, CWE types, publication years—making it trivial to spot trends or identify high-risk areas in your technology stack.

The filters command deserves mention for its utility in building queries. Running vulnx filters dumps all available field names and their types, effectively serving as inline documentation. This discoverability feature reduces the learning curve significantly; you don't need to memorize 69 fields or consult external docs to build effective queries.

Under the hood, vulnx makes RESTful API calls to ProjectDiscovery's infrastructure. The Go codebase handles argument parsing, query construction, HTTP client management, and output formatting. Error handling includes helpful messages when queries fail validation, and the tool respects standard Unix conventions (exit codes, stdout/stderr separation), making it composable with other command-line tools.

Gotcha

vulnx's cloud-dependent architecture is both its strength and primary limitation. The tool requires internet connectivity and relies entirely on ProjectDiscovery's service availability. If their API experiences downtime or you're working in an air-gapped environment, vulnx becomes unusable. There's no local database option or offline mode—it's fundamentally a thin client.

Data completeness and freshness are potential concerns. While ProjectDiscovery aggregates from multiple sources, you're trusting their indexing pipeline and update frequency. During critical zero-day events, there may be a delay between NVD publication and availability in vulnx. The tool also doesn't expose which upstream sources contributed to each vulnerability record, making it difficult to verify data provenance. For compliance-driven environments where audit trails matter, this opacity might be problematic. Additionally, the query syntax and field names are proprietary to ProjectDiscovery's API—building automation around vulnx creates vendor lock-in. If you later want to switch to a different vulnerability database, you'll need to rewrite your queries and potentially your entire workflow.

Verdict

Use if: You're doing security research that requires flexible, ad-hoc vulnerability queries; you're already using ProjectDiscovery tools like Nuclei and want tight integration; you need to build automated workflows that prioritize vulnerabilities based on EPSS scores or exploit availability; or you want to perform threat intelligence analysis without managing database infrastructure. Skip if: You require offline access or work in air-gapped networks; you need guaranteed data completeness with traceable sources for compliance; you're building long-term automation where vendor lock-in is unacceptable; or you need to query multiple vulnerability databases simultaneously with a unified interface. For those cases, consider self-hosted solutions like cve-search or database-agnostic tools like osv-scanner.