DSPy CVE-2026-72742: model output can exfiltrate local files

CVE-2026-72742 in DSPy, a framework for programming language-model systems, was published on 11 August 2026. It demonstrates an unusual but important prompt-injection path: a model does not need a direct file-reading tool. Its response only needs to be interpreted as an Image or Audio object whose value names a local path. Framework code checked whether that file existed, read it and encoded it as base64, after which the content could appear in a later prompt sent to an attacker-controlled model endpoint.

The record covers DSPy through 3.3.0b1, scoring it 9.2 under CVSS 4.0 and 8.6 under CVSS 3.1. An attacker must influence model output, and the application must parse that output into a media type and reuse it. This is not automatic access to every file in every DSPy application. It is still a violation of a crucial boundary: output validation performs host I/O.

From model text to a local file

DSPy lets developers define typed input and output signatures. An adapter such as JSONAdapter or ChatAdapter asks a model for a structure and converts values to their expected types. The concept is useful: types reduce free-form ambiguity and make modules easier to compose. Risk appears when construction of a type has side effects.

In the vulnerable flow, output passed through parse_value and Pydantic’s TypeAdapter. Constructing a media object invoked code that recognised a value as a path. Image or audio encoders called os.path.isfile, read bytes and produced a data URL. If the object then became part of another model request, the local file left the host.

The attacker therefore needs control of a model or its response. That could be an external LLM endpoint, malicious intermediary, poisoned context influencing output or a model the application trusts too broadly. Potential targets include configuration, keys readable by the process, working data and secrets mounted into a container. Operating-system rights limit the readable set, which makes least privilege a practical control.

Why ordinary type validation was not enough

A team may expect Pydantic coercion only to check syntax. If object construction reads a file or makes a network request, model data controls host behaviour. This resembles deserialization with side effects. The boundary in which “the model emits text and the application decides what to do” becomes illusory.

A safer rule is that parsing and ordinary value construction should be pure. They may normalise text, check a format and create an in-memory structure, but should not open files, fetch URLs or launch processes. I/O should require an explicit application call after checking policy and argument provenance.

The commit fixing CVE-2026-72742 adopts that model. Normal creation of Image, Audio and File no longer performs automatic I/O. A developer uses an explicit factory such as Image.from_path() or Audio.from_path() when local reading is intended. A separate from_url() makes a network operation visible.

Explicit from_url still needs policy

Explicitness removes the dangerous automatic behaviour but does not solve every SSRF case. The patch documentation notes that from_url() does not impose an allowlist and may follow redirects. If an application passes a model-generated URL, it must independently validate the scheme, hostname, resolved address, redirects and private network ranges.

Validation should occur before every connection and after redirection so a public hostname cannot switch to an internal address. In cloud environments, egress policy should prevent access to instance metadata and management networks. Application validation and outbound filtering are complementary.

Likewise, from_path() should receive a path selected by trusted application code, not a raw model field. If a product deliberately lets a model reference resources, use an opaque identifier that the server maps to a file under one root. After canonicalisation, the path must remain below that root.

What teams should do

1. Find projects and images containing DSPy, including experiments, notebooks and services evaluating model output.
2. Check the effective version and determine whether code parses outputs into Image, Audio or File and later sends those values to a model.
3. Move to a release containing the fixing commit and test migration to explicit resource factories.
4. Search application code for automatic from_path() or from_url() calls on model-controlled data.
5. Run model workflows as accounts that cannot read unnecessary secrets or files. Limit mounts to read-only access or remove them.
6. Restrict egress to approved LLM endpoints through a controlled proxy and record destination, model and data volume.
7. If a vulnerable path ran against an untrusted model, analyse outbound requests and rotate secrets whose reading is plausible.

Rotation should not become a chaotic company-wide action. First establish process rights: system user, container mounts, environment, working directory and agent tokens. Then identify which data could pass through media functions and which endpoint received prompts. That produces a defensible and auditable scope.

Finding the broader bug class

During code review, look for constructors, Pydantic validators, deserializers and coercion functions that call open, an HTTP client, DNS resolution, subprocess or dynamic imports. Those operations are not always bugs, but they require an explicit trust boundary. They are especially risky when the value comes from an LLM, webhook, user file or another tenant.

A security test can supply a fake path to a test file and prove that parsing alone causes neither a read nor network traffic. Instrument I/O functions and fail the test whenever validation invokes them. This tests an architectural property rather than a signature for one exploit.

Telemetry can look for sudden large base64 fields in prompts, media types unexpected for a workflow, AI worker access to sensitive files and connections to new model providers. Record metadata and hashes without copying secrets into logs. DLP on a controlled proxy can identify patterns but should not be the only barrier.

The lesson for secure AI agents

A model is an untrusted data source even when the organisation selected it. It can hallucinate, be manipulated through prompt injection or sit behind an endpoint whose integrity changed. Typed output improves reliability but does not make content trusted. Every external effect needs separate authorization based on application policy.

The parsing path, affected versions and API change are facts from the CVE record and project commit. Those sources do not establish a mass exploitation campaign. Breachroad’s broader conclusion is to keep deserialization pure and side effects explicit.

This case should be discussed jointly by developers, AI engineers and the SOC because no single group sees the whole flow. Our AI and cybersecurity training helps translate a threat model into code and monitoring. Agent architecture, permissions and data flows can then be formalised through a secure AI implementation review.