Docling RCE exposes shadow vulnerability risk in AI parsing flows

At a glance

What this is: Docling RCE is a shadow vulnerability in document parsing that lets malicious YAML trigger arbitrary Python code during normal processing.

Why it matters: It matters because AI, AppSec, and workload teams often treat parsing helpers as low-risk plumbing, even though transitive dependencies can turn routine document ingestion into execution.

👉 Read Oligo Security's analysis of Docling RCE and shadow vulnerability risk

Context

Docling RCE shows what happens when a document parser treats untrusted YAML as trusted input. In practical terms, a routine ingestion step can become code execution if the underlying loader can construct attacker-controlled objects during normal parsing.

For identity and access teams, the issue sits at the boundary between application runtime and machine identity governance: a parsing service that can execute code inherits the privileges of its process identity, then uses that foothold to reach data, systems, and adjacent workloads.

The deeper problem is visibility. Shadow vulnerabilities often hide in helper libraries and transitive dependencies, so the security programme sees a harmless workflow while the runtime is already capable of abuse.

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 do transitive dependencies create hidden risk in parsing pipelines?

A: Because the application may trust a top-level library while the dangerous behaviour lives deeper in a helper layer. If that dependency can deserialize attacker-controlled input into executable objects, the real risk is inherited at runtime. Teams must evaluate what the code does when it runs, not just what packages are listed in the repository.

Q: How can security teams tell whether document parsing is truly safe?

A: They need runtime evidence, not just static review. The key signals are whether parsing can instantiate objects, launch processes, or reach sensitive data under real input conditions. If those behaviours are possible, the parser is not just handling documents. It is operating as an execution-capable component and should be governed accordingly.

Q: Who should be accountable when a parsing library enables code execution?

A: Accountability should sit with the team that owns the runtime and the workload identity, not only the developer who added the dependency. The control failure spans application design, dependency governance, and runtime protection. Frameworks such as NIST Cybersecurity Framework 2.0 help teams assign ownership across identify, protect, detect, and respond.

Technical breakdown

Unsafe YAML deserialization becomes execution

PyYAML is designed to parse YAML into Python objects, but unsafe loaders can go further and instantiate attacker-controlled objects. When a framework like Docling feeds untrusted YAML into that path, deserialization stops being a data-handling step and becomes an execution primitive. No memory corruption is required. The malicious document is the payload, and the application’s normal parse flow becomes the trigger. Because the input is structurally valid, many controls that look for malformed files or obvious exploit strings will miss it.

Practical implication: treat every parsing path that accepts structured input as an execution surface, not just a data transformation step.

Shadow vulnerabilities hide in transitive dependencies

A shadow vulnerability is exploitable behaviour introduced through a dependency or helper layer that the application team may not even import directly. That matters because risk analysis based only on the top-level repository, package list, or code review can miss the dangerous call path entirely. In this case, the application may believe it is only consuming a document parser, while the parser delegates to a loader with unsafe object construction semantics. The vulnerability therefore lives in runtime behaviour, not just code ownership.

Practical implication: map dependency call paths to runtime behaviour, not just package names, before you assume a parsing library is safe.

Runtime detection is the only reliable control point

This class of issue is hard to prove statically because exploitability depends on the specific input, code path, and loader configuration used at runtime. That is why runtime controls matter more than repository scanning alone. If the application can observe deserialization, object creation, process spawning, and data access as they happen, it can distinguish legitimate parsing from malicious execution. In other words, the control surface sits where the parser runs, not where the dependency was first added.

Practical implication: instrument document processing paths for runtime visibility and block unsafe execution at the point of use.

Threat narrative

Attacker objective: The attacker aims to turn ordinary document ingestion into code execution that expands into data access, lateral movement, and persistence.

1. Entry occurs when an attacker supplies a malicious document containing YAML designed to hit an unsafe parsing path.
2. Credential access or abuse happens when the parsing process executes attacker-controlled Python code under the Docling service identity.
3. Escalation and impact follow when the attacker uses that foothold to access sensitive data, move laterally, or establish persistence inside the environment.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow vulnerabilities are not hidden code defects, they are hidden runtime authorities. CVE-2026-24009 exists because the application trusted a parsing path that could execute code during normal workflow execution. That is a governance failure, not just a coding mistake, because the dangerous capability sat inside an assumed-safe helper layer. Practitioners should treat inherited runtime behaviour as part of the identity and control boundary.

Parsing services inherit the privilege of the workload identity that runs them. Once a document parser can execute arbitrary code, the question is no longer whether YAML is valid. The question is what that process identity can reach after parsing begins. This is why workload identity scope, data access boundaries, and execution controls belong in the same review. The practitioner conclusion is that application runtime privilege is a security boundary.

