Andrea Cosentino

**Name of the Vulnerable Software and Affected Versions** Apache Camel Karavan versions 4.0.0 through 4.22.0 **Description** Improper input validation occurs when a deployment is started. The software unmarshals a project's `kubernetes.yaml` and applies all contained resources to the cluster without restricting resource kinds, rejecting security-sensitive pod options, or pinning the target namespace. An authenticated user with any role can cause the application of arbitrary Kubernetes resources accessible to its service account, including pods requesting `hostNetwork`, `hostPID`, `hostIPC`, `hostPath` volumes, host ports, privileged containers, privilege escalation, or added capabilities. **Recommendations** Upgrade to version 4.22.1.

**Name of the Vulnerable Software and Affected Versions** Apache Camel Karavan versions 3.18.0 through 4.22.0 **Description** An authenticated user with any role can exploit a path traversal issue where a project file name provided via the project file API is used without proper validation when writing the project to a working copy for a Git commit. By including `../` sequences in the file name, an attacker can write file content outside the intended project directory to any location writable by the process. This can lead to the overwriting of application configuration or files on the application classpath, potentially resulting in remote code execution within the container. **Recommendations** Upgrade to version 4.22.1.

**Name of the Vulnerable Software and Affected Versions** Apache Shiro versions 2.x through 3.0.0 **Description** When used with the Jakarta EE integration module, a low-privileged user can craft an HTTP request that forces the server to initiate a connection to an attacker-controlled URL and transmit attacker-controlled data. **Recommendations** Upgrade to version 3.0.1 or later. Set the `org.apache.shiro.form-resubmit-host` and `org.apache.shiro.form-resubmit-port` system properties to restrict the host and port used when resubmitting a form.

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 2.17.0 through 4.14.8 Apache Camel versions 4.15.0 through 4.18.3 Apache Camel versions 4.19.0 through 4.21.x **Description** Improper input validation in the `camel-mail` component's `MimeMultipart` data format allows a sender to inject headers into the Camel Exchange. When the `headersInline` variable is set to true, the unmarshal process copies MIME headers from the incoming message to the Camel message without applying a `HeaderFilterStrategy`. An attacker can provide headers within the Camel-internal namespace to override the configured behavior of downstream components. For example, the `camel-sql` producer may execute a statement provided via an injected header. The impact depends on the route configuration following the unmarshal step. This issue only occurs when `headersInline` is enabled. **Recommendations** Upgrade to version 4.22.0. Upgrade to version 4.14.9 for those on the 4.14.x LTS stream. Upgrade to version 4.18.4 for those on the 4.18.x stream. Set the `headersInline` variable to false if inline headers are not required. Use `removeHeaders("Camel*")` immediately after the unmarshal step to strip Camel-internal headers before they reach any processor or producer. Avoid unmarshalling MIME content from untrusted senders in routes that dispatch based on header values. Treat all MIME header names from outside the trust boundary as untrusted input.

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.11.0 through 4.14.8 Apache Camel versions 4.15.0 through 4.18.3 Apache Camel versions 4.19.0 through 4.21.9 **Description** Improper input validation in the Apache Camel Undertow component occurs because the `UndertowEndpoint` incorrectly defaults its `headerFilterStrategy` field to the base `HttpHeaderFilterStrategy`. This action overwrites the `UndertowHeaderFilterStrategy` installed by the `DefaultUndertowHttpBinding`, causing undertow-specific filtering to be bypassed on endpoint-configured routes. Consequently, the legacy `websocket.` Exchange-header prefix is not filtered at the transport boundary. This allows an undertow HTTP consumer to map inbound wire headers onto the Exchange, which an undertow WebSocket producer may then interpret as dispatch directives to deliver messages to an unintended peer. Additionally, header names rejected by undertow are mapped onto the Exchange instead of being skipped. This issue does not affect Rest DSL consumers as they use `UndertowRestHeaderFilterStrategy`. **Recommendations** Upgrade to version 4.14.9 for those on the 4.14.x LTS releases stream. Upgrade to version 4.18.4 for those on the 4.18.x releases stream. Upgrade to version 4.22.0. As a temporary workaround, explicitly configure the strategy by binding an `UndertowHeaderFilterStrategy` in the registry and referencing it on the endpoint, and use `removeHeaders("websocket.*")` to strip dispatch headers at the trust boundary.

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.0.0 through 4.14.8 Apache Camel versions 4.15.0 through 4.18.3 Apache Camel versions 4.19.0 through 4.21.x **Description** A relative path traversal issue exists in the `camel-azure-storage-datalake` component during the `downloadToFile` operation. The component writes files to a local directory specified by the `fileDir` endpoint option by joining it with the remote path name provided by the Azure SDK without lexical normalization or boundary checks. Because the `DataLakeConsumer.createBatchExchangesFromPath` function creates exchanges from `PathItem.getName()` verbatim, a remote file name containing parent-directory segments can resolve to a location outside the intended `fileDir`. This allows an attacker who can influence file names in the consumed Data Lake filesystem to create or overwrite files on the local filesystem with the privileges of the Camel process, potentially leading to a loss of file integrity or further privilege escalation. **Recommendations** Upgrade to version 4.14.9 for those on the 4.14.x LTS releases stream. Upgrade to version 4.18.4 for those on the 4.18.x releases stream. Upgrade to version 4.22.0 for all other affected versions. As a temporary mitigation, use the `regex` endpoint option to ensure only simple single-segment names are accepted, filtering out any names with path separators or parent-directory segments. Avoid using the `downloadToFile` operation on untrusted filesystems and instead use a file name controlled by the route. Treat object names in externally writable Data Lake filesystems as untrusted input and avoid deriving local filesystem paths from them.

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.8.0 through 4.21.x Apache Camel versions 4.14.x through 4.14.8 Apache Camel versions 4.18.x through 4.18.3 **Description** An improper authentication issue exists in the Apache Camel Platform HTTP Main component. When the embedded HTTP server is configured for JWT authentication using `authenticationEnabled` and JWT keystore properties, the `JWTAuthenticationConfigurer.buildJwtOptions()` function may return null if neither `jwtIssuer` nor `jwtAudience` is configured. This causes the system to skip the `JWTAuthOptions.setJWTOptions()` call, resulting in a Vert.x JWTAuth instance that only validates the token signature and expiry. Consequently, the issuer (`iss`) and audience (`aud`) claims are not validated, allowing any unexpired token signed by a trusted key in the keystore to be accepted, regardless of the intended audience or issuer. This affects both the application server and the management server. **Recommendations** For versions 4.8.0 through 4.21.x, upgrade to version 4.22.0. For versions 4.14.x through 4.14.8, upgrade to version 4.14.9 and configure `jwtIssuer`, `jwtAudience`, or both. For versions 4.18.x through 4.18.3, upgrade to version 4.18.4 and configure `jwtIssuer`, `jwtAudience`, or both. Restrict the JWT keystore to the smallest possible trust set, preferably using a signer dedicated to the service. Ensure that any gateway validating issuer and audience in front of the server cannot be bypassed.

