Andrea Cosentino

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

**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** An injection and Server-Side Request Forgery (SSRF) issue exists in the Apache Camel Solr component. The `camel-solr` producer copies Exchange message headers starting with the `SolrParam.` prefix into Solr request parameters and those starting with `SolrField.` into indexed Solr document fields. Because these prefixes do not start with the `Camel` or `camel` namespace, the `HttpHeaderFilterStrategy` allows them to pass from inbound HTTP requests into the Exchange. In routes bridging an HTTP consumer to a `solr:` producer, an unauthenticated attacker can inject arbitrary Solr request parameters via `SolrParam.*` headers—such as `shards` or `stream.url` to trigger SSRF toward internal services or cloud metadata endpoints, or `qt` to access administrative handlers—and inject arbitrary fields into documents via `SolrField.*` headers. **Recommendations** Upgrade Apache Camel versions 4.0.0 through 4.14.7 to version 4.14.8. Upgrade Apache Camel versions 4.15.0 through 4.18.2 to version 4.18.3. Upgrade Apache Camel versions 4.19.0 through 4.20.9 to version 4.21.0. After upgrading, update routes that set Solr parameters or fields to use `CamelSolrParam.` and `CamelSolrField.` instead of `SolrParam.` and `SolrField.`. As a temporary mitigation, strip `SolrParam.*` and `SolrField.*` headers from untrusted ingress before they reach the `solr:` producer and set required parameters from a trusted source within the route.

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.18.0 through 4.18.2 Apache Camel versions 4.19.0 through 4.20.x **Description** Deserialization of untrusted data in the Apache Camel PQC component occurs when `HashicorpVaultKeyLifecycleManager`, `AwsSecretsManagerKeyLifecycleManager`, and `FileBasedKeyLifecycleManager` read key metadata from secret backends. These components use `java.io.ObjectInputStream.readObject()` to deserialize Base64-wrapped values without an `ObjectInputFilter` or class allow-list. An attacker with write access to the HashiCorp Vault KV path or AWS Secrets Manager secret can store a crafted serialized object. When the application performs normal key-lifecycle operations, the object is deserialized, potentially leading to remote code execution in the application context. **Recommendations** Upgrade to version 4.18.3 for those on the 4.18.x LTS release stream. Upgrade to version 4.21.0. Restrict write access to the key backend so only the application identity can write secrets using least-privilege HashiCorp Vault policies and `secretsmanager:PutSecretValue` IAM permissions. Store PQC key material in a backend separate from data accessible to less-trusted principals.

