Qué ha pasado
Entre el 4 y el 21 de agosto de 2026, unas 5.000 cuentas de Dropbox quedaron expuestas. Los atacantes no adivinaron ninguna contraseña ni tumbaron ningún servidor: registraron una cuenta de Lenovo ID con el correo de otra persona y entraron en el Dropbox de esa persona sin necesitar su contraseña. En aproximadamente un tercio de esas cuentas se llegaron a ver o descargar archivos. Los datos son los que publica wwwhatsnew, que es también quien fecha el episodio.
Lo que falló, tal y como lo cuenta la fuente, no estaba dentro de ninguno de los dos productos: estaba en la costura entre los dos. Una integración de inicio de sesión que permitía usar la cuenta de Lenovo para entrar en Dropbox y que no comprobaba bien algo tan elemental como que ese correo fuera de quien decía serlo. Según la misma fuente, era «un sistema que nadie había revisado en años», y ninguna de las cuentas afectadas tenía activada la verificación en dos pasos.
Fíjate en las fechas, porque ahí está lo que importa: el acceso empezó a usarse el 4 de agosto y no se detectó hasta el 21. Cuando se detectó, Dropbox cerró todas las sesiones abiertas por esa vía, desactivó la integración entera y pasó a exigir contraseña propia. La reacción fue la correcta. El problema nunca estuvo en la reacción: estuvo en las semanas anteriores, cuando aquello ya estaba pasando y nadie tenía motivo para ir a mirar precisamente ahí.
Por qué esto no va de Dropbox
Es tentador leerlo como una noticia de dos gigantes y pasar página. La lectura útil para una empresa pequeña es otra, y es incómoda: tu web no es solo tu web. Es tu web más todo lo que tu web tiene conectado.
Haz la lista mental de una pyme cualquiera con una web que funciona:
- La pasarela de pago.
- El «entrar con Google» del área de clientes.
- El formulario de contacto que deposita los avisos en un CRM.
- La conexión con el programa de contabilidad o con el TPV.
- El servicio de correo que manda las confirmaciones.
- Aquella integración que se montó para una campaña de hace tres años y que nunca se desconectó.
Cada una de esas conexiones es una puerta. Ninguna es mala por existir: existen porque hacen falta y porque ahorran trabajo real. Lo que las convierte en un problema es una propiedad muy concreta y muy silenciosa: una integración no envejece de forma visible. Un diseño anticuado se ve. Una web lenta se nota. Una conexión que sigue abierta y ya no debería estarlo no se ve, no se nota y no da ningún síntoma, hasta el día que da todos a la vez.
Y hay un segundo detalle del caso que conviene retener, porque es el que más se repite en pequeño: la integración de Dropbox y Lenovo funcionaba. Los usuarios entraban, la cosa iba. Que algo funcione no dice nada sobre si comprueba lo que tiene que comprobar. Ya escribimos sobre esto desde otro ángulo, con la prueba de las dos cuentas: una función puede aprobar todas las pruebas que le hicieron y estar dando acceso a quien no debe, porque nadie diseñó la prueba que lo cazaba.
Cuatro preguntas sobre la seguridad de las integraciones de tu web
No hace falta entender de criptografía para saber si esto te afecta. Hacen falta cuatro respuestas, y son cuatro preguntas para hacerle a quien lleva tu web —nosotros o cualquier otro—. Que algunas no tengan respuesta hoy es lo más normal del mundo: casi ninguna web pequeña nació con esto documentado. Saber cuáles faltan ya es la mitad del trabajo.
1. ¿Existe la lista? ¿Hay algún sitio donde esté escrito qué tiene conectado tu web, para qué sirve cada conexión y desde cuándo está? Si no existe, no pasa nada grave: se hace una vez y luego se mantiene. Este es el paso que hace posibles los otros tres, y por eso va primero.
2. ¿Qué puede hacer cada conexión? No es lo mismo un servicio que solo puede escribir un pedido que otro que puede leer toda la base de clientes. Una conexión debería poder hacer exactamente lo que necesita y ni una cosa más, porque el día que algo se tuerce, el daño posible es el que le hayamos dejado hacer. Esta pregunta no la ilustra el caso de agosto —allí lo que falló fue otra cosa—, pero es la que decide cuánto se pierde cuando algo falla.
3. ¿Qué pasa cuando alguien entra por otra puerta? Si tu web deja iniciar sesión con una cuenta de otro sitio, ¿qué comprueba antes de dejar pasar? La comprobación que faltaba en el caso de agosto es exactamente esta, y es la más aburrida de todas: verificar que el correo con el que alguien se presenta es de verdad suyo.
4. ¿Y las que ya no se usan? La campaña terminó, el proveedor cambió, la herramienta se sustituyó. ¿Se desconectó la integración, o solo se dejó de usar? Una conexión abandonada es la peor de todas: nadie la vigila porque nadie se acuerda de ella, y sigue teniendo los mismos permisos que el día que se montó.
Si de las cuatro sale un «no lo sé», eso no es una emergencia. Es una tarea. Pero es una tarea que hoy no está en la lista de nadie.
Qué hacemos nosotros con esto
En Galianet desarrollamos software a medida y lo mantenemos nosotros mismos, y por eso el mantenimiento no es un extra que se añade al final: es parte del mismo trabajo. Desde el plan Básico, de 40 € al mes más IVA, todos nuestros planes incluyen la actualización mensual de frameworks y librerías —lo que se apoya debajo de tu aplicación, y donde aparecen los fallos que ya están publicados y catalogados a la vista de todos—, además de las actualizaciones del sistema operativo, la revisión diaria de los registros del servidor de correo, la revisión semanal de los registros del sistema y de las aplicaciones de seguridad, y la resolución de incidencias de la tecnología que hemos hecho nosotros.
Conviene decirlo con el verbo correcto y con su alcance, porque es lo que de verdad se puede sostener: aplicamos las actualizaciones que publican los fabricantes y revisamos esos registros con la cadencia que está escrita en el plan. Eso es lo que se contrata. Y una cosa que no se contrata, dicha aquí para que no haya que suponerla: esa revisión mira el servidor y sus aplicaciones de seguridad, no va conexión por conexión comprobando qué permisos tiene cada una de las cuatro preguntas de arriba. Eso, cuando hace falta, se mira en el proyecto y se decide caso por caso. Nadie puede prometerte tampoco que no aparecerá jamás un fallo en un componente que no ha escrito, y quien te lo prometa te está vendiendo algo que no depende de él.
Sobre las integraciones en concreto: en nuestros planes, las integraciones por API son un módulo que entra a partir del plan Profesional. Lo decimos aquí porque tiene una consecuencia que no es comercial: cada integración que se añade es una puerta más que hay que conocer y volver a mirar, y esa cuenta conviene hacerla antes de conectar, no después. La conexión que no existe es la única que no hay que revisar.
Y cuando la conexión sí hace falta, porque el trabajo la necesita, lo que cambia las cosas es haberla diseñado sabiendo qué permisos da, en vez de montarla y olvidarla. Esa es la diferencia entre una integración y una puerta olvidada, y no se ve desde fuera: cuando el arreglo de un fallo es la pista para encontrarlo, el tiempo que pasa entre que algo se sabe y algo se aplica es todo lo que separa las dos cosas.
Por dónde empezar mañana
Abre un documento y escribe la lista de la pregunta 1. Sin valorarla, sin decidir nada: solo qué tiene conectado tu web y para qué sirve cada cosa. Si al terminar hay una línea de la que no sabes decir quién la usa hoy, ya has encontrado por dónde empezar.
Y si estás pensando en un proyecto a medida, o el tuyo ya lo llevamos nosotros, esa lista es una buena primera conversación. Escríbenos: te respondemos en menos de 24 horas laborables.
Fuente: «Dropbox: 5.000 cuentas comprometidas a través de un login de Lenovo que nadie había revisado en años», wwwhatsnew, 4 de septiembre de 2026. https://wwwhatsnew.com/2026/09/04/dropbox-5000-cuentas-comprometidas-lenovo-id-sso-agosto-2026/
