Andrea Cosentino

**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.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.

**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.

**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.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** Improper input validation in the Apache Camel Atmosphere Websocket component allows for header injection. The `camel-atmosphere-websocket` producer determines message delivery to WebSocket peers using specific exchange headers: `websocket.connectionKey`, `websocket.connectionKey.list`, `websocket.sendToAll`, `websocket.eventType`, and `websocket.errorType`. Because these headers fall outside the filtered Camel namespace, they are admitted by HTTP-family consumers. In routes bridging an HTTP consumer to an atmosphere-websocket producer, an external sender can supply these headers to manipulate the producer's dispatch decisions. This can lead to notifications being suppressed or delivered to an unintended client. This occurs because the `WebsocketProducer.process()` function prioritizes the list header over the single-key header. **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, strip dispatch headers at the trust boundary before the producer by using `removeHeaders(“websocket.*”)` between the HTTP consumer and the atmosphere-websocket producer. Avoid bridging an untrusted HTTP consumer directly into a WebSocket producer whose dispatch is header-driven without first stripping the dispatch namespace.

**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.

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.

**Name of the Vulnerable Software and Affected Versions** Apache InLong versions 2.0.0 through 2.3.x **Description** An SQL injection issue exists due to improper neutralization of special elements used in an SQL command. This occurs via unvalidated MyBatis $-sign interpolation within the `AuditAlertRuleService` function, allowing an attacker to inject string values into SQL statements. The issue is network accessible and requires no authentication. **Recommendations** Upgrade to version 2.4.0.

**Name of the Vulnerable Software and Affected Versions** Apache Ranger versions 0.6 through 2.8 **Description** Apache Ranger contains a command injection flaw, which occurs when the software fails to properly neutralize special elements used in a command, potentially allowing an attacker to execute arbitrary commands on the system. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Apache Polaris (affected versions not specified) **Description** An authenticated principal with permissions to register tables or views can cause the system to use catalog storage credentials to read a selected Iceberg metadata file before verifying if the file is within allowed storage locations. This occurs when the system fails to consistently validate storage locations during registration. If the underlying credentials have access to objects outside the defined boundary, limited information from those objects may be disclosed. Additionally, the system may accept registration metadata within an allowed location that references storage locations outside the allowed boundary, although this does not trigger a read of the external locations during registration. This issue requires a deployment using S3 credential vending and an object outside the allowed locations that the catalog credentials can access. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Apache Zeppelin versions 0.6.0 through 0.12.0 **Description** An LDAP injection issue exists where the ActiveDirectoryGroupRealm constructs LDAP search filters without escaping user-controlled input. This allows an authenticated attacker to inject LDAP filter syntax through the 'user-search' endpoint and the role-lookup path following successful LDAP authentication, potentially exposing directory information. **Recommendations** Upgrade to version 0.12.1.

**Name of the Vulnerable Software and Affected Versions** Apache Gravitino versions 1.0.0 through 1.2.0 **Description** URL path injection occurs due to the use of unencoded user-supplied identifiers. **Recommendations** Upgrade to version 1.2.1.

**Name of the Vulnerable Software and Affected Versions** Apache IoTDB versions 1.0.0 through 2.0.9 **Description** An improper limitation of a pathname to a restricted directory, known as Path Traversal, exists in Apache IoTDB. This allows an attacker to write arbitrary files to any location where the IoTDB process has write permissions by utilizing an unsafe API. **Recommendations** Upgrade to version 2.0.10.

