Vulnerabilidades

*** Pendiente de traducción *** Improper Input Validation, Improper Neutralization of Special Elements in Output Used by a Downstream Component (&amp;#39;Injection&amp;#39;) vulnerability in Apache Camel IRC component.<br /> <br /> The camel-irc producer chooses the destination of an outgoing IRC message from the irc.sendTo Exchange header (the constant IrcConstants.IRC_SEND_TO, value irc.sendTo); when that header is present it overrides the channel list configured on the endpoint, and the message is sent only to the specified destination. This and the component&amp;#39;s other control headers (irc.target, irc.messageType, irc.user.*, irc.num, irc.value) used plain, non-Camel-prefixed values. Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that bridges an HTTP consumer (for example platform-http) into an irc: producer, any HTTP client could therefore set the irc.sendTo header and redirect a message that the route intended for a configured channel to an arbitrary IRC channel or user - exfiltrating the message content to an attacker-chosen nickname, leaking it into a public channel, or delivering messages that appear to come from the bot. No credentials are required when the bridging consumer is unauthenticated.<br /> This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.<br /> <br /> Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, routes that set IRC headers via the raw header names must use the CamelIrc* names (for example CamelIrcSendTo) instead of the old irc.* values. For deployments that cannot upgrade immediately, strip the irc.* headers from any untrusted ingress before the irc: producer (for example removeHeaders(&amp;#39;irc.*&amp;#39;) at the start of the route), and set the IRC destination from a trusted source.

Vulnerabilidad por validación inadecuada de entradas y neutralización incorrecta de elementos especiales en la salida utilizada por un componente posterior (inyección) en el componente Apache Camel Kafka. El productor camel-kafka puede anular el tema de destino configurado en tiempo de ejecución a través del encabezado kafka.OVERRIDE_TOPIC de Exchange: KafkaProducer.evaluateTopic() devuelve el valor del encabezado en lugar del tema configurado en el punto final. Las constantes de los encabezados de control en KafkaConstants (por ejemplo, OVERRIDE_TOPIC = kafka.OVERRIDE_TOPIC, OVERRIDE_TIMESTAMP = kafka.OVERRIDE_TIMESTAMP, PARTITION_KEY = kafka. PARTITION_KEY) utilizan valores simples, sin prefijo Camel. La propia estrategia KafkaHeaderFilterStrategy de camel-kafka filtra el espacio de nombres kafka.*, pero solo en el límite de serialización de Kafka a Exchange (al leer los encabezados de los registros de Kafka en Exchange y al escribir los encabezados de Exchange en un registro de Kafka); no se aplica a los encabezados que llegan desde un consumidor anterior en una ruta de múltiples componentes. El consumidor HTTP anterior utiliza HttpHeaderFilterStrategy, que solo bloquea el espacio de nombres Camel / camel, por lo que un encabezado kafka.* pasa sin ser filtrado. Como resultado, en una ruta que conecta un consumidor HTTP (por ejemplo, platform-http) con un productor kafka:, cualquier cliente HTTP podría establecer el encabezado kafka.OVERRIDE_TOPIC y provocar que el mensaje se publique en un tema de Kafka arbitrario en lugar del configurado, redirigiéndolo a un tema interno sensible o inyectando mensajes creados por un atacante en un tema consumido por un servicio crítico posterior. Los encabezados relacionados kafka.OVERRIDE_TIMESTAMP y kafka.PARTITION_KEY también podrían inyectarse para antedatar mensajes o dirigirlos a particiones específicas. No se requieren credenciales cuando el consumidor puente no está autenticado. Este problema afecta a Apache Camel: desde la versión 4.0.0 hasta la 4.14.8, desde la 4.15.0 hasta la 4.18.3 y desde la 4.19.0 hasta la 4.21.0. Se recomienda a los usuarios que actualicen a la versión 4.21.0, que corrige el problema. Si los usuarios utilizan las versiones LTS de la rama 4.14.x, se les sugiere que actualicen a la 4.14.8. Si los usuarios utilizan las versiones de la rama 4.18.x, se les sugiere que actualicen a la 4.18.3. Tras la actualización, las rutas que establezcan o lean encabezados de Kafka mediante los nombres de encabezado sin formato deben utilizar los nombres CamelKafka* (por ejemplo, CamelKafkaOverrideTopic y CamelKafkaTopic) en lugar de los antiguos valores kafka.*. En el caso de las implementaciones que no puedan actualizarse de inmediato, elimine los encabezados «kafka.*» de cualquier entrada no fiable antes del productor kafka: (por ejemplo, removeHeaders(“kafka.*”) al inicio de la ruta) y establezca el tema de destino a partir de una fuente fiable.

Neutralización incorrecta de elementos especiales en la salida utilizada por un componente posterior (inyección), vulnerabilidad que permite eludir la autorización mediante una clave controlada por el usuario en el componente Apache Camel para Salesforce. El productor camel-salesforce resuelve sus parámetros de funcionamiento —la consulta SOQL, la búsqueda SOSL, el nombre y el identificador del SObject de destino, la URL y el método REST de Apex, y los parámetros de consulta de Apex— a partir de los encabezados de los mensajes de Exchange, dando prioridad a la lectura del encabezado frente al valor configurado en el punto final (AbstractSalesforceProcessor.getParameter() lee primero el encabezado y utiliza la configuración del punto final solo como alternativa). Las constantes de los encabezados de control en SalesforceEndpointConfig (por ejemplo, SOBJECT_QUERY = sObjectQuery, SOBJECT_SEARCH = sObjectSearch, SOBJECT_NAME = sObjectName, SOBJECT_ID = sObjectId, APEX_URL = apexUrl, APEX_METHOD = apexMethod y el prefijo apexQueryParam. prefijo) utilizaban valores simples, sin prefijo Camel. Dado que estos nombres no comienzan con el prefijo Camel / camel, HttpHeaderFilterStrategy —que bloquea únicamente el espacio de nombres de encabezados Camel en el límite HTTP— permitía que pasaran directamente desde una solicitud HTTP entrante al Exchange. En una ruta que conecta a un consumidor HTTP (por ejemplo, platform-http) con un salesforce: cualquier cliente HTTP podría, por lo tanto, establecer estos encabezados y anular lo que la ruta pretendía: proporcionar su propia consulta SOQL o búsqueda SOSL para leer datos de cualquier SObject al que pueda acceder el usuario de Salesforce conectado, anular el nombre y el ID del SObject de destino para operaciones CRUD, o redirigir una llamada REST de Apex a un punto final y un método HTTP diferentes (incluidos métodos destructivos) con parámetros de consulta inyectados. Todas estas operaciones se ejecutan con todos los permisos del usuario conectado a Salesforce (de integración), que suelen ser amplios. El atacante no necesita credenciales cuando el consumidor puente no está autenticado. Este problema afecta a Apache Camel: desde la versión 4.0.0 hasta la 4.14.8, desde la 4.15.0 hasta la 4.18.3 y desde la 4.19.0 hasta la 4.21.0. Se recomienda a los usuarios que actualicen a la versión 4.21.0, que corrige el problema. Si los usuarios utilizan las versiones LTS de la rama 4.14.x, se les sugiere que actualicen a la 4.14.8. Si los usuarios utilizan las versiones de la rama 4.18.x, se les sugiere que actualicen a la 4.18.3. Tras la actualización, las rutas que configuren los parámetros de operación de Salesforce mediante los nombres de encabezado sin formato deben utilizar los nombres CamelSalesforce* (por ejemplo, CamelSalesforceSObjectQuery y CamelSalesforceApexUrl) en lugar de los antiguos valores sObject* / apex*; la ortografía de las opciones de punto final no ha cambiado. En el caso de las implementaciones que no puedan actualizarse de inmediato, elimine los encabezados de control de Salesforce de cualquier entrada no fiable antes del productor salesforce: (por ejemplo, removeHeaders(“sObject*”) y removeHeaders(“apex*”) al inicio de la ruta) y configure los parámetros de consulta, SObject y Apex a partir de una fuente fiable.

Vulnerabilidad relacionada con la generación de mensajes de error que contienen información confidencial en el componente HTTP Netty de Apache Camel. El consumidor del servidor HTTP camel-netty-http expone una opción denominada muteException que controla lo que se devuelve al cliente cuando se produce un error en el procesamiento de una ruta. Esta opción tenía como valor predeterminado false porque el campo subyacente era un valor booleano primitivo no inicializado (el valor predeterminado de Java es false), mientras que los demás componentes del servidor HTTP de Camel (camel-http, camel-jetty, camel-servlet y camel-platform-http) lo establecen por defecto en true. Con muteException=false, cuando una solicitud provoca una excepción durante el procesamiento de la ruta, el consumidor escribe el seguimiento completo de la pila de Throwable en el cuerpo de la respuesta HTTP como text/plain (a través de DefaultNettyHttpBinding), en lugar de devolver un cuerpo vacío. Cualquier cliente no autenticado que pueda acceder al punto final y provocar un error de procesamiento —por ejemplo, enviando un cuerpo de solicitud mal formado, un parámetro no válido o provocando de cualquier otra forma un fallo interno de la ruta— recibirá, por lo tanto, un seguimiento completo de la pila de Java. Dicha traza de pila puede revelar información interna confidencial, incluidas credenciales incrustadas en los mensajes de excepción, nombres de host internos y direcciones IP, rutas del sistema de archivos, detalles de dependencias y versiones, nombres de bases de datos y de clases, y la estructura interna de la aplicación, que un atacante puede utilizar para planear nuevos ataques. Este problema afecta a Apache Camel: desde la versión 4.0.0 hasta la 4.14.8, desde la 4.15.0 hasta la 4.18.3 y desde la 4.19.0 hasta la 4.21.0. Se recomienda a los usuarios que actualicen a la versión 4.21.0, que corrige el problema. Si los usuarios utilizan las versiones LTS de la rama 4.14.x, se les sugiere que actualicen a la 4.14.8. Si los usuarios utilizan las versiones de la rama 4.18.x, se les sugiere que actualicen a la 4.18.3. En el caso de las implementaciones que no puedan actualizarse de inmediato, establezca explícitamente `muteException=true` en el consumidor camel-netty-http (por ejemplo, `netty-http: http://0.0.0.0:8080/api?muteException=true`, o de forma global mediante la propiedad `camel.component.netty-http.configuration.mute-exception=true`), de modo que los errores de procesamiento ya no devuelvan el seguimiento de la pila al cliente.

Validación incorrecta de entradas, exposición de información confidencial a un agente no autorizado y vulnerabilidad de falsificación de solicitudes del lado del servidor (SSRF) en Apache Camel, en el componente Atmosphere WebSocket. El consumidor camel-atmosphere-websocket asignaba los parámetros de consulta de WebSocket entrantes al mapa de encabezados de Camel Exchange sin aplicar ninguna HeaderFilterStrategy (WebsocketConsumer.sendEventNotification() recorre el mapa de cadenas de consulta recopilado en WebsocketConsumer.service() y copia cada entrada en el Exchange). Dado que nada bloqueaba el espacio de nombres de encabezados de Camel, un cliente que se conectara al punto final de WebSocket podía establecer encabezados de control internos de Camel —incluido CamelHttpUri (Exchange.HTTP_URI)— simplemente proporcionándolos como parámetros de consulta. En una ruta en la que el consumidor WebSocket alimenta a un productor HTTP posterior, el CamelHttpUri inyectado redirige la solicitud HTTP del lado del servidor a un destino elegido por el atacante (falsificación de solicitudes del lado del servidor; por ejemplo, a un servicio interno o a un punto final de metadatos en la nube). Además, el productor HTTP resuelve los marcadores de posición de propiedades de Camel en la URI resultante (controlada por el atacante), por lo que los marcadores de posición incrustados en el valor inyectado —como una referencia a una variable de entorno, una propiedad de la aplicación o una referencia al almacén de secretos— se resuelven a sus valores reales y se envían al atacante, revelando variables de entorno, propiedades de la aplicación y secretos del almacén. Cuando el punto final de WebSocket está expuesto sin autenticación, un atacante remoto no autenticado puede acceder a él. Este problema afecta a Apache Camel: desde la versión 4.0.0 hasta la 4.14.8, desde la 4.15.0 hasta la 4.18.3 y desde la 4.19.0 hasta la 4.21.0. Se recomienda a los usuarios que actualicen a la versión 4.21.0, que corrige el problema. Si los usuarios utilizan las versiones LTS de la rama 4.14.x, se les sugiere que actualicen a la 4.14.8. Si los usuarios utilizan las versiones de la rama 4.18.x, se les sugiere que actualicen a la 4.18.3. La corrección hace que el consumidor aplique la estrategia HeaderFilterStrategy que ya hereda de la pila HTTP/servlet, filtrando el espacio de nombres de los encabezados de Camel sin distinguir entre mayúsculas y minúsculas en la asignación de entrada, de modo que los encabezados Camel* / camel* proporcionados externamente ya no se copian en el Exchange. En el caso de las implementaciones que no puedan actualizarse de inmediato, elimine los encabezados de control de Camel del mensaje entrante antes de que lleguen a cualquier productor posterior (por ejemplo, utilice removeHeaders(“Camel*”) y removeHeaders(“camel*”) al inicio de la ruta), exija la autenticación en el punto final de WebSocket y evite conectar un consumidor no fiable directamente a un productor HTTP cuyo URI de destino pueda determinarse a partir de los encabezados del mensaje.

*** Pendiente de traducción *** Deserialization of Untrusted Data vulnerability in Apache Camel PQC component.<br /> <br /> The camel-pqc component persists post-quantum key metadata (KeyMetadata) through pluggable KeyLifecycleManager implementations. HashicorpVaultKeyLifecycleManager and AwsSecretsManagerKeyLifecycleManager read that metadata back from the configured secret backend by deserializing a Base64-wrapped value with a raw java.io.ObjectInputStream.readObject() and no ObjectInputFilter or class allow-list; the cast to KeyMetadata happens only after readObject() returns, so any readObject() side effects in a crafted object run before the type check. The same unfiltered legacy-migration read also remained in FileBasedKeyLifecycleManager (for the stored KeyPair and KeyMetadata). A principal who can write to the operator-controlled backend that holds these values - the HashiCorp Vault KV path, or the AWS Secrets Manager secret (requiring a Vault token or secretsmanager:PutSecretValue) - could store a crafted serialized object that is deserialized during normal key-lifecycle operations, potentially leading to code execution in the context of the application that manages the keys. This is an incomplete-remediation follow-on to CVE-2026-40048 (CAMEL-23200), which changed FileBasedKeyLifecycleManager to store metadata as JSON / PKCS#8 / X.509 but did not add an ObjectInputFilter, did not cover the Vault and AWS sibling managers, and left FileBasedKeyLifecycleManager&amp;#39;s own legacy-migration deserialization unfiltered.<br /> This issue affects Apache Camel: from 4.18.0 before 4.18.3, from 4.19.0 before 4.21.0.<br /> <br /> Users are recommended to upgrade to version 4.21.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.3. For deployments that cannot upgrade immediately, restrict write access to the key backend so that only the application&amp;#39;s own identity can write the camel-pqc secrets (least-privilege HashiCorp Vault policies and secretsmanager:PutSecretValue IAM), and keep the PQC key material in a backend separate from any data that less-trusted principals can write.

*** Pendiente de traducción *** Improper Neutralization of Special Elements in Data Query Logic vulnerability in Apache Camel Neo4J component.<br /> <br /> The camel-neo4j producer builds the Cypher WHERE clause for its match/retrieve and delete operations from the CamelNeo4jMatchProperties map. CVE-2025-66169 addressed Cypher injection through the property values by binding them as query parameters ($paramN), but the property names (the JSON keys of that map) were still concatenated into the query string verbatim in Neo4jProducer.retrieveNodes() and deleteNode(). A property name containing Cypher syntax therefore alters the structure of the executed query. Where a route maps untrusted input into the CamelNeo4jMatchProperties map - for example by passing a request body as the match map, or from a consumer that does not filter inbound Camel* headers - an attacker who controls the JSON key names can inject arbitrary Cypher and read, modify or delete any node or relationship in the Neo4j database. The CamelNeo4jMatchProperties header is itself Camel-prefixed and is filtered by the HTTP header-filter strategy, so a plain HTTP client cannot set it directly; the issue is reachable through routes that deliberately or inadvertently carry untrusted data into that header.<br /> This issue affects Apache Camel: from 4.10.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.<br /> <br /> Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. For deployments that cannot upgrade immediately, do not populate the CamelNeo4jMatchProperties map from untrusted input: validate or allow-list the property names (for example against ^[A-Za-z_][A-Za-z0-9_]*$) before the Neo4j producer, and ensure that any consumer feeding such a route filters inbound Camel* / camel* headers so the match header cannot be supplied by an external sender.

*** Pendiente de traducción *** Improper Input Validation, Authorization Bypass Through User-Controlled Key vulnerability in Apache Camel Lucene Component.<br /> <br /> The camel-lucene producer reads the search phrase from an Exchange header (LuceneConstants.HEADER_QUERY) whose value was the plain string QUERY (and RETURN_LUCENE_DOCS for HEADER_RETURN_LUCENE_DOCS). Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that exposes a Lucene query operation behind an HTTP consumer (for example platform-http), any HTTP client could therefore set the QUERY header and have its value executed against the full-text index, overriding the query the route intended to run. Depending on what is indexed, this allows reading documents the request should not have access to (for example a match-all query returns the entire index, or the route&amp;#39;s intended per-user filter can be replaced), and expensive regular-expression queries can consume significant CPU. No credentials are required when the HTTP consumer is unauthenticated.<br /> This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.<br /> <br /> Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, routes that set the query via the raw header name must use CamelLuceneQuery (and CamelLuceneReturnLuceneDocs) instead of QUERY / RETURN_LUCENE_DOCS. For deployments that cannot upgrade immediately, strip the attacker-controllable headers before the Lucene producer and set the query from a trusted source (for example removeHeader(&amp;#39;QUERY&amp;#39;) and removeHeader(&amp;#39;RETURN_LUCENE_DOCS&amp;#39;), then setHeader(&amp;#39;QUERY&amp;#39;, constant(...)) at the start of the route).

*** Pendiente de traducción *** Improper Input Validation, Unintended Proxy or Intermediary (&amp;#39;Confused Deputy&amp;#39;) vulnerability in Apache Camel CXF SOAP component.<br /> <br /> The camel-cxf producer selects which SOAP operation to invoke on the backend service from the operationName (and operationNamespace) Exchange header, whose constant values (CxfConstants.OPERATION_NAME / OPERATION_NAMESPACE) were the plain strings operationName / operationNamespace. Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that bridges an HTTP consumer (for example platform-http) into a cxf: producer, any HTTP client could therefore set the operationName header and have CxfProducer resolve and invoke a different WSDL operation than the route intended - for example replacing a read operation with a destructive one - against the backend SOAP service (a confused-deputy redirection). The constant is defined in the shared camel-cxf-common module, so the same non-prefixed names also applied to camel-cxfrs. No credentials are required when the bridging consumer is unauthenticated.<br /> This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.<br /> <br /> Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, the operation-selection headers are named CamelCxfOperationName / CamelCxfOperationNamespace and are filtered at transport boundaries; see the 4.21 upgrade guide for the cross-transport carrier-header pattern. For deployments that cannot upgrade immediately, do not select the CXF operation from untrusted input: strip the operationName and operationNamespace headers from any untrusted ingress before the cxf: producer and set the operation from a trusted source in the route.

*** Pendiente de traducción *** Improper Input Validation, Exposure of Sensitive Information to an Unauthorized Actor, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel in Vertx Websocket component.<br /> <br /> The camel-vertx-websocket consumer mapped inbound WebSocket query and path parameters into the Camel Exchange header map without applying any HeaderFilterStrategy (VertxWebsocketConsumer.populateExchangeHeaders()). Because nothing blocked the Camel header namespace, a client connecting to the WebSocket endpoint could set Camel-internal control headers - including CamelHttpUri (Exchange.HTTP_URI) - simply by supplying them as query parameters. In a route where the WebSocket consumer feeds a downstream HTTP producer, the injected CamelHttpUri redirects the server-side HTTP request to an attacker-chosen destination (server-side request forgery - for example to an internal service or a cloud metadata endpoint). In addition, the HTTP producer resolves Camel property placeholders on the resulting (attacker-controlled) URI, so placeholders embedded in the injected value - such as an environment-variable reference, an application property, or a vault reference - are resolved to their real values and sent to the attacker, disclosing environment variables, application properties and vault secrets. When the WebSocket endpoint is exposed without authentication, this is reachable by an unauthenticated remote attacker.<br /> This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.<br /> <br /> Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. The fix makes the affected consumers apply a HeaderFilterStrategy that filters the Camel header namespace case-insensitively on inbound mapping, so externally-supplied Camel* / camel* headers are no longer copied into the Exchange. For deployments that cannot upgrade immediately, strip the Camel control headers from the inbound message before they reach any downstream producer (for example removeHeaders(&amp;#39;Camel*&amp;#39;) and removeHeaders(&amp;#39;camel*&amp;#39;) at the start of the route), require authentication on the WebSocket endpoint, and avoid bridging an untrusted consumer directly into an HTTP producer whose target URI can be driven from message headers.

*** Pendiente de traducción *** Improper Neutralization of Special Elements in Output Used by a Downstream Component (&amp;#39;Injection&amp;#39;), Improper Input Validation, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel Solr component.<br /> <br /> The camel-solr producer copies Exchange message headers whose names begin with the SolrParam. prefix into the parameters of the Solr request, and headers whose names begin with the SolrField. prefix into the fields of the indexed Solr document. The prefix constants (SolrConstants.HEADER_PARAM_PREFIX / HEADER_FIELD_PREFIX) were the plain strings SolrParam. / SolrField.. Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that bridges an HTTP consumer (for example platform-http) into a solr: producer, any HTTP client could therefore set SolrParam.* headers to inject arbitrary Solr request parameters - including shards or stream.url, which cause the Solr server to issue server-side requests to an attacker-chosen URL (server-side request forgery, for example to an internal service or a cloud metadata endpoint), or qt to reach administrative request handlers - and set SolrField.* headers to inject arbitrary fields into indexed documents. No credentials are required when the bridging consumer is unauthenticated.<br /> This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.<br /> <br /> Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, routes that set Solr parameters or fields via the raw header prefixes must use CamelSolrParam. / CamelSolrField. instead of SolrParam. / SolrField.. For deployments that cannot upgrade immediately, strip the SolrParam.* and SolrField.* headers from any untrusted ingress before the solr: producer, and set the required Solr parameters and fields from a trusted source in the route.

*** Pendiente de traducción *** Improper Input Validation, Improper Access Control vulnerability in Apache Camel in Camel Mongodb Gridfs component.<br /> <br /> The camel-mongodb-gridfs producer selects the GridFS operation to perform from the gridfs.operation Exchange header when the endpoint&amp;#39;s operation parameter is not set - which is the default. The control-header constants (GridFsConstants.GRIDFS_OPERATION, GRIDFS_OBJECT_ID, GRIDFS_METADATA, GRIDFS_CHUNKSIZE, GRIDFS_FILE_ID_PRODUCED) were the plain strings gridfs.operation, gridfs.objectid, gridfs.metadata, gridfs.chunksize and gridfs.fileid. Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that bridges an HTTP consumer (for example platform-http) into a mongodb-gridfs: producer with no explicit operation, any HTTP client could therefore set the gridfs.operation header to override the route&amp;#39;s intended operation - switching, for example, a file upload to remove (deleting a file identified by the attacker-supplied gridfs.objectid), listAll (enumerating every file in the bucket) or findOne (reading a file) - and supply a gridfs.metadata value that is parsed as a MongoDB document, enabling NoSQL operator injection. No credentials are required when the bridging consumer is unauthenticated.<br /> This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.<br /> <br /> Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, routes that drive GridFS operations or metadata via the raw header names must use CamelGridFsOperation / CamelGridFsObjectId / CamelGridFsMetadata / CamelGridFsChunkSize / CamelGridFsFileId instead of the gridfs.* names. For deployments that cannot upgrade immediately, set an explicit operation on the mongodb-gridfs: endpoint so the operation is not taken from a header, and strip the gridfs.* headers from any untrusted ingress before the producer.