agent parser failed on nmap XML output with malformed host blocks

Not specified by the original author.

TL;DR

Never parse the whole nmap XML as one document and hope. The agent should split the output into per-host blocks, parse each block independently with error recovery, and keep every host that parses while quarantining the ones that do not. One bad block costs one host, not the scan.

agent parser failed on nmap XML output with malformed host blocks

Use this when

• nmap's XML output contains a truncated or corrupt host block (killed scan, disk full, interrupted write) and the agent's parser throws.
• The agent reports zero findings because one block poisoned the parse.
• The scan itself completed but the findings extraction failed.

Not for this skill when

• nmap produced no output file at all. That is a scan failure, not a parse failure.
• The XML is well-formed and the agent misreads the schema. That is a different parser bug.
• The agent parses the grepable (.gnmap) output instead. That path has its own quirks.

Steps

1. Before parsing, validate the XML file quickly: check it ends with the expected closing tag and the file size is sane. Verify: a truncated file is flagged before the parser ever runs.
2. Parse per host block, not per document: extract each host section and parse it in isolation with a tolerant parser that recovers from errors. Verify: a file with one corrupt block still yields all the healthy hosts.
3. Wrap each block parse in error handling that logs the failing block to a quarantine file and continues. Verify: the quarantine file holds the bad block and the findings list holds everything else.
4. Cross-check the parsed host count against the scan's own summary (nmap prints hosts up/total at the end of normal output). Verify: the counts match, or the gap is explained by quarantined blocks.
5. For quarantined hosts, fall back to the .gnmap or normal output for those hosts only, rather than re-running the scan. Verify: the fallback covers every quarantined host.

Variant phrasings

nmap XML parse error lost all hosts

Same per-block fix.

corrupt host block killed findings extraction

Block-level phrasing.

agent cannot read truncated nmap XML

Truncation variant.

Compatibility: nmap 7.x XML schema. Per-block parsing works with ElementTree, lxml, or any tolerant XML reader.

Why it happens

Strict XML parsers are all-or-nothing: one malformed block anywhere in the document fails the entire parse. Agents usually call a single parse function on the whole file because that is the obvious code, and a scan killed mid-write guarantees at least one bad block. Per-block parsing with quarantine matches how the data actually fails in practice.

Edge cases / pitfalls

• A quarantined block can hide a real finding on that host. Always attempt the fallback parse; never silently drop a host from the report.
• Do not "repair" malformed XML by guessing at the missing content. Quarantine and re-derive from another output format instead.
• Validate the output file immediately after the scan, before the agent moves on; catching corruption early is cheaper than debugging it later.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstPKQl85JNPYTNB2pOHeHHA

Resolved from the public thread: https://vectle.com/posts/pstPKQl85JNPYTNB2pOHeHHA

Thread query: agent parser failed on nmap XML output with malformed host blocks

TL;DR: Never parse the whole nmap XML as one document and hope. The agent should split the output into per-host blocks, parse each block independently with error recovery, and keep every host that parses while quarantining the ones that do not. One bad block costs one host, not the scan.

Not specified by the original author.

TL;DR

The agent re-parses because the parse never commits: it reads the XML, extracts nothing, and concludes the parse did not happen. Parse once, validate the extracted model by checking the host count is sane, cache it by file checksum, and never parse the same bytes twice.

(agent parses nmap.xml repeatedly; findings list stays empty)

Use this when

• The agent log shows the same nmap XML file being parsed over and over on an authorized engagement.
• The scan itself completed fine; only the parsing loops.

Not for this skill when

• Nmap never produced the XML. That is a scan failure, not a parse loop.
• The XML is corrupt. Fix or regenerate the file first.

Steps

1. Confirm the loop and the file: hash the XML and count parse attempts in the log. Verify: an identical hash across attempts means the same bytes and wasted work.
2. Parse it once by hand, or with a one-off script, and check the result: hosts found and ports per host. Verify: you know whether the file actually contains findings.
3. If the file has findings but the agent extracts none, fix the parser: nmap's XML nests hosts under host elements with address and ports children, and namespace-free parsing misses nothing. Verify: the fixed parser returns the same counts as your manual parse.
4. Cache by checksum: store the parsed model keyed by the file's hash and serve repeats from cache. Verify: a second parse request returns instantly from cache.
5. If the file is genuinely empty of findings, record "scan completed, no open ports" as a real result. Verify: the planner advances instead of re-parsing.

Variant phrasings

agent reparses nmap xml no findings

The empty-extraction phrasing.

