GHSA-wvcr-jpx6-3fjh: 
Python Analyse et atténuation de la vulnérabilité

Summary

ReportRenderer._render_narrative_template (src/mulder/report/renderer.py:1017) compiles the model-authored case narrative with Jinja2's SandboxedEnvironment.from_string and renders it with the full report context. The sandbox blocks attribute escapes, but it does not bound CPU or memory: nested range() loops, ** and string * are all evaluated. Narrative text steered by hostile evidence (prompt injection) can therefore wedge or crash report generation. Reached through submit_narrative (server/tools/findings.py:574), the finalize_report fallback (findings.py:745) and mulder report.

PoC

Tested against main @ 5ebc9ab. Have the REPORT agent call submit_narrative with:

{% for a in range(100000) %}{% for b in range(100000) %}{{ 'x' * 10**7 }}{% endfor %}{% endfor %}

then run finalize_report or mulder report. template.render spins for hours or raises MemoryError, which the except clause does not catch. The markdown fallback re-renders the same narrative.

Impact

• Report generation and the synchronous MCP tool thread stall or crash.
• The investigation cannot be finalised until someone edits the stored narrative in the database by hand.
• The template can also pull any report-context value (audit_log_path, findings, audit entries, source windows) into the rendered report.

Fix

The narrative was templated only so it could cite authoritative counts (the placeholders listed in orchestrator/prompts/report.md). The fix branch on the temporary private fork stops evaluating the narrative as a template:

• {{name}} is replaced with an integer context value, and {{name | length}} with a collection's length.
• Anything else is left as written. Every documented placeholder keeps working. The full test suite passes (1758 passed, 16 skipped).