**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** An improper input validation issue exists in the Apache Camel CXF SOAP component, leading to a confused-deputy redirection. The `camel-cxf` producer determines which SOAP operation to invoke on a backend service using the `operationName` and `operationNamespace` Exchange headers. Because these headers lacked the required Camel prefix, the `HttpHeaderFilterStrategy` failed to block them at the HTTP boundary. Consequently, an unauthenticated HTTP client could manipulate these headers to force the `CxfProducer` to execute a different WSDL operation than intended, such as replacing a read-only operation with a destructive one. This issue also affects `camel-cxfrs` due to the shared `camel-cxf-common` module. **Recommendations** Upgrade Apache Camel versions 4.0.0 through 4.14.7 to version 4.14.8. Upgrade Apache Camel versions 4.15.0 through 4.18.2 to version 4.18.3. Upgrade Apache Camel versions 4.19.0 through 4.20.9 to version 4.21.0. As a temporary mitigation, strip the `operationName` and `operationNamespace` headers from untrusted ingress before they reach the `cxf:` producer and define the operation from a trusted source within the route.

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.15.0 through 4.18.2 Apache Camel versions 4.19.0 through 4.20.9 **Description** Improper authentication and a failure to fail securely in the Apache Camel Keycloak component allow unauthenticated access to protected routes. The `KeycloakSecurityPolicy` uses the `KeycloakSecurityProcessor.beforeProcess()` function to validate requests. By default, the `requiredRoles` and `requiredPermissions` variables are empty, causing the system to skip cryptographic verification of the bearer access token, including checks for signature, issuer, and expiry. While requests without a token are rejected, any non-null value in the `Authorization: Bearer` header—such as an arbitrary string or a forged, unsigned JWT—is accepted. This occurs because `allowTokenFromHeader` is set to `true` by default. If a protected route forwards to a producer capable of executing code, this flaw can lead to unauthenticated remote code execution. **Recommendations** Update Apache Camel to version 4.21.0. Update Apache Camel to version 4.18.3 for those on the 4.18.x release stream. Configure a non-empty `requiredRoles` or `requiredPermissions` on every `KeycloakSecurityPolicy` to ensure token verification is performed. Set `allowTokenFromHeader` to `false` if the token is not expected to come from the request header. Perform token verification at the framework layer before the policy is applied.

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 3.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** An issue exists in the Apache Camel JMS component where the `JmsBinding.extractBodyFromJms()` function in `camel-jms` (and equivalent bindings in `camel-sjms`, `camel-sjms2`, `camel-amqp`, `camel-activemq`, and `camel-activemq6`) improperly handles the deserialization of incoming JMS ObjectMessage payloads when the `mapJmsMessage` option is enabled. Although a post-deserialization class check was implemented to restrict allowed classes, the `org.apache.camel.support.DefaultExchangeHolder` class is included in the allow-list. An attacker can send a crafted ObjectMessage with a `DefaultExchangeHolder` as the top-level object to bypass this check. The system then calls `DefaultExchangeHolder.unmarshal()`, allowing the attacker to inject arbitrary Exchange state—including message bodies, headers, properties, and variables—using only trusted `java.lang` and `java.util` types. This allows for the manipulation of routing, headers, exchange properties, and error handling without requiring a deserialization gadget chain. **Recommendations** Upgrade to version 4.21.0. Upgrade to version 4.14.8 for those on the 4.14.x LTS release stream. Upgrade to version 4.18.3 for those on the 4.18.x release stream. Restrict publish access to the queues and topics consumed by Camel to trusted producers via JMS broker authorization. Avoid exposing JMS consumers that map ObjectMessage bodies to untrusted networks.

**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 Lucene Component allows for authorization bypass through user-controlled keys. The `camel-lucene` producer reads search phrases from an Exchange header `LuceneConstants.HEADER QUERY` (with the value `QUERY`) and `HEADER RETURN LUCENE DOCS` (with the value `RETURN LUCENE DOCS`). Since these names lack the `Camel` or `camel` prefix, the `HttpHeaderFilterStrategy` allows them to pass from inbound HTTP requests into the Exchange. In routes exposing Lucene query operations via an HTTP consumer, an attacker can set the `QUERY` header to execute arbitrary queries against the full-text index, overriding intended filters. This can lead to unauthorized access to documents or high CPU consumption through expensive regular-expression queries. No credentials are required if the HTTP consumer is unauthenticated. **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, routes setting the query via raw header names must use `CamelLuceneQuery` and `CamelLuceneReturnLuceneDocs` instead of `QUERY` and `RETURN LUCENE DOCS`. As a temporary mitigation, strip the `QUERY` and `RETURN LUCENE DOCS` headers before the Lucene producer and set the query from a trusted source.

**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.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.18.0 through 4.18.2 Apache Camel versions 4.19.0 through 4.20.x **Description** Insufficient session expiration in the Apache Camel Keycloak Component occurs because the `KeycloakSecurityHelper.parseAndVerifyAccessToken()` function fails to apply the `IS ACTIVE` predicate. This predicate is responsible for validating the `exp` (expiration) and `nbf` (not-before) claims of a token. Consequently, while the helper verifies the token signature, subject, and issuer, it does not enforce the validity window, allowing expired or not-yet-valid access tokens to be accepted as valid for inbound request authentication. **Recommendations** Upgrade to version 4.18.3 for those on the 4.18.x release stream. Upgrade to version 4.21.0. As a temporary mitigation, validate the `exp` and `nbf` claims of the access token within the route before trusting it. Keep Keycloak access-token lifetimes short. Ensure any upstream gateway or resource server validates the token validity window.

☕ Apache Camel critical alert: CVE-2026-43867 hits the camel-pqc component. Post-quantum key metadata deserialized via ObjectInputStream with zero ObjectInputFilter — unauthenticated RCE risk at CVSS 9.8. Check your Camel builds now. #AppSec #Apache https://t.co/iaMBNrOfI0 https://t.co/mkIJ19Sd5Y

