Średni Oczekuje na analizę

CVE-2026-95629

opublikowano: 26.10.2026, 10:16

modyfikacja: 26.10.2026, 14:42

Ocena CVSS

5.4

Średni · v3.1

Oficjalne źródła

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

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

Luka w zabezpieczeniach Nieprawidłowe ograniczenie nazwy ścieżki do katalogu z ograniczeniami („Path Traversal”) w komponencie Apache Camel Docling.

Ten problem dotyczy Apache Camel: od 4.15.0 przed 4.18.5, od 4.19.0 przed 4.22.2.

DoclingProducer uruchamia zewnętrzne narzędzie doclingu w trybie CLI (domyślnie) i informuje go, gdzie zapisać przekonwertowany dokument za pomocą flagi --output. Kiedy ustawiono nagłówek CamelDoclingOutputFilePath, addOutputDirectoryArguments dosłownie przekazał jego wartość tej flagi: wartość nie została znormalizowana, ścieżka bezwzględna lub ścieżka zawierająca .. segmenty została zaakceptowana jako podana i żadna opcja punktu końcowego nie mogła ograniczyć jej do katalogu. Funkcja sprawdzania poprawności argumentów niestandardowych dodana przez poprawkę CVE-2026-40047 odrzuca flagi --output i -o w nagłówku CamelDoclingCustomArguments i informuje osoby wywołujące, aby zamiast tego wybrały katalog wyjściowy z tym nagłówkiem, tak aby jedyna wartość decydująca o tym, gdzie zapisy docling dotarły do wiersza poleceń bez żadnej kontroli stosowanej do argumentów niestandardowych. Docling zapisuje wynik konwersji jako Markdown, HTML, JSON lub tekst do tego katalogu, nadając plikowi nazwę odpowiadającą plikowi wejściowemu, a następnie producent usuwa tylko swój własny katalog tymczasowy, więc plik pozostaje na miejscu. Osoba mogąca ustawić nagłówek może zatem utworzyć dane wyjściowe konwersji w dowolnym katalogu, do którego proces Camela może zapisywać. Zawartość takiego pliku to konwersja dokumentu niesionego przez wiadomość, więc jest ona kształtowana przez tego, kto dostarcza ten dokument bez zapisywania bajt po bajcie, a gdy treść dokumentu dotrze do treści wiadomości, producent przechowuje ją pod losową tymczasową nazwą, którą następnie przenosi plik wyjściowy. Nagłówek należy do przestrzeni nazw nagłówka Camel, którą konsumenci stosujący domyślne filtrowanie nagłówków Camel, tacy jak konsumenci JMS i Kafka, usuwają z wiadomości przychodzących, więc problem występuje, gdy trasa przekazuje do nagłówka wartości, na które wpływają zewnętrzne wartości lub gdy konsument mapuje przychodzące nagłówki bez tego filtrowania. Tryb docling-serve nie używa nagłówka.

Użytkownikom zaleca się aktualizację do wersji 4.23.0, która rozwiązuje problem. Jeśli użytkownicy korzystają ze strumienia wydań 4.22.x, sugeruje się im aktualizację do wersji 4.22.2. Jeśli użytkownicy korzystają ze strumienia wydań 4.18.x, sugeruje się im aktualizację do wersji 4.18.5. Poprawka dodaje opcję punktu końcowego OutputBaseDirectory, która jest domyślnie nieustawiona, więc po aktualizacji należy ją ustawić w każdym doclingowym punkcie końcowym, którego nagłówek CamelDoclingOutputFilePath może przenosić wartość, na którą ma wpływ spoza wdrożenia; bez tego nagłówek jest znormalizowany, ale nadal może nazwać dowolny katalog. Linie wydań 4.15.x do 4.17.xi 4.19.x do 4.21.x dobiegły końca przed rozwiązaniem tego problemu i nie otrzymają poprawki, więc wdrożenia w nich muszą zostać przeniesione do obsługiwanej wersji. W przypadku wdrożeń, których nie można uaktualnić natychmiast, nie twórz nagłówka CamelDoclingOutputFilePath z wartości pochodzących spoza wdrożenia, usuń ten nagłówek z wiadomości przychodzących z zewnątrz, zanim dotrą do doclingowego punktu końcowego, i upewnij się, że konsumenci mapujący nagłówki wiadomości przychodzących opuszczają przestrzeń nazw nagłówka Camel, tak aby tylko sama trasa wybierała katalog wyjściowy.

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Camel Docling component.

This issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.2.

DoclingProducer runs the external docling tool in CLI mode, the default, and tells it where to write the converted document through the --output flag. When the CamelDoclingOutputFilePath header was set, addOutputDirectoryArguments handed its value to that flag verbatim: the value was not normalized, an absolute path or a path containing .. segments was accepted as given, and no endpoint option could confine it to a directory. The custom-argument validation added by the fix for CVE-2026-40047 refuses the --output and -o flags in the CamelDoclingCustomArguments header and tells callers to choose the output directory with this header instead, so the one value that decides where docling writes reached the command line without any of the checks applied to custom arguments. Docling writes the conversion result, as Markdown, HTML, JSON or text, into that directory, naming the file after the input file, and the producer afterwards removes only its own temporary directory, so the file is left in place. A party able to set the header could therefore have conversion output created in any directory the Camel process can write to. The content of such a file is the conversion of the document carried by the message, so it is shaped by whoever supplies that document without being written byte for byte, and when the document content arrives in the message body the producer stores it under a random temporary name, which the output file then carries. The header belongs to the Camel header namespace, which consumers applying Camel's default header filtering, such as the JMS and Kafka consumers, remove from incoming messages, so the issue is reached where a route forwards externally influenced values into the header or where a consumer maps incoming headers without that filtering. The docling-serve mode does not use the header.

Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The fix adds an outputBaseDirectory endpoint option that is unset by default, so after upgrading, set it on every docling endpoint whose CamelDoclingOutputFilePath header can carry a value influenced from outside the deployment; without it the header is normalized but can still name any directory. The 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, do not build the CamelDoclingOutputFilePath header from values that originate outside the deployment, remove that header from messages that arrive from outside before they reach a docling endpoint, and make sure that consumers which map incoming message headers drop the Camel header namespace, so that only the route itself chooses the output directory.

>_ Słabości (CWE)

CWE-22

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve