La mayoría de las noticias de seguridad de este boletín tratan sobre cosas que te suceden directamente: un mensaje de phishing, una contraseña filtrada, un sitio de compras falso. Esta es diferente. Los incidentes que aparecen a continuación les sucedieron a desarrolladores — las personas que escriben las aplicaciones y los servicios que usas todos los días. Pero la razón por la que pertenecen a este boletín es sencilla: si alguien envenena las herramientas utilizadas para crear software, el veneno no se queda con quien lo crea. Se distribuye con el producto.

Recientemente sucedieron dos cosas que ilustran esto. Ninguna llegó a los titulares como lo haría una gran filtración, porque ninguna es, específicamente, una filtración de tus datos. Ambas son ataques contra la cadena que produce el software que finalmente instalas, abres o en el que inicias sesión.

Extensiones falsificadas disfrazadas de marcas de confianza

Open VSX es un mercado público de extensiones para editores de código — pequeños complementos que los desarrolladores instalan para obtener autocompletado, linting e integraciones para las herramientas que usan a diario (Visual Studio Code y varios de sus equivalentes de código abierto recurren a él). Entre el 26 de julio y el 1 de agosto de 2026, investigadores de seguridad de Manifold Security encontraron 77 extensiones falsificadas en el registro. Cada una copiaba el nombre y el espacio de nombres de una extensión real y de confianza, pero se había publicado desde una cuenta que no era propietaria de la original — una clásica suplantación de identidad, a veces llamada apropiación de nombres de espacio.

Los nombres apropiados no eran aleatorios. Tomaban prestadas las identidades de AMD, LEGO Education, Hyperledger, Azure, Artsy, los proyectos de código abierto de Salesforce, una agencia federal de EE. UU. y — con una especie de ironía oscura — el propio mercado de extensiones. Los 77 paquetes se comunicaban con un único dominio que se había registrado apenas 11 días antes de que apareciera el primer paquete falso, un patrón que sugiere una campaña coordinada y diseñada específicamente para ese fin, en lugar de una copia oportunista.

La mayoría de las extensiones falsas hacía algo relativamente inofensivo: enviaba discretamente el nombre del equipo al servidor del atacante, lo que por sí solo podría ser simplemente una comprobación para ver quién había instalado el señuelo. Pero los investigadores descubrieron que aproximadamente una cuarta parte de las 77 — 19 paquetes — iba más allá. Segundos después de la activación, recopilaban el nombre del equipo, el nombre de usuario del sistema operativo, detalles del editor y un identificador de la máquina. Después leían el proyecto que el desarrollador tuviera abierto: el remoto de git (que revela la organización y el servidor del repositorio), el dominio del correo electrónico de los commits, la rama actual y el commit más reciente. También extraían valores de integración continua — las credenciales y la configuración que permiten a los sistemas automatizados compilar y desplegar código sin que una persona tenga que escribir una contraseña cada vez.

Ninguno de esos datos sirve para vaciar la cuenta bancaria de alguien. Sirve para otra cosa: averiguar para qué empresas trabaja un desarrollador, cómo es su infraestructura interna y cómo conseguir afianzarse en ella.

Un fallo de 9,8 sobre 10 en la máquina que construye el software

El segundo incidente involucra a TeamCity, una plataforma de integración y entrega continuas (CI/CD) creada por JetBrains. Si un editor de código es el lugar donde los desarrolladores escriben software, una plataforma de CI/CD es la planta de producción automatizada donde ese código se compila, se prueba y se envía a producción — a menudo sin que ninguna persona haga clic en «desplegar». TeamCity es una pieza central de esa maquinaria en muchas empresas.

Se divulgó una vulnerabilidad identificada como CVE-2026-63077, con una puntuación de gravedad de 9.8 sobre un máximo de 10, en las versiones locales de TeamCity. Es un fallo de deserialización — una clase de error en la que un programa confía lo suficiente en los datos entrantes como para convertirlos directamente en código ejecutable, sin comprobar primero qué son realmente esos datos. En la práctica, permitía a un atacante enviar una solicitud a un servidor TeamCity vulnerable, sin necesidad de iniciar sesión, y ejecutar comandos arbitrarios con los mismos privilegios que el propio servicio de TeamCity. JetBrains publicó parches (versiones 2025.11.7 y 2026.1.3, además de un complemento de parche para instalaciones antiguas 2017.1+), pero desde entonces la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) ha advertido que los atacantes están explotando activamente los sistemas sin parchear.