**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** The camel-netty-http server consumer in Apache Camel contains an issue where the `muteException` option defaults to false. When this option is false, any request that triggers an exception during route processing causes the consumer to write the full Java stack trace of the Throwable into the HTTP response body as text/plain via `DefaultNettyHttpBinding`. An unauthenticated client can trigger this by sending malformed request bodies or invalid parameters. The resulting stack trace may disclose sensitive internal information, such as embedded credentials, internal hostnames, IP addresses, filesystem paths, dependency versions, and database or class names. **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. As a temporary mitigation, explicitly set `muteException=true` on the camel-netty-http consumer or globally via the `camel.component.netty-http.configuration.mute-exception=true` property.

**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** The camel-undertow HTTP server consumer contains an issue where the `muteException` option defaults to false. When this option is false, any request that triggers an exception during route processing causes the consumer to write the full Java Throwable stack trace into the HTTP response body as text/plain. This allows unauthenticated clients to obtain sensitive internal information, such as embedded credentials, internal hostnames, IP addresses, filesystem paths, dependency versions, and database names. Additionally, for Rest DSL consumers, the `muteException` option is ignored because the `RestUndertowHttpBinding` uses a hard-coded false value, ensuring the stack trace is returned regardless of the configuration. **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. As a temporary mitigation for non-Rest DSL consumers, explicitly set `muteException=true` on the camel-undertow consumer or globally via the `camel.component.undertow.mute-exception=true` property.

**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** An injection and authorization bypass issue exists in the Apache Camel Salesforce component. The `camel-salesforce` producer resolves operation parameters—including SOQL queries, SOSL searches, target SObject names and IDs, Apex REST URLs, methods, and query parameters—from Exchange message headers, prioritizing these over endpoint configurations via the `getParameter()` function. Because the control-header constants in `SalesforceEndpointConfig` (such as `sObjectQuery`, `sObjectSearch`, `sObjectName`, `sObjectId`, `apexUrl`, and `apexMethod`) lacked the Camel prefix, they were not blocked by the `HttpHeaderFilterStrategy` at the HTTP boundary. In routes bridging an HTTP consumer to a Salesforce producer, an unauthenticated HTTP client can inject these headers to override intended operations. This allows attackers to execute unauthorized SOQL queries, SOSL searches, CRUD operations, or redirect Apex REST calls using the broad permissions of the connected Salesforce integration user. **Recommendations** Upgrade Apache Camel versions 4.0.0 through 4.14.7 to version 4.14.8. Upgrade Apache Camel versions 4.15.0 through 4.18.2 to version 4.18.3. Upgrade Apache Camel versions 4.19.0 through 4.20.9 to version 4.21.0. After upgrading, update routes that set Salesforce operation parameters via raw header names to use `CamelSalesforce*` names (e.g., `CamelSalesforceSObjectQuery` and `CamelSalesforceApexUrl`) instead of `sObject*` or `apex*` values. As a temporary mitigation, strip Salesforce control headers from untrusted ingress before the Salesforce producer by using `removeHeaders('sObject*')` and `removeHeaders('apex*')` at the start of the route, and ensure parameters are set from a trusted source.

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.12.0 through 4.14.7 Apache Camel versions 4.15.0 through 4.18.2 Apache Camel versions 4.19.0 through 4.20.x **Description** An improper input validation issue exists in the Apache Camel DAPR component, specifically within the `DaprPubSubConsumer`. The component copies the Pub/Sub component name and topic from inbound CloudEvents into the `CamelDaprPubSubName` and `CamelDaprTopic` Exchange headers. Because the `DaprConfigurationOptionsProxy` prioritizes these headers over the configured destination during republishing, an attacker capable of publishing messages to a subscribed topic can manipulate these values. This allows the attacker to redirect or exfiltrate messages to an arbitrary Dapr Pub/Sub component and topic, bypassing intended routing and topic-level access controls. Exploitation requires the ability to publish to the topic the route subscribes to. **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. As a temporary mitigation, remove the `CamelDaprPubSubName` and `CamelDaprTopic` headers from the Exchange between the Dapr consumer and any Dapr producer in the route. Restrict publishing permissions for the subscribed Dapr Pub/Sub topic to trusted producers only.