CVE-2022-46364 Prueba de concepto, Apache CXF MTOM SSRF en la práctica

CVE-2022-46364 es un problema de falsificación de peticiones del lado del servidor de Apache CXF en el procesamiento de peticiones MTOM. La descripción oficial es precisa: las versiones vulnerables de CXF analizan el archivo href atributo de xop:Incluir en peticiones MTOM de una forma que puede ser abusada para ataques del estilo SSRF contra servicios web que toman al menos un parámetro de cualquier tipo. Apache enumera las ramas afectadas como versiones anteriores a 3.4.10 y 3.5.5, y la incidencia subyacente en Jira vincula el fallo a servicios SOAP y servicios JAX-RS con MTOM activado. (Apache CXF)

La razón por la que la gente vuelve a buscar "CVE-2022-46364-Proof-of-the-concept" a finales de marzo de 2026 no es que la CVE se haya vuelto nueva de repente. Es que han vuelto a aparecer nuevos repositorios públicos PoC en GitHub y han sido recogidos por los feeds de seguimiento de exploits. La página de CVE de Feedly mostraba nuevas referencias PoC de GitHub para este CVE aproximadamente en el último día, incluyendo repositorios llamados cybermaksxx/CVE-2022-46364-Proof-of-the-concept y kasem545/CVE-2022-46364-Poc. Este es exactamente el tipo de evento que devuelve un fallo antiguo al conjunto de trabajo para los equipos rojos, cazadores de recompensas por fallos, vendedores de escáneres y defensores que saben que la circulación pública de PoC a menudo cambia la priorización. (Feedly)

Lo que hace que merezca la pena leer detenidamente esta CVE es que se sitúa en la incómoda intersección entre el cumplimiento de los estándares, el comportamiento del marco, la configuración del producto y la explotabilidad real. Si sólo lees el titular, parece un SSRF genérico de Apache. Si sólo lees el resultado de un escáner, parece otro hallazgo de dependencias basado en versiones. Si sólo lees un repositorio PoC, puede parecer más fácil de lo que es. La historia real es más estrecha y más útil: esta vulnerabilidad depende del manejo de MTOM y XOP, el fallo existe en una ruta específica de resolución de adjuntos, el parche cambió el comportamiento de seguimiento de URL por defecto, y la gravedad que debe asignar en su entorno depende en gran medida de si la ruta de código afectada es realmente alcanzable. (Problemas de Apache)

CVE-2022-46364, la definición oficial y el verdadero desacuerdo

El propio aviso de Apache llama a CVE-2022-46364 una "Vulnerabilidad SSRF de Apache CXF" y la califica como importante. NVD, GitHub Advisory, Open Liberty y varios avisos de proveedores posteriores lo presentan como 9,8 crítico. Tanto el registro CVE como la base de datos de avisos de GitHub repiten la misma descripción básica sobre xop:Incluir href en las peticiones MTOM; Open Liberty lo cataloga como un problema de la 9.8 SSRF que afecta al jaxws-2.2 El boletín WebSphere Liberty de IBM también asigna una puntuación base de 9,8 y vincula el impacto a las instancias de Liberty mediante la función jaxws-2.2 característica. (Apache CXF)

Esa división no es trivial. El lenguaje de Apache indica seriedad sin afirmar que todos los despliegues de CXF están igualmente expuestos. NVD y los productos posteriores exponen el perfil de consecuencias máximas de un fallo de red no autenticado sin interacción del usuario. Ambos puntos de vista pueden ser defendibles al mismo tiempo. Las bases de datos oficiales describen la clase de vulnerabilidad y el modelo de impacto en el peor de los casos. Los operadores de productos, por otro lado, todavía tienen que preguntarse si el MTOM está habilitado, si el punto final del servicio es alcanzable, si la estructura del cuerpo de la solicitud es aceptada por la operación de destino y si la aplicación puede realmente alcanzar los recursos internos, externos o basados en archivos que el atacante desea. Esto es una inferencia de las precondiciones oficiales y de la varianza del producto aguas abajo, no una contradicción de los propios avisos. (Apache CXF)

Un buen ejemplo de ese matiz aparece en el propio tratamiento de Oracle de la misma CVE. El texto detallado de la CPU de Oracle de abril de 2023 y julio de 2023 dice que CVE-2022-46364 "no puede explotarse en el contexto" de Oracle Essbase. Pero el texto de la CPU de Oracle de abril de 2024 dice que la misma CVE es explotable en el componente Oracle Commerce Platform's Endeca Integration, afecta a las versiones 11.3.0 a 11.3.2, y puede permitir a un atacante no autenticado comprometer el producto a través de HTTP. Mismo CVE, diferente contexto de producto, diferente ruta de código alcanzable, diferente consecuencia operativa. Esta es exactamente la razón por la que un artículo serio sobre una PoC tiene que hablar de condiciones previas en lugar de repetir la puntuación CVSS como si fuera toda la historia. (Oracle)

Por qué MTOM y XOP son importantes para una prueba de concepto de CVE-2022-46364

