Para quién es esto: cualquiera que instale paquetes con pip, uv, conda o pixi, cualquiera que ejecute programas que hacen llamadas HTTPS con bibliotecas como requests, y cualquiera que mantenga imágenes Docker de Python o CI.
Este artículo se basa en declaraciones oficiales de los proyectos de Python (desarrolladores de CPython y pip), de los proyectos certifi, uv y conda, de Mozilla, Google, eMudhra y las distribuciones de Linux. No explica cómo atacar nada ni cómo se recuperaron las claves. Las redes sociales han llamado a esto una «emergencia de seguridad de Python», pero no se ha encontrado ningún fallo de ejecución de código en el propio Python.
続報待ち：この記事は公式発表に合わせて更新します
24 de octubre de 2026 (JST)まだ分かっていないこと
- Si el módulo ssl de CPython rechazará las claves intermedias comprometidas (el cambio está en revisión y aún no se ha fusionado)
- Cómo gestionarán Python 3.11 y 3.12, y sus imágenes oficiales de Docker, el pip antiguo (los responsables de las versiones planean trasladar al backport el cambio del módulo ssl que bloquea los intermedios comprometidos en lugar de actualizar pip; no fusionado al 24 de octubre)
- El informe final de causa raíz de eMudhra
- La eliminación de la raíz en Chrome, prevista para el 27 de octubre (hora del Pacífico)
Los proyectos de Python publicaron su aviso el 20 de octubre y lanzaron Python 3.15.1, 3.14.9 y 3.13.17 el 21 de octubre. Chrome y Firefox bloquearon los intermedios afectados el 17 de octubre. No se ha anunciado ninguna explotación. Añadiremos las decisiones sobre 3.11 y 3.12 y cualquier otro cambio de CPython cuando se confirmen.
¿Estoy afectado? Una tabla rápida por entorno
Que esté afectado depende de qué parte de su configuración de Python contenga una lista de CA. Una misma máquina puede tener listas separadas para cada versión de Python, cada forma de instalación de Python y cada entorno virtual.
| Entorno | Qué contiene la lista antigua | Qué hacer |
|---|---|---|
| Cualquier entorno que use pip | El certifi incluido en pip (sobrevive a una corrección del sistema operativo) | Actualizar pip a 26.2.2+ |
| Programas configurados para usar el certifi independiente, como requests | El paquete certifi independiente | Actualizar certifi a 2026.10.19+ |
| Entornos que usan uv | La lista de CA integrada en uv | Actualizar uv a 0.13.4+ |
| conda, Mamba, pixi | Cada herramienta más los paquetes certifi y ca-certificates | Actualizar a conda 26.9.4+ y pixi 0.82.1+, y actualizar certifi y ca-certificates en el entorno |
| Python del instalador de macOS de python.org | El certifi incluido en el instalador | Siga la publicación oficial para actualizar pip y certifi; en 3.13+ cambie al Python corregido |
| Imágenes Docker y CI | Cualquier pip, certifi y paquete de SO que existiera en el momento de la compilación | Reconstruir sin caché |
| pip o certifi instalados desde paquetes de Linux (apt, dnf) | El ca-certificates del sistema operativo (Debian parchea pip para usarlo) | Actualizar ca-certificates a la versión corregida |
Cuando se usa urllib3 directamente, el valor predeterminado es el almacén de CA del sistema. Actualice ese almacén; si su configuración usa explícitamente certifi u otro paquete, actualice también ese paquete (guía de verificación de certificados de urllib3).
Qué ocurrió (según las declaraciones oficiales)
- Informe
- El 17 de octubre de 2026, un investigador de seguridad informó a los programas raíz de Apple, Google, Microsoft y Mozilla, y a eMudhra, de que las claves privadas de ocho certificados intermedios de eMudhra podían recuperarse
- Alcance
- Ocho intermedios. Seis son para TLS (HTTPS) y fueron confiados por Chrome, Mozilla, Microsoft y Apple; dos son para firma de código. Todos se crearon en una ceremonia de generación de claves el 30 de abril de 2025. Los seis intermedios TLS se encadenan a la raíz emSign ECC Root CA - G3 (los dos de firma de código están bajo una raíz diferente)
- Causa
- Google afirma que las claves privadas se generaron con aleatoriedad insuficiente. Mozilla afirma que recuperó las claves de forma independiente y confirmó que la generación de claves era defectuosa. eMudhra afirma que un paso de la ceremonia produjo un segundo conjunto de claves débiles junto a las fuertes, y que se usaron las débiles. La causa raíz completa sigue bajo investigación
- Lo que permiten las claves
- Mozilla afirma que las claves podrían usarse para emitir certificados HTTPS fraudulentos para sitios que el titular no controla. Un atacante que pueda interceptar la conexión de un usuario podría usarlas para suplantar sitios web y, potencialmente, leer o modificar el tráfico
- Respuesta de eMudhra
- Revocó los ocho el 18 de octubre. Afirma que siete nunca se usaron en producción y que el que sí se usó no había emitido ningún certificado. Detuvo la emisión bajo esta raíz el 20 de octubre y, el 22 de octubre, anunció que abandonará el negocio global de certificados SSL/TLS
- Navegadores
- Chrome bloqueó las claves mediante CRLSet el 17 de octubre. Firefox las bloqueó el mismo día mediante OneCRL y publicó Firefox 158.0.1 y actualizaciones ESR el 20 de octubre. El 20 de octubre Mozilla decidió una retirada de emergencia de la raíz y la eliminó de NSS 3.131.1. Chrome la eliminará el 27 de octubre (hora del Pacífico)
- 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 con la caché de capas desactivada. El 21 de octubre publicaron Python 3.15.1, 3.14.9 y 3.13.17, que incluyen pip 26.2.2
certifi es el paquete de Python muy usado que contiene una lista de autoridades de certificación de confianza. Se deriva de la lista de Mozilla, y requests y pip lo usan para decidir si el certificado de un servidor es auténtico. certifi 2026.10.18 (publicado el 18 de octubre, UTC) eliminó todas las raíces de emSign, y 2026.10.19 (publicado el 20 de octubre, UTC) restauró las raíces de emSign no afectadas. El aviso propio de certifi indica 2026.10.18 como corregida, pero la entrada de la GitHub Advisory Database y los proyectos de Python recomiendan 2026.10.19 o posterior por compatibilidad con las raíces de emSign no afectadas. Después, certifi 2026.10.23 eliminó dos raíces de emSign más para seguir a Mozilla (eMudhra afirma que esa eliminación estaba planeada antes y no está relacionada con este incidente).
¿Qué tan grave es?
Chrome, Firefox
Bloqueados el 17 de octubre. También rechazan certificados que faltan en los registros CT públicos
pip anterior a 26.2.2
Siempre lee su certifi incluido, incluso tras una corrección del sistema operativo
requests y otros clientes basados en certifi
Usan certifi independiente anterior a 2026.10.19
uv anterior a 0.13.4, imágenes Docker
Conservan la lista de la fecha de compilación
Los navegadores están protegidos por dos mecanismos: reciben bloqueos de certificados automáticamente y rechazan certificados que no figuran en los registros públicos de Certificate Transparency (CT). Google afirma que no se registraron en CT certificados TLS encadenados a los intermedios afectados antes de su bloqueo, por lo que no pudo usarse ningún certificado falso contra clientes que exigen CT.
pip y requests no usan ninguno de estos mecanismos. Solo se guían por la lista de CA que llevan, así que si esa lista es antigua, aceptan un certificado falso como auténtico.
Qué podría pasar
- Un atacante en la ruta de red redirige las conexiones a PyPI, python.org y otros sitios a un servidor falso
- pip install instala un paquete manipulado
- Se leen claves de API o contraseñas enviadas con requests
Qué necesita un atacante y qué sabemos
- El atacante debe poder situarse en su ruta de red (la misma Wi-Fi, un router comprometido, un proxy corporativo, etc.)
- No hay fallo de ejecución de código en el propio Python
- No se había anunciado ninguna explotación al 24 de octubre
No se confíe. Mozilla dijo el 20 de octubre que varias personas habían recuperado las claves de forma independiente y algunas lo habían revelado públicamente, por lo que fabricar un certificado falso no es difícil. Evite ejecutar un pip antiguo en cualquier lugar donde alguien pueda acceder a la ruta, como redes Wi-Fi públicas, redes compartidas o la red alrededor de un ejecutor de CI. Nuestra guía sobre riesgos de las redes Wi-Fi públicas cubre ese aspecto.
Primero, compruebe sus versiones
Compruebe la versión de pip
Ejecute esto con el Python que quiere comprobar (dentro del entorno virtual, si usa uno). La versión 26.2.2 o posterior está corregida.
python -m pip --versionEjecutar pip por sí solo puede apuntar al pip de otro Python. Use python -m pip para saber qué Python está comprobando.
Compruebe la versión de certifi
Esto muestra el certifi independiente que usan requests y bibliotecas similares. La versión 2026.10.19 o posterior está corregida. Si no está instalado, pip muestra una advertencia de «not found».
python -m pip show certifiEl certifi incluido en pip es una copia separada. Ejecute python -m pip debug y busque la línea certifi== en «vendored library versions». Tras actualizar a pip 26.2.2, indicará 2026.10.19.
Compruebe uv y conda
Ejecute uv --version (0.13.4+ está corregido), conda --version (26.9.4+) y pixi --version (0.82.1+).
Enumere todos los lugares donde está instalado Python
En una misma máquina suele haber el Python del sistema operativo, un Python de python.org, Pythons de Homebrew o pyenv, y entornos virtuales por proyecto (como .venv). Un entorno virtual es cualquier directorio con un archivo pyvenv.cfg. Anotar primero la lista completa hace mucho más difícil pasar por alto alguno.
Actualizar en un orden seguro
El orden importa. Un pip antiguo confía en los certificados afectados, así que si simplemente descarga un pip nuevo y esa descarga se intercepta, podría instalarse un pip falso. Los proyectos de Python recomiendan instalar pip con un hash de archivo fijado (una huella del contenido del archivo) y usar ese pip para todo lo demás.
Actualice pip a 26.2.2 con un hash fijado
La publicación oficial y el blog de Python ofrecen un comando con la URL del archivo de pip 26.2.2 y su hash SHA-256. Tiene esta forma. Copie la URL y el hash exactamente desde la publicación oficial (deliberadamente no los reproducimos aquí).
python -m pip install "pip @ <URL de la publicación oficial>#sha256=<hash de la publicación oficial>"Con un hash fijado, pip se niega a instalar un archivo cuyo contenido sea diferente, así que una descarga interceptada no puede instalar un pip falso. La publicación oficial indica que los navegadores ya deberían haber actualizado sus almacenes y pueden usarse para comprobarlo. Por ejemplo, abra la página de archivos de pip 26.2.2 en PyPI y confirme que el hash mostrado coincide.
Use el nuevo pip para actualizar certifi y uv
Una vez que pip sea 26.2.2, úselo para actualizar certifi. Si instaló uv con pip, actualícelo también aquí.
python -m pip install --upgrade certifi
python -m pip install --upgrade uvSi instaló uv con su instalador independiente, siga el aviso de uv y pase a 0.13.4 o posterior. El aviso indica que, si cambia uv para usar los certificados del sistema, debe confirmar que el sistema operativo ya eliminó la raíz o los intermedios afectados.
Repita en cada entorno virtual
pip y certifi viven dentro de cada entorno virtual. Los proyectos de Python piden actualizar pip y uv en todos los entornos virtuales existentes del sistema. En los entornos antiguos que ya no use, recrearlos o eliminarlos puede ser más rápido.
Pase de 3.13 a 3.15 a las versiones corregidas; en 3.11 y 3.12, actualice pip en cada venv nuevo
Python 3.15.1, 3.14.9 y 3.13.17 incluyen pip 26.2.2, así que los nuevos entornos creados con python -m venv también obtienen el pip corregido.
Los proyectos de Python dicen que no habrá una versión 3.11 ni 3.12 que incluya un pip más nuevo, por riesgo de compatibilidad. Actualice pip lo primero cada vez que cree un entorno virtual. pip 26.2.2 es compatible con Python 3.10 y posteriores. En 3.9 y anteriores no está disponible el pip corregido, así que actualice el propio Python (3.10 también ha llegado al fin de su vida útil).
Para el Python de macOS de python.org, actualice con ese intérprete
El Python del instalador de macOS de python.org incluye certifi. El blog enumera comandos para 3.13, 3.14 y 3.15 (la publicación oficial muestra 3.15 como ejemplo) que llaman directamente a ese intérprete, por ejemplo /Library/Frameworks/Python.framework/Versions/3.15/bin/python3.15, para actualizar pip y certifi. Actualice la compilación de subprocesos libres (como python3.15t) por separado. Si pip install --upgrade certifi falla con el certifi del instalador, la publicación oficial sugiere reinstalarlo con --ignore-installed --no-deps certifi.
Docker, CI y lockfiles
Aquí es donde más a menudo se pasan por alto las correcciones. Arreglar su portátil no sirve de nada para las imágenes y los ejecutores de CI, que conservan la lista antigua de la fecha de compilación.
Reconstruya las imágenes de Docker sin caché
Los proyectos de Python le piden reconstruir las imágenes de contenedor con la caché de capas desactivada para obtener los certificados más recientes del sistema operativo. Vuelva a descargar también la imagen base, por ejemplo con docker build --pull --no-cache. Tras reconstruir, ejecute python -m pip --version dentro del contenedor para confirmarlo.
El 21 de octubre, las imágenes oficiales de Docker actualizaron sus definiciones 3.13 y posteriores a las versiones corregidas de Python (3.15.1, 3.14.9 y 3.13.17). Los responsables de las imágenes dicen que no actualizarán pip en las etiquetas 3.11 y 3.12 a menos que Python publique nuevas versiones. Si usa imágenes 3.11 o 3.12, actualice pip a 26.2.2 en su Dockerfile con un hash fijado.
Eleve las fijaciones de certifi en requirements y lockfiles
Una fijación como certifi==2025.x.x en requirements.txt o constraints.txt devuelve directamente el certifi antiguo. Lo mismo ocurre con uv.lock, poetry.lock, pylock.toml y Pipfile.lock. Suba certifi a 2026.10.19 o posterior, regenere el lockfile y despliéguelo en sus imágenes y en CI.
Excluya certifi y pip de los periodos de enfriamiento de dependencias
Si usa una configuración que espera un periodo fijo antes de aceptar versiones recién publicadas (un enfriamiento de dependencias), la corrección no llegará hasta que termine ese periodo. Un responsable de empaquetado de Python advirtió que los usuarios con enfriamiento siguen expuestos hasta que actualizan. Excluya certifi, pip y uv de esa configuración.
Actualice las acciones y herramientas que usa su CI
La acción de GitHub pypa/gh-action-pypi-publish, usada para publicar en PyPI, tiene una versión corregida, v1.14.3. Para cibuildwheel, actualice a v4.3.4 o posterior (v4.3.3 trajo la corrección; v4.3.4 también cubre pip en Python 3.9 y otros destinos). Compruebe que su configuración de CI no fije versiones anteriores.
Atención a las copias firmadas cruzadamente por otra CA
Algunos de los intermedios afectados también tenían copias firmadas cruzadamente por otra autoridad de certificación. La firma cruzada permite que la misma clave intermedia se confíe bajo una raíz diferente. Un desarrollador principal de CPython dice que la raíz usada para esa firma cruzada está presente en las versiones de certifi anteriores a abril de 2025 y en versiones antiguas de pip que las incluyen (por ejemplo, pip 25.0.1 con certifi 2024.8.30). Según la CA de firma cruzada, esa raíz ya se había eliminado de los almacenes de Chrome y Mozilla, pero Microsoft y Apple seguían confiando en ella a 18 de octubre (registro de Mozilla). Debian, y Ubuntu 14.04 a 20.04 (USN-8944-2), también eliminaron esa raíz de firma cruzada junto con la raíz de emSign. La CA de firma cruzada afirma que revocó las copias firmadas cruzadamente el 19 de octubre, pero la mayoría de los clientes fuera del navegador no comprueban la revocación. Eliminar solo la raíz de emSign de un paquete antiguo no basta, porque la raíz de firma cruzada permanecería. Pase a certifi 2026.10.19 o posterior (las versiones de certifi desde abril de 2025 ya no contienen la raíz de firma cruzada).
Actualice los certificados del sistema operativo (ca-certificates)
En Linux, el paquete ca-certificates contiene la lista de CA del sistema. curl y los Python instalados desde paquetes del sistema operativo la usan.
| Distribución | Aviso oficial | Versión corregida |
|---|---|---|
| Debian 13 (trixie) | DSA-6572-1 (20 de octubre) | ca-certificates 20250419+deb13u1 |
| Debian 12 (bookworm) | DLA-4845-1 | ca-certificates 20250419~deb12u2 |
| Ubuntu 26.10, 26.04, 24.04, 22.04 | USN-8944-1 (20 de octubre) | ca-certificates 20260816ubuntu0.(release) |
| Ubuntu 20.04, 18.04, 16.04, 14.04 | USN-8944-2 (20 de octubre) | Disponible mediante Ubuntu Pro (ESM) |
La corrección de Debian elimina emSign ECC Root CA - G3 y la raíz de firma cruzada. El USN-8944-1 de Ubuntu elimina emSign ECC Root CA - G3 y, en 22.04 a 26.04, actualiza la lista a la versión 2.90 del paquete de Mozilla; el USN-8944-2 elimina ambas raíces en 14.04 a 20.04. pip instalado desde el paquete propio de Debian (python3-pip) está parcheado para leer la lista del sistema en lugar de certifi incluido, por lo que actualizar ca-certificates lo soluciona. En Windows y macOS, instale las actualizaciones del sistema operativo.
Cómo confirmar que ha terminado
Compruebe tres versiones en todas partes
En su equipo, en cada entorno virtual, dentro de cada imagen de Docker y en CI, confirme pip 26.2.2+, certifi 2026.10.19+ y uv 0.13.4+. Si queda aunque sea una copia antigua, no ha terminado.
Confirme que la raíz afectada ya no está en la lista de certifi
python -m certifi muestra la ruta del archivo de paquete de certifi. Si el nombre «emSign ECC Root CA - G3» ya no aparece en él, la lista está corregida.
grep -c "emSign ECC Root CA - G3" "$(python -m certifi)"Un resultado de 0 significa que ya no está. Con el certifi empaquetado de Debian o Ubuntu, el archivo no tiene nombres de certificados, así que 0 no demuestra nada; compruebe en su lugar la versión de ca-certificates. La lista incluida en pip está corregida cuando pip es 26.2.2 o posterior.
Revise las fijaciones y el sistema operativo
Busque certifi en sus archivos de requisitos y lockfiles y asegúrese de que no haya nada anterior a 2026.10.19 fijado. En Linux, confirme que ca-certificates está en la versión corregida de la tabla anterior o igual a ella, por ejemplo con apt policy ca-certificates.
La opinión de este sitio: proteger los navegadores no protege todo lo demás
Los usuarios de navegadores quedaron protegidos en cuestión de horas sin hacer nada, porque los navegadores reciben bloqueos automáticamente y rechazan certificados que faltan en los registros CT. pip, requests y las imágenes de CI no tienen ninguno de estos mecanismos. Cada uno mantiene su propia copia de la lista de CA, y el responsable debe actualizar cada copia una por una. Hay tantas copias como entornos virtuales e imágenes.
Un hábito también ayuda ante el siguiente incidente de este tipo: mantenga los hashes de los paquetes en sus requisitos (--require-hashes). Si los hashes están en sus propios archivos, una descarga interceptada no puede sustituir un paquete con contenido distinto. Consulte auditar dependencias con OSV-Scanner para fijar y comprobar dependencias, y el incidente de malware en LiteLLM 1.107.0 para un caso en que se atacó el propio canal de distribución.
Para operadores de sitios web
Chrome dejará de confiar en emSign ECC Root CA - G3 el 27 de octubre (hora del Pacífico). Google pide a los operadores cuyos certificados se encadenan a esta raíz que obtengan de inmediato un nuevo certificado TLS de otra jerarquía (bajo una raíz diferente) en Chrome Root Store. Si usa un certificado de eMudhra, consulte las indicaciones del emisor.
Cronología
30 de abril de 2025
eMudhra crea intermedios, incluidos los ocho afectados, en una ceremonia de generación de claves.17 de octubre de 2026
Un investigador de seguridad informa de que las ocho claves pueden recuperarse. Chrome (CRLSet) y Firefox (OneCRL) las bloquean el mismo día.18 de octubre
eMudhra revoca los ocho intermedios. certifi 2026.10.18 elimina todas las raíces de emSign.19 de octubre
La CA de firma cruzada revoca sus copias firmadas cruzadamente.20 de octubre
Mozilla decide la retirada de emergencia de la raíz. Se publican certifi 2026.10.19, pip 26.2.2 y uv 0.13.4, y los proyectos de Python publican su aviso. Debian y Ubuntu actualizan ca-certificates. Google anuncia que Chrome eliminará la raíz el 27 de octubre.21 de octubre
Se publican Python 3.15.1, 3.14.9 y 3.13.17, y conda 26.9.4. Las imágenes oficiales de Docker actualizan sus definiciones 3.13+ a las versiones corregidas de Python.22 de octubre
eMudhra anuncia que abandonará el negocio global de certificados SSL/TLS.23 de octubre
certifi 2026.10.23 elimina dos raíces de emSign más para seguir a Mozilla.
Fuentes (registro público)
Los hechos de este artículo proceden de las fuentes públicas siguientes. No reproducimos cómo se recuperaron las claves ni nada que pueda usarse para un ataque.
- Proyectos de Python, «Information for Python users regarding eMudhra / emSign CA certificate security incident» (20 de octubre de 2026; publicaciones posteriores revisadas hasta el 24 de octubre) — discuss.python.org
- Python, «Python 3.15.1, 3.14.9 and 3.13.17 are out» (21 de octubre de 2026) — blog.python.org
- Aviso de seguridad de certifi (GHSA-6q48-6c7w-9gw2) — github.com / GitHub Advisory Database github.com
- certifi, «Remove emsign» (#437, 18 de octubre de 2026) — github.com / historial de versiones de certifi pypi.org
- Registro de cambios de pip (26.2.2: actualizar certifi a 2026.10.19) — pip.pypa.io
- Aviso de seguridad de uv (GHSA-hq85-5cpj-mr62) y 0.13.4 — github.com
- conda, «Security updates for conda, Mamba, and Pixi» (21 de octubre de 2026) — conda.org
- Google, «Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates» (20 de octubre de 2026) — blog.google
- Mozilla, «Protecting Firefox users following the compromise of eMudhra intermediate certificates» (20 de octubre de 2026) — blog.mozilla.org
- Registro de incidente de Mozilla (Bug 2083449: los ocho intermedios, horas de revocación, eliminación de la raíz, copias firmadas cruzadamente) — bugzilla.mozilla.org
- eMudhra, «eMudhra Statement on Recent Certificate Security Incident» (publicado por primera vez el 20 de octubre, actualizado el 22 de octubre) — emudhra.com
- eMudhra, «eMudhra to exit global SSL/TLS certificate business» (22 de octubre de 2026) — emudhra.com
- Cobertura de la salida de eMudhra (The Record, 22 de octubre de 2026) — therecord.media
- Debian, «DSA-6572-1 ca-certificates» (20 de octubre de 2026) — lists.debian.org / «DLA-4845-1 ca-certificates» lists.debian.org
- Ubuntu, «USN-8944-1» y «USN-8944-2» ca-certificates (20 de octubre de 2026) — ubuntu.com / ubuntu.com
- Incidencia de la imagen oficial de Docker (python), «These images ship vulnerable pip» (corrección para 3.13+, tratamiento de 3.11 y 3.12) — github.com
- CPython, «Distrust compromised eMudhra intermediate CA keys» (defensa adicional del módulo ssl, no fusionada al 24 de octubre) — github.com
- Estado de las versiones de Python — devguide.python.org
Historial de actualizaciones
2026-10-24: Primera versión, basada en el aviso de los proyectos de Python del 20 de octubre y publicaciones hasta el 23 de octubre, las versiones Python 3.15.1, 3.14.9 y 3.13.17, los avisos de certifi, pip y uv, las declaraciones de Google, Mozilla y eMudhra, y las actualizaciones de ca-certificates de Debian y Ubuntu. Actualizaremos esta página cuando se decida el tratamiento de 3.11 y 3.12 y cualquier otro cambio de CPython.
Lea a continuación
- Auditoría de dependencias: Auditoría de dependencias con OSV-Scanner
- Ataques a los canales de distribución: Incidente de malware en LiteLLM 1.107.0 / Compromiso de la cadena de suministro de Trivy
- Cuando se anuncia una vulnerabilidad: Guía de remediación de CVE
- Suplantación en la ruta de red: Riesgos de las redes Wi-Fi públicas
- Términos: ¿Qué es la criptografía de clave pública? / ¿Qué es Let's Encrypt?