CVE-2026-44023 - Docling Core remote filename SSRF

docling-core resolved remote document metadata too trustingly. In affected versions, applications that pass untrusted URLs into Docling remote-fetch flows can let a server-provided Content-Disposition filename influence local cache paths outside the intended user-defined cache directory. The advisory also calls out insufficient destination restriction, so the practical exposure is a combined document-ingestion SSRF and cache-path containment problem.

This recipe is for repositories that ingest user, tenant, connector, knowledge-base, or model-produced documents. A dependency bump is necessary, but reviewers will expect the PR to prove that untrusted remote fetches are disabled or tightly allow-listed, redirects are rechecked, and cache writes stay inside the owned cache root.

When to use it

Use this recipe when a repository, document ingestion service, RAG pipeline, or agent knowledge-base workflow passes untrusted remote URLs into docling-core. It supports source-code remediation, remote filename validation, cache-path containment, SSRF review, and evidence that server-provided filenames cannot escape intended cache directories.

Inputs

  • docling-core version, remote fetch settings, cache directory policy, destination restriction, redirect handling, and deployment egress controls.
  • Source paths that call Docling remote fetch, accept document URLs, process Content-Disposition, write cache files, or serialize ingestion errors.
  • Regression fixtures for remote filenames with traversal, absolute paths, redirects, private IPs, allowed documents, and expected block/containment.
  • Boundary evidence: ingestion sources, cache roots, network egress policy, credentials, customer document classification, and rollout owner.

Affected versions

Package Vulnerable versions Fixed versions
docling-core >=1.5.0, <2.74.1 2.74.1+

Indicator-of-exposure

  • The repository resolves docling-core >=1.5.0, <2.74.1, either directly or transitively through docling, a document-ingestion worker, notebook, support-upload service, RAG pipeline, agent knowledge-base importer, or CLI.
  • Application code accepts untrusted or mixed-trust URLs and passes them to Docling or docling-core remote-fetch helpers.
  • Remote responses can supply Content-Disposition filenames, redirects, or resource URLs that influence local file names, cache keys, cache paths, or downloaded artifacts.
  • The converter runs with access to internal networks, metadata services, mounted secrets, tenant files, package credentials, shared caches, or privileged worker identities.
  • The same cache directory is reused across tenants, users, jobs, or agent workspaces.

Quick checks:

rg -n "docling-core|docling_core|docling|DocumentConverter|download|Content-Disposition|resolve_remote_filename|remote.*filename|cache_dir|cache_path|artifact|urlopen|requests\\.|httpx\\.|enable_remote_fetch|HTMLFormatOption" .
python -m pip show docling-core docling
python -m pip freeze | rg "^(docling-core|docling)=="
pipdeptree -p docling-core,docling

Windows:

rg -n "docling-core|docling_core|docling|DocumentConverter|download|Content-Disposition|resolve_remote_filename|remote.*filename|cache_dir|cache_path|artifact|urlopen|requests\.|httpx\.|enable_remote_fetch|HTMLFormatOption" .
python -m pip show docling-core docling
python -m pip freeze | rg "^(docling-core|docling)=="
pipdeptree -p docling-core,docling

Remediation strategy

  • Upgrade docling-core to 2.74.1+ everywhere the repository controls manifests, lockfiles, constraints, images, notebooks, generated dependency reports, or SBOMs.
  • If docling brings in docling-core, pin or upgrade docling so the resolved transitive docling-core version is fixed.
  • Disable remote fetch for untrusted documents by default. If remote fetch is a product requirement, require an explicit allow-list for schemes, hosts, ports, path prefixes, response sizes, and redirect destinations.
  • Normalize server-provided filenames before use, reject absolute paths and traversal, and verify the final resolved path stays under the intended cache root before writing.
  • Isolate document-ingestion caches per tenant or job when feasible. At minimum, prevent one tenant’s remote document metadata from selecting another tenant’s cache path.
  • Add regression tests around the repository’s wrapper, not only the library: untrusted URLs are denied by default, private-address destinations are blocked, redirects are revalidated, and hostile filenames cannot escape the cache root.

The prompt

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2026-44023 / GHSA-jmmv-h3mp-59v8, a docling-core
remote filename resolution and destination validation issue that can expose
document-ingestion services to SSRF and unsafe cache-path writes. Produce
exactly one output:

- A reviewer-ready PR/change request that upgrades docling-core, hardens
  remote document ingestion, adds safe cache-containment regression tests,
  refreshes generated artifacts, and documents operator actions, or
- TRIAGE.md if this repository does not control an affected docling-core
  remote-ingestion path.

## Rules

- Scope only CVE-2026-44023 and directly related Docling remote-fetch,
  filename, cache, redirect, and document-ingestion wrapper behavior.
- Do not send test requests to real internal services, cloud metadata
  endpoints, production URLs, customer documents, private tenant files, or live
  signed URLs.
- Do not log document contents, converted output, cookies, bearer tokens, API
  keys, signed URLs, tenant IDs, cache contents, or response headers that may
  contain secrets.
- Do not enable remote fetch for untrusted documents to make conversion tests
  pass.
