Docling RCE exposes shadow vulnerability risk in AI parsing flows

At a glance

What this is: This research shows that Docling’s unsafe YAML deserialization can turn ordinary document parsing into remote code execution, creating a shadow vulnerability that is invisible until runtime.

Why it matters: It matters because AI parsing and document ingestion pipelines often sit inside broader application and identity-controlled environments, so one unsafe dependency can create execution, data exposure, and lateral movement risk beyond the original parser.

Context

Docling is a document parsing framework used to turn documents into structured data for downstream AI processing. The security issue is not the parsing workflow itself, but the way untrusted YAML input can be deserialized with a loader that allows object construction and code execution.

That creates a governance gap for AI-enabled ingestion flows: teams often treat parsing as a trusted utility rather than an execution boundary. When the vulnerable behaviour only appears during normal runtime paths, static review and dependency inventories can miss the real exposure.

The article frames this as a shadow vulnerability, meaning the risk lives in a transitive dependency or hidden code path that does not look dangerous in source control. That makes the issue operationally important for teams running document pipelines at scale, because reachability is discovered only when the application is already live.

Key questions

Q: What breaks when a document parser uses unsafe YAML deserialization?

A: The parser stops being a passive data handler and becomes an execution surface. A malicious document can trigger object construction, code execution, and process creation inside the normal workflow. That means the attacker does not need to crash the application or exploit memory corruption. The unsafe behaviour is activated by legitimate input.

Q: Why are shadow vulnerabilities hard to catch before deployment?

A: They often live in transitive dependencies or hidden helper layers, so the dangerous code is not obvious in the repository. Static review and dependency lists can miss them because the exploit only appears when a particular runtime path is exercised. That means reachability testing matters more than package presence alone.

Q: How should teams evaluate whether a parsing flow is safe enough for production?

A: Teams should validate the actual runtime path, not just the library version or dependency manifest. If a parser accepts untrusted structured data, test whether the path can instantiate objects, start processes, or touch sensitive data. A parsing flow is only safe when the dangerous behaviour is impossible or fully constrained.

Q: When does a document parser become part of the trusted computing base?

A: It becomes part of the trusted computing base when the parser can influence execution, access sensitive data, or interact with adjacent systems using application privileges. At that point, the parser is no longer just handling content. It is a security-sensitive runtime component that needs the same scrutiny as code execution paths.

Technical breakdown

Unsafe YAML deserialization turns parsing into execution

PyYAML can construct Python objects while loading YAML. That is safe only when the input is trusted and the loader restricts object creation. In Docling’s case, untrusted YAML passed through an unsafe loader, so attacker-controlled content could trigger arbitrary Python code during a normal parse. This is a classic deserialization failure: the parser is doing legitimate work, but the input controls what objects get instantiated. The danger is that no memory corruption or exploit chain is needed. The application simply follows its own parsing logic and crosses into execution.

Practical implication: treat every deserialization path in document ingestion as an execution boundary, not a data handling step.

Why shadow vulnerabilities evade static and dependency-based checks

A shadow vulnerability is a real exploitable flaw that is hidden behind helpers, wrappers, or transitive dependencies. Projects may never import PyYAML directly and still inherit its unsafe behaviour through another library. That is why repository scanning alone often misses the problem: the codebase can look clean while runtime behaviour remains dangerous. The issue only becomes obvious when a specific input path is exercised in production. For AI parsing flows, that means the security question is reachability at runtime, not just whether a dependency exists in the bill of materials.

Practical implication: test live parsing paths with representative malicious inputs, not just dependency manifests and source inspection.

Serialized data can become an application attack vector

When structured input is allowed to shape object construction, serialized data stops being passive content and becomes an application-layer attack surface. The parser may accept the input, complete successfully, and still trigger code execution, process creation, or follow-on access within the host environment. That is why these flaws often evade obvious detection. They behave like valid application traffic until the parser crosses the trust boundary. In AI document pipelines, the risk extends beyond the parser itself because downstream services may receive data or execution context that was never meant to be attacker-influenced.

Practical implication: classify serialized input handling alongside other code-execution paths in threat modeling and runtime monitoring.

Threat narrative

Attacker objective: The attacker wants arbitrary code execution inside the document parsing environment so they can access data and extend their foothold.

