Resultados para “caché”
30 resultado(s)
SSRF en Lichess: el parámetro players de la exportación de partidas hacía que el servidor pidiera cualquier URL
Los endpoints públicos de exportación de partidas de Lichess pasaban el parámetro players, sin validar, al cliente HTTP del servidor. Cualquiera, sin autenticarse, podía hacer que Lichess lanzase peticiones GET a la URL que quisiera.
3 min
curl con HTTP/3 (ngtcp2) enviaba la petición en early data antes de verificar el certificado del servidor
Al reanudar una sesión TLS con early data, el backend ngtcp2 de curl daba la conexión por establecida y mandaba cabeceras y cuerpo de la petición antes de comprobar el certificado. Un atacante en medio podía leerlos.
5 min
CVE-2026-8932: curl reutilizaba conexiones mTLS entre handles con distinta clave privada o contraseña de clave
curl solo comparaba parte de la configuración TLS al reutilizar conexiones: dos handles que compartían pool y diferían solo en la clave privada, su contraseña o su tipo usaban la misma conexión mTLS y la misma identidad.
8 min
Django: la caché de páginas confunde una cabecera ausente con una vacía y puede servir la respuesta equivocada con Vary
El middleware de caché de Django generaba la misma clave para una petición sin la cabecera indicada en Vary y para otra con esa cabecera vacía, de modo que una respuesta privada podía servirse a quien no debía.
3 min
curl con OpenSSL: la caché de CApath provoca un use-after-free que un servidor malicioso puede disparar
Desde curl 8.23.0, los certificados de CApath quedan en la caché del multi handle tras liberarse su contexto de OpenSSL. Un servidor con un certificado falso puede hacer que el cliente lea esa memoria liberada y se caiga.
7 min
CVE-2026-111480: use-after-free y doble free en libcurl al reanudar una transferencia desde un callback
Llamar a curl_easy_pause() desde un callback mientras libcurl reenvía datos en búfer libera memoria que el bucle exterior sigue usando. La aplicación se cae, pero un servidor remoto no puede provocarlo por sí solo.
5 min
curl reutiliza en HTTPS sesiones TLS creadas para FTPS, lo que permite sustituir una respuesta verificada
La caché de sesiones TLS de curl 8.12.0 a 8.23.0 no distingue el esquema de la URL. Un atacante en la red, con varias condiciones a favor, puede hacer pasar un fichero FTPS por una respuesta HTTPS válida sin romper la verificación del certificado.
7 min
Weblate: el filtro de metadatos VCS del ZIP de descarga olvidaba .svn y .bzr tras el parche de CVE-2026-61792
El parche de CVE-2026-61792 en Weblate quitaba .git y .hg de los ZIP de descarga, pero no .svn ni .bzr. Si un componente los contenía, su contenido (incluido wc.db) salía en el ZIP.
6 min
Vercel Live: un colaborador revocado recuperaba el acceso a los comentarios privados cuando otro colaborador comentaba
En Vercel Live, el token de un colaborador ya expulsado volvía a ser aceptado en cuanto un colaborador activo usaba la barra de comentarios, y con él se podían descargar los hilos privados del despliegue.
5 min
Omise: la CDN de www.omise.co guardaba una copia distinta de cada página por cada parámetro GET inventado
La CDN de www.omise.co usaba la URL completa como clave de caché, sin descartar parámetros desconocidos. Con ?test=123, ?abc=456… cualquiera podía llenar la caché de copias idénticas de una misma página.
3 min
curl con Schannel conserva la identidad del certificado de cliente tras una redirección gracias a la reanudación de sesión TLS
En curl 8.23.0 con Schannel, la reanudación de sesión TLS mantenía la identidad mTLS del cliente al seguir una redirección a otro origen. El investigador lo presenta como un arreglo incompleto de CVE-2026-86415.
3 min
curl reutilizaba entre orígenes distintos una conexión autenticada con Negotiate (CVE-2026-87861)
Un cambio en los comparadores de reutilización de conexiones de libcurl permitía que una petición para un host saliera por una conexión ya autenticada con Negotiate para otro host detrás del mismo proxy.
4 min