🚨 CVE-2026-63621 Improper Input Validation, Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') vulnerability in Apache Camel Knative component The Knative consumer in camel-knative maps inbound CloudEvent attributes onto Camel message headers. In binary content mode the HTTP-header path filters Camel-internal headers through KnativeHttpHeaderFilterStrategy, but in structured content mode (Content-Type application/cloudevents+json) the CloudEvent extension fields are read directly from the JSON body and every extension key is copied into the Exchange headers without applying any HeaderFilterStrategy (CloudEventProcessors, spec versions 1.0, 1.0.1 and 1.0.2). As a result, an unauthenticated attacker can inject Camel-internal headers (e.g. CamelHttpUri, CamelHttpPath, CamelFileName) via a structured-mode CloudEvent request, matched case-insensitively against Camel's header map. When a route forwards messages from a Knative consumer to a header-driven component such as camel-http or camel-file, the injected headers override configured values, enabling server-side request forgery (SSRF), path traversal or message-dispatch redirection depending on the route. This is an incomplete fix of the inbound header filtering previously added for the binary content-mode path, and is the same pattern addressed in camel-cxf/camel-knative (CVE-2026-47323), camel-undertow (CVE-2025-30177), the broader incoming-header filter (CVE-2025-27636 and CVE-2025-29891), and the non-HTTP strategies (CVE-2026-40453). This issue affects Apache Camel: from 3.15.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.22.0, which fixes the issue. If users are on the 4.18.x LTS releases stream, then they are suggested to upgrade to 4.18.4. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.9. The non-LTS releases 4.15.0 through 4.17.0 and 4.19.0 through 4.21.0 are affected but do not receive a maintenance fix; users on those versions should upgrade to 4.18.4 or 4.22.0. 🎖@cveNotify

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.0.0 through 4.14.8 Apache Camel versions 4.15.0 through 4.18.3 Apache Camel versions 4.19.0 through 4.21.9 **Description** A relative path traversal issue exists in the `camel-azure-storage-blob` component. The `downloadBlobToFile` operation in the `BlobOperations.downloadBlobToFile()` function allows downloading Azure Storage blobs to the local filesystem using the `fileDir` endpoint option. Because the component joins `fileDir` with the remote blob name without lexical normalization or boundary checks, a blob name containing parent-directory segments can resolve to a location outside the intended directory. This allows an attacker who can influence blob names in a consumed container to create or overwrite files on the local system with the privileges of the Camel process. **Recommendations** Upgrade to version 4.14.9 for those on the 4.14.x LTS stream. Upgrade to version 4.18.4 for those on the 4.18.x stream. Upgrade to version 4.22.0. As a temporary mitigation, use the `regex` endpoint option to ensure only simple single-segment names are accepted, filtering out path separators or parent-directory segments. Avoid using the `downloadBlobToFile` operation on untrusted containers and instead use a file name controlled by the route. Treat blob names in externally writable containers as untrusted input and avoid deriving local filesystem paths from them.

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.0.0 through 4.14.8 Apache Camel versions 4.15.0 through 4.18.3 Apache Camel versions 4.19.0 through 4.21.9 **Description** A relative path traversal issue exists in the `camel-google-storage` consumer. When the `downloadFileName` option is used, the consumer downloads objects from Google Cloud Storage to the local filesystem. If the `downloadFileName` value contains no expression token, the system appends the remote object name to the destination path using the `${file:name}` token. Because this token returns the file name verbatim without lexical normalization or boundary checks, an object name containing parent-directory segments (e.g., ../) can resolve to a location outside the intended directory. This allows an attacker who can control object names in the consumed bucket to create or overwrite files on the local filesystem with the privileges of the Camel process. **Recommendations** Upgrade to version 4.22.0. Upgrade to version 4.14.9 for those on the 4.14.x LTS stream. Upgrade to version 4.18.4 for those on the 4.18.x stream. Set the `filter` option to a regular expression that only accepts simple single-segment object names to exclude those with path separators. Use an explicit expression for `downloadFileName` based on `${file:onlyname}` instead of the implicit `${file:name}`. Treat object names in externally writable buckets as untrusted input and avoid deriving local filesystem paths from them.

