<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-07T10:11:05.970829+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/fkie_cve-2026-105751</id>
    <title>fkie_cve-2026-105751</title>
    <updated>2026-10-07T10:11:06.503875+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Docling simplifies document processing by parsing diverse formats and providing integrations with the generative AI ecosystem. From 2.107.0 until 2.120.3, docling/backend/opendocument_backend.py uses the xlink:href attribute value of a draw:image element as a filesystem path when the referenced part is not found in the document archive. The _image_ref_from_odf_image function reads that attacker-controlled path without a scheme check, extraction-directory confinement, or the enable_local_fetch setting used by other backends. Readable files that Pillow can decode as images are embedded in converted output, and other existing paths can be distinguished through the attempted read. This issue is fixed in 2.120.3.</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-105751"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-4xhp-xg4w-8ppm</id>
    <title>GHSA-4xhp-xg4w-8ppm — Docling: Arbitrary local file read via draw:image xlink:href in the OpenDocument backend</title>
    <updated>2026-10-07T10:11:06.503994+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: docling</p>
<p>## Summary
 
The ODF backend resolves the `xlink:href` of a `draw:image` element as a filesystem path whenever
the referenced part is not found inside the document archive. The value comes straight from
`content.xml`, so it is document content, and it is used with no scheme check, no confinement to
the extraction directory, and without consulting the `enable_local_fetch` / `enable_remote_fetch`
controls that the other backends use for exactly this decision.
 
Converting a crafted `.odt` therefore causes Docling to open an attacker-named absolute path on
the converting host. Where the target decodes as an image, its complete contents are embedded in
the resulting `DoclingDocument` and appear in the HTML, Markdown and JSON exports.
 
Both the read and the disclosure are confirmed by execution. The trigger is a 452-byte archive
containing two entries.
 
## Affected component
 
`docling/backend/opendocument_backend.py`, in `_image_ref_from_odf_image`:
 
```python
image_url = _odf_image_href(image)
...
if image_data is None and odf_obj is not None and image_url:
    try:
        image_data = odf_obj.get_part(image_url)
    except Exception:
        image_data = None
 
if image_data is None and image_url:
    image_path = Path(image_url)
    if image_path.is_file():
        image_data = image_path.read_bytes()
```
 
`_odf_image_href` returns the `xlink:href` attribute. The in-archive lookup is attempted first;
when it fails, the same string is handed to `Path` and read from disk.…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-4xhp-xg4w-8ppm"/>
  </entry>
</feed>
