75.000 instalaciones, 8 almacenes, 1 zero-day: la semana en que la seguridad volvió a ser protagonista

Esta semana no hubo un solo titular grande de inteligencia artificial que nos obligara a detenernos. Hubo, en cambio, tres historias distintas —un ataque a una empresa de logística, cientos de extensiones falsas en el navegador y un grupo de espionaje norcoreano explotando una falla de Windows— que, leídas juntas, cuentan la misma historia de fondo: la seguridad ya no es un capítulo aparte del desarrollo de software. Es parte del producto.

Como equipo que construye software que termina en producción, con datos reales de clientes reales, seguimos estas noticias con más atención que cualquier lanzamiento de modelo. Porque cada una de ellas es, en el fondo, la misma pregunta que nos hacemos con cada proyecto: ¿qué pasa el día que algo sale mal?

Cuando un ataque a un almacén frena media Europa

CEVA Logistics, una de las mayores operadoras logísticas del continente, sufrió una intrusión que comprometió sistemas de procesamiento de pedidos en ocho almacenes europeos. La empresa no lo comunicó públicamente. Se enteraron sus clientes corporativos, primero, y luego el resto del mundo a través de ellos (The Record).

Y la lista de afectados es la parte que más nos interesa: Bol, una de las plataformas de e-commerce más grandes de Países Bajos. De Bijenkorf, una tienda departamental de lujo. Ace & Tate, una marca de monturas ópticas. El club de fútbol Ajax. Y Steam, a través de su negocio de hardware en Europa. Ninguna de estas empresas fue atacada directamente. Todas quedaron expuestas porque confiaron parte de su operación a un proveedor externo.

Los datos filtrados no son especialmente sensibles en el sentido tradicional: nombres, direcciones, teléfonos, correos, números de pedido, información de rastreo. Pero es exactamente el tipo de información que permite construir campañas de phishing muy convincentes contra los clientes finales de cada una de esas marcas. El daño real de este tipo de brechas casi nunca se mide en el momento del ataque, sino meses después, cuando alguien recibe un correo que parece perfectamente legítimo porque menciona el pedido correcto.

Este caso es un recordatorio simple pero incómodo: tu superficie de riesgo no termina en tu propio código. Incluye cada proveedor, cada integración, cada API de terceros que toca datos de tus usuarios. Elegir con quién construyes tu cadena de operación es una decisión de arquitectura, no solo una decisión de compras.

737 extensiones de Chrome que prometían privacidad y vendían lo contrario

La segunda historia de la semana ocurrió en un lugar mucho más cercano al día a día de cualquier equipo técnico: el Chrome Web Store. Investigadores identificaron 737 extensiones falsas de VPN y proxy, distribuidas desde al menos 40 cuentas de desarrollador, con más de 75.000 instalaciones confirmadas (The Hacker News).

Suplantaban a 66 marcas legítimas —Proton VPN, NordVPN, Surfshark, ExpressVPN, entre otras— y hacían exactamente lo contrario de lo que prometían: en lugar de proteger la navegación, enrutaban toda la sesión del usuario a través de servidores controlados por el atacante, posicionándose como intermediarios capaces de observar cada destino, cada dirección IP y cada conexión cifrada.

Lo que más nos llamó la atención no es la escala del fraude, sino su sofisticación operativa. Los investigadores encontraron documentación interna en ruso, con instrucciones detalladas sobre cómo evadir las revisiones automáticas del Chrome Web Store. No era un experimento improvisado. Era un proceso, con procedimientos escritos, pensado para sostenerse en el tiempo.

Para cualquier equipo que construye software hoy, esto es una lección sobre confianza y dependencias. Cada librería que instalamos, cada extensión que recomendamos, cada paquete de código abierto que sumamos a un proyecto es, en la práctica, código de un tercero corriendo dentro de nuestro producto. La cadena de suministro de software —quién escribió el código que usamos, cómo se audita, con qué frecuencia se revisa— dejó de ser una preocupación exclusiva de equipos de seguridad. Es parte de cómo se construye bien, punto.

Una oferta de trabajo falsa, un visor de PDF y una falla de Windows

La tercera historia es, para nosotros, la más reveladora de las tres. El grupo norcoreano Lazarus explotó una vulnerabilidad de escalada de privilegios en Windows —identificada como CVE-2026-68820, reportada a Microsoft en julio y parchada en agosto— para atacar a empresas de defensa y aeroespaciales en Francia, Alemania, Brasil e India, en una campaña conocida como Operation Dream Job (The Hacker News).

El punto de entrada no fue técnico. Fue humano. Reclutadores falsos contactaban a empleados por LinkedIn con ofertas de trabajo en empresas como Lockheed Martin. La víctima terminaba abriendo un visor de PDF troyanizado o descargando software desde un sitio que imitaba a una empresa legítima. De ahí en adelante, la cadena de infección combinaba varias piezas de malware hasta lograr acceso a nivel de sistema, usando incluso sitios WordPress y servidores comprometidos como infraestructura de comando y control.

La falla técnica importa, y parchar rápido importa. Pero la vulnerabilidad que realmente abrió la puerta fue la confianza depositada en un mensaje que parecía legítimo. Ningún firewall corrige eso. Solo lo hace una cultura de trabajo donde verificar antes de confiar es la norma, no la excepción, incluso —o especialmente— cuando el mensaje viene de alguien que dice representar a una marca conocida.

Lo que estas tres historias tienen en común

Ninguna de las tres empresas afectadas esta semana —CEVA Logistics, las víctimas de las extensiones falsas, las firmas de defensa atacadas por Lazarus— fue descuidada de forma obvia. Ninguna dejó una puerta abierta a propósito. En los tres casos, el problema apareció en el lugar donde menos se estaba mirando: un proveedor de confianza, una extensión de navegador aparentemente inofensiva, un mensaje que parecía una oportunidad laboral real.

Esa es, para nosotros, la lección central. La seguridad no se resuelve agregando una capa al final del desarrollo, como quien pinta una pared después de construir la casa. Se construye desde el principio: en cómo se diseña la arquitectura, en qué proveedores se eligen, en cómo se gestionan las dependencias de código, en qué procesos existen para aplicar parches sin que eso dependa de que alguien se acuerde de hacerlo.

En Rukma no vendemos auditorías de seguridad como producto aparte. Las incorporamos como parte de cómo desarrollamos software real: bases de datos, arquitectura, despliegue. Cuando construimos un producto para un cliente, la pregunta de qué pasa si algo falla no llega al final del proyecto. Llega al principio, junto con las preguntas de qué problema estamos resolviendo y para quién.

Eso significa cosas concretas: revisar de dónde vienen las dependencias que usamos, diseñar arquitecturas donde un proveedor comprometido no se lleve todo el sistema con él, y dejar procesos de actualización y monitoreo que no dependan de la memoria de una sola persona. No es la parte más vistosa de construir un producto digital. Pero es la que determina si ese producto sigue en pie cuando algo, inevitablemente, sale mal.

Si estás construyendo o escalando un producto y la pregunta de "qué tan sólida es realmente nuestra infraestructura" te genera más dudas que certezas, conversemos. Preferimos tener esa conversación incómoda ahora que como respuesta a un incidente.