**اسم البرنامج المعرض للخطر والإصدارات المتأثرة** إصدارات Apache Camel من 4.0.0 إلى 4.14.8 إصدارات Apache Camel من 4.15.0 إلى 4.18.3 إصدارات Apache Camel من 4.19.0 إلى 4.21.9 **الوصف** يؤدي التحقق غير السليم من صحة المدخلات في مكون Apache Camel Atmosphere Websocket إلى السماح بحقن الرؤوس. يحدد منتج `camel-atmosphere-websocket` تسليم الرسائل إلى أقران WebSocket باستخدام رؤوس تبادل محددة: `websocket.connectionKey`، و`websocket.connectionKey.list`، و`websocket.sendToAll`، و`websocket.eventType`، و`websocket.errorType`. ونظرًا لأن هذه الرؤوس تقع خارج نطاق أسماء Camel الذي يتم تصفيته، فإن مستهلكي عائلة HTTP يقبلونها. في المسارات التي تربط مستهلك HTTP بمنتج atmosphere-websocket، يمكن لمرسل خارجي توفير هذه الرؤوس للتلاعب بقرارات التوزيع الخاصة بالمنتج. وقد يؤدي ذلك إلى حجب الإشعارات أو تسليمها إلى عميل غير مقصود. ويحدث هذا لأن الدالة `WebsocketProducer.process()` تعطي الأولوية لرأس القائمة على رأس المفتاح الفردي. **التوصيات** قم بالترقية إلى الإصدار 4.14.9 لمن يستخدمون سلسلة إصدارات 4.14.x LTS. قم بالترقية إلى الإصدار 4.18.4 لمن يستخدمون سلسلة إصدارات 4.18.x. قم بالترقية إلى الإصدار 4.22.0 لجميع الإصدارات الأخرى المتأثرة. كإجراء تخفيفي مؤقت، قم بإزالة رؤوس الإرسال عند حدود الثقة قبل المنتج باستخدام `removeHeaders(“websocket.*”)` بين مستهلك HTTP ومنتج atmosphere-websocket. تجنب ربط مستهلك HTTP غير موثوق به

**اسم البرنامج المعرض للخطر والإصدارات المتأثرة** إصدارات Apache InLong من 2.0.0 إلى 2.3.x **الوصف** توجد مشكلة حقن SQL بسبب عدم معالجة العناصر الخاصة المستخدمة في أمر SQL بشكل صحيح. يحدث هذا من خلال استيفاء علامة $ في MyBatis غير الخاضع للتحقق داخل الدالة `AuditAlertRuleService`، مما يسمح للمهاجم بحقن قيم سلاسل نصية في عبارات SQL. هذه المشكلة يمكن الوصول إليها عبر الشبكة ولا تتطلب أي مصادقة. **التوصيات** الترقية إلى الإصدار 2.4.0.

