Empresa
¿Quiénes somos? Visión y Valores
Herramientas
Email Checker Vigía DNS SSL Checker Password Strength HTTP Headers Password Generator VPN PSK Generator
Alertas
Todas las alertas Vulnerabilidades Incidentes Solo críticas En CISA KEV Vigía LATAM
Editorial
Análisis técnico ¿Cuál es mi IP?
Blog
Blog 2MCI Noticias ISO 27001 Amenazas LATAM Recursos Gratuitos eBook Gratuito Newsletter Podcast / YouTube
Empresa
Servicios Contacto Suscribirse al Newsletter
Nuevo en 2MCI
Crear cuenta gratis Ver herramientas sin registro
Ya tengo cuenta
Iniciar sesión
Equipo
Portal interno 2MCI
Alto CVE-2026-78164 Multiple Vendors

Vulnerabilidad alta en Apache Camel: inyección en motor de templates e exposición de información sensible

Vulnerabilidad · Publicado 19/10/2026

8.2
CVSS 3.x
04 Medio7 Alto9 Crítico10
Severidad: Alto
Resumen ejecutivo

Apache Camel (versiones 4.0.0-4.18.4 y 4.19.0-4.22.0) presenta una falla que permite neutralizar elementos especiales en motores de templates, exponiendo datos sensibles. Afecta componentes HTTP en Netty, Undertow y Vert.x. Empresas en LATAM que usan Camel en pipelines de integración de APIs, microservicios o procesamiento de pagos requieren actualizar inmediatamente para evitar acceso no autorizado a credenciales, tokens y datos PII.

Análisis asistido por IA, contexto LATAM revisado por el equipo 2MCI.

Descripción técnica

Descripción técnica

Improper Neutralization of Special Elements Used in a Template Engine and Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Camel HTTP, Netty HTTP, Undertow and Vert.x HTTP components. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. The Camel HTTP producer families let an inbound message override the endpoint URI through the CamelHttpUri and CamelRestHttpUri headers, and then passed that message-supplied string through CamelContext.resolvePropertyPlaceholders() before using it. Property-placeholder resolution is a configuration-resolution facility, not a URI-parsing step: it reaches operating-system environment variables, JVM system properties, every PropertiesFunction registered on the classpath - including the AWS, Azure, GCP, HashiCorp, IBM, CyberArk and Kubernetes secret functions - and, through camel-bean, the invocation of a no-argument method on any bean in the registry. Applying it to Exchange content therefore turned a URI string into a configuration- and bean-evaluation context. A route author opted into none of this: a plain static to("http://backend/api") was sufficient. Seven call sites were affected: HttpHelper.createURL and HttpHelper.createMethod in camel-http-common, HttpMethodHelper.createMethod in camel-http, VertxHttpHelper.resolveHttpURI in camel-vertx-http, UndertowHelper.createURL and UndertowHelper.createMethod in camel-undertow, and NettyHttpHelper.createURL in camel-netty-http. The bridgeEndpoint option did not bound the exposure: it suppresses the CamelHttpUri override in the createURL family but not in the createMethod family, so a route using the documented bridging configuration still resolved placeholders taken from the header, and CamelRestHttpUri was consumed before any bridgeEndpoint check in all four components. Only camel-http offered an opt-out, skipControlHeaders, which defaults to false. Reaching the headers did not always require header injection, because several Camel HTTP consumers populate CamelHttpUri from the request line themselves as a documented reverse-proxy feature. An unresolvable placeholder additionally produced a RuntimeExchangeException whose message echoed the URI, which distinguishes a set from an unset configuration key even where no outbound request is made. The behaviour predates the 4.x line; it dates back to the camel-http4 and camel-netty4 components. This advisory continues the alignment CAMEL-24282 applied to the toD and enrich dynamic-URI EIPs in 4.22.0, extending the same build-time-resolution contract to the HTTP producer components. Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.1. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.14.x releases stream and earlier reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release. For deployments that cannot upgrade immediately, strip the override headers at the trust boundary before the producer with removeHeader("CamelHttpUri") and removeHeader("CamelRestHttpUri"), or set skipControlHeaders=true on camel-http endpoints, which is the only component offering that option. Note that bridgeEndpoint=true is not a workaround: it suppresses the header override when the outbound URL is built but not when the header is re-parsed for the query string. Percent-encoding the placeholder delimiters is likewise not a mitigation for camel-netty-http, whose binding decodes the request path before the value reaches the header, so proxy or WAF rules written against the raw delimiters do not help there. As defence in depth, ensure consumers exposed to untrusted senders apply a strict inbound HeaderFilterStrategy over the Camel namespace, and resolve secrets through a vault rather than through environment variables or system properties that a placeholder can name.

Puntuación CVSS

Score: 8.2/10 — Severidad: HIGH — Estado NIST: Received

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N

Debilidades (CWE)

CWE-200, CWE-1336

Fuente oficial

Publicado en NIST NVD.

¿Qué hacer?
  • Actualizar Apache Camel a 4.18.5 o 4.22.1+ inmediatamente
  • Auditar logs para acceso a URIs de endpoints entre enero 2024-presente
  • Revocar credenciales expuestas en configuraciones de templates
  • Implementar WAF y validación de entrada en proxies HTTP
  • Validar CVSS 8.2 en NVD NIST y verificar estado de parches con Apache
Esta alerta fue generada automáticamente a partir del NVD del NIST.