This is an automated email from the ASF dual-hosted git repository. oscerd pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/camel-website.git
commit c0cb529d687251e14288b7609eefa147da048896 Author: Andrea Cosentino <[email protected]> AuthorDate: Mon Oct 12 14:52:16 2026 +0200 Correct the end-of-life note in CVE-2026-78163 and re-sign it The last sentence of the 4.15.0 paragraph said that "releases from 4.15.0 through the 4.14.x-equivalent maintenance lines" would not be fixed, which contradicts itself. It now names the lines in the affected ranges that reached end of life: 4.15.x to 4.17.x and 4.19.x to 4.21.x. The signature still covered an older rendering of the advisory that predated later edits to the page, so the .txt.asc is regenerated from the current .md in the same clearsigned layout as the other advisories. Co-Authored-By: Claude Opus 5.5 <[email protected]> Signed-off-by: Andrea Cosentino <[email protected]> --- content/security/CVE-2026-78163.md | 2 +- content/security/CVE-2026-78163.txt.asc | 150 +++++++------------------------- 2 files changed, 34 insertions(+), 118 deletions(-) diff --git a/content/security/CVE-2026-78163.md b/content/security/CVE-2026-78163.md index 1844a361..b1d2b74b 100644 --- a/content/security/CVE-2026-78163.md +++ b/content/security/CVE-2026-78163.md @@ -20,6 +20,6 @@ The fix was merged on main in https://github.com/apache/camel/pull/25596 (commit A String message body is now treated as the document itself by default. The two location readings became opt-in through two new endpoint options, allowUrlSource and allowFilePathSource, both defaulting to false; a body that looks like a URL or a path is otherwise rejected with an IllegalArgumentException naming the option that would enable it. A further inputBaseDirectory option, unset by default, confines every local input path to a configured directory, normalizing lexically and compar [...] -The local file disclosure has been present since camel-docling was introduced in 4.15.0. The remote URL sink was added later, in 4.16.0, when docling-serve support was introduced, so releases in the 4.15.x line are affected by the file disclosure only. Releases from 4.15.0 through the 4.14.x-equivalent maintenance lines that have reached end of life will not receive a fix. +The local file disclosure has been present since camel-docling was introduced in 4.15.0. The remote URL sink was added later, in 4.16.0, when docling-serve support was introduced, so releases in the 4.15.x line are affected by the file disclosure only. The 4.15.x to 4.17.x and 4.19.x to 4.21.x 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. This advisory is distinct from CVE-2026-40047, which concerned insufficient validation of the CamelDoclingCustomArguments header in the same component and was fixed in 4.18.3 and 4.19.0. That fix was scoped to the custom-argument allowlist and did not touch the body-derived input path described here. Reaching this issue is also easier, because the Camel header namespace is filtered at consumer boundaries by the default HeaderFilterStrategy whereas the message body never is. It is classif [...] diff --git a/content/security/CVE-2026-78163.txt.asc b/content/security/CVE-2026-78163.txt.asc index bb52b3f4..a5301b42 100644 --- a/content/security/CVE-2026-78163.txt.asc +++ b/content/security/CVE-2026-78163.txt.asc @@ -1,123 +1,39 @@ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 -Apache Camel security advisory: CVE-2026-78163 - -Project: Apache Camel -CVE ID: CVE-2026-78163 - -Severity - -MEDIUM - -Summary - -Camel-Docling: Unvalidated message body input source enables server-side -request forgery and local file disclosure in DoclingProducer - -Versions affected - -- - From 4.15.0 before 4.18.5, from 4.19.0 before 4.22.1. - -Versions fixed - -4.18.5, 4.22.1 and 4.23.0 - -Description - -DoclingProducer decided what a String message body meant by inspecting its -prefix. A body starting with http:// or https:// was handed to Docling as a -remote URL to fetch, a body starting with / or containing a backslash was read -from the local filesystem, and anything else was written to a temporary file -and converted as document content. - -The mode was chosen implicitly and no endpoint option allowed a route author to -pin the component to a single interpretation, so a route that means "convert -whatever text arrives in the body" silently became a fetcher of remote -resources or a reader of local files whenever that text happened to begin with -one of those prefixes. - -The only guard applied to the derived value was a size check, and that check -was wrapped in an existence test, so a path that resolved to nothing, or to a -pseudo-file reporting a size of zero, passed without being checked at all. - -Five call sites reached the two sinks: the CLI mode appended the value as the -final positional argument of the docling subprocess, and the docling-serve mode -passed it either to HttpSource for the backend to fetch, or to -Files.readAllBytes so that the content could be base64-encoded and uploaded. - -Because the exchange body is never filtered by a HeaderFilterStrategy, unlike -the Camel header namespace, a sender able to place text in a message that a -route forwards into a docling endpoint could reach both sinks without any -opt-in from the deployment. - -Notes - -A String message body is now treated as the document itself by default. The two -location readings became opt-in through two new endpoint options, -allowUrlSource and allowFilePathSource, both defaulting to false; a body that -looks like a URL or a path is otherwise rejected with an -IllegalArgumentException naming the option that would enable it. - -A further inputBaseDirectory option, unset by default, confines every local -input path to a configured directory, normalizing lexically and comparing on -path-segment boundaries so that a sibling directory sharing a name prefix with -the base is not accepted. - -Only a bare String body is gated, because only it is ambiguous: the -CamelDoclingInputFilePath header, File, byte[] and InputStream bodies, and the -explicit path collections accepted by the batch operations all state their -meaning already and continue to work without an opt-in, while remaining subject -to inputBaseDirectory. - -The local file disclosure has been present since camel-docling was introduced -in 4.15.0. The remote URL sink was added later, in 4.16.0, when docling-serve -support was introduced, so releases in the 4.15.x line are affected by the file -disclosure only. - -This advisory is distinct from CVE-2026-40047, which concerned insufficient -validation of the CamelDoclingCustomArguments header in the same component and -was fixed in 4.18.3 and 4.19.0. That fix was scoped to the custom-argument -allowlist and did not touch the body-derived input path described here. -Reaching this issue is also easier, because the Camel header namespace is -filtered at consumer boundaries by the default HeaderFilterStrategy whereas the -message body never is. - -It is classified as CWE-918 (Server-Side Request Forgery), CWE-22 (Improper -Limitation of a Pathname to a Restricted Directory) and CWE-200 (Exposure of -Sensitive Information to an Unauthorized Actor). - -Mitigation - -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.1. If users are on the 4.18.x releases stream, then they are suggested to -upgrade to 4.18.5. The 4.14.x releases stream and earlier reached end of life -before this issue was resolved and will not receive a fix, so deployments on -those lines must move to a supported release. - -For deployments that cannot upgrade immediately, do not route message bodies -that originate outside the deployment into a docling endpoint, and pass the -document through a typed body such as File, byte[] or InputStream, or through -the CamelDoclingInputFilePath header, so that the body is never subject to -prefix interpretation. - -Credit - -This issue was discovered by Li Zhiyao (BUPT) - -References - -PGP signed advisory data: CVE-2026-78163.txt.asc -Mitre CVE Entry: https://www.cve.org/CVERecord?id=CVE-2026-78163 +- --- +title: "Apache Camel Security Advisory - CVE-2026-78163" +date: 2026-09-07T10:00:00+02:00 +url: /security/CVE-2026-78163.html +draft: false +type: security-advisory +cve: CVE-2026-78163 +severity: MEDIUM +summary: "Camel-Docling: Unvalidated message body input source enables server-side request forgery and local file disclosure in DoclingProducer" +description: "DoclingProducer decided what a String message body meant by inspecting its prefix. A body starting with http:// or https:// was handed to Docling as a remote URL to fetch, a body starting with / or containing a backslash was read from the local filesystem, and anything else was written to a temporary file and converted as document content. The mode was chosen implicitly and no endpoint option allowed a route author to pin the component to a single interpretation, so a route [...] +mitigation: "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.1. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.14.x releases stream and earlier reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release. For deployments that cannot upgrade immedi [...] +credit: "This issue was discovered by Li Zhiyao (BUPT)" +affected: "From 4.15.0 before 4.18.5, from 4.19.0 before 4.22.1." +fixed: 4.18.5, 4.22.1 and 4.23.0 +- --- + +The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-24422 refers to the commits that resolved the issue, and has more details. + +The fix was merged on main in https://github.com/apache/camel/pull/25596 (commit 8b95ef19002a86ed530563a6df0772140ddb5cd0), and backported to camel-4.22.x in https://github.com/apache/camel/pull/25733 (commit 13909b1cb931cf0d38ee3170f5399510fe49d1eb) and to camel-4.18.x in https://github.com/apache/camel/pull/25744 (commit 5e6d0c94735102e5ea9bc249dd27042cd9157cb8). + +A String message body is now treated as the document itself by default. The two location readings became opt-in through two new endpoint options, allowUrlSource and allowFilePathSource, both defaulting to false; a body that looks like a URL or a path is otherwise rejected with an IllegalArgumentException naming the option that would enable it. A further inputBaseDirectory option, unset by default, confines every local input path to a configured directory, normalizing lexically and compar [...] + +The local file disclosure has been present since camel-docling was introduced in 4.15.0. The remote URL sink was added later, in 4.16.0, when docling-serve support was introduced, so releases in the 4.15.x line are affected by the file disclosure only. The 4.15.x to 4.17.x and 4.19.x to 4.21.x 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. + +This advisory is distinct from CVE-2026-40047, which concerned insufficient validation of the CamelDoclingCustomArguments header in the same component and was fixed in 4.18.3 and 4.19.0. That fix was scoped to the custom-argument allowlist and did not touch the body-derived input path described here. Reaching this issue is also easier, because the Camel header namespace is filtered at consumer boundaries by the default HeaderFilterStrategy whereas the message body never is. It is classif [...] -----BEGIN PGP SIGNATURE----- -iQEzBAEBCgAdFiEEJ2Y0ButtuvUpHyYV406fOAL/QQAFAmqemOkACgkQ406fOAL/ -QQD9tAf/UlUGPGYeKLoi+C+rddwScxzWsjGZcAErWTXKUG8Kt8FWmJkCHH+RQu3u -EDGouIAaNXIhrdpLdMSESBgKuZBeW19ZSLwGqNO4Omi9fTDpm2+TJZ/Wj2X9ED20 -kVCHlX3tFBNIUEiYYt0jUTjgO6GnZSIuBA7a+i44/a7Y5/bH5Bix9hDFMoXkT3qp -e8ll0jiyGkFLFpcSX7ed3mtQocsItzI4OfIxtM1XuQCvIKHuwqPyjptJjLky/KQX -V2HrgmJ1oG9DoLBIS78K7LqChMeLzYv3HXXPkuZ6mO9xEEaVWVs7Q02pZstg4/yV -w9H5B6tw/9hvnIic4Py7cj0O2rWlPw== -=iKIU +iQEzBAEBCgAdFiEEJ2Y0ButtuvUpHyYV406fOAL/QQAFAmrM1+EACgkQ406fOAL/ +QQATnAf/Z3GRQcU04gAHc8/vfOtqbjoQ+lGgee4qmEA+rp0WCSlVtkXXduY4z3so +oovRm+sV/HrNVKowLJKTafxG+zBcgyFRjehX5VeHE7P8VxEykl5oH0t9XX59pptX +D8PVYMTZ8vzpOYZvwASXwYfnMsJHjxSThSnQ4bUkO3ZvXQCv05VI4+ZLC/XWJSel +zLAA1mkJ/JAGiGq4ra3t3Jglfz4dNHbjnrS9tgScaCBnQU3tYr8LPmRqvUlx7iUv +23FN6cnt9+Ob28ulTUde4y5Ig4/TXen43kvmxhr10F+FpStYZ9a/5lrapncfvY7W +8Ugs0IeW225oonk0mCTHRSHTmbzIBA== +=wqNB -----END PGP SIGNATURE-----