La documentación de MTOM de Apache CXF es explícita sobre para qué sirve MTOM. MTOM es un mecanismo SOAP para enviar datos binarios de forma eficiente, utilizando paquetes XOP para que el contenido binario pueda viajar como adjuntos en lugar de inflar el cuerpo XML. La documentación de CXF explica que MTOM requiere anotar los datos y habilitar el soporte de MTOM en el tiempo de ejecución. También dice que MTOM es no activado por defecto. Este detalle es importante porque un gran número de escritos se detienen en "Apache CXF SSRF" y se saltan la parte en la que la ruta de gestión de adjuntos relevante puede no estar activa en absoluto en un punto final determinado. (Apache CXF)

La norma XOP es aún más importante. La especificación XOP del W3C dice que el valor normalizado de la variable xop:Incluir href debe ser un URI válido en el marco de cid: esquema URI. El propio Jira issue de Apache para CXF-8706 dice que el problema era que, cuando se usaba con servicios SOAP o JAX-RS con MTOM activado, el unmarshaller permitía xop:Incluir etiquetas para llevar href atributos que permitían cualquier protocolo, mientras que según la especificación MTOM del W3C sólo cid: debe permitirse para el href esquema. Esa es la diferencia entre la gestión de referencias de adjuntos conforme a las normas y un fallo del marco que puede convertir la resolución de adjuntos en SSRF. (W3C)

Esto también explica por qué el PoC es conceptualmente simple incluso cuando la ruta real del exploit no lo es. XOP asume que href apunta a una parte MIME en la misma solicitud empaquetada. Si un framework acepta en su lugar una URL remota, una URL de ruta de archivo local u otro esquema desreferenciable en esa etapa, el servicio puede ser engañado para que obtenga algo que el cliente nunca adjuntó legítimamente. Una vez entendido esto, el resto de la PdC se convierte en una cuestión de forma de la petición, comportamiento del punto final y observabilidad, en lugar de un misterio oculto tras el número CVE. (W3C)

El problema es también más amplio de lo que sugieren los modelos mentales clásicos basados únicamente en JAX-WS. El aviso de Snyk señala que la vulnerabilidad existe para servicios web SOAP y JAX-RS con MTOM activado. La documentación de JAX-RS multiparts de Apache dice que los clientes y endpoints JAX-RS de CXF pueden soportar XOP y que es necesario establecer una directiva mtom habilitado en puntos finales JAX-RS y clientes para experimentar con ella. Así que la pregunta correcta no es "¿Es esto un SOAP CVE o un REST CVE". La pregunta correcta es "¿Acepta este endpoint la ruta XOP y MTOM que llega a la lógica de resolución de adjuntos vulnerable?". (VulnGuide)

La ruta vulnerable, desde la entrada XOP hasta la desviación de URL

La entrada Jira de Apache para CXF-8706 es inusualmente útil porque expone directamente la pila de llamadas afectada. El informe de error dice que cuando los servicios SOAP o JAX-RS utilizan MTOM, el unmarshaller permite xop:Incluir href que aceptan protocolos arbitrarios. A continuación, nombra el flujo afectado mediante AttachmentUtil.getAttachmentDataSource, JAXBAttachmentUnmarshaller.getAttachmentAsDataHandlery MTOMDecorator.startElement. Es una descripción mucho más útil que el lenguaje genérico de "validación de entrada incorrecta" porque te dice que el ataque está ligado a la resolución de adjuntos durante la vinculación y desvinculación, no a un método de negocio aleatorio. (Problemas de Apache)

El commit del parche rellena el resto. El mensaje de confirmación ASF para CXF-8706 dice "Desactivar URLDataSource por defecto, buscar siempre dentro de la lista de adjuntos por defecto". El diff introduce una constante llamada org.apache.cxf.attachment.xop.follow.urlsdocumenta que XOP href puede incluir URL arbitrarias que "nunca debemos seguir a menos que se permita explícitamente", y los cambios AttachmentUtil.getAttachmentDataSource por lo que el seguimiento de URL se controla mediante una propiedad del sistema que por defecto es falso. El parche también añade pruebas que verifican que la ruta por defecto ya no produce un URLDataSource, mientras que si se establece explícitamente la propiedad en true se restablece el siguiente comportamiento de URL. (Archivo de correo)

Ese comportamiento del parche dice algo importante sobre el fallo original. El problema no era sólo que CXF olvidara una estrecha lista de protocolos denegados. El problema era que la resolución de adjuntos permitía un comportamiento de fuente de datos basado en URL cuando el framework debería haber permanecido dentro del conjunto de adjuntos referenciado por el paquete. La solución es, por tanto, una corrección semántica tanto como una corrección de seguridad: dejar de tratar a xop:Incluir como una instrucción de desreferencia de propósito general, y tratarla como una referencia adjunta a menos que un operador tome una decisión consciente y arriesgada de optar de nuevo por la siguiente URL. (Archivo de correo)

La misma confirmación también cambia una solicitud de prueba del sistema para que el ejemplo href no es un desnudo http://localhost:9036/policy.xsd sino un cid:http://localhost:9036/policy.xsd valor. Es un detalle sutil pero revelador. Refleja un cambio de diseño hacia la semántica de adjunto en lugar de la semántica de recuperación externa. Cualquiera que escriba o revise un PoC debería prestar atención a ese cambio, porque deja claro que un exploit exitoso no se trata de un nombre de método u objeto de negocio. Se trata de si el servidor sigue la semántica de referencia incorrecta en la capa de gestión de adjuntos. (Archivo de correo)

