El radar pwn.watch: 34 incidentes abiertos y 15 críticos

Qué está pasando: 34 incidentes abiertos y 15 críticos

pwn.watch, un feed en vivo de incidentes de seguridad, cierra su tablero del 22 de octubre de 2026 con 34 incidentes activos, 15 de ellos críticos y 17 sin parchear del todo. En los últimos doce meses acumula 190 incidentes, cada uno con su CVE, los productos afectados, las versiones que lo corrigen y los avisos oficiales detrás.

Para un founder, ese número no es una curiosidad de nicho: es la lista de tareas que su equipo de ingeniería probablemente no está mirando. La mayoría de las startups hispanohablantes no tiene un CISO. Tiene dos o tres developers que además hacen producto, soporte y deploy, y el volumen de parches que sale cada semana hace imposible seguirlos a mano.

Lo incómodo es qué aparece en el tramo reciente del feed. No son sistemas heredados de los noventa: son herramientas que cualquier equipo usa todos los días. GitLab, LiteLLM, Node.js, PHP, Signal, OpenCode, Railway, ConnectWise.

El patrón de 2026: te atacan por tus herramientas, no por tu código

Si hay un hilo que cruza los incidentes de este año, es la cadena de suministro de software. El atacante ya no busca una vulnerabilidad en tu producto: busca un eslabón débil en algo que instalas, actualizas o ejecutas automáticamente.

El feed lo muestra en su forma más cruda. Aparecen compromisos de paquetes publicados en PyPI y npm, releases backdooreadas en GitHub, un plugin de WordPress con el instalador manipulado, una extensión de wallet que filtró claves privadas durante meses y hasta una CLI de nube con binarios alterados. En casi todos los casos el vector es el mismo: credenciales de mantenedor robadas y un pipeline de CI que confía en lo que descarga.

La consecuencia práctica es que "tener las dependencias actualizadas" dejó de ser una política de seguridad suficiente. La actualización automática es, precisamente, el mecanismo que propaga el ataque.

GitLab: dos fallos de severidad máxima en pocas semanas

El feed marca como crítico un RCE no autenticado en GitLab (CVE-2026-110264) que seguía actualizándose al 22 de octubre. No es la primera vez que la plataforma aparece en el radar este año.

En septiembre, GitLab parcheó CVE-2026-85706, una vulnerabilidad de path traversal con CVSS 10.0 que, según InfoQ, permitía a un atacante no autenticado leer archivos arbitrarios del servidor por un fallo de confinamiento de rutas y falta de autenticación en la API de commits del repositorio. La condición para explotarla era mínima: que la instancia tuviera al menos un proyecto público.

Según CSO Online, la firma watchTowr observó sondeos en la naturaleza pocas horas después de la divulgación, y CISA sumó la vulnerabilidad a su catálogo de explotadas. El dato que dimensiona el riesgo: GitLab lo usan cerca del 50% de las empresas del Fortune 100 y tiene más de 50 millones de usuarios registrados, según la misma nota. Cuando ese servidor guarda variables de CI/CD, tokens de runner y claves SSH, un fallo de lectura arbitraria deja de ser un problema de infraestructura y se convierte en un problema de negocio.

Hay un matiz que casi nadie ejecuta: parchear cierra la puerta, pero no invalida lo que el atacante ya copió. Si los tokens de deploy y las variables de CI estuvieron expuestos, siguen siendo válidos hasta que alguien los rote.

LiteLLM: por qué parchear no cierra el incidente

El feed marca como crítico un compromiso de cadena de suministro en LiteLLM 1.107.0, distribuido vía PyPI y Docker. Tampoco es un caso aislado: en marzo de 2026, según el reporte de GCN sobre el análisis de CloudSEK, un actor publicó versiones maliciosas de LiteLLM (1.82.7 y 1.82.8) tras comprometer las credenciales de PyPI del proyecto a través de una versión envenenada del escáner Trivy que corría en su pipeline de CI.

Las cifras de ese episodio explican por qué el tema importa tanto. LiteLLM se descarga 3,4 millones de veces por día y funciona como gateway unificado hacia múltiples proveedores de modelos, así que vive dentro de frameworks de agentes, servidores MCP y pipelines de producción. El reporte de CloudSEK, publicado el 11 de agosto de 2026, vincula el incidente con cerca de 2.500 organizaciones y unos 434.000 pipelines de CI/CD; Hudson Rock, según el mismo artículo, atribuyó 118.829 volcados de runners a 2.488 dominios corporativos en un archivo de 153 GB con 433.909 archivos.

