Vulnerabilidades

OpenEMR es una aplicación de código abierto y gratuita para la gestión de registros médicos electrónicos y la práctica médica. Antes de la versión 8.0.0, una vulnerabilidad de omisión de autorización en el endpoint de firma del portal del paciente permite a los usuarios autenticados del portal subir y sobrescribir firmas de proveedores estableciendo 'type=admin-signature' y especificando cualquier ID de usuario de proveedor. Esto podría potencialmente conducir a la falsificación de firmas en documentos médicos, violaciones de cumplimiento legal y fraude. El problema ocurre cuando a los usuarios del portal se les permite modificar firmas de proveedores sin las comprobaciones de autorización adecuadas. La versión 8.0.0 soluciona el problema.

OpenEMR es una aplicación gratuita y de código abierto de registros de salud electrónicos y gestión de consultorios médicos. Antes de la versión 8.0.0, una vulnerabilidad de inyección SQL en el endpoint de la API REST de Pacientes permite a usuarios autenticados con acceso a la API ejecutar consultas SQL arbitrarias a través del parámetro '_sort'. Esto podría potencialmente llevar a acceso a la base de datos, exposición de PHI (Información de Salud Protegida) y compromiso de credenciales. El problema ocurre cuando los nombres de campos de ordenación proporcionados por el usuario se utilizan en cláusulas ORDER por sin una validación adecuada o escape de identificadores. La versión 8.0.0 corrige el problema.

OpenEMR es una aplicación de código abierto y gratuita para registros de salud electrónicos y gestión de consultorios médicos. Antes de la versión 8.0.0, la tabla de rutas de la API REST en 'apis/routes/_rest_routes_standard.inc.php' no llama a 'RestConfig::request_authorization_check()' para las rutas de documentos y seguros. Otras rutas de pacientes en el mismo archivo (por ejemplo, encuentros, pacientes/med) la llaman con la ACL apropiada. Como resultado, cualquier token portador de API válido puede acceder o modificar los documentos y datos de seguro de cada paciente, independientemente de las ACL de OpenEMR del token —exponiendo eficazmente toda la información de salud protegida (PHI) de documentos y seguros a cualquier cliente de API autenticado. La versión 8.0.0 corrige el problema.

OpenEMR es una aplicación gratuita y de código abierto de registros de salud electrónicos y gestión de consultorios médicos. Antes de la versión 8.0.0, el Centro de Mensajes acepta el parámetro de URL 'show_all=yes' y lo pasa a 'getPnotesByUser()', que devuelve todos los mensajes internos (notas de todos los usuarios). El backend no verifica que el usuario solicitante sea un administrador antes de respetar 'show_all=yes'. El enlace 'Mostrar todo' también es visible para usuarios no administradores. Como resultado, cualquier usuario autenticado puede ver la lista completa de mensajes internos al solicitar 'messages.PHP?show_all=yes'. La versión 8.0.0 corrige el problema.

OpenEMR es una aplicación de gestión de registros médicos electrónicos y práctica médica de código abierto y gratuita. Antes de la versión 8.0.0, una vulnerabilidad de inyección SQL en el módulo de Inmunización permite a cualquier usuario autenticado ejecutar consultas SQL arbitrarias, lo que lleva a la completa compromiso de la base de datos, exfiltración de PHI, robo de credenciales y potencial ejecución remota de código. La vulnerabilidad existe porque los valores de 'patient_id' proporcionados por el usuario se concatenan directamente en las cláusulas SQL WHERE sin parametrización ni escape. La versión 8.0.0 corrige el problema.

Kruise proporciona gestión automatizada de aplicaciones a gran escala en Kubernetes. Antes de las versiones 1.8.3 y 1.7.5, PodProbeMarker permite definir sondas personalizadas con manejadores TCPSocket o HTTPGet. La validación del webhook no restringe el campo Host en estas configuraciones de sonda. Dado que kruise-daemon se ejecuta con hostNetwork=true, ejecuta sondas desde el espacio de nombres de red del nodo. Un atacante con permiso de creación de PodProbeMarker puede especificar valores de Host arbitrarios para activar SSRF desde el nodo, realizar escaneo de puertos y recibir retroalimentación de la respuesta a través de mensajes de estado de NodePodProbe. Las versiones 1.8.3 y 1.7.5 parchean el problema.

Se ha encontrado una falla en Chia Blockchain 2.1.0. El elemento afectado es la función send_transaction/get_private_key del componente RPC Servidor Master Passphrase Gestor. Esta manipulación causa autenticación faltante. El ataque solo puede ejecutarse localmente. La complejidad del ataque se califica como alta. La explotabilidad se describe como difícil. El exploit se ha publicado y puede usarse. El proveedor fue informado tempranamente por correo electrónico. Un informe separado a través de bugbounty fue rechazado con la razón 'Esto es por diseño. El usuario es responsable de la seguridad del host'.

LangChain es un framework para construir aplicaciones impulsadas por LLM. Antes de la versión 1.1.8, existe una omisión de falsificación de petición del lado del servidor (SSRF) basada en redirección en `RecursiveUrlLoader` en `@langchain/community`. El cargador valida la URL inicial, pero permite que la recuperación subyacente siga las redirecciones automáticamente, lo que permite una transición de una URL pública segura a un endpoint interno o de metadatos sin revalidación. Esto es una omisión de las protecciones de SSRF introducidas en 1.1.14 (CVE-2026-26019). Los usuarios deben actualizar a `@langchain/community` 1.1.18, que valida cada salto de redirección deshabilitando las redirecciones automáticas y revalidando los objetivos de `Location` antes de seguirlos. En esta versión, las redirecciones automáticas están deshabilitadas (`redirect: 'manual'`), cada `Location` 3xx se resuelve y valida con `validateSafeUrl()` antes de la siguiente petición, y un límite máximo de redirecciones evita bucles infinitos.

