Skip to content
KitploitKITPLOIT
HerramientasBlog
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
mirth-connect-security-poc — PoCs funcionales para tres vulnerabilidades de NextGen Connect 4.5.2. | Kitploit
Herramientas/GitHubGitHub/abhinavagarwal07/mirth-connect-security-poc
Herramientas DefensivasAnálisis de VulnerabilidadesExplotaciónExplotación de Aplicaciones WebVirtualización de SeguridadPruebas de PenetraciónAprendizaje y Educación
GitHubabhinavagarwal07/mirth-connect-security-poc

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →

mirth-connect-security-poc

PoCs funcionales para tres vulnerabilidades de NextGen Connect 4.5.2.

Ver Repositorio
5hace 1 díaAún no revisado
Compartir

PoCs de vulnerabilidades de NextGen Connect 4.5.2

Exploits de prueba de concepto funcionales para tres vulnerabilidades alcanzables por red en NextGen Connect (Mirth Connect) 4.5.2. Los arneses ejecutan la imagen de contenedor oficial, crean únicamente la configuración de canal necesaria para el hallazgo, ejecutan el ataque desde un contenedor separado y fallan a menos que se observe el efecto de seguridad declarado.

Esta revisión utilizó la pública metodología Refute-or-Promote y su playbook de orquestación de código abierto. El método separa la generación de candidatos de la revisión adversarial con contexto fresco y requiere prueba empírica antes de la promoción. El código fuente vulnerable 4.5.2 y el método de revisión son ambos públicos: cualquiera con acceso ordinario a modelos, el código fuente y la capacidad de validar de forma segura en un laboratorio puede aplicar el mismo proceso, y podría haber encontrado estas clases de errores de forma independiente. La confidencialidad en torno a un informe no hace que la capacidad de revisión subyacente sea privada.

Estos son exploits reales, no pruebas unitarias de analizadores. Recuperan un hash de contraseña en vivo mediante inyección SQL, exfiltran contenidos de archivos locales del objetivo a través de dos rutas XML no autenticadas distintas, y bloquean operaciones respaldadas por Derby integrado hasta el reinicio.

CVEHallazgoAtacanteImpacto demostradoCVSS 3.1 / 4.0PoC
CVE-2026-82583Inyección selectLimit en _getTablesUsuario autenticado de la APIExportación de la tabla de contraseñas a la raíz web pública; congelación de Derby integrado hasta el reinicio8.3 / 7.2sql-selectlimit-injection/
CVE-2026-78224XXE en paso XSLTCliente de canal no autenticadoLectura OOB de un archivo local del objetivo; DoS por entidad lenta local del canal8.2 / 8.8xslt-step-xxe/
CVE-2026-82578XXE en adaptador de lote XMLCliente de canal no autenticadoLectura OOB de un archivo local del objetivo7.5 / 8.7xml-batch-xxe/

CVSS 3.1 y 4.0 son estándares diferentes; las puntuaciones emparejadas no son una comparación de antes y después.

Los tres se reprodujeron contra:

root@kitploit:~
nextgenhealthcare/connect:4.5.2
sha256:4afa295cfe7c5ffd596efee69594157fea87202e33d66bb4a98a52db4598f836

NextGen informó de forma privada que el problema de XSLT se corrigió en 4.7.1 y los problemas de inyección SQL y de lote XML se corrigieron en 4.7.2. El aviso de CISA ICSMA-26-253-01 considera afectadas las versiones 4.7.1 y anteriores y recomienda 4.7.2 o posterior. Las versiones posteriores a 4.5 son propietarias, por lo que no existe una imagen corregida pública a partir de la cual este repositorio pueda proporcionar el mismo tipo de control negativo reproducible utilizado para una versión de parche de código abierto.

Qué gana un atacante

CVE-2026-82583: exposición de la base de datos y de secretos de integración

Un punto de apoyo autenticado en la API administrativa se convierte en acceso a datos que la cuenta no estaba destinada a exportar. El exploit empaquetado escribe la fila en vivo de PERSON_PASSWORD bajo public_html y demuestra que el archivo resultante es descargable sin autenticación. El paso que importa es pasar de una acción restringida de la API a un archivo en disco que ya no necesita la sesión del atacante en absoluto.