**Name of the Vulnerable Software and Affected Versions** Apache IoTDB versions 1.0.0 through 2.0.9 **Description** The pipe processor reads a fully qualified Java class name and instantiates it using the `Class.forName().newInstance()` function without validation or allowlisting. This unsafe reflection allows an attacker to force the instantiation of arbitrary classes on the classpath via RPC without authentication. If a suitable gadget class is present, this can lead to remote code execution and full compromise of the process. **Recommendations** Upgrade to version 2.0.10.

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.15.0 through 4.18.2 **Description** An argument injection issue exists in the Apache Camel Docling component. The component uses `java.lang.ProcessBuilder` to execute the external `docling` command-line tool. When custom CLI arguments are provided via the `CamelDoclingCustomArguments` exchange header, the system fails to validate them properly, relying on a denylist of disallowed flags and a basic check for `../` sequences. This allows an attacker to inject unintended `docling` CLI flags or use directory traversal sequences to access files outside the intended directory. While the use of the list-based `ProcessBuilder` prevents OS command injection via shell metacharacters, the weak validation of the `CamelDoclingCustomArguments` header and path-bearing headers enables the injection of arguments passed to the external tool. **Recommendations** Upgrade Apache Camel versions 4.15.0 through 4.17.x to version 4.19.0 or later. Upgrade Apache Camel version 4.18.x to version 4.18.3. Avoid mapping untrusted message content into the `CamelDoclingCustomArguments` header and path-bearing headers. Strip Camel-internal headers from messages arriving from untrusted producers.

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.0.0 through 4.14.7 Apache Camel versions 4.15.0 through 4.18.2 Apache Camel versions 4.19.0 through 4.20.9 **Description** Improper input validation in the Vertx Websocket component allows an unauthenticated remote attacker to perform Server-Side Request Forgery (SSRF) and expose sensitive information. The `camel-vertx-websocket` consumer maps inbound WebSocket query and path parameters into the Camel Exchange header map via the `populateExchangeHeaders()` function without applying a HeaderFilterStrategy. This allows attackers to set internal control headers, such as `CamelHttpUri`, by providing them as query parameters. If the consumer feeds a downstream HTTP producer, the injected `CamelHttpUri` redirects the server-side request to an attacker-controlled destination. Furthermore, the HTTP producer resolves Camel property placeholders within the URI, potentially disclosing environment variables, application properties, or vault secrets to the attacker. **Recommendations** Upgrade to version 4.21.0. Upgrade to version 4.14.8 for those on the 4.14.x LTS releases stream. Upgrade to version 4.18.3 for those on the 4.18.x releases stream. Strip Camel control headers from inbound messages before they reach downstream producers by using `removeHeaders('Camel*')` and `removeHeaders('camel*')` at the start of the route. Require authentication on the WebSocket endpoint. Avoid bridging an untrusted consumer directly into an HTTP producer whose target URI can be driven from message headers.

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.0.0 through 4.14.7 Apache Camel versions 4.15.0 through 4.18.2 Apache Camel versions 4.19.0 through 4.20.9 **Description** Improper input validation exists in the `camel-aws2-sns` component. The `Sns2HeaderFilterStrategy` originally lacked an inbound filter rule, only configuring an outbound filter via `setOutFilterPattern` to block `Camel*`, `breadcrumbId`, and `org.apache.camel.*` headers. While a similar gap in the `camel-aws2-sqs` component allowed the injection of Camel control headers through `HeaderFilterStrategy.applyFilterToExternalHeaders`, this is not exploitable in `camel-aws2-sns` because the `Sns2Endpoint` is producer-only and does not support consumers, as `createConsumer()` throws an `UnsupportedOperationException`. This update is a defense-in-depth hardening measure to align the configuration with other strategies by adding a `setInFilterStartsWith` rule for the Camel namespace. **Recommendations** Update Apache Camel versions 4.0.0 through 4.14.7 to version 4.14.8. Update Apache Camel versions 4.15.0 through 4.18.2 to version 4.18.3. Update Apache Camel versions 4.19.0 through 4.20.9 to version 4.21.0. Apply least-privilege IAM permissions on SNS topics as a general best practice.

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.0.0 through 4.14.7 Apache Camel versions 4.15.0 through 4.18.2 Apache Camel versions 4.19.0 through 4.20.9 **Description** Improper input validation in the Apache Camel DNS component allows for Server-Side Request Forgery (SSRF). The `camel-dns` producers read DNS operation parameters from Exchange message headers using plain strings: `dns.server`, `dns.name`, `dns.domain`, `dns.type`, `dns.class`, and `term`. Because these do not start with the Camel prefix, the `HttpHeaderFilterStrategy` allows them to pass from inbound HTTP requests into the Exchange. In routes bridging an HTTP consumer to a `dns:` producer, an unauthenticated attacker can set the `dns.server` header to redirect queries to a malicious DNS server to observe queried names or return poisoned responses. Additionally, manipulating `dns.name` or `dns.domain` allows for internal network reconnaissance by resolving arbitrary internal hostnames. **Recommendations** Upgrade to version 4.21.0. Upgrade to version 4.14.8 for those on the 4.14.x LTS stream. Upgrade to version 4.18.3 for those on the 4.18.x stream. After upgrading, replace the use of `dns.*` and `term` header names with `CamelDnsServer`, `CamelDnsName`, `CamelDnsDomain`, `CamelDnsType`, `CamelDnsClass`, and `CamelDnsTerm` in routes driving DNS operations. As a temporary mitigation, strip `dns.*` and `term` headers from untrusted ingress before they reach the `dns:` producer and set DNS parameters from a trusted source within the route.