CVE-2026-59230
Apache Camel: Camel-Mail: el formato de datos MimeMultipart copiaba las cabeceras MIME al mensaje Camel sin una estrategia de filtrado de cabeceras al deserializar con headersInline habilitado
- Publicado
- 24 ago 2026
- Actualizado
- 25 ago 2026
- Asignación de CNA
- apache
- Evidencia observada
- 24 ago 2026
CVSS primario
nvd · CVSS 3.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:NBajo · próximos 30 días
- Percentil
- 35,8 %
- Fecha del modelo
- 21 sept 2026
EPSS es una estimación estadística, no una certeza o una medida de impacto. Combínelo con CVSS, estado KEV, exposición y su entorno.
Resumen
Vulnerabilidad de validación de entrada incorrecta en Apache Camel. Este problema afecta a Apache Camel: desde 2.17.0 hasta antes de 4.14.9, desde 4.15.0 hasta antes de 4.18.4, desde 4.19.0 hasta antes de 4.22.0. El componente camel-mail incluye un formato de datos MimeMultipart que puede deserializar (unmarshal) un mensaje multipart MIME. Cuando se configura con headersInline establecido a true, la ruta de unmarshal copia las cabeceras MIME del mensaje entrante al mensaje Camel: enumera cada cabecera que no sea una de las tres estándar que genera por sí mismo —Message-ID, MIME-Version y Content-Type— y llama a setHeader para cada una, sin aplicar ninguna HeaderFilterStrategy. Los nombres de esas cabeceras MIME provienen del mensaje que se está deserializando, por lo que un remitente capaz de influir en el mensaje podría colocar una cabecera cuyo nombre caiga en el espacio de nombres interno de Camel y lograr que se establezca en el Exchange. Los componentes de Camel leen cabeceras de control de ese espacio de nombres para sobrescribir su comportamiento configurado —el productor camel-sql, por ejemplo, toma la sentencia a ejecutar de una cabecera Camel cuando está presente—, por lo que una cabecera inyectada podría redirigir lo que un paso posterior de la ruta hace con datos que el autor de la ruta nunca tuvo la intención de que tomara del mensaje. Qué sinks son alcanzables y cuáles son las consecuencias depende por completo de lo que la ruta haga después del paso de unmarshal. El consumidor camel-mail ya aplicaba una estrategia de filtrado de cabeceras en su propia ruta de entrada, por lo que esta era la ruta de entrada paralela al mismo componente que el endurecimiento anterior no cubría. La copia afectada solo se alcanza cuando headersInline está habilitado, que no es el valor predeterminado: con la configuración predeterminada, las cabeceras MIME se muestran como adjuntos en lugar de como cabeceras de mensaje y no se ven afectadas. El comportamiento se remonta a la introducción del formato de datos en 2.17.0 y estaba presente en todas las líneas de versiones hasta esta corrección. Se recomienda a los usuarios actualizar a la versión 4.22.0, que corrige el problema. Si los usuarios están en la línea de versiones LTS 4.14.x, se les sugiere actualizar a 4.14.9. Si los usuarios están en la línea de versiones 4.18.x, se les sugiere actualizar a 4.18.4. Para los despliegues que no puedan actualizar de inmediato, dejen headersInline en su valor predeterminado de false cuando no se necesiten las cabeceras en línea, ya que la copia solo se alcanza cuando está habilitado. Cuando deba permanecer habilitado, elimine las cabeceras internas de Camel inmediatamente después del paso de unmarshal, por ejemplo con removeHeaders("Camel*") colocado antes de cualquier procesador o productor que lea cabeceras de control, y no deserialice contenido MIME de un remitente no confiable en una ruta que despache según valores de cabeceras. Como defensa en profundidad, trate los nombres de las cabeceras de cualquier mensaje MIME que llegue desde fuera del límite de confianza como entrada no confiable.
Uso responsable
Utilice información sobre vulnerabilidades solo en sistemas de su propiedad o que esté autorizado a probar. Kitploit enlaza con metadatos de investigación pública y no almacena código de explotación ni cargas útiles maliciosas.