Por qué una PoC pública de CVE-2022-46364 puede parecer más fácil que el exploit real

Los nuevos repositorios públicos GitHub PoC son útiles porque hacen visible la anatomía de la petición. Uno de los repositorios describe el fallo como un MTOM de Apache CXF xop:Incluir SSRF y lo enmarca como SSRF con posibles efectos de inclusión de archivos locales. Su README dice que el problema existe porque CXF valida incorrectamente el archivo href atributo dentro de xop:Incluir al procesar mensajes SOAP codificados con MTOM y, a continuación, enumera ejemplos como archivo://, http://, https://y ftp://. Otro repositorio README ofrece una versión más sencilla: un punto final SOAP CXF vulnerable, una URL SSRF para exfiltrar y un ejemplo que utiliza file:///etc/passwd. Si cada una de esas afirmaciones se mantendrá en cada objetivo es una cuestión aparte, pero estos repos reflejan cómo se está enmarcando ahora la conversación pública sobre la PdC. (GitHub)

La parte más interesante es la forma de solicitud visible en el código. El nuevo PoC público de Python utiliza solicitaconjuntos Tipo de contenido a multiparte/relacionado con aplicación/xop+xmldeclara una parte raíz e incrusta <xop:Include href="..."/> dentro de un parámetro del cuerpo SOAP. No se trata de una elección de formato aleatoria. Refleja exactamente el modelo de empaquetado que MTOM y XOP esperan. En otras palabras, el exploit no es mágico. Sólo tiene éxito si la petición llega a un código que trata la parte entrante como contenido XOP y, a continuación, desvía la atención de la parte proporcionada por el atacante. href. (GitHub)

Esta es la razón por la que una PoC copiada a menudo falla contra objetivos reales, incluso cuando el objetivo utiliza Apache CXF. El script publicado puede apuntar a un nombre de operación de servicio, espacio de nombres o forma de esquema específicos que no existen en su objetivo. El objetivo puede utilizar CXF pero no exponer una operación compatible con MTOM. El destino puede aceptar SOAP pero rechazar ese cuerpo XML concreto. El destino puede tener restricciones de salida que impidan resultados SSRF visibles. O el destino puede llevar la dependencia en una ruta de código que es inalcanzable en la práctica, que es exactamente el tipo de distinción producto-contexto que Oracle documenta a través de diferentes líneas de productos. (GitHub)

Matriz de explotabilidad de CVE-2022-46364 en entornos reales

Una prueba de concepto seria tiene que empezar con una matriz de condiciones y no con un exploit copiado y pegado. La tabla siguiente es la versión honesta más corta de esa matriz.

Condición	Por qué es importante
Existe una versión vulnerable de Apache CXF	Tanto el aviso oficial como el NVD y el GitHub Advisory amplían el problema a las versiones anteriores a 3.4.10 y 3.5.5 en las líneas afectadas.
La ruta MTOM o XOP está realmente activada	Apache documenta que MTOM no está habilitado por defecto, y el fallo afecta específicamente al procesamiento de peticiones MTOM y al manejo de XOP.
El endpoint acepta una forma de petición que llega a attachment unmarshalling	La incidencia de Jira apunta a la resolución de adjuntos y a la pila de llamadas JAXB unmarshalling, no a una ruta de código arbitraria.
El servicio puede llegar al objetivo elegido por el atacante	SSRF sigue necesitando algo útil que obtener, ya sea un punto final HTTP interno, un servicio de metadatos u otro recurso accesible.
El atacante puede observar el efecto	El éxito puede aparecer dentro de la banda en la respuesta, o fuera de la banda a través de un oyente, una diferencia de tiempo o un registro de acceso descendente.
El contexto del producto no neutraliza la ruta del código vulnerable	El tratamiento dado por Oracle a la misma CVE en Essbase y Oracle Commerce demuestra que distribuir un componente vulnerable no es idéntico a exponer una ruta explotable.

La matriz es un resumen del aviso de Apache, la incidencia de Jira, la documentación de MTOM, la documentación de JAX-RS XOP y los boletines de proveedores posteriores. Un escáner normalmente puede confirmar la primera fila. Un PoC real tiene que responder al resto. (Apache CXF)

Esta distinción es importante desde el punto de vista operativo. El complemento Red Hat JBoss EAP de Tenable para un conjunto de paquetes descendentes dice explícitamente que Nessus no probó la explotabilidad y en su lugar se basó en el número de versión autoinformado de la aplicación. Este tipo de detección es útil para el descubrimiento de la exposición, la gestión de parches y la clasificación SBOM. No es lo mismo que probar que tu superficie SOAP o JAX-RS específica es explotable a través de MTOM y XOP. La diferencia entre estas dos actividades es exactamente donde un buen PoC se gana su sustento. (Tenable)

Misma CVE, distinta realidad