1. Entry occurs when an attacker supplies a malicious document containing YAML designed to trigger unsafe object construction during parsing.
2. Credential access is not the main mechanism here; the exploitation path is parser-driven code execution that runs with the Docling process privileges.
3. Escalation follows when the executed code can access data, create processes, or move laterally from the parsing host into adjacent systems.
4. Impact is achieved when the attacker uses that foothold to exfiltrate sensitive data or establish persistence in the environment.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow vulnerability is now a runtime governance problem, not a code-review problem. This issue exists because the dangerous behaviour is inherited through a dependency chain and only materialises when the parser is exercised with attacker-controlled input. Security teams cannot rely on source inspection alone when the true execution path sits behind helper libraries and transitive packages. The practical conclusion is that runtime behaviour, not repository appearance, must define exposure.

Document ingestion should be treated as an execution boundary. The common assumption is that parsers consume content, transform it, and stop there. CVE-2026-24009 shows that assumption fails when parsing logic can instantiate objects or invoke code. That breaks the security model for AI pipelines that ingest documents automatically, because the ingestion layer may be the first place an attacker can execute code inside the application stack.

Unsafe deserialization is a repeatable application attack pattern, not an isolated bug. The article is describing a class of flaw that has appeared across frameworks and runtimes for years, which means governance has to focus on pattern recognition rather than one-off patch response. Oligo Security’s analysis also reinforces that hidden dependency behaviour can convert ordinary functionality into exploitable execution. Practitioners should treat serialized input as hostile until proven otherwise.

Parsing pipelines create identity-relevant blast radius when the process runs with valuable privileges. Once attacker-controlled content executes in the parser’s runtime, the resulting access is limited only by the process account, network reach, and adjacent service trust. That makes workload identity scope and host privilege equally important in AI ingestion environments. The lesson for teams is that document parsing is part of the trusted computing base, whether they intended it or not.

Runtime detection is the only control that can prove exploitability in these flows. Because the vulnerable behaviour emerges only when specific input meets specific code paths, governance has to be grounded in observable execution, not theoretical risk alone. That shifts the operational conversation from static approval to runtime proof. Teams should assume the attack surface is wider than the codebase suggests and narrower than a blanket scanner implies.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Shadow vulnerability: hidden runtime risk in trusted parsing paths. Document ingestion often looks like a utility function, but the real control boundary is whether the parser can instantiate objects or execute code from untrusted content. That means AI data pipelines need runtime proof of safety, not just dependency hygiene.

The operational signal is simple: if a document parser can turn structured input into code execution, the organisation has already lost the separation between content handling and execution. Teams should expect these flaws to keep reappearing wherever transitive dependencies sit between developers and runtime behaviour.

For practitioners

• Constrain deserialization loaders Replace unsafe YAML loaders in parsing pipelines with safe equivalents and prohibit object construction from untrusted documents.
• Map document ingestion to execution boundaries Classify every document parsing workflow that can invoke code, create processes, or instantiate objects as a high-risk execution path.
• Test transitive parser behaviour in production-like paths Exercise the actual document ingestion route with malicious YAML samples to verify whether hidden dependencies can trigger execution.
• Monitor runtime signs of deserialization abuse Alert on parser-driven process creation, unexpected object instantiation, and code execution originating from document handling services.

Key takeaways

• Unsafe YAML deserialization can convert a routine parsing step into arbitrary code execution inside the application process.
• The article describes a shadow vulnerability pattern where the dangerous behaviour is hidden in runtime paths and transitive dependencies rather than obvious source code.
• Teams need to treat document parsing as an execution boundary and verify the live path, not just the dependency list.

Key terms

• Shadow Vulnerability: A shadow vulnerability is exploitable behaviour introduced through a dependency, helper layer, or runtime path that the application team may not visibly own. The codebase can look safe on inspection while the deployed service still exposes a real attack surface at execution time.
• Unsafe Deserialisation: Unsafe deserialisation happens when an application turns untrusted serialized data back into objects without strict validation. In Python, this can become code execution if the format supports callable reconstruction or hidden execution paths. Authentication code should avoid it entirely when processing cookies, sessions, or request data.
• Runtime Reach: The total set of identities, repositories, tools, memory paths, and services an autonomous system can actually access while executing a task. It is broader than the workflow that was originally approved, and it determines the real governance boundary for agent behaviour.
• Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.