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
CVE-2026-47117-openmed-rce — OpenMed < 1.5.2 RCE no autenticado a través de la carga del modelo del filtro de privacidad PII y trust_remote_code=True | Kitploit
Herramientas/GitHubGitHub/saiteja-erukude/cve-2026-47117-openmed-rce
Análisis de VulnerabilidadesExplotaciónExplotación de Aplicaciones WebSeguridad WebPruebas de PenetraciónSeguridad de IA
GitHubsaiteja-erukude/cve-2026-47117-openmed-rce

CVE-2026-47117-openmed-rce

OpenMed < 1.5.2 RCE no autenticado a través de la carga del modelo del filtro de privacidad PII y trust_remote_code=True

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 →
Compartir
Ver Repositorio
hace 5 díasAún no revisado

CVE-2026-47117: OpenMed Ejecución Remota de Código No Autenticada mediante la Carga de Modelos PII

Severidad: Crítica, CVSS 4.0 9.3, CVSS 3.1 9.8 (asignado por VulnCheck, la CNA)

Vector (v4.0): CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Vector (v3.1): CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Afectados: OpenMed < 1.5.2

Corregido en: 1.5.2

CWE: CWE-94 (Control Inadecuado de la Generación de Código, Inyección de Código)

Reportado por: Sai Teja Erukude

CNA: VulnCheck

Publicado: 2 de junio de 2026


Resumen

OpenMed anterior a 1.5.2 contiene una vulnerabilidad de ejecución remota de código no autenticada en la ruta de carga del modelo de filtro de privacidad PII.

Los endpoints de la API REST POST /pii/extract y POST /pii/deidentify aceptan un valor model_name del cuerpo de la solicitud. En las versiones vulnerables, el despachador del filtro de privacidad utilizaba una coincidencia amplia de subcadenas sobre este valor controlado por el atacante. Un nombre de modelo como attacker/foo-privacy-filter-bar podía, por tanto, enrutarse al backend del filtro de privacidad.

En implementaciones que no son MLX/Torch, ese backend cargaba los artefactos de modelos de Hugging Face a través de Transformers con trust_remote_code=True. Si el repositorio de modelos controlado por el atacante contenía código personalizado de Transformers referenciado mediante auto_map en config.json o tokenizer_config.json, Transformers importaba y ejecutaba ese código Python durante la carga del modelo o del tokenizador.

El código importado se ejecutaba con los privilegios del proceso de servicio de OpenMed.

Impacto

Un atacante remoto no autenticado que pueda alcanzar la API REST de OpenMed puede ejecutar código Python arbitrario en el servidor proporcionando un identificador de modelo malicioso de estilo Hugging Face en model_name.

Dependiendo del despliegue del servicio, esto puede permitir:

  • Leer o modificar archivos accesibles para el proceso de OpenMed.
  • Acceder a variables de entorno y secretos de la aplicación.
  • Llamar a servicios internos alcanzables desde el host de OpenMed.
  • Interrumpir o reemplazar el comportamiento de la aplicación.

Endpoints Afectados

El problema es alcanzable a través de ambos endpoints PII porque ambos aceptan model_name y usan la misma ruta de extracción/carga de modelos PII:

root@kitploit:~
POST /pii/extract
Content-Type: application/json

{
  "text": "John Doe called 555-1212",
  "model_name": "attacker/foo-privacy-filter-bar",
  "confidence_threshold": 0.0
}
root@kitploit:~
POST /pii/deidentify
Content-Type: application/json

{
  "text": "John Doe called 555-1212",
  "model_name": "attacker/foo-privacy-filter-bar",
  "confidence_threshold": 0.0
}

Detalle Técnico

El flujo de control vulnerable tiene dos fallos de límite de confianza:

  1. La API confiaba en un model_name proporcionado por el usuario al seleccionar el backend del filtro de privacidad.
  2. El backend seleccionado confiaba en el código del repositorio de modelos remoto al cargar los artefactos de Transformers con trust_remote_code=True.

El despachador trataba cualquier identificador de modelo que contuviera privacy-filter como parte de la familia del filtro de privacidad. Esto permitía que identificadores controlados por el atacante, por ejemplo attacker/foo-privacy-filter-bar, alcanzaran una ruta de código destinada a los modelos de filtro de privacidad de primera parte confiables.

