Vulnerabilities

The Vulnerabilities page lists findings with affected asset context so operators can quickly understand where a finding applies.

Asset Context

Vulnerability API responses include the existing vulnerability fields plus derived asset context:

asset_id
asset_type
asset_value
asset_criticality
asset_source_plugin
affected_host
affected_port
affected_protocol
affected_service
affected_url
source_plugin
scan_id when available from exposure-change context
scan_job_id when available from exposure-change context

The backend does not duplicate asset data into the vulnerability table. It joins the current asset row at read time and derives affected host/port/protocol/service/url from vulnerability metadata when present.

Fallback order for asset display is:

joined asset_value
affected_url
metadata host, url, or matched_url
Unknown asset

Legacy findings without metadata are still valid and render with empty context fields.

Filtering

The organization vulnerability list supports these query parameters:

Parameter	Meaning
`severity`	Existing severity filter.
`status`	Existing status filter.
`asset_id`	Exact affected asset UUID.
`asset_type`	Joined asset type, such as `ip`, `service`, or `url`.
`asset`	Case-insensitive search across joined asset value plus metadata host/url fields.
`source_plugin`	Plugin that produced the finding, such as `nuclei` or `nmap_vulns`.
`port`	Metadata port filter for service-level findings.
`protocol`	Metadata protocol filter for service-level findings.

Example:

GET /api/v1/organizations/{org_id}/vulnerabilities?asset_type=service&asset=192.0.2.10&source_plugin=nmap_vulns

Service-Level Findings

Service-level findings, including nmap_vulns, should carry metadata such as:

{
  "host": "192.0.2.10",
  "port": "3306",
  "protocol": "tcp",
  "service": "mysql",
  "script_id": "vulners",
  "cves": ["CVE-2017-15945"]
}

The UI displays this as a readable asset plus context line instead of showing only the internal external ID.