Yu Bao

**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 Mail Component allows for the exposure of sensitive information. The `MailProducer.getSender()` function scans outgoing exchanges for message headers within the `mail.smtp.` and `mail.smtps.` namespaces. If present, these values are applied as JavaMail session properties, overriding the endpoint configuration. Since this namespace is not blocked by any `HeaderFilterStrategy`, untrusted input from protocols such as HTTP query parameters, request headers, JMS, or Kafka can be used to manipulate the producer. In versions prior to 4.19.0, an attacker can set the `mail.smtp.host` variable to redirect the SMTP connection to a malicious server, leading to the theft of configured usernames and passwords. In versions 4.19.0 and later, the impact is limited to weakening transport security via variables such as `mail.smtp.ssl.trust`, `mail.smtp.starttls.enable`, or `mail.smtp.socks.host`, potentially allowing the interception of outgoing messages. **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 workaround, use `removeHeaders('mail.smtp.*')` and `removeHeaders('mail.smtps.*')` to strip the namespace between any untrusted ingress and the smtp/smtps producer. Restrict the use of per-message overrides by ensuring `useJavaMailSessionPropertiesFromHeaders` is set to false, enabling it only on trusted endpoints.

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

**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.3.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 camel-elasticsearch-rest-client component allows for authorization bypass. The component uses unprefixed header constants—`SEARCH QUERY`, `OPERATION`, `INDEX NAME`, `INDEX SETTINGS`, and `ID`—which are not blocked by the `HttpHeaderFilterStrategy` because they lack the required 'Camel' or 'camel' prefix. When a route exposes an HTTP entry point before an elasticsearch-rest-client producer, an untrusted client can provide these headers to override configured queries and operations. This can lead to unauthorized actions such as reading all documents in an index, deleting documents, or exfiltrating specific fields without requiring credentials. **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. As a temporary mitigation, strip the `SEARCH QUERY`, `OPERATION`, `INDEX NAME`, `INDEX SETTINGS`, and `ID` headers from untrusted inbound messages before they reach the producer. Apply a custom `HeaderFilterStrategy` that blocks the aforementioned header names.

**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 AWS2-SQS component allows an attacker to inject arbitrary Camel control headers into the Camel Exchange. This occurs because the `Sqs2HeaderFilterStrategy` failed to configure an inbound filter, allowing `Sqs2Consumer` to copy SQS MessageAttributes—including internal headers like `CamelHttpUri`, `CamelFileName`, or `CamelSqlQuery`—unmodified via the `applyFilterToExternalHeaders()` function. An entity with permissions to send messages to the consumed SQS queue can use this to influence the behavior of downstream producers, such as redirecting HTTP producers or overriding queries. These injected headers persist across internal direct, seda, and vm hops. **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 Camel control headers from inbound messages at the start of the route using `removeHeaders('Camel*')` and `removeHeaders('camel*')` before they reach downstream producers. Restrict access to the consumed SQS queue by applying least-privilege `sqs:SendMessage` permissions on the queue resource policy.

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

**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 Cometd component allows unauthenticated users to inject arbitrary Camel control headers. The `CometdBinding.populateExchangeFromMessage()` function copies the `ext.CamelHeaders` map from the CometD client directly into the Camel message without using a HeaderFilterStrategy. Since no Bayeux SecurityPolicy is installed by default, any client completing the Bayeux handshake can publish messages that modify internal control headers such as `CamelHttpUri`, `CamelFileName`, or `CamelJmsDestinationName`. This can lead to the redirection of HTTP producers, modification of file names, or overriding of JMS destinations, with the injected headers persisting across internal direct, seda, and vm hops. **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 CometD messages using `removeHeaders('Camel*')` and `removeHeaders('camel*')` at the start of the route. Install an explicit Bayeux SecurityPolicy on the CometdComponent to ensure only authenticated clients can publish messages.

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.14.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 where the default ObjectInputFilter pattern used for deserialization filtering in several components allows classes that perform network I/O, such as `java.net.URL` and `java.net.InetAddress`. An attacker can send a Java-serialized payload containing a `HashMap` with `java.net.URL` keys to an affected consumer. This triggers the JVM to issue DNS queries to an attacker-controlled host during deserialization, creating an out-of-band side channel. The risk is most significant in the `camel-jms` family because the `extractBodyFromJms()` function in `JmsBinding` unconditionally invokes `getObject()` when the `mapJmsMessage` variable is set to true. Affected components include `camel-jms`, `camel-sjms`, `camel-amqp`, `camel-mina`, `camel-netty`, `camel-netty-http`, `camel-vertx-http`, `camel-infinispan`, and aggregation repository components `camel-leveldb`, `camel-cassandraql`, `camel-consul`, and `camel-sql`. **Recommendations** Update Apache Camel versions 4.14.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. Configure a JMS-provider-side allow-list using `deserializationAllowList` or `deserializationDenyList` in Apache ActiveMQ Artemis, or `org.apache.activemq.SERIALIZABLE PACKAGES` in Apache ActiveMQ Classic. Override the default filter via the `deserializationFilter` option at the endpoint level or the `-Djdk.serialFilter` JVM system property using the pattern `!java.net.**;java.**;javax.**;org.apache.camel.**;!*` (or `!java.net.**;java.**;org.apache.camel.**;!*` for aggregation-repository components).