Runtime observability exposes the difference between harmless ingestion and exploitability. Static dependency review cannot reliably tell teams when a helper library becomes a weapon. The important control gap is the lack of behavioural visibility at the moment the parser instantiates objects or spawns processes. That means security programmes need to understand execution paths, not just artefacts. The practitioner conclusion is to govern the behaviour, not the package label.

Serialized data attack paths keep recurring because organisations still trust structured input too early. The repeated lesson is not about YAML alone. It is about any system that assumes parsed content is safe before the runtime has proven otherwise. The implication for AppSec and identity teams is that trust should be earned at execution time, not granted at ingestion time.

Shadow vulnerability: inherited execution risk. This issue shows how a transitive dependency can create an exploitable authority that the application team never explicitly approved. That premise was designed for code ownership and package review. It fails when the actor is the runtime path itself, because the actual authority is exercised only after the document is processed. The implication is that governance must account for runtime autonomy inside dependency chains.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• Runtime exposure is the issue, so use NHI Lifecycle Management Guide to tighten provisioning, rotation, and offboarding around parsing workloads.

What this signals

Shadow vulnerability: the useful mental model here is inherited runtime authority. When a parser can execute code through a dependency chain, the security team needs controls that follow behaviour, not just package inventory. That is where runtime protection and workload identity boundaries become operationally relevant, especially for document pipelines that process untrusted input.

The wider signal is that application security and identity governance are converging at the execution layer. With 27 days the average time to remediate a leaked secret, per The State of Secrets in AppSec, many organisations already struggle to close exposure windows after discovery. A parser that can execute code turns that delay into active blast-radius risk, so teams need runtime visibility tied to NIST Cybersecurity Framework 2.0.

Document ingestion should now be treated as a governed workload, not a low-risk utility. That means aligning AppSec, platform engineering, and identity owners on which services may parse untrusted content, what those services can reach, and how quickly they can be isolated when behaviour shifts.

For practitioners

• Audit document ingestion paths for executable loaders Trace every place the application accepts structured documents and confirm whether the runtime can instantiate objects, call functions, or spawn processes during parsing. Focus on transitive helpers as well as direct imports, because the dangerous loader may sit below the code you review first.
• Constrain the workload identity behind parsing services Run parsers with the smallest feasible filesystem, network, and data-access scope so a parsing exploit cannot immediately reach adjacent systems or high-value data. Separate ingestion identities from downstream processing identities where the architecture allows it.
• Block unsafe deserialization at runtime Instrument parsing flows so the security stack can detect object instantiation, process creation, and anomalous execution during document handling. Where possible, deny unsafe loader behaviour before it can progress beyond the offending function call.
• Map dependency risk to runtime behaviour Review SBOM and dependency output alongside runtime traces so the team can identify libraries that become dangerous only under specific input conditions. Treat a library as risky when its normal behaviour can cross from parsing into execution.

Key takeaways

• Docling RCE shows how a normal document parsing flow can become arbitrary code execution when unsafe deserialization is present.
• The breach pattern is a shadow vulnerability, where risk hides in a transitive dependency and only becomes visible at runtime.
• Teams should govern parsing services as executable workloads, with constrained identity, runtime detection, and behaviour-based isolation.

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 Deserialization: Unsafe deserialization is the act of turning untrusted structured data into live objects or executable behaviour without strict controls. In practice, it can let a parser construct attacker-controlled objects, call methods, or trigger code execution during a normal workflow.
• Runtime Attack Surface: Runtime attack surface is the part of a system that becomes reachable only when code is actually executing, such as parsing, object creation, and process spawning. It matters because static review can miss risks that only appear under specific inputs or production conditions.
• Workload Identity: Workload identity is the set of credentials and permissions assigned to a service, parser, or machine process so it can access data and systems. When a runtime exploit lands, the workload identity defines how far the attacker can move and what resources they can reach.

What's in the full article

Oligo Security's full research covers the operational detail this post intentionally leaves for the source:

• Runtime call stack evidence showing how the unsafe loader is reached during normal parsing
• The specific Docling Core fix version and the remediation context around CVE-2026-24009
• Examples of how the vulnerable path can be triggered through the parser or helper abstractions
• The runtime protection behaviour the vendor says can block the exploit without terminating the container

👉 The full Oligo Security post covers the attack path, runtime indicators, and the fix details for Docling Core v2.48.4.

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 responsible for identity security strategy or operational resilience in your organisation, it is worth exploring.