Vulnerability Verification
The core question in vulnerability verification is: after an affected asset list is available, how can you automatically confirm which assets are truly exploitable, which only match component versions but are unreachable, and which cannot be verified for now?
Flocks has the vulnerability verification Agent choose an appropriate verification mode based on vulnerability type and automatically execute verification actions in an authorized / isolated environment. The final output is a three-state conclusion, "exists / does not exist / cannot verify", plus evidence records.
Scenario Overview
Vulnerability asset matching can answer whether a version matches, but it cannot directly answer whether the issue is actually exploitable. The latter is often critical for reducing response scope:
- Version match does not equal exploitability; a WAF may block it, or the component feature may not be enabled
- Non-exploitable assets can be downgraded in remediation priority.
- Exploitable assets should enter "emergency patch / temporary offline" processes
Therefore, the core output of this scenario is a three-state conclusion and corresponding evidence for each asset.
Important constraint: all verification actions must run only in authorized, isolated, or backed-up environments. The vulnerability verification Agent has a built-in behavior constraint to refuse verification against unauthorized targets. Before execution, it follows the safety policy in the Skill / system prompt.
Automated Flow
The vulnerability verification Agent selects the matching verification mode by vulnerability type:
| Vulnerability type | Verification method | Typical action |
|---|---|---|
| Weak password / default credential | Authentication test | Attempt default credential login to SSH / RDP / Web / database, and stop after failure |
| Unauthorized access | Credential-free request | Request sensitive interfaces, admin consoles, or data APIs directly and check whether 200 + data is returned |
| Information disclosure | Path probing | Probe whether .git/, .env, backup files, or debug interfaces are exposed |
| Path traversal / arbitrary file read | Construct Payload | Request paths containing ../ to verify file read boundaries |
| SSRF / request forgery | Callback verification | Construct Payloads that trigger the target to initiate external or internal connections, then verify with a controlled callback point |
| POC execution | Full POC | Construct standard POC in an isolated or authorized environment and observe response characteristics |
The Agent records the raw request / response for every attempt, not just the conclusion. This is the most important auditability guarantee in vulnerability verification.
Prerequisites
| Dependency | Requirement |
|---|---|
| Model | Reasoning models are preferred as the verification mode is selected based on vulnerability type. |
| Authorization boundary | A clear authorized asset list / IP range is required. The Agent verifies only targets inside the list |
| Toolchain | HTTP tools, DNS / HTTP callback point for SSRF scenarios, POC library which can be introduced from the community |
| Skill safety policy | Reject unauthorized targets and actions that cause business impact, such as SQL injection DROP |
| Affected asset list | Usually from the output of Vulnerability Asset Matching |
Steps (WebUI)
Step 1: Continue from the Asset List
"Hand the four assets marked 'externally exposed + core business' in the list to the vulnerability verification Agent. Run verification for CVE-2026-xxxx and write the results back here."
You can also manually provide the list in a new session.
Step 2: Select Verification Mode
The vulnerability verification Agent automatically selects the mode based on the CVE type. If it cannot determine the mode automatically, it explains the inference and asks the user to confirm.
Step 3: Confirm Authorization Boundary
The Agent's first step is to confirm that the target is inside the authorized list. Targets outside the authorized scope are refused, and the reason is recorded to Workspace.
Step 4: Execute Verification + Keep Evidence
Each asset runs the verification action matching the selected mode. Every request / response is persisted:
vulns/CVE-2026-xxxx/verify/1.2.3.4/
request.txt
response.txt
verdict.json # {status: "exists" | "not_exists" | "unknown", evidence: ...}Step 5: Output the Three-state Report
Each asset gets one conclusion. The overall result is summarized into Markdown, pushed through channels, and persisted to Workspace:
| IP | Component version | Conclusion | Evidence |
|---|---|---|---|
| 1.2.3.4 | v1.2.1 | Exists | Constructed Payload returned the expected callback |
| 1.2.3.5 | v1.2.1 | Does not exist | Request was blocked by WAF, response 403 |
| 10.10.x.x | v1.2.0 | Cannot verify | Verification requires authentication credentials, not provided in this run |
| 10.10.x.y | v1.2.0 | Exists | Path traversal read the first line of /etc/passwd |
Output Example (verdict.json Fragment)
{
"cve": "CVE-2026-xxxx",
"target": "1.2.3.4",
"mode": "poc",
"status": "exists",
"evidence": {
"request": "POST /api/xxx ... [Refer to request.txt]",
"response_marker": "unique_echo_abc123",
"observed_at": "2026-03-28T15:22:18+08:00"
},
"next_action": "emergency_patch"
}Boundaries and FAQ
| Question | Handling |
|---|---|
| Will verification against production affect the business? | Strict limits: unauthorized / non-isolated targets are refused; destructive actions, such as dropping tables, enter the blocklist |
| What if a new vulnerability has no POC? | Run only generic verification modes, such as unauthorized access or information disclosure; mark CVE-specific logic as "cannot verify" |
| WAF blocking distorts the conclusion | Clearly mark in evidence: "blocked by WAF -> does not prove the vulnerability is absent"; recommend manual retesting |
| Want the Agent to exploit the vulnerability and extract data | Not supported. The Agent only verifies existence and does not perform exploitation |
| Verification requires credentials | Inject authorized credentials through a Skill, or mark as "authentication required -> cannot verify" and hand off to humans |
Related Resources: Scenario Overview · Vulnerability Asset Matching · Threat Intelligence and IOC Triage · Skills · Public Exposure Notes