El boletín de IBM WebSphere Liberty dice que el problema afecta a Liberty cuando el jaxws-2.2 y recomienda aplicar correcciones provisionales o pasar a Liberty Fix Pack 23.0.0.2 o posterior. La lista de vulnerabilidades de seguridad de Open Liberty indica que la CVE-2022-46364 afecta a las versiones 17.0.0.3 a 23.0.0.1, está corregida en 23.0.0.2 y afecta a la versión jaxws-2.2 característica. No son notas de marketing a pie de página. Son pistas de explotabilidad. Si la característica relevante de los servicios web no está presente, la versión vulnerable de la biblioteca puede seguir apareciendo en los inventarios sin producir una superficie de ataque alcanzable. (IBM)

WildFly es útil por otra razón. Sus notas de la versión 26.1.3 indican una actualización de CXF 3.4.7 a 3.4.10 específicamente para abordar CVE-2022-46364. Esto indica que el ecosistema trató este problema como un problema lo suficientemente real como para justificar la actualización del marco en las versiones de la plataforma, y no sólo como un aviso que se quedó sin leer en un archivo de lista de correo. Las notas de lanzamiento de Red Hat Fuse 7.12 también listan CVE-2022-46364 como un problema solucionado. Si usted opera pilas de middleware Java, eso significa que su análisis de exposición tiene que incluir servidores de aplicaciones, buses de integración y paquetes de marcos incrustados en lugar de limitar la búsqueda a las declaraciones directas de Maven en su propio código. (WildFly)

Oracle es donde el matiz se vuelve imposible de ignorar. En un lugar Oracle dice que la CVE "no puede ser explotada en el contexto" de Essbase. En otro, Oracle lo describe como una ruta HTTP no autenticada fácilmente explotable para comprometer el componente Endeca Integration de Oracle Commerce Platform. Esa diferencia es exactamente la razón por la que "Apache CXF versión presente" es sólo el comienzo de su análisis. La verdadera cuestión es si el producto afectado convierte las características vulnerables del framework en una ruta de petición alcanzable con entrada controlada por el atacante y acceso saliente útil. (Oracle)

Creación de un laboratorio seguro para la validación de CVE-2022-46364

Si vas a validar este fallo, hazlo en un entorno aislado que controles. El laboratorio más seguro es un servicio CXF deliberadamente vulnerable que se ejecute en una red privada, un oyente independiente que registre las peticiones entrantes y una petición de prueba que demuestre si el servidor sigue la petición maliciosa. href. El objetivo no es construir el exploit más bonito. El objetivo es confirmar la condición exacta que importa: si el servicio hace referencia a un valor que debería haber permanecido dentro del paquete adjunto. Este tipo de laboratorio permite comparar el comportamiento antes y después de la corrección y ver hasta qué punto la ruta del exploit depende de la aplicación y no sólo de CXF. (Archivo de correo)

La documentación MTOM de Apache te da los ingredientes clave de laboratorio. Para JAX-WS, CXF dice que puedes publicar un endpoint, lanzar su enlace a SOAPBindingy llame a binding.setMTOMEnabled(true). También muestra la configuración XML utilizando un jaxws:punto final con un <entry key="mtom-enabled" value="true"/>. Su documentación MTOM-with-JAXB repite ese proceso y muestra el mismo mtom habilitado en XML. Para JAX-RS, la documentación multiparts dice que los experimentos XOP requieren establecer una propiedad mtom habilitado en los endpoints y clientes JAX-RS. Si su servicio no hace alguna versión de eso, un PoC para este CVE es poco probable que llegue a la ruta vulnerable en absoluto. (Apache CXF)

Por lo tanto, una configuración de laboratorio JAX-WS mínima puede tener este aspecto:

import javax.xml.ws.Endpoint;
import javax.xml.ws.soap.SOAPBinding;

Endpoint ep = Endpoint.publish("http://127.0.0.1:8080/mtom-lab", new MyService());
SOAPBinding binding = (SOAPBinding) ep.getBinding();
binding.setMTOMEnabled(true);

Apache documenta este patrón como la forma programática de habilitar MTOM en un endpoint del lado del servidor. El objetivo de mostrarlo aquí no es darle una receta de producción. Es para concretar la precondición: MTOM es una opción, no una propiedad automática de cada servicio SOAP. (Apache CXF)

Una configuración basada en XML sirve para lo mismo:

La documentación de CXF utiliza esta forma para mostrar cómo se habilita MTOM en despliegues basados en configuración. Eso también lo convierte en un buen patrón de caza para los defensores que buscan bases de código antiguas, paquetes XML de Spring y paquetes de proveedores para la exposición alcanzable. (Apache CXF)

Para JAX-RS, la documentación de Apache es más corta pero sigue siendo útil. Dice que los endpoints JAX-RS de CXF pueden soportar XOP y que es necesario establecer un parámetro mtom habilitado en el endpoint y en el cliente. Esto significa que una revisión de código o configuración no debería detenerse en las clases de servicio SOAP clásicas. Una aplicación JAX-RS que utilice las características multiparte y XOP de CXF puede seguir siendo relevante para esta CVE si alcanza la misma semántica de resolución de adjuntos. (Apache CXF)