**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 `camel-nats` component allows a client to inject arbitrary Camel control headers into the Camel Exchange. This occurs because the `NatsConsumer` uses a `DefaultHeaderFilterStrategy` without configured inbound rules, causing it to copy all NATS message headers unmodified. An attacker publishing to a consumed NATS subject can inject headers such as `CamelHttpUri`, `CamelFileName`, or `CamelSqlQuery` to influence downstream producers, potentially redirecting HTTP requests, altering file names, or overriding queries. These injected headers persist across internal `direct`, `seda`, and `vm` hops. The issue is accessible without credentials if the NATS server is configured without authentication. **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. As a temporary mitigation, strip Camel control headers from inbound NATS messages at the start of the route using `removeHeaders('Camel*')` and `removeHeaders('camel*')`. Enable authentication on the NATS server to ensure only trusted clients can publish to the consumed subject.

**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.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 issue exists in the Apache Camel IRC component due to improper input validation and neutralization of special elements. The `camel-irc` producer determines the destination of outgoing IRC messages using the `irc.sendTo` Exchange header. Because this header and other control headers—including `irc.target`, `irc.messageType`, `irc.user.*`, `irc.num`, and `irc.value`—do not use the required Camel prefix, they bypass the `HttpHeaderFilterStrategy` when passing through an HTTP boundary. In routes bridging an HTTP consumer to an `irc:` producer, an unauthenticated HTTP client can manipulate the `irc.sendTo` header to redirect messages to an arbitrary IRC channel or user. This can lead to the exfiltration of message content to an attacker-controlled nickname, leakage into public channels, or the delivery of messages that falsely appear to originate from the bot. **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 IRC headers to use `CamelIrc*` names (e.g., `CamelIrcSendTo`) instead of `irc.*` values. As a temporary mitigation, strip `irc.*` headers from untrusted ingress before they reach the `irc:` producer by using `removeHeaders('irc.*')` at the start of the route and ensure the IRC destination is set 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** An injection issue exists in the Apache Camel Kafka component due to improper input validation and incorrect neutralization of special elements. The `camel-kafka` producer allows the configured target topic to be overridden at runtime via the `kafka.OVERRIDE TOPIC` Exchange header because the `KafkaProducer.evaluateTopic()` function prioritizes the header value over the endpoint configuration. While the `KafkaHeaderFilterStrategy` filters the `kafka.*` namespace during Kafka-to-Exchange serialization, it does not apply to headers arriving from upstream consumers in multi-component routes. For instance, an HTTP consumer using `HttpHeaderFilterStrategy` only blocks the `Camel` or `camel` namespace, allowing `kafka.*` headers to pass through. Consequently, an unauthenticated HTTP client could use the `kafka.OVERRIDE TOPIC` header to redirect messages to arbitrary internal topics or inject crafted messages into critical downstream services. Similarly, the `kafka.OVERRIDE TIMESTAMP` and `kafka.PARTITION KEY` variables can be injected to backdate messages or target specific partitions. **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. After updating, replace raw `kafka.*` header names with `CamelKafka*` names, such as `CamelKafkaOverrideTopic` and `CamelKafkaTopic`. As a temporary mitigation, remove `kafka.*` headers from untrusted ingress using `removeHeaders('kafka.*')` at the start of the route and ensure the target topic is set from a trusted source.

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.8.0 through 4.18.2 Apache Camel versions 4.19.0 through 4.20.0 **Description** Improper Input Validation issue in Apache Camel. The problem occurs within the `langchain4j-tools` component, where tool argument headers are not properly filtered against declared parameters. **Recommendations** Upgrade Apache Camel versions 4.8.0 through 4.18.2 to version 4.18.3. Upgrade Apache Camel versions 4.19.0 through 4.20.0 to version 4.21.0.

**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 and improper access control in the Camel Mongodb Gridfs component allow unauthenticated HTTP clients to hijack GridFS operations. The `camel-mongodb-gridfs` producer uses the `gridfs.operation` Exchange header to determine the operation when no explicit operation parameter is set. Because the control headers `gridfs.operation`, `gridfs.objectid`, `gridfs.metadata`, `gridfs.chunksize`, and `gridfs.fileid` do not use the Camel prefix, they bypass the `HttpHeaderFilterStrategy` and are passed directly from inbound HTTP requests into the Exchange. An attacker can use this to override intended operations—such as changing a file upload to a remove, listAll, or findOne operation—and provide a `gridfs.metadata` value to perform NoSQL operator injection, which is a technique used to manipulate database queries by injecting NoSQL syntax. This can lead to arbitrary file deletion or reading of files. **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 `gridfs.*` header names with `CamelGridFsOperation`, `CamelGridFsObjectId`, `CamelGridFsMetadata`, `CamelGridFsChunkSize`, or `CamelGridFsFileId` in routes driving GridFS operations. As a temporary mitigation, set an explicit operation on the `mongodb-gridfs:` endpoint and strip all `gridfs.*` headers from untrusted ingress before they reach the producer.