vulnx: Query 250,000+ CVEs Like You’re Searching Your Email
Hook
The average security team checks 47 vulnerabilities daily but only 2% are ever exploited in the wild. What if you could filter 250,000+ CVEs down to the 10 that actually matter to your stack in under 3 seconds?
Context
Vulnerability management has traditionally been a game of drinking from a firehose. The National Vulnerability Database publishes 50-70 new CVEs daily, and security teams are expected to triage each one against their infrastructure. Existing tools fall into two camps: web-based dashboards (slow, click-heavy interfaces) or direct NVD API access (powerful but requiring custom scripting for every query). Both approaches force teams to build their own filtering logic, maintain API clients, and manually correlate vulnerability data with exploitation intelligence like CISA’s Known Exploited Vulnerabilities (KEV) catalog or EPSS probability scores.
vulnx emerged from ProjectDiscovery’s observation that security researchers were spending more time wrangling API responses than analyzing threats. Instead of treating vulnerability search as a database query problem, they modeled it after modern search engines: a rich query language that feels natural to developers already familiar with GitHub search or Gmail filters. The tool abstracts ProjectDiscovery’s vulnerability API behind a CLI that supports complex boolean logic, range queries, and field-specific operators—all without writing a single line of code.
Technical Insight
At its core, vulnx implements a domain-specific language (DSL) parser that translates human-readable queries into structured API requests. The architecture is deceptively simple: a command dispatcher routes requests to query builders, which construct HTTP calls to ProjectDiscovery’s backend, then format responses using template renderers. What makes it powerful is the query syntax itself, which supports 69+ filterable fields with intuitive operators.
Here’s a practical example that demonstrates the DSL’s expressiveness. Suppose you’re running Kubernetes infrastructure and need to find critical vulnerabilities affecting etcd, but only those with public exploits and EPSS scores indicating active exploitation:
vulnx search 'product:etcd severity:critical is_poc:true epss_score:>0.5'This single query combines four filters across different data dimensions. The product: operator searches vendor-reported product names, severity: maps to CVSS classifications, is_poc:true checks for proof-of-concept availability, and epss_score:>0.5 filters for vulnerabilities with greater than 50% exploitation probability according to FIRST’s Exploit Prediction Scoring System. Behind the scenes, vulnx’s parser tokenizes this string, validates field names against the API schema, and constructs a JSON payload that might look like:
{
"filters": {
"product": ["etcd"],
"severity": ["critical"],
"is_poc": true,
"epss_score_gte": 0.5
}
}The tool’s real sophistication emerges in its handling of temporal queries and range operations. Vulnerability management isn’t just about what exists—it’s about what changed. You can query vulnerabilities by disclosure date, patch availability, or even age:
vulnx search 'product:"microsoft exchange" age:<30d is_exploited:true'This finds Microsoft Exchange vulnerabilities disclosed in the last 30 days that are actively exploited (according to KEV listings). The age filter uses Go’s time.ParseDuration under the hood, supporting formats like 24h, 7d, or 6m (months). The parser translates relative time expressions into absolute timestamps before querying the API.
Where vulnx truly shines is its integration of contextual intelligence through the analyze command. Rather than returning raw CVE lists, it can aggregate data across dimensions:
vulnx analyze 'product:linux' --facets 'severity,epss_percentile,is_template'This generates a statistical breakdown showing severity distribution, EPSS score percentiles, and how many vulnerabilities have associated Nuclei detection templates. The output might reveal that 73% of critical Linux CVEs lack public exploit templates—actionable intelligence for prioritization. The faceting system uses the same query DSL but returns aggregated counts instead of individual records, essentially giving you pivot table capabilities from the command line.
The architecture makes a deliberate trade-off: by relying on ProjectDiscovery’s hosted API, vulnx avoids the complexity of local database management, synchronization, and data enrichment. The client is stateless—each query is independent, cacheable at the HTTP layer, and doesn’t require local storage. This design choice means the binary is just 8MB and startup time is near-instantaneous, but it also means you’re coupled to their infrastructure and data freshness.
Gotcha
The most significant limitation is network dependency and vendor lock-in. Unlike tools like grype or trivy that download vulnerability databases locally, vulnx requires an active internet connection and functioning ProjectDiscovery API endpoints for every query. If their service experiences downtime or you’re working in an air-gapped environment, the tool becomes a paperweight. For teams with strict data sovereignty requirements or those operating in classified networks, this architectural dependency is a non-starter.
Rate limiting creates a chicken-and-egg problem for new users. Unauthenticated requests are capped at 10 queries per hour—enough to explore the tool but insufficient for serious research. You’ll need to register for a free API key to unlock the full experience, which adds friction to the onboarding process. More critically, even authenticated free-tier users hit limits during intensive analysis sessions. If you’re scanning hundreds of products or performing large-scale trend analysis, you’ll quickly encounter HTTP 429 responses. ProjectDiscovery offers paid tiers for higher limits, but this transforms what appears to be an open-source tool into a freemium service gateway.
The query DSL, while powerful, has undocumented edge cases around operator precedence and quoting. Complex boolean queries with mixed AND/OR logic sometimes produce unexpected results because the parser doesn’t support explicit grouping with parentheses. For example, product:apache OR product:nginx severity:critical might not parse as (apache OR nginx) AND critical—you may need to reformulate as two separate queries. The filters command helps by showing available fields, but it doesn’t explain the query grammar itself, leading to trial-and-error syntax discovery.
Verdict
Use if: You’re a security researcher, penetration tester, or DevSecOps engineer who needs rapid vulnerability intelligence without building custom tooling. vulnx excels for one-off investigations (“show me all Apache Struts CVEs with KEV listings”), daily threat briefings (“what critical CVEs were disclosed this week with EPSS > 0.7?”), or validating patch priorities against exploitation likelihood. It’s ideal when you’re already invested in ProjectDiscovery’s ecosystem (using Nuclei, interacting with their API) and value convenience over data ownership. The free tier works well for individual researchers; teams should budget for API subscriptions. Skip if: You need offline capability, require guaranteed uptime SLAs for production security automation, or have compliance mandates around vulnerability data sovereignty. Also avoid if you’re building long-running services that need local caching—constantly hitting external APIs for historical queries is inefficient. Choose self-hosted alternatives like cve-search or direct NVD integration if you need vendor-neutral infrastructure. Finally, skip if your organization already has a mature vulnerability management platform (Tenable, Qualys, Rapid7) that provides similar querying—vulnx doesn’t replace asset-aware scanners, it complements them for ad-hoc research.
