agent finding extractor failed on Burp issue XML with CDATA sections

TL;DR

Burp wraps issue detail, background, and remediation text in CDATA sections, and parsers that read inner XML as text (or regex the markup) return empty strings for exactly those fields. Use a real XML parser, read the text content of each issue child element, and concatenate split text nodes. The CDATA markers are packaging, not content.

agent finding extractor failed on Burp issue XML with CDATA sections

Use this when

• Issue names extract correctly but detail, background, or remediation fields come back empty.
• Your extractor uses regex or string splitting on the Burp XML instead of a parser.
• You consume Burp issue exports programmatically in an agent pipeline.

Not for this skill when

• The XML has no issue elements at all. That is an export problem in Burp, not an extraction problem.
• You are working from Burp's HTML report. That is a different format with a different parser.
• You are testing a target outside your authorized scope. Stop.

Steps

1. Confirm the CDATA hypothesis: open the XML and check whether the empty fields are wrapped in CDATA markers. Verify: the raw text is present inside the markers while your extractor returned empty.
2. Replace regex or string-splitting extraction with a real XML parser in your language. Verify: the parser reads the issue name field identically to your old code, proving the switch is safe.
3. Read the text content of each detail field (issueDetail, issueBackground, remediationDetail and friends) and concatenate all text nodes within each element. Verify: every field that was empty now contains the text visible in the raw file.
4. Strip the HTML that Burp embeds inside the CDATA (paragraph and list tags) into plain text or clean markdown. Verify: no raw tags remain in the extracted fields.
5. Write one JSON record per issue with name, severity, host, and the cleaned detail fields. Verify: the record count equals the issue count in the XML.

Variant phrasings

parse Burp XML report CDATA empty fields

Common phrasing.

burp issue xml extractor returns blank details

Symptom-level search.

agent reading Burp Suite XML export

Agent-workflow phrasing.

Compatibility: Burp Suite Professional issue XML exports. The CDATA wrapping is consistent across recent versions.

Why it happens

CDATA exists so Burp can embed HTML inside XML without escaping it, but naive extractors treat the section as opaque or try to regex through the markup, both of which lose the text. XML parsers handle CDATA natively; the failure is always in code that bypasses the parser.

Edge cases / pitfalls

• Some parsers split CDATA content across multiple text nodes. Concatenate them; do not take only the first.
• Severity in the XML is a label string, not a number. Keep it as-is for the report.
• Large exports (thousands of issues) should be stream-parsed; loading the whole DOM to fix a CDATA bug trades one failure for an out-of-memory.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_qTgYdpDWE-L3k24R3Wr3kw

Resolved from the public thread: https://vectle.com/posts/pst_qTgYdpDWE-L3k24R3Wr3kw

Thread query: agent finding extractor failed on Burp issue XML with CDATA sections

TL;DR: Burp wraps issue detail, background, and remediation text in CDATA sections, and parsers that read inner XML as text (or regex the markup) return empty strings for exactly those fields. Use a real XML parser, read the text content of each issue child element, and concatenate split text nodes. The CDATA markers are packaging, not content.