Vulnerabilidades

*** Pendiente de traducción *** The software accepts user-supplied input via a URL parameter without adequate output encoding before reflecting it back to the user&amp;#39;s browser. This condition allows an attacker to inject malicious script content into pages served by the application.<br /> <br /> By leveraging this weakness, an attacker can cause the user&amp;#39;s browser to redirect to a malicious website, modify the UI of the webpage, or retrieve information from the browser. However, the impact is mitigated by the use of httpOnly flags on session-related cookies, preventing session hijacking.

Vulnerabilidad relacionada con la generación de mensajes de error que contienen información confidencial en el componente Apache Camel Undertow. El consumidor del servidor HTTP camel-undertow 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. El valor predeterminado de esta opción es false, mientras que en los demás componentes del servidor HTTP de Camel (camel-http, camel-jetty, camel-servlet y camel-platform-http) el valor predeterminado es 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, en lugar de devolver un cuerpo vacío. Por lo tanto, 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— recibe 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 clases, y la estructura interna de la aplicación, que un atacante puede utilizar para planear nuevos ataques. Además, para los usuarios de Rest DSL, la opción `muteException` no se respetaba en absoluto: el `RestUndertowHttpBinding` se creaba con un valor false codificado de forma fija, por lo que se devolvía el seguimiento de la pila incluso cuando se había configurado `muteException=true`. 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 la rama de versiones LTS 4.14.x, se les recomienda actualizar a la versión 4.14.8. Si utilizan la rama de versiones 4.18.x, se les recomienda actualizar a la versión 4.18.3. En el caso de implementaciones que no puedan actualizarse de inmediato, se debe establecer explícitamente muteException=true en el consumidor camel-undertow (por ejemplo, undertow: http://0.0.0.0:8080/api?muteException=true, o de forma global mediante la propiedad camel.component.undertow.mute-exception=true), de modo que los errores de procesamiento ya no devuelvan el seguimiento de la pila al cliente; ten en cuenta que, en las versiones afectadas, esta solución provisional no se aplica a los consumidores de Rest DSL, cuyo enlace ignora la opción hasta que se aplique la corrección.

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 Iggy. El consumidor «camel-iggy» asignaba los encabezados de usuario de los mensajes entrantes de Iggy al mapa de encabezados de Camel Exchange sin aplicar ninguna estrategia de filtrado de encabezados (HeaderFilterStrategy); IggyFetchRecords copiaba los encabezados de usuario del mensaje directamente en el Exchange. Dado que nada bloqueaba el espacio de nombres de encabezados de Camel, un actor capaz de publicar en el flujo o tema de Iggy consumido podía establecer encabezados de control internos de Camel —incluido CamelHttpUri (Exchange.HTTP_URI)— simplemente proporcionándolos como encabezados de usuario del mensaje. En una ruta en la que el consumidor de Iggy 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. Este problema afecta a Apache Camel: desde la versión 4.17.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 se encuentran en la rama de versiones 4.18.x, se les sugiere que actualicen a la 4.18.3. La corrección añade una IggyHeaderFilterStrategy específica (y una opción de punto final headerFilterStrategy) que filtra 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 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), restrinja quién puede publicar en el flujo o tema de Iggy consumido y evite conectar a un consumidor no fiable directamente a un productor HTTP cuyo URI de destino pueda determinarse a partir de los encabezados del mensaje.

Vulnerabilidad por validación incorrecta de entradas en el componente AWS SNS de Apache Camel. El componente «camel-aws2-sns» filtra los encabezados de Camel mediante una estrategia de filtrado de encabezados específica del componente, «Sns2HeaderFilterStrategy». Al igual que su homólogo Sqs2HeaderFilterStrategy, originalmente solo configuraba un filtro de salida (setOutFilterPattern, que impide que se escriban los encabezados Camel*, breadcrumbId y org.apache.camel.*) y no configuraba ninguna regla de filtro de entrada. En el caso del componente relacionado camel-aws2-sqs, esta laguna en el filtrado de entrada era explotable, ya que Sqs2Consumer mapea los atributos de los mensajes SQS entrantes al Camel Exchange mediante HeaderFilterStrategy.applyFilterToExternalHeaders, lo que permite al remitente de un mensaje inyectar encabezados de control de Camel (registrado como CVE-2026-46456). camel-aws2-sns, por el contrario, es exclusivamente de productor: Sns2Endpoint no admite consumidores (createConsumer lanza una excepción UnsupportedOperationException, «No se pueden recibir mensajes desde este punto final»), por lo que ningún atributo de mensaje proporcionado externamente se asigna nunca en la entrada a un Camel Exchange a través de SNS, y, por lo tanto, la regla de filtro de entrada que faltaba en Sns2HeaderFilterStrategy no era accesible para un atacante. Como parte de la misma corrección (CAMEL-23506), se ha añadido una regla de filtro de entrada (setInFilterStartsWith para el espacio de nombres Camel) a Sns2HeaderFilterStrategy, de modo que su configuración coincida con la de Sqs2HeaderFilterStrategy, ya corregida, y con la de las demás estrategias equivalentes. Se trata de una medida de defensa en profundidad sin ninguna vía de explotación conocida en camel-aws2-sns. 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 trata de un cambio de refuerzo de la defensa en profundidad sin vías de explotación conocidas en camel-aws2-sns, que es de solo productor, por lo que no se requiere ninguna acción urgente ni solución alternativa. Los usuarios que deseen que el comportamiento se ajuste a lo previsto pueden actualizar a la versión 4.21.0, o a la 4.14.8 en la rama de versiones LTS 4.14.x, o a la 4.18.3 en la rama de versiones 4.18.x, que incluyen el cambio. Como buena práctica general, los operadores deben seguir aplicando permisos IAM de «privilegio mínimo» a sus temas de SNS.

