Vulnerabilidades

Vulnerabilidad por autenticación incorrecta, falta de autenticación para funciones críticas y fallo de seguridad (Failing Open) en el componente Keycloak de Apache Camel. La política KeycloakSecurityPolicy de camel-keycloak protege una ruta ejecutando KeycloakSecurityProcessor.beforeProcess(), que realiza tres comprobaciones en secuencia: rechaza una solicitud que no incluya un token de acceso; a continuación, solo si requiredRoles no está vacío, valida los roles; y, solo si requiredPermissions no está vacío, valida los permisos. La verificación criptográfica propiamente dicha del token de acceso de portador (firma, emisor y fecha de caducidad para un JWT local, o estado activo y emisor para la introspección del token) se lleva a cabo exclusivamente dentro de esas comprobaciones de roles y permisos. KeycloakSecurityPolicy establece por defecto requiredRoles y requiredPermissions como vacíos —lo que constituye la configuración básica documentada—, por lo que, en una ruta configurada de ese modo, se omiten las comprobaciones de roles y permisos y, por lo tanto, el token de acceso nunca se verifica. La comprobación de presencia del token sigue rechazando un token ausente, pero se acepta un token no válido: cualquier valor distinto de nulo en el encabezado Authorization: Bearer —incluida una cadena arbitraria o un JWT falsificado y sin firmar— supera la política y la solicitud llega a la ruta protegida, sin que se comprueben la firma, el emisor o la fecha de caducidad, y sin que se envíe ninguna solicitud a Keycloak. El token se lee del encabezado de la solicitud entrante porque allowTokenFromHeader tiene por defecto el valor «true». Dado que la razón habitual para situar una ruta detrás de esta política es que dicha ruta realice tareas del lado del servidor, esta omisión da lugar a un acceso no autenticado a dichas tareas; cuando la ruta protegida reenvía a un productor capaz de ejecutar código, puede dar lugar a la ejecución remota de código sin autenticación. Este defecto es independiente de CVE-2026-23552: ese problema se refería a la reclamación del emisor y se solucionó añadiendo una comprobación dentro de la rutina de verificación, pero en este caso no se llega en absoluto a la rutina de verificación en la configuración por defecto, por lo que el defecto persiste. Este problema afecta a Apache Camel: desde la versión 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 la rama de versiones 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, configure un requiredRoles o requiredPermissions no vacío en cada KeycloakSecurityPolicy para que se ejecute la ruta de verificación del token, establezca allowTokenFromHeader en false cuando no se espere que el token provenga del encabezado de la solicitud, o realice la verificación del token en la capa del marco de trabajo antes de la política.

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.

*** Pendiente de traducción *** Improper Input Validation, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel DNS component.<br /> <br /> The camel-dns producers read DNS operation parameters - the resolver to query, the name or domain to look up, the record type and class, and the search term - from Exchange message headers whose constant values (DnsConstants.DNS_SERVER, DNS_NAME, DNS_DOMAIN, DNS_TYPE, DNS_CLASS, TERM) were the plain strings dns.server, dns.name, dns.domain, dns.type, dns.class and term. 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 dns: producer, any HTTP client could therefore set the dns.server header to make the dig producer build a SimpleResolver pointing at an attacker-controlled DNS server - a server-side request forgery via DNS, through which the attacker observes the queried name and can return poisoned responses - and set the dns.name / dns.domain headers to resolve arbitrary internal hostnames, disclosing whether they exist (internal network reconnaissance). 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 DNS operations via the raw header names must use CamelDnsServer / CamelDnsName / CamelDnsDomain / CamelDnsType / CamelDnsClass / CamelDnsTerm instead of the dns.* / term names. For deployments that cannot upgrade immediately, strip the dns.* and term headers from any untrusted ingress before the dns: producer, and set the DNS server and lookup parameters 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.

*** 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, 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 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 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 *** 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 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 *** A information disclosure when DEBUG loglevel is set in SUSE Rancher AI Agent 1.0 before 1.0.2 could leak API keys or LLM response text with potential sensitive data into logfiles, allowing local attackers to misuse respective gained data or credentials.

*** Pendiente de traducción *** Improper Input Validation, Authorization Bypass Through User-Controlled Key vulnerability in Apache Camel ElasticSearch Rest Client.<br /> <br /> The camel-elasticsearch-rest-client component reads several Exchange headers to control its behaviour - SEARCH_QUERY (an advanced query body), OPERATION (which Elasticsearch operation to run), INDEX_NAME, INDEX_SETTINGS and ID. The string values of these header constants, defined in ElasticSearchRestClientConstant, are plain unprefixed names (&amp;#39;SEARCH_QUERY&amp;#39;, &amp;#39;OPERATION&amp;#39;, &amp;#39;INDEX_NAME&amp;#39;, &amp;#39;INDEX_SETTINGS&amp;#39;, &amp;#39;ID&amp;#39;) rather than the &amp;#39;Camel&amp;#39;-prefixed names used by every other Camel component (for example CamelSqlQuery, CamelMongoDbCriteria, CamelCqlQuery). Camel&amp;#39;s inbound HTTP header filter, HttpHeaderFilterStrategy, blocks only header names that begin with &amp;#39;Camel&amp;#39; or &amp;#39;camel&amp;#39;. Because the Elasticsearch header names do not carry that prefix, they pass through the inbound filter unchanged. When a Camel route exposes an HTTP entry point (for example platform-http) in front of an elasticsearch-rest-client producer, an untrusted HTTP client can set these headers directly on its request and override the query and operation that the route author configured: reading every document in the index (SEARCH_QUERY with a match_all query), deleting documents (OPERATION set to Delete together with ID), or exfiltrating selected fields. No credentials are required and the producer reads the headers unconditionally.<br /> This issue affects Apache Camel: from 4.3.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 renames the camel-elasticsearch-rest-client Exchange header constant string values (ID, SEARCH_QUERY, INDEX_SETTINGS, INDEX_NAME, OPERATION) to carry the Camel prefix (CamelElasticsearchId, CamelElasticsearchSearchQuery, CamelElasticsearchIndexSettings, CamelElasticsearchIndexName, CamelElasticsearchOperation) so that they are blocked by the inbound HttpHeaderFilterStrategy; the Java field names are unchanged. For deployments that cannot upgrade immediately, strip the affected headers from untrusted inbound messages before they reach the producer (for example removeHeader(&amp;#39;SEARCH_QUERY&amp;#39;), removeHeader(&amp;#39;OPERATION&amp;#39;), removeHeader(&amp;#39;INDEX_NAME&amp;#39;), removeHeader(&amp;#39;INDEX_SETTINGS&amp;#39;) and removeHeader(&amp;#39;ID&amp;#39;) in front of the elasticsearch-rest-client endpoint), or apply a custom HeaderFilterStrategy that blocks these names.