Debido a una regla de cortafuegos mal configurada, el router aceptará cualquier conexión en el puerto WAN con el puerto de origen 5222, exponiendo todos los servicios que normalmente solo son accesibles a través de la red local.<br /> Este problema afecta a MR9600: 1.0.4.205530; MX4200: 1.0.13.210200.

Las versiones de OpenSIPS 3.1 anteriores a la 3.6.4 que contienen el módulo auth_jwt (anterior al commit 3822d33) contienen una vulnerabilidad de inyección SQL en la función jwt_db_authorize() en modules/auth_jwt/authorize.c cuando db_mode está habilitado y se utiliza un backend de base de datos SQL. La función extrae la tag claim de un JWT sin verificación de firma previa e incorpora el valor sin escapar directamente en una consulta SQL. Un atacante puede proporcionar un JWT manipulado con una tag claim maliciosa para manipular el resultado de la consulta y eludir la autenticación JWT, permitiendo la suplantación de identidades arbitrarias.

Angular SSR es una herramienta de renderizado del lado del servidor para aplicaciones Angular. Las versiones anteriores a 21.2.0-rc.1, 21.1.5, 20.3.17 y 19.2.21 tienen una vulnerabilidad de falsificación de petición del lado del servidor (SSRF) en la cadena de manejo de peticiones de Angular SSR. La vulnerabilidad existe porque la lógica interna de reconstrucción de URL de Angular confía y consume directamente los encabezados HTTP controlados por el usuario, específicamente los de la familia Host y &amp;#39;X-Forwarded-*&amp;#39;, para determinar el origen base de la aplicación sin ninguna validación del dominio de destino. Específicamente, el framework no tenía comprobaciones para el dominio del host, la sanitización de rutas y caracteres, y la validación del puerto. Esta vulnerabilidad se manifiesta de dos formas principales: resolución implícita de URL relativas y construcción manual explícita. Cuando se explota con éxito, esta vulnerabilidad permite la dirección arbitraria de peticiones internas. Esto puede llevar a la exfiltración de credenciales, el sondeo de redes internas y una violación de la confidencialidad. Para ser vulnerable, la aplicación víctima debe usar Angular SSR (Server-Side Rendering), la aplicación debe realizar peticiones &amp;#39;HttpClient&amp;#39; usando URL relativas O construir URL manualmente usando los encabezados &amp;#39;Host&amp;#39; / &amp;#39;X-Forwarded-*&amp;#39; no validados usando el objeto &amp;#39;REQUEST&amp;#39;, el servidor de aplicaciones debe ser accesible por un atacante que pueda influir en estos encabezados sin una validación estricta de un proxy frontal, y la infraestructura (Nube, CDN o Balanceador de Carga) no debe sanitizar o validar los encabezados entrantes. Las versiones 21.2.0-rc.1, 21.1.5, 20.3.17 y 19.2.21 contienen un parche. Algunas soluciones alternativas están disponibles. Evite usar &amp;#39;req.headers&amp;#39; para la construcción de URL. En su lugar, use variables de confianza para las rutas base de la API. Aquellos que no puedan actualizar inmediatamente deben implementar un middleware en su &amp;#39;server.ts&amp;#39; para exigir puertos numéricos y nombres de host validados.

LangGraph Checkpoint define la interfaz base para los gestores de puntos de control de LangGraph. Antes de la versión 4.0.0, existe una vulnerabilidad de ejecución remota de código en la capa de caché de LangGraph cuando las aplicaciones habilitan *backends* de caché que heredan de `BaseCache` y habilitan nodos para el almacenamiento en caché a través de `CachePolicy`. Antes de `langgraph-checkpoint` 4.0.0, `BaseCache` por defecto utiliza `JsonPlusSerializer(pickle_fallback=True)`. Cuando la serialización de msgpack falla, los valores almacenados en caché pueden ser deserializados a través de `pickle.loads(...)`. El almacenamiento en caché no está habilitado por defecto. Las aplicaciones se ven afectadas solo cuando la aplicación habilita explícitamente un *backend* de caché (por ejemplo, pasando `cache=...` a `StateGraph.compile(...)` o configurando de otra manera una implementación de `BaseCache`), uno o más nodos habilitan el almacenamiento en caché a través de `CachePolicy`, y el atacante puede escribir en el *backend* de caché (por ejemplo, una instancia de Redis accesible por red con autenticación débil/nula, infraestructura de caché compartida accesible por otros inquilinos/servicios, o un archivo de caché SQLite escribible). Un atacante debe poder escribir bytes controlados por el atacante en el *backend* de caché de modo que el proceso de LangGraph los lea y deserialice posteriormente. Esto normalmente requiere acceso de escritura a una caché en red (por ejemplo, una instancia de Redis accesible por red con autenticación débil/nula o infraestructura de caché compartida accesible por otros inquilinos/servicios) o acceso de escritura al almacenamiento de caché local (por ejemplo, un archivo de caché SQLite escribible a través de permisos de archivo permisivos o un volumen compartido escribible). Debido a que la explotación requiere acceso de escritura a la capa de almacenamiento de caché, este es un vector de escalada post-compromiso / post-acceso. LangGraph Checkpoint 4.0.0 corrige el problema.