- Do not auto-merge.

## Steps

1. Inventory every `docling-core` and `docling` reference in manifests,
   lockfiles, constraints, Docker images, notebooks, worker services, ingestion
   APIs, CLIs, generated dependency reports, and SBOMs controlled by this
   repository.
2. Determine every resolved `docling-core` version. A target is vulnerable if
   it resolves to `>=1.5.0, <2.74.1`.
3. Trace every path that passes URLs, remote document references, uploaded HTML,
   support attachments, knowledge-base imports, tenant connectors, queued jobs,
   or model-generated document references into Docling or docling-core.
4. Identify the remote-fetch and cache behavior for each path:
   - whether untrusted input can select a URL;
   - whether redirects are followed;
   - whether `Content-Disposition` filenames are used;
   - where cache files are written;
   - whether cache directories are shared across tenants, users, jobs, or
     agents;
   - what network destinations the worker can reach.
5. If this repository does not control an affected remote-ingestion path, stop
   with `TRIAGE.md` listing checked files, resolved versions, and why exposure
   is absent.
6. Upgrade `docling-core` to `2.74.1+`. If the package is transitive, upgrade or
   constrain `docling` and regenerate lockfiles, constraints, images, SBOMs,
   generated dependency reports, and deployment artifacts.
7. Harden the repository-owned wrapper before it calls Docling remote-fetch
   functionality:
   - deny untrusted remote URLs by default;
   - allow only `https` unless the repository has an explicit offline fixture;
   - block loopback, link-local, private, multicast, and cloud metadata
     destinations;
   - revalidate the resolved destination after every DNS resolution and
     redirect;
   - cap response size, filename length, redirect count, and wall time;
   - normalize `Content-Disposition` filenames;
   - reject absolute paths, drive-qualified paths, path traversal, control
     characters, symlinks, and names that resolve outside the cache root.
8. Split or namespace cache directories by tenant, user, job, or agent
   workspace where the product handles mixed-trust documents. If this cannot be
   done in the PR, document the operator-owned migration and temporary
   containment.
9. Add safe regression tests using inert fixture hosts and temporary
   directories:
   - vulnerable `docling-core` versions fail dependency checks;
   - untrusted remote URLs are denied by default;
   - private-address and metadata-service destinations are blocked;
   - redirected destinations are revalidated;
   - hostile `Content-Disposition` filenames cannot escape the cache root;
   - cache paths do not cross tenant or job boundaries;
   - logs omit URLs with secrets, response headers, document contents, and
     converted output.
10. Add a PR body section named `CVE-2026-44023 operator actions` that states:
    - docling-core versions before and after;
    - every remote-ingestion surface reviewed;
    - whether remote fetch remains enabled and why;
    - cache-root, redirect, private-address, and filename controls added;
    - whether shared caches need cleanup or tenant namespace migration;
    - which validation commands passed.
11. Run available validation: package install, unit tests, ingestion tests,
    typecheck/lint, build, container build, SBOM refresh, dependency/security
    scans, and worker or queue integration tests.
12. Use PR title:
    `fix(sec): remediate CVE-2026-44023 in Docling Core ingestion`.

## Stop conditions

- No controlled package, image, notebook, worker, CLI, or generated artifact
  resolves `docling-core >=1.5.0, <2.74.1`.
- Docling is present only in offline examples or research code that does not
  process untrusted URLs or remote documents.
- The affected document-ingestion service is owned by another repository; write
  TRIAGE.md with the owner, fixed target version, and temporary remote-fetch
  restrictions.
- Safe verification would require live internal network probing, production
  documents, customer content, privileged tenant credentials, or real signed
  URLs.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Output contract

  • A reviewer-ready PR or change request that upgrades docling-core, blocks untrusted remote fetch inputs where appropriate, enforces cache-path containment, adds SSRF/path tests, and documents ingestion controls.
  • Or a TRIAGE.md file that lists inspected files, owner, observed version, remote-fetch boundary, cache path policy, required fix, and residual risk.
  • The output must include exact validation commands and must not fetch cloud metadata, internal services, local files, or customer documents.

Verification - what the reviewer looks for

  • No manifest, lockfile, constraints file, image, notebook, SBOM, or generated dependency report resolves docling-core >=1.5.0, <2.74.1.
  • Remote document ingestion is denied by default for untrusted input or guarded by explicit scheme, host, redirect, response-size, and private-address controls.
  • Filename handling normalizes server-provided names and proves writes remain under the intended cache root.
  • Shared cache and tenant-boundary risk is explicitly reviewed.
  • Tests exercise the repository’s ingestion wrapper with inert fixtures, not live internal targets.

Watch for

  • Upgrading docling while a constraints file, notebook image, or worker image still resolves a vulnerable transitive docling-core.
  • URL allow-lists that check only the original URL and skip DNS or redirect revalidation.
  • Cache-path checks that compare strings instead of resolved paths.
  • Windows drive-letter and UNC path variants in filename sanitizers.
  • Logs that include signed URLs, response headers, tenant names, or converted document contents while adding observability.

References