Anatomía de una solicitud de prueba de concepto segura

Un PoC responsable para CVE-2022-46364 no necesita ser un script de explotación pulido. Necesita hacer observable una cosa: si el servidor sigue un xop:Incluir href que no deben seguirse. Los actuales repositorios públicos de PdC muestran claramente la estructura común: un multiparte/relacionado una parte raíz declarada como aplicación/xop+xmlun sobre SOAP, un elemento de operación comercial y un elemento controlado por el atacante. href en xop:Incluir. Esa estructura sigue el modelo de empaquetado MTOM en lugar de algún truco específico de CVE. (GitHub)

Una plantilla de laboratorio segura tiene este aspecto:

POST /su-servicio HTTP/1.1
Alojamiento: lab.example
Content-Type: multipart/related; type="application/xop+xml"; start=""; start-info="text/xml"; boundary="boundary"

--límite
Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
Content-Transfer-Encoding: 8bit
Content-ID: 


  
  
    
      
        
          
        
      
    
  


--boundary--

Esta plantilla utiliza intencionadamente un dominio de escucha marcador de posición y una operación genérica. Es útil porque enseña la forma de la solicitud sin pretender que su objetivo acepte el mismo espacio de nombres, nombre de método o esquema de cuerpo que un repositorio público de demostración. El verdadero trabajo en cualquier prueba autorizada es adaptar el cuerpo al contrato de servicio real del objetivo. (GitHub)

Hay varias cosas que verificar antes de interpretar los resultados. En primer lugar, confirme que la operación comercial acepta normalmente el contenido MTOM o XOP en lugar de rechazar de plano las cargas útiles multiparte. En segundo lugar, establezca una solicitud de control que utilice una referencia de archivo adjunto benigna o una referencia de archivo adjunto válida. cid: para poder comparar el comportamiento de análisis normal con el malicioso. En tercer lugar, observa tanto la respuesta de la aplicación como el lado del oyente. Algunos servicios reflejarán datos. Otros sólo producirán diferencias de tiempo, mensajes de error o devoluciones de llamada salientes. Una buena PoC es, por lo tanto, menos sobre "tengo un shell" y más sobre "he probado que el servidor dereferenció una referencia controlada por el atacante en un lugar donde no debería haberlo hecho". (W3C)

Qué aspecto tiene el éxito en una PoC de CVE-2022-46364

Para algunos objetivos, el éxito es obvio. El servicio obtiene un recurso benigno de su servidor web de escucha o de laboratorio, y usted puede ver la solicitud entrante en sus registros. Para otros, el éxito es indirecto. Una solicitud con una URL interna enrutable tarda más que una solicitud con una URL no enrutable. Una búsqueda basada en archivos o recursos internos provoca una ruta de fallo distinta. Una petición dirigida a un endpoint canario produce un encabezado, una búsqueda DNS o un hit HTTP que la petición de control nunca produce. No se trata de insistir en un resultado universal. Se trata de definir de antemano cuál es su condición de prueba. (Feedly)

Los repositorios públicos de PoC tienden a enfatizar resultados dramáticos como la inclusión de archivos locales o el acceso a metadatos en la nube. Esas son consecuencias plausibles en algunos entornos, pero no son resultados garantizados de la CVE por sí mismos. La vía de explotación sigue dependiendo de los esquemas aceptados, los privilegios del proceso de servicio, la presencia o ausencia de controles de salida y la visibilidad de la vía de respuesta. La forma más segura y profesional de enmarcar una PoC es comenzar con la confirmación SSRF y sólo entonces razonar sobre lo que el servidor podría alcanzar desde su contexto de red y privilegios. (GitHub)

Aquí es también donde muchos informes débiles van mal. Un escáner de versión ve CXF 3.5.4, marca CVE-2022-46364, y el informe implica inmediatamente que la aplicación puede leer archivos locales o golpear metadatos en la nube. Eso puede ser cierto. También puede ser falso. El propio lenguaje de productos de Oracle demuestra que la misma CVE a nivel de componente puede ser no explotable en un contexto de producto y materialmente explotable en otro. Una buena PoC cierra esa brecha con pruebas en lugar de suposiciones. (Oracle)

Qué ha cambiado con el parche y por qué es importante desde el punto de vista operativo

El detalle más importante del parche es la nueva propiedad del sistema org.apache.cxf.attachment.xop.follow.urls. El parche lo pone por defecto en falso. Esto significa que las versiones fijas dejan de seguir referencias arbitrarias basadas en URL durante la resolución de adjuntos a menos que alguien opte explícitamente por volver al comportamiento anterior. Los comentarios del commit dicen explícitamente que el xop:Incluir href puede incluir URL arbitrarias "que nunca deberíamos seguir a menos que se permita explícitamente". Esto no es sólo un ajuste de implementación. Es una declaración de comportamiento seguro por defecto. (Archivo de correo)