Se ha detectado una vulnerabilidad en Red Hat Advanced Cluster Security para Kubernetes (RHACS). Central no limita la profundidad de las consultas GraphQL que se sirven en la API GraphQL autenticada. Un usuario autenticado con un token de API válido puede enviar consultas profundamente anidadas que provocan un consumo excesivo de recursos en Central, lo que da lugar a una denegación de servicio en el plano de gestión.

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

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

*** Pendiente de traducción *** Improper Input Validation, Authorization Bypass Through User-Controlled Key vulnerability in Apache Camel JIRA component.<br /> <br /> The camel-jira producers read their operation parameters - the issue key, project key, transition id, summary, type, assignee, components, watchers, link type, work-log minutes and others - from Exchange message headers. The header constants defined in JiraConstants (for example ISSUE_KEY = IssueKey, ISSUE_PROJECT_KEY = ProjectKey, ISSUE_TRANSITION_ID = IssueTransitionId, LINK_TYPE = linkType) 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 a jira: producer, any HTTP client could therefore supply these headers and override the values the route intended, driving JIRA operations against the configured JIRA instance with the endpoint&amp;#39;s configured service-account credentials - for example deleting or transitioning an arbitrary issue (via IssueKey / IssueTransitionId), creating an issue in a different project (via ProjectKey), modifying issue fields, adding or removing watchers, or logging work. The operations are bounded by what the configured service account is permitted to do. No credentials are required from the attacker 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 JIRA operations via the raw header names must use the CamelJira* names (for example CamelJiraIssueKey) instead of the old values. For deployments that cannot upgrade immediately, strip the camel-jira control headers from any untrusted ingress before the jira: producer (for example removing the IssueKey, ProjectKey, IssueTransitionId and related headers at the start of the route), and set the required JIRA operation parameters from a trusted source.

*** Pendiente de traducción *** Improper Input Validation, Unintended Proxy or Intermediary (&amp;#39;Confused Deputy&amp;#39;) vulnerability in Apache Camel DAPR component.<br /> <br /> The camel-dapr Dapr Pub/Sub consumer (DaprPubSubConsumer) copied two fields from each inbound CloudEvent - its Pub/Sub component name and its topic - into the CamelDaprPubSubName and CamelDaprTopic Exchange headers. These two headers are producer-direction routing headers: when the route republishes through a Dapr producer, DaprConfigurationOptionsProxy reads them back and prefers them over the destination configured on the endpoint. As a result, in a route that consumes from one Dapr Pub/Sub topic and republishes to another (for example from(&amp;#39;dapr-pubsub:p:t&amp;#39;).to(&amp;#39;dapr-pubsub:p:other&amp;#39;)), an actor able to publish a message to the subscribed topic could set the CloudEvent&amp;#39;s pub/sub-name and topic to values of their choosing and cause the re-published message to be delivered to an arbitrary Dapr Pub/Sub component and topic instead of the configured destination - redirecting or exfiltrating the message and bypassing the route&amp;#39;s intended routing and any topic-level access controls in the underlying broker. Exploitation requires the ability to publish to the topic the route subscribes to; no other authentication or user interaction is needed.<br /> This issue affects Apache Camel: from 4.12.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, remove the CamelDaprPubSubName and CamelDaprTopic headers from the Exchange between the Dapr consumer and any Dapr producer in the route (for example removeHeaders(&amp;#39;CamelDaprPubSubName&amp;#39;, &amp;#39;CamelDaprTopic&amp;#39;)), and restrict who can publish to the subscribed Dapr Pub/Sub topic so that only trusted producers can send to it.

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.

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.