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

Recientemente ocurrieron dos cosas que ilustran esto. Ninguna llegó a los titulares como lo haría una gran filtración, porque ninguna es una filtración que te afecte específicamente a ti. 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 confiables

Open VSX es un marketplace 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 confiable, pero se publicaba desde una cuenta que no era propietaria de la original: una clásica táctica de suplantación, 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 marketplace de extensiones. Cada uno de los 77 paquetes se comunicaba 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 creada con un propósito específico, no una copia oportunista.

La mayoría de las extensiones falsas hacía algo modesto: informaba discretamente el nombre del host al servidor del atacante, lo que por sí solo quizá solo fuera una comprobación para saber 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 activarse, recopilaban el nombre del host, el nombre de usuario del sistema operativo, detalles del editor y un identificador de la máquina. Luego leían cualquier proyecto que el desarrollador tuviera abierto: el remoto de git (que revela la organización y el host 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 escriba 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 un punto de apoyo en ella.

Un error con una puntuación de 9.8 sobre 10 en la máquina que compila el software

El segundo incidente involucra a TeamCity, una plataforma de integración continua y entrega continua (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 registrada 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 una falla 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 que un atacante enviara una solicitud a un servidor de TeamCity vulnerable, sin necesidad de iniciar sesión, y ejecutara 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 la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) advirtió desde entonces 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: esa es literalmente la función de la herramienta.

El mismo manual, dos puertas diferentes

Son incidentes no relacionados de investigadores distintos, pero comparten una característica. 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 distribuida. Esa es la característica definitoria de un ataque a la cadena de suministro de software: en lugar de entrar en un objetivo, comprometes algo en la cadena de suministro de lo que dependen muchos objetivos y dejas que su propio proceso confiable lleve tu acceso más adelante por ti.

Vale la pena 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 posteriores que hayan sido comprometidos como resultado directo: la campaña de extensiones parece estar dedicada al reconocimiento y la obtenció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 se rastree la recompensa final —o en lugar de que se rastree—.

Por qué esto 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 usas el resultado de cientos de ellos: tu aplicación bancaria, tu administrador de contraseñas, el portal escolar de tus hijos, 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 alguno de esos eslabones se ve comprometido silenciosamente, el cambio malicioso puede viajar junto con una actualización de software común y rutinaria, de esas que instalas porque te dijeron que actualizar es lo seguro.

Esta también es 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 mediante 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ó por una puerta cuya existencia nunca conociste.

Lo que realmente ayuda

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

Mantén activadas las actualizaciones automáticas, pero no trates las actualizaciones como si fueran confiables 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 de responsabilidad del proveedor, no un problema tuyo.

Si trabajas con desarrolladores o los administras, 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 que tenga un nombre coincidente (Open VSX y marketplaces similares muestran la identidad del editor: compruébala, no confíes únicamente en el ícono y el título); y si tu organización ejecuta TeamCity en sus instalaciones, confirma hoy que esté en 2025.11.7, 2026.1.3 o que tenga aplicado el complemento de parche, no durante la próxima ventana de mantenimiento: la advertencia de CISA significa que esto está siendo explotado activamente, no que sea algo teórico.

Para todos los demás, el cambio útil es simplemente tomar conciencia: 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 de nicho. 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 en la cadena, antes de que el producto llegara a ti.