En un entorno de integración real, la base de datos puede describir canales, endpoints y credenciales utilizadas para alcanzar bases de datos, servidores SFTP, retransmisores de correo, APIs y otros sistemas clínicos. Una prueba controlada separada recuperó una contraseña de conector plantada deliberadamente desde el XML de canal exportado. Eso hace que la primitiva sea útil para el mapeo del entorno y el robo de secretos; el uso de cualquier credencial recuperada contra un sistema posterior no se probó y no se afirma.

La rama opcional de denegación de servicio congela la base de datos Derby integrada. Las llamadas a la API respaldadas por la base de datos entonces expiran, la misma inyección no puede descongelar su propio punto de entrada, y se requiere reiniciar el proceso. Esta es una carga de recuperación práctica para instalaciones respaldadas por Derby, no una prueba de que las bases de datos de producción externas se comporten de la misma manera.

CVE-2026-78224: divulgación no autenticada de archivos del servidor e interrupción del canal

Una vez que se despliega un canal XSLT afectado, el atacante no necesita ninguna cuenta de Mirth. El XML entrante hace que el servicio lea un archivo local del objetivo y envíe su contenido a un callback controlado por el atacante. Esto es útil incluso cuando la respuesta normal del canal no contiene los datos transformados y el atacante no puede leer el historial de mensajes.

El cliente independiente acepta un URI file: de una sola línea seleccionado por el llamador. Archivos como identificadores de host, tokens, fragmentos de configuración o credenciales son prácticamente valiosos si la cuenta de servicio de Mirth puede leerlos y el servidor puede alcanzar el callback. La prueba empaquetada utiliza únicamente un canario generado y no afirma recuperación universal de archivos arbitrarios, transporte multilínea ni acceso más allá de la cuenta de servicio.

Una entidad externa lenta también ocupa el canal víctima predeterminado de un solo hilo. Eso puede retrasar o detener la interfaz clínica específica mapeada a ese canal hasta que se libere la entidad. El canal de control y la API administrativa permanecen sanos, por lo que esto es una interrupción local del canal en lugar de una caída de todo el servidor.

CVE-2026-82578: exfiltración ciega de archivos a través de la entrada por lotes

Cuando se habilita un modo de lote XML afectado, un remitente no autenticado puede usar el cuerpo de lote sin procesar para desencadenar el mismo tipo de divulgación de archivos saliente. El servidor devuelve HTTP 500, pero el atacante ya tiene el contenido del archivo exclusivo del objetivo a través del callback OOB. Eso hace que el fallo sea prácticamente útil como una ruta de exfiltración ciega incluso cuando las pruebas basadas únicamente en el código de respuesta descartarían la solicitud como un fallo del analizador.

El procesamiento por lotes está desactivado de forma predeterminada, el modo de división debe alcanzar el analizador respaldado por XPath, y se requiere salida de red del servidor. Este repositorio no afirma una denegación de servicio demostrada para CVE-2026-82578.

Ejecución

Requisitos: Bash, Docker, Linux x86-64 y acceso a la red para la extracción inicial de la imagen. Ambas imágenes están fijadas por digest. No se publica ningún puerto del host; el objetivo y el atacante se comunican únicamente en un puente Docker interno específico de la tarea.

root@kitploit:~
./run-all.sh

O ejecutar un único hallazgo:

root@kitploit:~
./sql-selectlimit-injection/poc/run.sh
./xslt-step-xxe/poc/run.sh
./xml-batch-xxe/poc/run.sh

Cada invocación crea contenedores con nombres únicos y una red de puente, registra evidence/current-run.log y elimina sus propios recursos de laboratorio al salir. Los archivos evidence/vulnerable-4.5.2.log incluidos en el repositorio son transcripciones de una repetición en Linux x86-64.