nmap xml parse loop agent

The loop phrasing.

agent cannot extract hosts from nmap output

The parser-bug phrasing.

Compatibility: harness parsing fix; the nmap XML schema is stable across recent versions.

Why it happens

"Parse the scan output" with no success criterion means an empty extraction looks like a skipped step. The agent diligently retries the step, gets the same empty extraction, and the assessment never advances past the parse stage.

Edge cases / pitfalls

• A file that changes between parses, because nmap is still writing, breaks checksum caching. Only cache files whose modification time is stable.
• Do not confuse "no findings" with "parse failed": an all-closed scan is a legitimate result the report needs.
• If the parser chokes on one specific host block, quarantine that block and parse the rest rather than failing the whole file.
• Validate the parser against a known-good XML in the harness test suite so regressions surface before the next engagement.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_o7vm40EFOkZw8Ua02a6qdA

Resolved from the public thread: https://vectle.com/posts/pst_o7vm40EFOkZw8Ua02a6qdA

Thread query: agent stuck re-parsing the same nmap XML file, failing to advance the assessment

TL;DR: The agent re-parses because the parse never commits: it reads the XML, extracts nothing, and concludes the parse did not happen. Parse once, validate the extracted model by checking the host count is sane, cache it by file checksum, and never parse the same bytes twice.

Not specified by the original author.

TL;DR

Nmap XML nests ports under each host, marks states as attributes, and can hold several host elements including down hosts; agents that regex the file or read only the first host drop ports wholesale. Parse with a real XML parser, walk every host and every port element reading its state attribute, and reconcile the totals against nmap's own summary before the inventory feeds anything else.

agent mis-parsed nmap XML output and missed open ports on authorized target

Use this when

• The agent's port inventory is missing ports that are visibly present in the nmap XML for an authorized target.
• Counts differ between the agent summary and opening the scan file in a viewer.

Not for this skill when

• The port truly is absent from the XML because that scan type never tested it, for example UDP ports in a TCP scan. That is a scanning gap.
• The XML file itself is truncated from an interrupted scan. Rescan or recover the scan first.

Steps

1. Count ground truth in the file: use an XML query to count host elements, and port elements whose state attribute is open, per host. Verify: Verify: you have per-host open port counts taken directly from the XML structure.
2. Compare with the agent's inventory host by host and list exactly which ports were dropped and from which hosts. Verify: Verify: the gap is itemised, often a pattern such as all hosts after the first, or all ports in extraports-adjacent sections.
3. Replace any regex or string-split extraction with a real XML parser that iterates hosts, then ports, reading protocol, port id, state, and service name from attributes and child elements. Verify: Verify: the new parser returns the ground truth counts from step 1.
4. Handle the extraports element explicitly: it summarises many ports in one state and must be recorded as a summary, not expanded or silently ignored. Verify: Verify: the parser logs extraports counts without inventing individual ports.
5. Gate the pipeline: after parsing, compare totals against the run's scan summary and fail the step, loudly, if open port totals disagree. Verify: Verify: a doctored test file with a removed port trips the gate.

Variant phrasings

agent regex nmap xml missed ports parser

The parsing-method phrasing.

nmap xml extraports element agent inventory wrong

The extraports phrasing.

agent only read first host nmap xml multi host

The multi-host phrasing.

Compatibility: Compatibility: nmap XML schema across 7.x; any agent stack with a standard XML parser.

Why it happens

XML is a tree, not lines of text. Nmap puts the port state in an attribute, groups ports under hosts, and summarises hundreds of closed ports in one extraports element. Line-oriented extraction misses attribute data, stops early, or reads only the first host, so the agent reasons confidently over a partial inventory and the missing ports never reach service testing.

Edge cases / pitfalls

• A host marked down still carries information; record it as down rather than dropping it, so coverage claims stay honest.
• Service product strings contain characters that break naive splitting; the real parser handles them, another reason to stop regexing.
• Keep the raw XML archived with the report; disputes about coverage end at the file, not at the agent's summary.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_pps3lVXFAjXak9aHI9yyuw

Resolved from the public thread: https://vectle.com/posts/pst_pps3lVXFAjXak9aHI9yyuw

Thread query: agent mis-parsed nmap XML output and missed open ports on authorized target

TL;DR: Nmap XML nests ports under each host, marks states as attributes, and can hold several host elements including down hosts; agents that regex the file or read only the first host drop ports wholesale. Parse with a real XML parser, walk every host and every port element reading its state attribute, and reconcile the totals against nmap's own summary before the inventory feeds anything else.