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

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

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

docling-core, a document processing library used in versions 2.5.0 through 2.74.0, contains a validation flaw that allows remote attackers to read arbitrary files accessible to the processing user or…. A patch is available.

How to fix or mitigate CVE-2026-44019?

Within 24 hours: inventory all applications and systems using docling-core and assess exposure to untrusted document inputs. Within 7 days: apply vendor-released patch version 2.74.1 to all affected systems and test in non-production environments. Within 30 days: complete deployment of version 2.74.1 across all production infrastructure and verify no versions 2.5.0-2.74.0 remain in use.

docling-core CVE-2026-44019

HIGH

External Control of File Name or Path (CWE-73)

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

GHSA-j5xp-7m2f-49jv

Information Disclosure

8.1

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

8.1 HIGH

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

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

Jun 03, 2026 - 21:47 vuln.today

Analysis Generated

Jun 03, 2026 - 21:47 vuln.today

DescriptionGitHub Advisory

Impact

In versions >= 2.5.0, < 2.74.1, docling-core could allow local file:// image references and accepted inline data: content without a decoded-size limit.

In applications that accept untrusted image references, this may allow access to local files readable by the process or excessive memory use from large inline payloads.

Patches

Patched in docling-core 2.74.1. The fix blocks local file URIs by default and adds a size limit for decoded inline image data.

Users should upgrade to:

docling-core >= 2.74.1

Workarounds

If upgrading is not immediately possible:

reject file: and data: image references from untrusted input
allow only approved local or remote image sources
apply input size and memory limits to processing workers

References

Fix release: v2.74.1

AnalysisAI

Improper URI validation in docling-core versions 2.5.0 through 2.74.0 lets remote attackers supplying crafted image references read arbitrary local files readable by the processing user or exhaust memory via oversized inline data: payloads. The flaw exists because the library accepted file:// references and did not enforce a decoded-size cap on inline base64 image content. No public exploit identified at time of analysis, but the GitHub advisory GHSA-j5xp-7m2f-49jv confirms the issue and a fixed release (2.74.1) is available.

Technical ContextAI

docling-core is a Python library (pkg:pip/docling-core) used to parse and serialize document content including embedded image references via ImageRef objects. The root cause maps to CWE-73 (External Control of File Name or Path): the ImageRef URI handler trusted user-supplied schemes, accepting file:// URIs that resolve to paths on the host filesystem and data: URIs whose base64 payloads were decoded without a size ceiling. When an upstream application - such as a document-ingestion pipeline, RAG indexer, or AI agent that feeds untrusted documents into docling-core - passed attacker-controlled image references, the library would either dereference local paths or allocate memory proportional to the inline payload. The 2.74.1 fix (commit 2087d0f, PR #595 'Refine ImageRef URI handling') blocks file:// URIs by default and enforces a decoded-size limit on inline data.

RemediationAI

Apply the vendor-released patch: upgrade docling-core to version 2.74.1 or later (https://github.com/docling-project/docling-core/releases/tag/v2.74.1), which blocks file:// URIs by default and adds a decoded-size limit for inline data: image payloads (PR #595, commit 2087d0f). Where an immediate upgrade is not feasible, reject file: and data: schemes in image references coming from untrusted input before passing documents to docling-core, restrict accepted image sources to an allowlist of approved local or remote origins (note: an allowlist may break legitimate workflows that depend on embedded base64 thumbnails or local-path references in trusted pipelines), and enforce input-size and per-worker memory limits to contain decoded-payload growth (trade-off: legitimate large images may be rejected, so tune limits against expected document sizes). Full advisory details and remediation guidance are at https://github.com/advisories/GHSA-j5xp-7m2f-49jv.