Operativamente, eso significa que la actualización es el primer paso, no el último. También tienes que buscar los lugares donde alguien puede haber vuelto a activar el comportamiento de riesgo. Si encuentra el org.apache.cxf.attachment.xop.follow.urls propiedad del sistema establecida en verdaderoSi no es así, considérelo un elemento de revisión de alta prioridad. En un entorno moderno, cualquier razón para volver a habilitar el seguimiento de URL externas en la resolución XOP debe examinarse a fondo, documentarse claramente y aislarse tras los controles de red. La mayoría de los equipos no deberían necesitarlo nunca. (Archivo de correo)

El parche también indica a los defensores cómo construir una prueba de regresión. Si envías una petición MTOM controlada con un xop:Incluir que apunta a un lab listener, las versiones fijas no deberían seguirlo por defecto. Si tu entorno postparche sigue generando la llamada de retorno, o bien no has actualizado realmente la ruta efectiva del framework, o no estás probando el componente que crees que estás probando, o alguien ha restaurado deliberadamente el comportamiento peligroso. Este es un modelo de regresión limpio y defendible. (Archivo de correo)

Detección, verificación y triaje para los defensores

El primer paso más fiable es el inventario de dependencias y tiempo de ejecución. Busque las versiones de CXF afectadas en las declaraciones de Maven y Gradle, las SBOM de las imágenes de contenedor, las bibliotecas integradas, los módulos del servidor de aplicaciones y los paquetes de plataforma. A continuación, pase inmediatamente a la búsqueda de configuraciones. En el código y XML de CXF, busque mtom habilitado, SOAPBinding.setMTOMEnabled(true), @XmlMimeType, Manejador de datosy JAX-RS multiparte o configuración XOP. Los propios ejemplos MTOM de Apache proporcionan las cadenas que importan en entornos reales. (Apache CXF)

Un simple triaje de código base puede comenzar con comandos como estos:

grep -R "setMTOMEnabled(true)" -n .
grep -R "mtom-enabled" -n .
grep -R "@XmlMimeType" -n .
grep -R "DataHandler" -n .
grep -R "multipart/related" -n .

Estos patrones no son perfectos, pero se alinean con la documentación oficial CXF MTOM y a menudo cortan a través de grandes bases de código Java sorprendentemente rápido. También ayudan a separar "la biblioteca existe en algún lugar de la pila" de "este servicio utiliza realmente las características de adjuntos y XOP que importan para este CVE". (Apache CXF)

La siguiente capa es la observación del tráfico y la salida. Si está revisando servicios en directo, busque multiparte/relacionado peticiones, aplicación/xop+xml, xop:Incluiry la salida sospechosa desde niveles SOAP o de servicios web a destinos privados, de enlace local o externos inusuales. El propio artículo de Penligent centrado en SSRF es útil aquí porque enmarca los destinos privados y de enlace local como casos de validación SSRF de primera clase en lugar de casos extremos de nicho. Eso coincide con lo que importa operativamente para esta CVE: el fallo es tan peligroso como las cosas a las que puede llegar el servicio y los límites de confianza que cruzan esas peticiones. (Penligente)

Una matriz de detección compacta ayuda a organizar ese trabajo:

Capa	Qué comprobar
Capa de dependencia	Versiones de CXF anteriores a 3.4.10 y 3.5.5 en dependencias directas, paquetes de servidores de aplicaciones o paquetes de proveedores.
Capa de configuración	mtom habilitadoJAX-WS SOAPBinding.setMTOMEnabled(true)Habilitación de JAX-RS XOP, @XmlMimeType, Manejador de datos uso
Capa de solicitud	multiparte/relacionado, aplicación/xop+xml, xop:IncluirArchivos adjuntos SOAP inusuales
Capa de salida en tiempo de ejecución	Solicitudes de hosts de servicio a redes privadas, rangos de enlaces locales, servicios de metadatos o destinos HTTP inesperados.
Capa de validación	Solicitudes canarias controladas que distinguen el procesamiento normal de los archivos adjuntos del comportamiento de las referencias externas.

Esta matriz proviene directamente de la documentación oficial de MTOM y XOP, el aviso de Apache y la descripción de la ruta del código de la vulnerabilidad. Es intencionadamente conservadora. Está diseñada para ayudar a los defensores a probar o refutar la explotabilidad alcanzable en lugar de detenerse en los nombres de los paquetes. (Apache CXF)

La salida del escáner debe leerse con ese mismo espíritu. El lenguaje de plugins de Tenable deja claro que algunas detecciones se basan en versiones y no en pruebas activas de exploits. Por eso, el flujo de trabajo correcto suele ser primero el inventario, segundo la revisión de condiciones previas y tercero la validación controlada. Un hallazgo de dependencia es suficiente para justificar la planificación de parches. No es suficiente para apoyar una afirmación contundente sobre explotabilidad a menos que se verifique la ruta relevante. (Tenable)

Los equipos que tienen que hacer esto repetidamente suelen alejarse de las secuencias de comandos puntuales y adoptar un flujo de trabajo de repetición de pruebas basado en las pruebas. El artículo de Penligent sobre PoC es muy útil en este sentido: un buen trabajo de PoC consiste en aislar la entrada controlada por el atacante, elegir el menor efecto relevante para la seguridad y preservar una comparación de control contra prueba. Esa es exactamente la mentalidad que los defensores deben utilizar para las pruebas de CVE-2022-46364, tanto si la herramienta es un comando curl, un arnés personalizado o una plataforma de validación automatizada más grande. (Penligente)

