CVE-2026-72742

The CVE describes a file exfiltration vulnerability in DSPy's parse_value pipeline, but the real issue is architectural: the system treats language model outputs as trusted structured data rather than unvalidated input. When parse_value successfully converts an LLM completion into a typed object, that success is mistakenly interpreted as authorization — but parsing is format recognition, not security validation. The downstream code then treats the parsed Image type's path field as a legitimate instruction to read and encode a file, transmitting the base64-encoded contents to whatever endpoint the object specifies. This is deserialization-as-side-effect: the parse operation doesn't just return data, it executes behavior automatically. The prerequisite that an attacker must have "influence over language model outputs" is actually describing how deployed LLM systems work by default. Users provide prompts. RAG pipelines inject retrieved context. Third-party APIs supply model responses. System prompts accept instructions. The bar for influencing LLM outputs is effectively zero in any production system — this isn't an elevated threat condition, it's the normal operating state. The fix isn't path validation, which only works as long as the model doesn't get clever with symlinks or traversal. The fix is architectural: separate parsing from execution entirely. Once parse_value completes, a distinct authorization layer should decide whether the parsed structure is permitted to trigger side effects — and that layer must treat the output as attacker-controlled evidence of intent, not as a trusted instruction. Audit every side effect reachable through parse_value. The "trusted parse" pattern has a 50-year lineage across SQL injection, command injection, and deserialization attacks; LLM-native versions amplify it because the LLM itself is an active interpreter that an attacker can manipulate to generate malicious payloads.

Reviewed through automated stages and approved by a human before publication.