What is the CVSS score of CVE-2026-44023?

CVE-2026-44023 has a CVSS 3.1 base score of 8.6 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L. EPSS exploitation probability: 0.1%.

Which versions of docling-core are affected by CVE-2026-44023?

A critical supply-chain vulnerability in docling-core (versions 1.5.0-2.74.0) allows remote attackers to write files to arbitrary locations within systems using this Python library, creating…. A patch is available.

How to fix or mitigate CVE-2026-44023?

24 hours: Identify all internal applications using docling-core; document affected versions and restrict document processing from untrusted external sources. 7 days: Implement filesystem sandboxing to isolate docling-core write operations; deploy monitoring to detect unauthorized file creation. 30 days: Monitor for vendor patch release; prepare and test upgrade path for all affected instances.

docling-core CVE-2026-44023

HIGH

Path Traversal (CWE-22)

2026-06-03 https://github.com/docling-project/docling-core

GHSA-jmmv-h3mp-59v8

Path Traversal SSRF

8.6

CVSS 3.1 · Vendor: https://github.com/docling-project/docling-core

Severity by source

Vendor (https://github.com/docling-project/docling-core) PRIMARY

8.6 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L

Primary rating from Vendor (https://github.com/docling-project/docling-core) · only source for this CVE.

CVSS VectorVendor: https://github.com/docling-project/docling-core

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

Low

Availability

Low

Lifecycle Timeline

Source Code Evidence Fetched

Jun 03, 2026 - 21:46 vuln.today

Analysis Generated

Jun 03, 2026 - 21:46 vuln.today

CVE Published

Jun 03, 2026 - 21:16 nvd

HIGH 8.6

DescriptionCVE.org

Impact

In versions >= 1.5.0, < 2.74.1, docling-core did not sufficiently restrict remote request destinations and could resolve a server-provided Content-Disposition to a local path in an unsafe manner.

In applications that accept untrusted URLs, this could allow SSRF attacks targeting local files outside the user-defined cache directory.

Patches

Patched in docling-core 2.74.1. The fix adds stricter validation for remote destinations and normalizes server-provided filenames before use.

Users should upgrade to:

docling-core >= 2.74.1

Workarounds

If upgrading is not immediately possible, avoid passing untrusted URLs into remote fetch functionality.

References

Fix release: v2.74.1

AnalysisAI

Server-Side Request Forgery and path traversal in docling-core versions 1.5.0 through 2.74.0 allow remote attackers to coerce the library into writing files outside the user-defined cache directory by manipulating server-controlled Content-Disposition headers when applications fetch untrusted URLs. The flaw stems from insufficient validation of remote request destinations combined with unsafe resolution of server-supplied filenames. No public exploit identified at time of analysis, but the network-reachable, unauthenticated nature of the bug (CVSS 8.6) makes it a meaningful supply-chain concern for Python applications integrating docling-core for document processing.

Technical ContextAI

docling-core is a Python package (pkg:pip/docling-core) published by the docling-project, providing document conversion and remote asset fetching utilities used in document-AI / RAG pipelines. The vulnerability sits at the intersection of CWE-22 (Path Traversal) and SSRF: when the library fetches a remote resource, it trusts the server-provided Content-Disposition header to derive a destination filename and does not adequately normalize that filename, nor does it sufficiently constrain the URL destinations it will follow. Because filename normalization happens after resolution, a malicious or compromised upstream server can return a Content-Disposition value that escapes the intended cache directory via traversal sequences, and the loose URL handling expands the SSRF surface for the fetch itself. The 2.74.1 fix (commit 473fbac, PR #591) tightens both the URL destination validation and filename normalization.

RemediationAI

Vendor-released patch: docling-core 2.74.1, which adds stricter remote destination validation and normalizes server-provided filenames before they are used to construct local paths (see release notes at https://github.com/docling-project/docling-core/releases/tag/v2.74.1 and fix commit 473fbac via PR #591). Pin or upgrade to docling-core >= 2.74.1 in requirements files, lockfiles, and container images, and rebuild any wheels or downstream images that vendor the older version. If immediate upgrade is not possible, the vendor workaround is to avoid passing untrusted URLs into docling-core's remote fetch functionality - practically, this means restricting input URLs to a vetted allowlist of domains, stripping or ignoring untrusted Content-Disposition headers at an upstream proxy, and confining the process to a sandboxed cache directory (e.g., a dedicated tmpfs mount or container volume) so any residual write traversal stays contained. The trade-off is reduced flexibility for legitimate user-supplied document URLs and added operational overhead maintaining the allowlist, so prioritize the upgrade as the durable fix. Reference the GitHub advisory GHSA-jmmv-h3mp-59v8 for the canonical fix metadata.