Software & Vulnerability Detection

October 31, 2025

Netlas uses passive scanning techniques to collect detailed intelligence about internet-facing services without introducing risk or disruption to the target systems.

Passive Scanning

Passive scanning is a non-intrusive method of gathering information about systems and services without sending any specially crafted packets or attempting to exploit weaknesses.

This means that during the scanning process, Netlas does not attempt actions beyond what the system is designed for. In other words, there are no attempts at authorization, password guessing, or any non-standard requests. Netlas.io sends requests only to publicly accessible services and saves the responses.

Technology Detection

By analyzing service responses, Netlas can often determine the specific software and even its version. This method allows Netlas to identify more than six thousand applications and services.

Detection rules are applied in different contexts. Here are a few examples:

• Header Inspection
  Server: Apache/2.4.51 →
  tag.name:apache + tag.apache.version:2.4.51
• Banner Parsing
  220 mail.example.com ESMTP Postfix →
  tag.name:postfix
• HTML Contents
  <meta name="generator" content="WordPress 6.8" /> →
  tag.name:wordpress + tag.wordpress.version:6.8

When a rule matches, Netlas adds a corresponding entry to the tag field. And, when available, records the version in tag.technology_name.version.

In the Responses Search tool, you can click the Search by Tag button on the right side of the search panel to access a list of detected technologies and build targeted searches.

Vulnerability Detection

Netlas performs passive vulnerability detection without sending any exploit attempts or intrusive payloads. Instead, when Netlas detects a software product (and, when possible, its version), we correlate that evidence against public vulnerability feeds and enrich the record with structured CVE data.

Each vulnerability entry includes:

• cve.name — CVE ID (e.g., CVE-2025-23048).
• cve.description — vulnerability text description.
• cve.severity — qualitative severity rating (Critical, High, Medium, or Low).
• cve.base_score — CVSS base score (numeric value from 0.0 to 10.0).
• cve.attack_vector — how the vulnerability can be exploited (e.g., NETWORK, LOCAL).
• cve.has_exploit — boolean flag; true if a known public exploit exists.
• cve.exploit_links — list of references to third-party public exploits or proof-of-concept repositories.
• cve.match_type — indicates how the CVE was attached – by CPE or only based on product name (see below).

Some additional fields are available. See the full list of fields and extended descriptions in the CVE Field Reference.

How Netlas Links Vulnerabilities

Netlas uses two independent detection algorithms:

1. By CPE (Common Platform Enumeration)
   When Netlas detects an exact software name and version, it links known vulnerabilities using the corresponding CPE identifier. This provides high-confidence, version-specific CVE associations.
2. By Product Name
   When the version cannot be reliably determined, Netlas attaches CVEs for the same product family based on product name and vendor context. This provides broader coverage, helping identify potential risks even when version data is missing.

The match_type field indicates which of these methods was used for each CVE.

Below is how CVEs linked by each algorithm appear in the JSON document:

CVE Added by CPECVE Added by Product Name

{
 "severity": "CRITICAL",
 "base_score": "9.1",
 "name": "CVE-2025-0000",
 "description": "Example",
 "match_type": "cpe"
}

{
 "severity": "CRITICAL",
 "base_score": "9.1",
 "name": "CVE-2025-0000",
 "description": "Example",
 "match_type": "product"
}

Passive Vulnerability Detection Method

Passive vulnerability detection offers a major advantage — it has no impact on the scanned systems. Detection is based purely on information that is already publicly visible.

However, there are important limitations to consider:

• Potential False Positives:
  Vulnerability matching is based solely on observed version numbers. If a system administrator has applied security patches without updating the reported version (e.g., via backported patches), Netlas may incorrectly report vulnerabilities that have already been mitigated.

• No Exploitation Verification:
  Netlas does not actively verify whether a vulnerability is actually exploitable in the target environment. It only flags that the detected version is known to be affected.

Relevance of Vulnerability Data

Netlas updates its vulnerability database daily, using the NVD as the primary and most authoritative source of CVE information. This means that if a CVE is published on day X in the NVD, Netlas will begin mapping this vulnerability to newly scanned devices starting from day X+1.

It’s important to understand that Netlas does not retroactively update previously collected scan results. Newly published vulnerabilities are linked only to scan results gathered after the CVE is added to the Netlas vulnerability database. In other words, if a resource was scanned on day X−1 and the CVE was published on day X, the vulnerability will not appear in the earlier scan results — it will only be detected in subsequent scans.

Exploit Links

Click the biohazard icon under the CVE tab to view available exploit links.