Una vez enrutado allí, Transformers podía cargar código personalizado controlado por el atacante mediante auto_map. Esta importación ocurre durante la carga del modelo/tokenizador, antes de que tenga que tener éxito ninguna inferencia útil. Por tanto, una carga útil de prueba puede ser tan pequeña como:

root@kitploit:~
from pathlib import Path

Path("marker.txt").write_text(
    "custom Transformers code executed via trust_remote_code\n",
    encoding="utf-8",
)

Prueba de Concepto

poc_exploit.py construye un directorio local inofensivo de modelo de estilo Hugging Face cuyo nombre contiene privacy-filter. Los módulos personalizados de Transformers generados escriben un archivo marcador cuando se importan. El script envía entonces una solicitud a una instancia de prueba de la API de OpenMed con ese directorio como model_name.

El comportamiento esperado en versiones vulnerables de OpenMed es:

  1. La API acepta el model_name controlado por el atacante.
  2. El enrutamiento por subcadenas lo envía al backend del filtro de privacidad.
  3. Transformers importa el módulo personalizado generado porque trust_remote_code=True.
  4. Se crea el archivo marcador, lo que demuestra la ejecución de código en el proceso de servicio de OpenMed.
  5. La solicitud puede fallar después porque el modelo de juguete no es un modelo real de filtro de privacidad; el marcador en tiempo de importación es la prueba relevante.

Ejecutar solo contra una instancia local de prueba:

root@kitploit:~
pip install -r requirements.txt
python poc_exploit.py --target http://127.0.0.1:8000 --endpoint /pii/extract

Si el servicio OpenMed se ejecuta en algún lugar que no puede acceder al directorio local generado, publique un modelo de prueba equivalente en un repositorio de Hugging Face controlado y pase ese identificador explícitamente:

root@kitploit:~
python poc_exploit.py \
  --target http://127.0.0.1:8000 \
  --model-name your-org/foo-privacy-filter-bar \
  --marker marker.txt

Remediación

Actualice a OpenMed 1.5.2 o posterior.

OpenMed 1.5.2 separa el enrutamiento de la confianza:

  • Los nombres de repositorio arbitrarios que contienen privacy-filter ya no se enrutan a través de la ruta confiable del filtro de privacidad.
  • PrivacyFilterTorchPipeline establece trust_remote_code en False de forma predeterminada.
  • Solo los repositorios explícitos de filtro de privacidad de primera parte están permitidos para la carga de código remoto confiable.
  • Los operadores que necesiten ajustes finos privados controlados pueden permitirlos con OPENMED_TRUSTED_REMOTE_CODE_MODELS.

Si la actualización inmediata no es posible:

  • No exponga la API REST vulnerable a clientes no confiables.
  • No pase valores model_name controlados por el usuario a Transformers con trust_remote_code=True.
  • Reemplace el enrutamiento de modelos basado en subcadenas con identificadores de modelos confiables exactos.
  • Precargue artefactos de modelos locales aprobados en producción y deshabilite las descargas arbitrarias de modelos.

Cronograma de Divulgación

Créditos

Descubierta y reportada por Sai Teja Erukude, coordinada a través de VulnCheck.

Referencias

  • Registro CVE: https://www.cve.org/CVERecord?id=CVE-2026-47117
  • NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-47117
  • Aviso de VulnCheck: https://www.vulncheck.com/advisories/openmed-remote-code-execution-via-pii-model-loading
  • Notas de la versión 1.5.2 de OpenMed: https://github.com/maziyarpanahi/openmed/releases/tag/v1.5.2
  • Proyecto OpenMed: https://github.com/maziyarpanahi/openmed
Descargar herramienta
FechaEvento
18 de mayo de 2026Vulnerabilidad enviada a VulnCheck
20 de mayo de 2026VulnCheck inició el proceso de divulgación coordinada
22 de mayo de 2026CVE-2026-47117 asignado provisionalmente
1 de junio de 2026Corrección de OpenMed 1.5.2 revisada y confirmada
2 de junio de 2026CVE-2026-47117 publicado