Vulnerabilidades

Loona es una implementación experimental de HTTP/1.1 y HTTP/2 en Rust basada en io-uring. `loona-hpack` sufre la misma vulnerabilidad que el `hpack` original, como se documenta en el problema n.° 11. Todos los usuarios que intenten decodificar entradas no confiables utilizando el decodificador son vulnerables a esta vulnerabilidad. Este problema se ha solucionado en la versión de lanzamiento 0.4.3. Se recomienda a todos los usuarios que actualicen. No se conocen workarounds para esta vulnerabilidad.

Zope AccessControl proporciona un marco de seguridad general para su uso en Zope. En las versiones afectadas, los usuarios anónimos pueden eliminar los datos de usuario que se mantienen en un `AccessControl.userfolder.UserFolder`, lo que puede impedir cualquier acceso privilegiado. Este problema se ha solucionado en la versión 7.2. Se recomienda a los usuarios que actualicen la versión. Los usuarios que no puedan actualizar la versión pueden solucionar el problema añadiendo `data__roles__ = ()` a `AccessControl.userfolder.UserFolder`.

El firmware Meshtastic es un firmware de dispositivo para el proyecto Meshtastic. El firmware Meshtastic no comprueba los paquetes que dicen provenir de la dirección de difusión especial (0xFFFFFFFF), lo que podría generar un comportamiento inesperado y la posibilidad de ataques DDoS en la red. Un actor malintencionado podría crear un paquete que diga que proviene de esa dirección, lo que daría como resultado una amplificación de este mensaje en cada nodo de la red que envíe múltiples mensajes. Un ataque de este tipo podría provocar una degradación del rendimiento de la red para todos los usuarios, ya que se consume el ancho de banda disponible. Este problema se ha solucionado en la versión 2.5.6. Se recomienda a todos los usuarios que actualicen. No existen workarounds conocidas para esta vulnerabilidad.

localai <=2.20.1 es vulnerable a ataques de cross site scripting (XSS). Al llamar a la API de eliminación de modelo y pasar parámetros inadecuados, puede provocar un ataque XSS de almacenamiento único, que activará el payload cuando un usuario acceda a la página de inicio.

En agentscope <=v0.0.4, el archivo agentscope\web\workstation\workflow_utils.py tiene la función is_callable_expression. Dentro de esta función, la línea result = eval(s) plantea un riesgo de seguridad, ya que puede ejecutar directamente comandos proporcionados por el usuario.

Refit es una librería REST automática y segura de tipos para .NET Core, Xamarin y .NET Los diversos atributos Refit relacionados con los encabezados (Header, HeaderCollection y Authorize) son vulnerables a la inyección CRLF. La forma en que se agregan los encabezados HTTP a una solicitud es a través del método `HttpHeaders.TryAddWithoutValidation`. Este método no verifica los caracteres CRLF en el valor del encabezado. Esto significa que cualquier encabezado agregado a una solicitud de refit es vulnerable a la inyección CRLF. En general, la inyección CRLF en un encabezado HTTP (cuando se usa HTTP/1.1) significa que uno puede inyectar encabezados HTTP adicionales o contrabandear solicitudes HTTP completas. Si una aplicación que usa la librería Refit pasa un valor controlable por el usuario a un encabezado, entonces esa aplicación se vuelve vulnerable a la inyección CRLF. Esto no es necesariamente un problema de seguridad para una aplicación de línea de comandos como la que se muestra arriba, pero si dicho código estuviera presente en una aplicación web, se volvería vulnerable a la división de solicitudes (como se muestra en la PoC) y, por lo tanto, a la Server Side Request Forgery. Estrictamente hablando, esta es una vulnerabilidad potencial en aplicaciones que usan Refit y no en Refit en sí. Este problema se ha solucionado en la versión 8.0.0 y se recomienda a todos los usuarios que actualicen. No existen workarounds conocidas para esta vulnerabilidad.

langflow <=1.0.18 es vulnerable a la ejecución remota de código (RCE), ya que cualquier componente proporciona la funcionalidad del código y los componentes se ejecutan en la máquina local en lugar de en un entorno aislado.

En gradio <=4.42.0, la función gr.DownloadButton tiene una vulnerabilidad oculta de server-side request forgery (SSRF). La razón es que dentro de la función save_url_to_cache no hay restricciones en la URL, lo que permite el acceso a recursos de destino locales. Esto puede provocar la descarga de recursos locales e información confidencial.

El proyecto gaizhenbiao/chuanhuchatgpt, versión <=20240802 es vulnerable a cross site scripting (XSS) almacenado en la transmisión de sesiones WebSocket. Un atacante puede inyectar contenido malicioso en un mensaje WebSocket. Cuando una víctima accede a esta sesión, el código JavaScript malicioso se ejecuta en el navegador de la víctima.

Se ha encontrado una vulnerabilidad en el University Event Management System 1.0. Se ha clasificado como crítica. Afecta a una parte desconocida del archivo doedit.php. La manipulación del argumento id provoca una inyección SQL. Es posible iniciar el ataque de forma remota. El exploit se ha hecho público y puede utilizarse. El aviso inicial para investigadores menciona que el nombre del producto afectado puede resultar confuso. También podrían verse afectados otros parámetros.

golang-jwt es una implementación de Go de tokens web JSON. La documentación poco clara del comportamiento de los errores en `ParseWithClaims` puede llevar a una situación en la que los usuarios potencialmente no estén verificando los errores como deberían. Especialmente, si un token está vencido y no es válido, los errores devueltos por `ParseWithClaims` devuelven ambos códigos de error. Si los usuarios solo verifican `jwt.ErrTokenExpired` usando `error.Is`, ignorarán el `jwt.ErrTokenSignatureInvalid` incorporado y, por lo tanto, potencialmente aceptarán tokens no válidos. Se ha incorporado una solución con la lógica de manejo de errores de la rama `v5` a la rama `v4`. En esta lógica, la función `ParseWithClaims` regresará inmediatamente en situaciones "peligrosas" (por ejemplo, una firma no válida), lo que limita los errores combinados solo a situaciones en las que la firma es válida, pero la validación posterior falló (por ejemplo, si la firma es válida, pero está vencida Y tiene la audiencia incorrecta). Esta corrección forma parte de la versión 4.5.1. Somos conscientes de que esto cambia el comportamiento de una función establecida y no es 100 % compatible con versiones anteriores, por lo que actualizar a la versión 4.5.1 podría dañar el código. En caso de que no pueda actualizar a la versión 4.5.0, asegúrese de comprobar correctamente todos los errores (primero los "peligrosos"), para que no se encuentre en el caso detallado anteriormente.

Bruno anterior a 1.29.1 usa Electron shell.openExternal sin validación (de http o https) para abrir ventanas dentro del visor de documentos Markdown.