El detalle técnico vale para cualquier equipo: el payload usaba un archivo .pth que se ejecutaba en cada arranque de Python, incluso si la aplicación nunca importaba la librería. Eso saltea las protecciones que muchos equipos creen tener en la etapa de instalación. Y la lista de alta confianza de CloudSEK incluye nombres como NVIDIA, Amazon Web Services, Samsung y Cisco, aunque la firma aclara que se trata de exposición reconstruida y no de prueba de compromiso de cada organización.

Zeabur: cuando el proveedor de hosting se apaga

El caso más didáctico del feed es Zeabur, una plataforma de hosting y despliegue. Según BleepingComputer, entre el 14 y el 15 de octubre de 2026 un atacante usó credenciales internas filtradas —guardadas en texto plano— para entrar al clúster compartido, a varios servidores dedicados y a los sistemas internos, y llegar hasta la base de datos de producción.

El saldo: más de 3,2 millones de registros de variables de entorno y datos de 321.810 cuentas, en clústeres compartidos de nueve regiones. Además, la empresa confirmó inicios de sesión como root en 101 servidores de GCP por parte de 92 usuarios, con claves SSH añadidas a 50 servidores y 16 copias de discos de clientes montadas en máquinas virtuales de los atacantes.

El detalle que debería hacerte revisar tus propios accesos: los tokens de administrador no tenían expiración, se habían creado en enero de 2024 y no se rotaron tras un incidente anterior en agosto de 2026. Zeabur anunció que cerrará sus servicios a partir del 1 de diciembre de 2026 y los completará el 31 de diciembre.

¿Qué significa esto para tu startup?

La lección no es "contrata seguridad". Es que el modelo de amenaza cambió y tus controles probablemente no.

• Rota secretos, no solo parchees. Después de cualquier incidente en una herramienta de tu stack, invalida tokens de deploy, variables de CI/CD, claves SSH y credenciales de nube que esa herramienta pudiera leer. Un parche no revoca nada.
• Pon fecha de vencimiento a todo token de administrador. El fallo de Zeabur no fue solo el acceso inicial: fue que una credencial de enero de 2024 seguía viva y sin rotar. Si tus tokens de admin no expiran, ya tienes un incidente latente.
• Fija tus dependencias de CI por hash, no por etiqueta. El ataque a LiteLLM entró por un escáner que el pipeline instalaba automáticamente. Anclar versiones y revisar los archivos que se ejecutan al arrancar procesos es barato comparado con rotar toda tu infraestructura.
• Reduce la exposición pública de lo self-hosted. Si corres GitLab, n8n, Metabase o cualquier panel interno en una IP pública, ese es tu perímetro real. Ciérralo detrás de VPN o lista blanca de IPs.
• Ten un proceso de detección, no solo de parcheo. En el caso de GitLab, la recomendación de watchTowr —citada por InfoQ y CSO Online— es buscar en los logs peticiones POST a /api/v4/projects/{id}/repository/commits/ con parámetros file.path. Es una consulta de diez minutos que te dice si ya te visitaron.

Conclusión

Un tablero con 34 incidentes abiertos y 15 críticos no es una señal de que la industria esté peor que antes, sino de que ahora se mide mejor. La parte buena es que la mayoría de los incidentes de 2026 comparte un puñado de causas evitables: credenciales que nunca se rotan, pipelines que confían en todo lo que descargan y paneles internos expuestos a internet.

Ninguna de esas tres cosas requiere presupuesto. Requiere una tarde de trabajo y la decisión de tratarlas como deuda técnica con fecha. La pregunta útil no es si tu startup va a aparecer en un feed como pwn.watch, sino cuánto tardarías en darte cuenta si ya apareció.

Fuentes

• pwn.watch (fuente original)
• GitLab Vulnerability under Active Exploitation Enables Unauthenticated Data Exfiltration
• A maximum severity GitLab flaw could turn your CI/CD server into an attacker's treasure trove
• 153GB of stolen credentials surface five months after LiteLLM supply chain attack
• Zeabur shutting down after second security breach in two months