**اسم البرنامج المعرض للخطر والإصدارات المتأثرة** إصدارات Apache Ranger من 0.6 إلى 2.8 **الوصف** يحتوي Apache Ranger على ثغرة في حقن الأوامر، تحدث عندما يفشل البرنامج في تحييد العناصر الخاصة المستخدمة في الأمر بشكل صحيح، مما قد يسمح للمهاجم بتنفيذ أوامر عشوائية على النظام. **التوصيات** في الوقت الحالي، لا توجد معلومات حول إصدار أحدث يحتوي على إصلاح لهذه الثغرة الأمنية.

**اسم البرنامج المعرض للخطر والإصدارات المتأثرة** Apache Polaris (لم يتم تحديد الإصدارات المتأثرة) **الوصف** يمكن لمستخدم معتمد يتمتع بأذونات تسجيل الجداول أو طرق العرض أن يتسبب في قيام النظام باستخدام بيانات اعتماد تخزين الكتالوج لقراءة ملف بيانات وصفية محدد من Iceberg قبل التحقق مما إذا كان الملف يقع ضمن مواقع التخزين المسموح بها. ويحدث هذا عندما يفشل النظام في التحقق من صحة مواقع التخزين بشكل متسق أثناء عملية التسجيل. إذا كانت بيانات الاعتماد الأساسية تتمتع بحق الوصول إلى كائنات خارج الحدود المحددة، فقد يتم الكشف عن معلومات محدودة من تلك الكائنات. بالإضافة إلى ذلك، قد يقبل النظام بيانات تعريف التسجيل داخل موقع مسموح به يشير إلى مواقع تخزين خارج الحدود المسموح بها، على الرغم من أن هذا لا يؤدي إلى قراءة المواقع الخارجية أثناء التسجيل. تتطلب هذه المشكلة نشرًا باستخدام بيع بيانات اعتماد S3 وكائن خارج المواقع المسموح بها يمكن لبيانات اعتماد الكتالوج الوصول إليه. **التوصيات** في الوقت الحالي، لا توجد معلومات حول إصدار أحدث يحتوي على إصلاح لهذه الثغرة الأمنية.

**اسم البرنامج المعرض للخطر والإصدارات المتأثرة** إصدارات Apache Zeppelin من 0.6.0 إلى 0.12.0 **الوصف** توجد مشكلة حقن LDAP حيث يقوم ActiveDirectoryGroupRealm بإنشاء عوامل تصفية بحث LDAP دون تصفية المدخلات التي يتحكم فيها المستخدم. وهذا يسمح لمهاجم تمت مصادقته بحقن صيغة عامل تصفية LDAP عبر نقطة النهاية ”user-search“ ومسار البحث عن الدور بعد نجاح مصادقة LDAP، مما قد يؤدي إلى كشف معلومات الدليل. **التوصيات** الترقية إلى الإصدار 0.12.1.

**اسم البرنامج المعرض للخطر والإصدارات المتأثرة** إصدارات Apache Gravitino من 1.0.0 إلى 1.2.0 **الوصف** يحدث حقن مسار عنوان URL بسبب استخدام معرّفات مقدمة من المستخدم دون تشفير. **التوصيات** الترقية إلى الإصدار 1.2.1.

**اسم البرنامج المعرض للخطر والإصدارات المتأثرة** إصدارات Apache IoTDB من 1.0.0 إلى 2.0.9 **الوصف** يقوم معالج الأنابيب (pipe processor) بقراءة اسم فئة Java كامل التأهيل ويقوم بإنشاء مثيل لها باستخدام الدالة `Class.forName().newInstance()` دون إجراء أي تحقق من الصحة أو إدراجها في قائمة المسموح بها. يسمح هذا الانعكاس غير الآمن للمهاجم بفرض إنشاء مثيلات لفئات عشوائية على مسار الفئات عبر RPC دون مصادقة. في حالة وجود فئة أداة مناسبة، قد يؤدي ذلك إلى تنفيذ تعليمات برمجية عن بُعد واختراق كامل للعملية. **التوصيات** الترقية إلى الإصدار 2.0.10.

