Describe the bug
PDF report generation fails when a finding contains HTML-like text with malformed or mismatched tags.
In my case, a finding contained the following text:
<b><i></b></i>
This text was part of the finding description and was intended to be displayed literally in the report. However, when Strix generates the PDF, the text appears to be passed to ReportLab’s Paragraph parser as markup.
ReportLab therefore attempts to parse and as formatting tags and raises:
ValueError: Parse error: saw instead of expected
As a result, the entire /api/report/send request fails and the report cannot be generated.
To Reproduce
- Run a Strix assessment that produces a finding containing HTML/XML-like text in its description.
- Ensure the finding contains malformed or mismatched tags, for example:
- Open the Strix viewer and attempt to generate/send the PDF report.
- The request to POST /api/report/send fails with a ReportLab parsing exception:
ValueError: Parse error: saw instead of expected
Relevant part of the traceback:
File "strix/interface/viewer/report_pdf.py", line 501, in _markdown_flowables
File "strix/interface/viewer/report_pdf.py", line 450, in flush_para
File "reportlab/platypus/paragraph.py", line 1861, in init
...
ValueError:
paragraph text '...' caused exception
Parse error: saw instead of expected
The problematic finding in this case contained:
Spring Boot's value sanitization masks password/secret/token keys inside
/actuator/env and /actuator/configprops (observed as ''),
so plaintext secrets are not directly exposed there.
Expected behavior
Finding content should not be able to break PDF generation.
HTML/XML-like strings originating from findings, LLM output, HTTP responses, logs, source code, or other assessment evidence should be rendered as literal text when appropriate rather than being interpreted as ReportLab markup.
For example:
should appear literally in the generated report and should not cause the ReportLab parser to fail.
Normal Markdown formatting such as bold, italic, and inline code should continue to render correctly.
Ideally, the report generation pipeline should safely escape untrusted/raw text before converting supported Markdown formatting into ReportLab markup.
Screenshots
N/A. The issue is reproducible from the viewer/server traceback.
Full error:
viewer request failed: POST /api/report/send
ValueError: Parse error: saw instead of expected
System Information
- OS: [fill in your OS, e.g. Ubuntu 22.04]
- Strix Version or Commit: [fill in version/commit]
- Python Version: [fill in Python version]
- LLM Used: Qwen3.5-397B-A17B-FP8 + DeepSeek-V4-Flash hybrid
Additional context
The failure occurs in the PDF rendering path:
POST /api/report/send
→ build_encrypted_report
→ generate_report_pdf
→ _finding_flowables
→ _field_block
→ _markdown_flowables
→ flush_para
→ reportlab.platypus.Paragraph
This suggests that raw or LLM-generated finding content can reach ReportLab’s markup parser without sufficient escaping.
This may affect more than this specific string. Similar content encountered during security assessments could potentially trigger the same problem, for example:
<script>alert(1)</script>
a & b < c > d
Since Strix findings frequently contain HTTP responses, HTML fragments, source code, XML, logs, and other attacker-controlled or target-controlled content, arbitrary <...> sequences should not be assumed to be trusted ReportLab markup.
A regression test covering malformed HTML-like input while preserving legitimate Markdown formatting would likely help prevent similar report-generation failures.
Describe the bug
PDF report generation fails when a finding contains HTML-like text with malformed or mismatched tags.
In my case, a finding contained the following text:
<b><i></b></i>This text was part of the finding description and was intended to be displayed literally in the report. However, when Strix generates the PDF, the text appears to be passed to ReportLab’s Paragraph parser as markup.
ReportLab therefore attempts to parse and as formatting tags and raises:
ValueError: Parse error: saw instead of expected
As a result, the entire /api/report/send request fails and the report cannot be generated.
To Reproduce
ValueError: Parse error: saw instead of expected
Relevant part of the traceback:
File "strix/interface/viewer/report_pdf.py", line 501, in _markdown_flowables
File "strix/interface/viewer/report_pdf.py", line 450, in flush_para
File "reportlab/platypus/paragraph.py", line 1861, in init
...
ValueError:
paragraph text '...' caused exception
Parse error: saw instead of expected
The problematic finding in this case contained:
Spring Boot's value sanitization masks password/secret/token keys inside
/actuator/env and /actuator/configprops (observed as ''),
so plaintext secrets are not directly exposed there.
Expected behavior
Finding content should not be able to break PDF generation.
HTML/XML-like strings originating from findings, LLM output, HTTP responses, logs, source code, or other assessment evidence should be rendered as literal text when appropriate rather than being interpreted as ReportLab markup.
For example:
should appear literally in the generated report and should not cause the ReportLab parser to fail.
Normal Markdown formatting such as bold, italic, and inline code should continue to render correctly.
Ideally, the report generation pipeline should safely escape untrusted/raw text before converting supported Markdown formatting into ReportLab markup.
Screenshots
N/A. The issue is reproducible from the viewer/server traceback.
Full error:
viewer request failed: POST /api/report/send
ValueError: Parse error: saw instead of expected
System Information
Additional context
The failure occurs in the PDF rendering path:
POST /api/report/send
→ build_encrypted_report
→ generate_report_pdf
→ _finding_flowables
→ _field_block
→ _markdown_flowables
→ flush_para
→ reportlab.platypus.Paragraph
This suggests that raw or LLM-generated finding content can reach ReportLab’s markup parser without sufficient escaping.
This may affect more than this specific string. Similar content encountered during security assessments could potentially trigger the same problem, for example:
<script>alert(1)</script> a & b < c > dSince Strix findings frequently contain HTTP responses, HTML fragments, source code, XML, logs, and other attacker-controlled or target-controlled content, arbitrary <...> sequences should not be assumed to be trusted ReportLab markup.
A regression test covering malformed HTML-like input while preserving legitimate Markdown formatting would likely help prevent similar report-generation failures.