Refuerzo más allá de la actualización del marco

La solución directa para Apache CXF es sencilla: pasar a 3.4.10, 3.5.5, o una versión posterior mantenida en una rama soportada. Las notas de la versión 3.5.5 de Apache marcan esa versión como la línea de parches actual para 3.5.x en ese momento, y el historial de versiones posteriores de Apache muestra que el proyecto continuó enviando correcciones de seguridad para otros problemas relacionados con SSRF en 2024 y 2025. La lección principal no es sólo "instalar un parche". Es que los marcos de servicios web merecen un mantenimiento regular porque los comportamientos de análisis sintáctico, descripción y desreferencia siguen produciendo problemas de seguridad con el tiempo. (Apache CXF)

La primera medida de refuerzo tras la aplicación de parches es cerrar las salidas innecesarias. Si un nivel SOAP no tiene nada que hacer hablando con hosts arbitrarios de Internet, rangos de red privada, servicios de metadatos o servicios de tipo loopback, bloquee ese tráfico en la capa de red. La defensa SSRF es mucho más fuerte cuando la aplicación no puede alcanzar físicamente los objetivos interesantes. Esto es especialmente importante porque Apache CXF también ha tenido avisos posteriores relacionados con SSRF, incluyendo CVE-2024-28752 en Aegis databinding y CVE-2024-29736 en WADL stylesheet parameters. Corregir un error está bien. Restringir lo que el servicio puede alcanzar es mejor. (Apache CXF)

El segundo movimiento es deshabilitar o retirar MTOM en los servicios que no lo necesitan. La propia documentación de MTOM de Apache deja claro que MTOM es una característica que debe estar habilitada. En muchos entornos antiguos permanece activada porque "así es como se ha desplegado siempre el servicio", no porque alguien necesite todavía la optimización de adjuntos binarios. La reducción de características heredadas es a menudo la reducción de riesgo real más barata que se puede comprar. (Apache CXF)

El tercer paso consiste en tratar las antiguas superficies SOAP y JAX-WS como activos especiales. Open Liberty, IBM Liberty, WildFly, Red Hat Fuse, Oracle Commerce y otros productos derivados ilustran el mismo punto operativo: la lógica vulnerable a menudo vive dentro de plataformas que los equipos olvidan que todavía están expuestas. Puede que estas interfaces no se sometan al mismo escrutinio que las modernas API REST, pero a menudo conllevan un comportamiento de integración privilegiado, esquemas estables y supuestos de salida heredados que hacen que SSRF sea más valioso cuando funciona. (IBM)

CVEs relacionados que ayudan a explicar el patrón

CVE-2022-46364 no está solo en la historia de Apache CXF. La versión emparejada 2022 también incluía CVE-2022-46363, que Apache describe como un problema de listado de directorios y exfiltración de código que aparece cuando CXFServlet está mal configurado con static-resources-list y redirect-query-check. Ese fallo no es el mismo que el de MTOM SSRF, pero sigue siendo una comparación útil porque muestra hasta qué punto el riesgo de CXF puede depender de las combinaciones de características y del contexto de configuración, en lugar de un modelo simplista de "biblioteca igual a exploit". (Apache CXF)

Luego está CVE-2024-28752. Apache lo describe como una vulnerabilidad SSRF usando el databinding Aegis, que afecta a versiones anteriores a 4.0.4, 3.6.3 y 3.5.8, y dice explícitamente que los usuarios de otros databindings, incluyendo el databinding por defecto, no están afectados. Este es otro caso en el que la cuestión de la explotabilidad no se responde únicamente con el nombre del framework. Necesitas saber qué modelo de vinculación utiliza realmente la aplicación. (Apache CXF)

CVE-2024-29736 lleva la misma lección a REST. Apache y NVD lo describen como un problema SSRF en el manejo de la descripción del servicio WADL, que afecta a CXF antes de 3.5.9, 3.6.4 y 4.0.5, pero sólo cuando se configura un parámetro de hoja de estilo personalizado. De nuevo, la CVE es real, el parche es real, y la explotabilidad depende de si la aplicación habilita la ruta de la característica de riesgo. Una vez que se observan estos tres fallos juntos, se hace obvio un patrón: siempre que se permite que el código del marco de trabajo interprete referencias, descriptores o ubicaciones de contenido externalizado controlados por atacantes, los problemas de clase SSRF siguen reapareciendo. (Apache CXF)

Se trata de una lección de diseño útil tanto para los equipos ofensivos como para los defensivos. Los equipos ofensivos deberían buscar comportamientos de resolución de referencias ocultos tras las características del marco de trabajo en lugar de tratar cada SSRF como un error de aplicación manual. Los equipos defensivos deberían dejar de pensar en SSRF como un problema exclusivo del controlador web y empezar a revisar el empaquetado binario, las transformaciones de estilo, los generadores de documentación y los gestores de adjuntos como ciudadanos iguales en el modelado de amenazas. El historial de avisos de Apache CXF respalda esta visión más amplia. (Apache CXF)

Por qué este PdC sigue siendo importante en 2026