Quien controla el servidor de compilación de una empresa controla lo que esa empresa distribuye. No es una hipótesis: es la función literal de la herramienta.

El mismo manual, dos puertas diferentes

Son incidentes no relacionados y descubiertos por investigadores diferentes, pero comparten una misma estructura. Ninguno ataca un producto terminado. Ambos atacan un paso anterior: el editor en el que un desarrollador escribe código o el servidor que convierte ese código en una versión lista para distribuir. Esa es la característica definitoria de un ataque a la cadena de suministro de software: en lugar de irrumpir en un objetivo, comprometes algo de lo que dependen muchos objetivos y dejas que su propio proceso de confianza lleve tu acceso más adelante por ti.

Conviene ser honestos sobre lo que todavía no sabemos. Ninguno de los informes que salieron a la luz esta semana reveló un caso confirmado de una aplicación o un usuario posterior comprometido como consecuencia directa — la campaña de extensiones parece estar orientada al reconocimiento y la recopilación de acceso, y la explotación de TeamCity se describe como activa, pero sin víctimas identificadas. Es normal; los compromisos de la cadena de suministro suelen descubrirse en el punto de entrada mucho antes de que (o en lugar de que) se rastree el desenlace final.

Por qué este también es tu problema, no solo el de ellos

Probablemente nunca instalarás una extensión de programación ni ejecutarás un servidor de CI/CD. Pero utilizas el resultado de cientos de ellos: tu aplicación bancaria, tu gestor de contraseñas, el portal escolar de tu hijo, el navegador en el que estás leyendo esto. Todo pasó por el editor de algún desarrollador y la cadena de compilación de alguna empresa antes de llegar a tu teléfono. Si cualquiera de esos eslabones se ve comprometido silenciosamente, el cambio malicioso puede viajar junto con una actualización de software ordinaria y rutinaria — el tipo de actualización que instalas porque te dijeron que actualizar es lo seguro.

Esta es también la razón por la que los consejos de un informe posterior a una filtración a veces resultan extraños para los lectores no técnicos: una empresa dice que sus sistemas fueron comprometidos a través de un servidor de compilación, una credencial de desarrollador robada o una dependencia maliciosa, y puede sonar abstracto frente a «alguien adivinó mi contraseña». No es abstracto. Es el mismo resultado — tus datos o la integridad de tu aplicación se vieron comprometidos — al que se llegó a través de una puerta cuya existencia desconocías.

Lo que realmente ayuda

No puedes auditar la cadena de CI/CD de tu banco, ni deberías tener que hacerlo. Pero algunos hábitos reducen genuinamente tu exposición a este tipo de riesgo:

Mantén activadas las actualizaciones automáticas, pero no trates las actualizaciones como algo digno de confianza automáticamente. Los parches son la forma en que correcciones como la de TeamCity mencionada arriba llegan al software que ejecutas; mantenerte al día cierra las ventanas que los atacantes están sondeando activamente. Al mismo tiempo, una actualización solo es tan buena como la cadena que la produjo, que es precisamente lo que se está atacando aquí; no existe una defensa individual perfecta contra una versión ascendente verdaderamente envenenada, por lo que este es fundamentalmente un problema responsabilidad del proveedor, no un problema tuyo.

Si trabajas con desarrolladores o los gestionas, hay dos cosas concretas y comprobables: verifica que cualquier extensión del editor de código esté instalada desde la cuenta real del editor verificado, no solo desde una cuenta con un nombre coincidente (Open VSX y mercados similares muestran la identidad del editor; compruébala, no confíes únicamente en el icono y el título); y si tu organización ejecuta TeamCity en sus instalaciones, confirma hoy que utiliza 2025.11.7, 2026.1.3 o que tiene aplicado el complemento de parche, no en la próxima ventana de mantenimiento; la advertencia de CISA significa que se está explotando activamente, no que sea algo teórico.

Para todos los demás, el cambio útil consiste simplemente en ser conscientes: cuando leas sobre una filtración de una empresa que se remonta a «una herramienta de desarrollo comprometida» o «un sistema de compilación», no es una nota técnica marginal. Es la misma categoría de incidente que las filtraciones de contraseñas y las estafas de phishing que este boletín cubre con más frecuencia; simplemente comenzó un nivel más arriba, antes de que el producto llegara a ti.