Qué se afirma y qué no

  • La inyección SQL se demuestra a través del punto de entrada REST real y la base de datos Derby integrada. El PoC exporta la fila en vivo de PERSON_PASSWORD y recupera el archivo sin autenticación. Su rama de laboratorio opcional invoca SYSCS_FREEZE_DATABASE, tras lo cual las llamadas a la API respaldadas por la base de datos dejan de responder hasta que el objetivo se reinicia.
  • El PoC de XSLT utiliza una transformación de identidad fija instalada por el administrador. El atacante controla únicamente el mensaje entrante no autenticado. Los contenidos de los archivos regresan a través de un callback DTD externo. Su cliente independiente acepta un URI file: de una sola línea local del objetivo; el contenedor de laboratorio utiliza un canario aleatorio y una aserción exacta. La misma ejecución demuestra la indisponibilidad local del canal con un segundo canal sano y la API de administración, y luego verifica la recuperación.
  • El PoC de lote XML habilita el modo de lote ordinario Element Name de XML del producto. El atacante controla únicamente el cuerpo del lote no autenticado. Su cliente independiente tiene el mismo modo --file-uri y la misma limitación OOB de una sola línea.
  • No se probó ningún producto sanitario posterior, registro de paciente ni sistema de terceros. Las referencias a posibles PHI o credenciales posteriores describen consecuencias de despliegue, no víctimas adicionales demostradas.
  • El candidato de ruta de exportación en el checkout de investigación está ausente intencionalmente. La API está diseñada para la exportación del lado del servidor y el material proporcionado no demostró una violación portátil del límite de privilegios ni una cadena completa de ejecución de código.

Seguridad

Ejecutar únicamente en un laboratorio desechable de su propiedad. El PoC de SQL congela deliberadamente la base de datos objetivo; la recuperación requiere reiniciar el objetivo. Los PoC de XXE leen un canario montado de forma predeterminada, pero sus clientes independientes aceptan URLs de escucha arbitrarias y URIs de archivos locales del objetivo de una sola línea. Nunca los dirija a sistemas sin autorización.

Mitigación

Según CISA, actualice a Connect 4.7.2 o posterior. Cuando una actualización inmediata no sea posible, restrinja la API administrativa a redes de gestión de confianza, elimine los pasos XSLT innecesarios, desactive el procesamiento por lotes XML donde no sea necesario y bloquee la salida de red innecesaria del servidor. Esas medidas reducen la exposición pero no reparan el código vulnerable.

Crédito

Los hallazgos 1 y 3 deben atribuirse a Abhinav Agarwal. El hallazgo 2 fue descubierto de forma independiente por Abhinav Agarwal y reportado por primera vez a NextGen por Youngdu. NextGen coordinó las correcciones y la asignación de CVE.

Uso defensivo previsto

Este repositorio está destinado a ayudar a los defensores a convertir el texto de los avisos en comportamiento observable y comprobable. En una copia aislada de un entorno, los defensores pueden usarlo para:

  • determinar si el comportamiento público de 4.5.2 está presente y comprender los requisitos exactos de configuración;
  • validar que los controles del plano de gestión impiden que cuentas no confiables alcancen la operación del Conector de Base de Datos;
  • confirmar que el filtrado de salida bloquea la ruta de callback XXE probada;
  • construir detecciones para solicitudes sospechosas a _getTables, procedimientos inesperados de exportación o congelación de Derby, nuevos archivos bajo public_html, XML entrante que contenga un DOCTYPE, y callbacks originados en Mirth tras errores de escucha;
  • priorizar la rotación de credenciales de conectores cuando un plano administrativo afectado pueda haber sido comprometido; y
  • volver a ejecutar las mismas aserciones contra una compilación corregida proporcionada por el proveedor como control negativo local, aunque esa compilación no pueda distribuirse aquí.

Cada PoC se ejecuta en un contenedor, fija sus imágenes por digest y falla de forma segura a menos que regrese un canario aleatorio. Un defensor puede reproducir el límite de seguridad real en lugar de aceptar una captura de pantalla o un número de severidad por fe. Existe para ayudar a las personas a encontrar lo que están ejecutando, probarlo y confirmar que un parche funcionó. No está aquí para ser apuntado a un hospital.

Descargar herramienta