La divulgación pública es antigua. El parche es antiguo. Pero la PdC sigue siendo importante porque el ciclo de vida de los fallos de marco es largo. La publicación de una nueva PdC cambia el comportamiento de los defensores, las firmas de los escáneres y la atención de los atacantes. La cronología de Feedly para CVE-2022-46364 muestra no sólo las nuevas referencias de la PdC de marzo de 2026, sino también las posteriores detecciones de los escáneres y los avisos de los proveedores a lo largo del tiempo. Esa es la vida posterior normal de un problema a nivel de dependencia en el software empresarial: larga cola, redescubrimiento repetido y estallidos periódicos de interés cada vez que aparece nuevo material de explotación o asignaciones de productos posteriores. (Feedly)

También importa porque Internet está lleno de páginas CVE poco profundas que aplanan todo en "SSRF crítico, actualice ahora". Ese consejo es direccionalmente correcto y analíticamente incompleto. La mejor pregunta es si su entorno expone una ruta MTOM o XOP que sea alcanzable, observable y útil para un atacante. Si la respuesta es sí, la PoC importa porque cierra la brecha de prueba entre el inventario de versiones y la realidad de la seguridad. Si la respuesta es negativa, la PoC sigue siendo importante porque te dice exactamente qué condiciones tendrían que cambiar para que el riesgo se convirtiera en real más adelante. (Apache CXF)

Reflexiones finales

CVE-2022-46364 es un buen ejemplo de cómo una vulnerabilidad de framework puede ser sobrevalorada y subestimada al mismo tiempo. Se sobrevalora cuando la gente actúa como si cualquier dependencia de Apache CXF significara automáticamente SSRF completo y lectura de archivos en producción. Se subestima cuando los equipos lo descartan como "sólo otro hallazgo de biblioteca" sin comprobar si MTOM y XOP están realmente expuestos en servicios alcanzables. Las fuentes oficiales apoyan una lectura más disciplinada: el fallo es real, el parche está claro, las versiones afectadas son conocidas, la ruta vulnerable es identificable, y la explotabilidad depende de la configuración y el contexto del producto de maneras que los operadores responsables deberían verificar en lugar de adivinar. (Apache CXF)

El reciente regreso del material PoC público hace que ahora sea un buen momento para hacer esa verificación. Haga un inventario de sus versiones de CXF. Busque la habilitación de MTOM y XOP. Compruebe si siguen existiendo las antiguas superficies SOAP y JAX-WS. Confirme si su nivel de servicio puede llegar a destinos internos sensibles. A continuación, ejecute una prueba de regresión controlada contra un entorno de laboratorio o claramente autorizado. Esa es la diferencia entre verse sorprendido por una CVE resucitada y tener ya la respuesta cuando la alerta llega a su cola. (Feedly)

Referencias

Apache CXF advisory for CVE-2022-46364, el resumen canónico del proveedor y la declaración de la versión corregida. (Apache CXF)

Entrada NVD para CVE-2022-46364, incluyendo la puntuación CVSS 9.8 y los rangos de versiones afectadas. (NVD)

Apache Jira issue CXF-8706, que muestra la descripción de la vulnerabilidad y la pila de llamadas afectada. (Problemas de Apache)

Archivo ASF commit para el parche CXF-8706, incluyendo el org.apache.cxf.attachment.xop.follow.urls y el cambio de comportamiento por defecto. (Archivo de correo)

La especificación XOP del W3C, que establece que xop:Incluir href debe ser un cid: URI. (W3C)

Documentación sobre MTOM de Apache CXF y MTOM con JAXB, útil para entender las precondiciones exactas de las características y los patrones de habilitación. (Apache CXF)

La documentación de Apache CXF JAX-RS multiparts, que documenta la compatibilidad con XOP y la función mtom habilitado para puntos finales y clientes JAX-RS. (Apache CXF)

Boletín de IBM WebSphere Liberty y lista de vulnerabilidades de Open Liberty, que muestran cómo los productos posteriores amplían el problema a las funciones relacionadas con JAX-WS. (IBM)

Nota de la versión 26.1.3 de WildFly, que muestra una mejora de CXF para abordar CVE-2022-46364 en una versión de plataforma real. (WildFly)

Material de Oracle CPU que muestra las diferencias producto-contexto, incluyendo Oracle Essbase como no explotable en contexto y Oracle Commerce Platform como explotable en contexto. (Oracle)

Avisos de Apache CXF relacionados para CVE-2022-46363, CVE-2024-28752 y CVE-2024-29736. (Apache CXF)

Artículo de Penligent sobre SSRF en destinos privados y de enlace local, que es relevante cuando se piensa en lo que un SSRF exitoso en un nivel de servicio puede realmente alcanzar. (Penligente)

El artículo de Penligent sobre la construcción de una PoC mínima reproducible, que se alinea con el flujo de trabajo de control contra prueba que hace que la validación de CVE-2022-46364 sea útil en lugar de ruidosa. (Penligente)

Página de inicio de Penligent, relevante si está comparando flujos de trabajo de repetición de pruebas asistidos por IA basados en pruebas y generación de PoC reproducibles. (Penligente)