Each result in a target-intel response represents a single observed host-port-service tuple. Results are returned as a JSON array under data. See Example Records for complete responses.
| Field | Type | Always Present | Description |
|---|---|---|---|
ip | string | Yes | IPv4 address of the observed host |
hostname | string | Yes | Hostname from DNS lookup at scan time (may be empty) |
port | integer | Yes | Port on which the service was observed |
timestamp | string | Yes | ISO 8601 timestamp of when the observation was made |
date_added | string | Yes | ISO 8601 timestamp of when the record was added to the index. This is the field the date query parameter filters on |
protocol | string | Yes | Application protocol observed on the port (e.g., http, ssh, modbus) |
transport | string | Yes | Transport protocol: tcp or udp |
cpe | array | Yes | CPE strings derived from fingerprinting. Excludes deprecated aliases |
cve | array|null | Conditional | CVE IDs associated with this host's fingerprint. null when no CVE match |
cve_confirmed | array | Conditional | Per-CVE confidence for the CVEs above — each entry is {cve_id, confirmed}. This is the field the confirmed parameter filters on |
vendor | array | Yes | Vendor names derived from fingerprinting |
product | array | Yes | Product names derived from fingerprinting |
version | array | Yes | Version strings derived from fingerprinting. CPE wildcard/unknown versions are excluded |
fingerprints | array | Yes | Per-fingerprint detail objects — see below |
contains_cve | boolean | Yes | true when the fingerprinted service has an associated CVE |
summary | object | Yes | Pre-computed rollup of the CVE/fingerprint data above — see below |
asn | string | Conditional | Autonomous System Number (e.g., AS64500). Omitted when not available |
as_name | string | Conditional | Autonomous System name. Omitted when not available |
as_domain | string | Conditional | Autonomous System domain. Returned but not searchable |
country | string | Conditional | Country name. Omitted when not available |
country_code | string | Conditional | ISO 3166-1 alpha-2 country code. Omitted when not available |
classifications | array | Conditional | Classification tags applied to this host, as type:value strings. Omitted when none apply. See Enrichment Data |
metadata | object | Conditional | Protocol-specific service metadata. Shape depends on protocol. See Enrichment Data |
The cpe, vendor, product, and version arrays are flattened rollups across every fingerprint on the record. On a host with more than one fingerprint they cannot be read positionally — index 0 of product does not necessarily pair with index 0 of version. Use fingerprints whenever the pairing matters.
fingerprints ArrayEach element describes a single fingerprint match for the host-port.
| Field | Type | Description |
|---|---|---|
cpe | string | CPE string for this fingerprint |
vendor | string | Vendor name |
product | string | Product name |
version | string | Product version |
deprecated | boolean | true when this entry is an NVD-deprecated CPE alias rather than the fingerprint's primary CPE — see Deprecated CPE aliases |
cves | array | CVEs attributed to this specific fingerprint's CPE — each entry is {cve_id, confirmed}. Omitted when this fingerprint has no CVE matches |
summary ObjectA pre-computed rollup of the CVE/fingerprint data on the record, so you don't have to count array lengths yourself.
| Field | Type | Description |
|---|---|---|
cve_count | integer | Total number of distinct CVEs matched across all fingerprints |
confirmed_count | integer | Number of those CVEs that are high-confidence (rule-authored or exact-version) matches |
fingerprint_count | integer | Number of fingerprints in the fingerprints array |
contains_cve | boolean | true when at least one CVE is associated with the host — mirrors the top-level contains_cve field |
A host's CVEs come from two independent sources, computed separately and then merged per CPE.
Rule-matched. A scanning rule can attach a CVE directly, when the matched evidence is itself proof of that specific vulnerability. These are always confirmed: true — no version index lookup is involved, because the rule author asserted the CVE from the match.
CPE-index-matched. The fingerprinted CPE (vendor/product/version) is looked up in VulnCheck's CVE-to-CPE index, built from exact enumerated NVD (cpe, cve) pairs and from version-range entries pre-resolved against observed fingerprint versions. A CPE whose version is a wildcard or unknown (-, *, or empty) never matches here, since that would produce false CVE hits.
When both sources produce the same (cpe, cve_id) pair with different verdicts, confirmed wins. A CVE asserted directly by a rule stays confirmed: true even if the index path flagged it as a possible backport.
confirmed Flagconfirmed addresses one specific false-positive class: distro backporting. A Linux distribution can backport a CVE fix into a package without bumping the upstream version string, so a version-based CVE match can be wrong for that host even though the raw version string looks vulnerable.
For each candidate CVE match:
confirmed: true if the vendor/product isn't tracked in any distro package index at all — backporting structurally can't apply — or if the exact observed version string is a distro-confirmed-vulnerable version.confirmed: false otherwise: there is evidence this vendor/product is distro-packaged, but this exact version string isn't confirmed vulnerable by a distro. This is a possible backport false positive.Two worked examples:
| CPE | CVE | confirmed | Why |
|---|---|---|---|
cpe:2.3:a:openresty:openresty:1.21.4.1:*:*:*:*:*:*:* | CVE-2023-44487 | true | Exact-version index match, and openresty is not distro-packaged, so backporting can't apply |
cpe:2.3:a:php:php:5.6.40:*:*:*:*:*:*:* | CVE-2007-3205 | false | php is distro-packaged, but 5.6.40 isn't a distro-confirmed-vulnerable version string for this CVE |
Read confirmed: false as "unconfirmed against this exact version string", not "wrong". The CVE genuinely affects that upstream version; what's unproven is whether this particular host's package carries the fix.
Filter on this with the confirmed query parameter: confirmed=true returns hosts with at least one high-confidence match, and confirmed=false returns hosts whose matches are all unconfirmed.
NVD sometimes indexes the same product under several CPE names, deprecating older ones. A scanning rule can declare those older names as aliases so that CVE lookups cover them too — older NVD entries may only exist under the deprecated name.
Each alias appears as its own entry in fingerprints with deprecated: true, carrying only the CVEs matched against that alias. Alias CVEs are never folded into the primary CPE's cves list, and deprecated CPEs are excluded from the top-level cpe array.
For example, a host running IIS 10.0 has a primary fingerprint of microsoft:internet_information_services:10.0 plus deprecated alias entries for microsoft:internet_information_server:10.0 and microsoft:iis:10.0. Only the deprecated internet_information_server name has entries in the CVE index, so on this host it is the alias entry — not the primary — that carries CVEs such as CVE-1999-0229.
This is the first thing to check during triage. If a host shows a CVE you don't expect — particularly one whose year predates the product version by a long way — look at whether it is attached to a deprecated: true fingerprint entry. That CVE fired because of deprecated-alias widening, not because the primary CPE matched.
Some scanning rules assert a CVE without extracting a CPE at all — a signature that proves a specific vulnerable device or firmware without identifying a versioned product. Those CVEs still appear in the record's cve and cve_confirmed arrays, but have no named fingerprints entry to nest under.
CVE-2021-36260 is a common example: the rule matches vulnerable camera firmware directly, so affected hosts carry the CVE with no corresponding product CPE. If you see a CVE in cve that you can't find in any fingerprints[].cves, this is why.