**اسم البرنامج المعرض للخطر والإصدارات المتأثرة** إصدارات Apache IoTDB من 1.0.0 إلى 2.0.9 **الوصف** يوجد في Apache IoTDB قيد غير صحيح لمسار اسم الملف المؤدي إلى دليل مقيد، وهو ما يُعرف باسم «عبور المسار» (Path Traversal). وهذا يسمح للمهاجم بكتابة ملفات عشوائية في أي موقع تتمتع فيه عملية IoTDB بأذونات الكتابة، وذلك باستخدام واجهة برمجة تطبيقات (API) غير آمنة. **التوصيات** الترقية إلى الإصدار 2.0.10.

**اسم البرنامج المعرض للخطر والإصدارات المتأثرة** إصدارات Apache Camel من 4.0.0 إلى 4.14.7 إصدارات Apache Camel من 4.15.0 إلى 4.18.2 إصدارات Apache Camel من 4.19.0 إلى 4.20.9 **الوصف** يوجد خطأ في التحقق من صحة المدخلات في مكون `camel-aws2-sns`. كان مكون `Sns2HeaderFilterStrategy` يفتقر في الأصل إلى قاعدة تصفية واردة، حيث كان يتم تكوين مرشح صادر فقط عبر `setOutFilterPattern` لحجب رؤوس `Camel*` و`breadcrumbId` و`org.apache.camel.*`. وفي حين أن ثغرة مماثلة في مكون `camel-aws2-sqs` سمحت بحقن رؤوس تحكم Camel عبر `HeaderFilterStrategy.applyFilterToExternalHeaders`، فإن هذه الثغرة لا يمكن استغلالها في `camel-aws2-sns` لأن `Sns2Endpoint` مخصص للمنتجين فقط ولا يدعم المستهلكين، حيث تُطلق `createConsumer()` استثناء `UnsupportedOperationException`. يُعد هذا التحديث إجراءً تقويًّا دفاعيًّا متعمقًا لمواءمة التكوين مع الاستراتيجيات الأخرى عن طريق إضافة قاعدة `setInFilterStartsWith` لمساحة أسماء Camel. **التوصيات** قم بتحديث إصدارات Apache Camel من 4.0.0 إلى 4.14.7 إلى الإصدار 4.14.8. قم بتحديث إصدارات Apache Camel من 4.15.0 إلى 4.18.2 إلى الإصدار 4.18.3. قم بتحديث إصدارات Apache Camel من 4.19.0 إلى 4.20.9 إلى الإصدار 4.21.0. قم بتطبيق أذونات IAM ذات الامتيازات الدنيا على مواضيع SNS كأفضل ممارسة عامة.

**اسم البرنامج المعرض للخطر والإصدارات المتأثرة** إصدارات Apache Camel من 4.0.0 إلى 4.14.7 إصدارات Apache Camel من 4.15.0 إلى 4.18.2 إصدارات Apache Camel من 4.19.0 إلى 4.20.9 **الوصف** توجد مشكلة تتعلق بالحقن وتزوير الطلبات من جانب الخادم (SSRF) في مكون Apache Camel Solr. يقوم منتج `camel-solr` بنسخ رؤوس رسائل Exchange التي تبدأ بالبادئة `SolrParam.` إلى معلمات طلب Solr، وتلك التي تبدأ بـ `SolrField.` إلى حقول مستندات Solr المفهرسة. ونظرًا لأن هذه البادئات لا تبدأ بمساحة الاسم `Camel` أو `camel`، فإن `HttpHeaderFilterStrategy` تسمح بمرورها من طلبات HTTP الواردة إلى Exchange. في المسارات التي تربط مستهلك HTTP بمنتج `solr:`، يمكن لمهاجم غير مصدق عليه حقن معلمات طلب Solr تعسفية عبر رؤوس `SolrParam.*` —مثل `shards` أو `stream.url`—لتشغيل هجوم SSRF تجاه الخدمات الداخلية أو نقاط نهاية بيانات التعريف السحابية، أو `qt` للوصول إلى معالجات إدارية—وحقن حقول تعسفية في المستندات عبر رؤوس `SolrField.*`. **التوصيات** قم بترقية إصدارات Apache Camel من 4.0.0 إلى 4.14.7 إلى الإصدار 4.14.8. قم بترقية إصدارات Apache Camel من 4.15.0 إلى 4.18.2 إلى الإصدار 4.18.3. قم بترقية إصدارات Apache Camel من 4.19.0 إلى 4.20.9 إلى الإصدار 4.21.0. بعد الترقية، قم بتحديث المسارات التي تحدد معلمات أو حقول Solr لاستخدام `CamelSolrParam.` و`CamelSolrField.` بدلاً من `SolrParam.` و`SolrField.`. كإجراء تخفيفي مؤقت، قم بإزالة `SolrParam.*` و`SolrField.*