El parche de arriba no cierra la puerta de abajo
El parche de arriba no cierra la puerta de abajo
El ecosistema de software sufre una crisis de inventario y confianza delegada, evidenciada por múltiples incidentes donde actualizar la aplicación principal ya no garantiza la seguridad.
En el caso de GitLab (CVE-2026-97229, CVSS 10) un fallo de ejecución remota sin autenticar en el pipeline de CI/CD está en explotación activa.
El problema, como comprobó Alpine Linux, es que el parche de GitLab no corrige el intérprete de Ruby subyacente. Si el sistema operativo mantiene un Ruby vulnerable, la puerta sigue abierta.
Un escenario idéntico afecta a PHP2Shell, demostrando que la superficie de ataque incluye dependencias invisibles que los equipos asumen como ajenas.
Si el patrón se puede manipular el atacante consigue que el intérprete ejecute lo que él escriba en lugar de solo buscar.
CISA lo añadió al catálogo KEV el 29 de octubre y dio a las agencias federales hasta el domingo para cerrarlo (Fuente: securityweek.com).
Ese detalle convierte un aviso rutinario en un problema de inventario. La pregunta ya no es si tienes GitLab actualizado sino qué versión de Ruby lo está ejecutando.
La semana trae el mismo patrón en otro sitio.
PHP2Shell sigue sin mitigación completa; y PHP advierte de que solo queda actualizar (Fuente: securityweek.com).
El fallo afecta a versiones desde la 5.4, tiene CVSS 9.2 y los fabricantes industriales revisan producto a producto si embeben el intérprete (Fuente: securityweek.com).
La confianza ciega en terceros se ha consolidado como el vector más rentable.
Polymarket perdió 2,7 millones de dólares en minutos debido a un script de analítica externo comprometido que secuestraba sesiones directamente en el navegador del usuario.
Paralelamente, la extensión oficial Claude Code distribuyó código troyanizado desde el marketplace de Cursor durante once horas, abriendo túneles inversos mediante claves SSH.
El atacante no necesita romper el código de la empresa porque le basta con comprometer la pieza intermedia o el canal de distribución oficial
En los tres casos el fallo vive en una pieza que el equipo no considera suya. Se parchea la aplicación de arriba y se da el caso por cerrado.
Cuando el canal es el ataque
El 29 de octubre, la extensión oficial de Claude Code 2.1.313 se sirvió troyanizada desde el marketplace de Cursor durante once horas (Fuente: microsoft.com).
La versión que llegó a los usuarios no era la que el fabricante había firmado y al loro… añadía una clave SSH del atacante y abría un túnel inverso persistente hacia su infraestructura.
Un túnel inverso es una conexión que sale del equipo comprometido hacia fuera y queda abierta. El atacante no necesita entrar después, porque la puerta ya está abierta desde dentro.
Hasta 5.000 usuarios quedaron expuestos en esa ventana de once horas. Cursor reconstruyó el marketplace y rotó las claves afectadas (Fuente: microsoft.com).
Lo llamativo no es que un paquete se comprometa sino que el compromiso ocurriera en el canal que la propia herramienta usa para distribuirse, el que el usuario instala porque confía en la marca.
Ese mismo día, OpenAI confirmó otro incidente en la misma dirección. Un enlace compartido de ChatGPT podía ejecutar código dentro de la sesión autenticada del destinatario y exfiltrar conversaciones que nunca se habían compartido (Fuente: thehackernews.com).
La corrección fue del lado servidor, sin acción del usuario por tanto el fallo no dependía de lo que hiciera la víctima sino de lo que el servicio permitía hacer con un enlace.
La semana trae un tercer caso en la misma línea.
TeamViewer corrigió CVE-2026-111585, con CVSS 8.8, en clientes anteriores a la versión 15.83 (Fuente: thehackernews.com).
El fallo es un desbordamiento al negociar el tamaño de pantalla. Permite ejecutar código en el visor Windows con la configuración por defecto; basta con aceptar la sesión.
La dirección del ataque es la que importa. El host remoto comprometido ataca a quien se conecta a él, no al revés. La máquina a la que llamas para arreglar algo puede ser la que te compromete.
El paradigma tradicional de conexión también está fallando.
El otro lado
No toda la semana va de parchear.
Polymarket perdió unos 2,7 millones de dólares en minutos porque el script de analítica de DebugBear estaba comprometido y secuestraba sesiones para vaciar carteras (Fuente: securityweek.com).
La plataforma pausó el trading una hora y prometió reembolsos y el vector no fue un fallo de su código sino un tercero que servía un script en su página.
En los cuatro casos, el eslabón débil estaba fuera del inventario propio.
La lectura propia
Mi lectura es que el agujero es de gestión, no de parches.
El equipo sabe qué aplicaciones tiene y no sabe qué las sostiene por debajo, qué canal las distribuye y a qué hosts se conecta ni qué scripts carga en el navegador del usuario.
La elección de herramienta ya no se decide solo por lo que hace sino por quién la distribuye y qué firma la respalda.
Un marketplace que reconstruye su catálogo en once horas demuestra capacidad de reacción pero no demuestra que el siguiente paquete vaya a llegar limpio.
Y con el acceso remoto pasa lo mismo ya que si el host al que te conectas puede atacarte, la política de conexión tiene que asumir que el otro extremo es hostil hasta que se demuestre lo contrario.
¿Qué mirar?
- La versión del intérprete. Comprueba en cada host con GitLab qué Ruby lo ejecuta y si está en la lista de versiones corregidas. Con PHP, lo mismo, el parche de la aplicación no cubre el intérprete.
- Los endpoints de CI/CD expuestos. Revisa si el pipeline acepta peticiones desde fuera de la red interna. GitLab ejecuta código por diseño, así que un fallo ahí no necesita una víctima que haga clic.
- Las extensiones instaladas. Si tienes Claude Code 2.1.313 o algo que llegara del marketplace de Cursor el 29 de octubre, rota las claves SSH del equipo y busca túneles inversos activos.
- El acceso remoto y los scripts de terceros. Ese visor no debería tener permisos sobre la red interna. Y cualquier analítica o tag manager embebido es superficie de ataque así que si no puedes fijar su versión, registra qué dominio sirve cada uno.
¿Cómo lo probaría en mi laboratorio?
Montaría un GitLab en un contenedor con el Ruby del sistema en la versión vulnerable y otro con la corregida. Lanzaría la misma petición maliciosa contra los dos y miraría el registro de cada uno.
Si el primero ejecuta y el segundo no, tengo la prueba de que el parche de GitLab no basta por sí solo. Si los dos ejecutan, el problema está en otra capa y toca seguir bajando.
Después instalaría una extensión desde un marketplace local y miraría qué claves escribe en el sistema. Es barato y dice mucho de lo que el usuario acepta sin leer.
Es una prueba que cabe en cualquier portátil con Docker. La haría antes de dar por cerrado el aviso de CISA en mi propia red.
Plan de acción
- Identifica el intérprete subyacente: Revisa en cada host qué versión exacta de Ruby, PHP u otro lenguaje base ejecuta la aplicación principal.
- Limita la exposición del CI/CD: Bloquea las peticiones externas a los endpoints del pipeline si no son estrictamente necesarias para la operación.
- Audita scripts externos: Registra cada dominio de terceros cargado en tu web; una herramienta de analítica comprometida otorga acceso total a las sesiones autenticadas.
- Aísla el soporte remoto: Los visores utilizados para conectarse a clientes o terceros no deben tener permisos ni visibilidad sobre tu red interna.
- Valida en laboratorio: Levanta contenedores Docker con versiones vulnerables y parcheadas del sistema base para comprobar empíricamente si la actualización de la aplicación detiene el exploit.