tag

Docker

2 artículos con esta etiqueta

2026-10-24

Claves de CA intermedias de eMudhra (emSign) comprometidas: qué deben hacer los usuarios de Python con pip, certifi y uv

El 17 de octubre de 2026, un informe mostró que las claves privadas de ocho certificados intermedios de la autoridad de certificación india eMudhra (seis para TLS) se habían generado tan mal que cualquiera podía recuperarlas. eMudhra revocó los ocho el 18 de octubre, y Chrome y Firefox los bloquearon el 17 de octubre mediante sus mecanismos de envío. El 20 de octubre Mozilla decidió una retirada de confianza de emergencia de la raíz superior, emSign ECC Root CA - G3, y Chrome la eliminará el 27 de octubre (hora del Pacífico). Los navegadores están protegidos, pero los clientes TLS fuera del navegador pueden confiar en certificados falsificados hasta que actualicen su propia copia de la lista de CA. En Python, pip siempre carga su certifi incluido, por lo que un pip antiguo sigue expuesto aunque el almacén del sistema operativo se corrija. Los proyectos de Python publicaron un aviso el 20 de octubre (actualizado hasta el 22 de octubre) pidiendo actualizar a certifi 2026.10.19 como mínimo, pip 26.2.2, uv 0.13.4, sigstore 4.5.1, conda 26.9.4 y pixi 0.82.1, y reconstruir las imágenes de contenedor sin la caché de capas. El 21 de octubre publicaron Python 3.15.1, 3.14.9 y 3.13.17 con pip 26.2.2 incluido. No habrá una versión 3.11 ni 3.12 con un pip más nuevo. No se trata de un fallo de ejecución de código en CPython: un atacante en la ruta de red podría redirigir las conexiones a PyPI, python.org y otros sitios a un servidor falso. No se había anunciado ninguna explotación al 24 de octubre. El 22 de octubre eMudhra anunció que abandonará el negocio global de certificados SSL/TLS. La opinión de este sitio: actualice pip a 26.2.2 o posterior y certifi a 2026.10.19 o posterior en todos los entornos, reconstruya las imágenes de Docker sin caché y eleve cualquier fijación de certifi en los lockfiles.

2026-06-07

Ejecutar Next.js de forma segura: no quedarse atrás con los CVE publicados

El mayor riesgo del framework son los CVE publicados descuidados. Defiende con cuatro prácticas: juzgar por la versión en ejecución, monitorear con Dependabot/osv-scanner, actualizar rápido, y operar con mínimo privilegio. La visión de este sitio: lo que suele faltar a los desarrolladores indie no es conocimiento sino una forma de mantener la operación; un sistema que no pase por alto los CVE importa más que la velocidad.