Dropbox: 5.000 cuentas comprometidas por login Lenovo sin MFA

Qué pasó entre el 4 y el 21 de agosto

Dropbox notificó a 5.000 usuarios que sus cuentas fueron accedidas sin autorización entre el 4 y el 21 de agosto de 2026 a través de una integración SSO con Lenovo ID que llevaba años sin revisarse. El atacante no necesitó contraseñas: bastaba con registrar un Lenovo ID usando el correo de la víctima y Dropbox lo aceptaba como autenticación válida, según confirmaron ambas compañías y recogió The Next Web.

La brecha no explotó una vulnerabilidad de Dropbox ni de Lenovo, sino la costura entre los dos sistemas. La integración legada entre Lenovo ID y Dropbox confiaba en que el proveedor de identidad hubiera verificado la propiedad del correo; el atacante descubrió que ese paso de verificación podía saltarse. Una vez registrado el Lenovo ID fraudulento, el sistema de identidad vinculada de Dropbox heredaba la confianza sin volver a comprobarla, permitiendo acceso completo sin contraseña.

Las cifras concretas del incidente:

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

5.000 cuentas accedidas entre el 4 y el 21 de agosto.
En menos de un tercio (aproximadamente 1.650 cuentas) se vieron o descargaron archivos.
Ninguna de las 5.000 cuentas tenía autenticación multifactor (MFA) activada.
17 días de ventana no detectada por los sistemas de monitorización.
Las acciones de Dropbox cayeron alrededor de un 2,4% en operaciones extended, según reportó The Next Web.

El fallo exacto: un bypass de verificación de correo

Bleeping Computer obtuvo la notificación enviada por Dropbox a los usuarios afectados. El texto es claro: un problema en el proceso de verificación de correo electrónico de Lenovo permitió a un tercero "registrar un Lenovo ID usando tu dirección de correo electrónico" y luego "usar ese Lenovo ID para iniciar sesión en la cuenta de Dropbox asociada".

Uno de los afectados, el desarrollador Yoni Levy, publicó capturas en X mostrando un inicio de sesión desde cerca de Canary Wharf, Londres, con Chrome sobre Windows el 18 de agosto a las 6:06 hora local. Levy declaró no haber tenido nunca una cuenta Lenovo ni haber estado en el Reino Unido, según Decrypt.

Lo más revelador es un detalle que otro usuario, identificado como xaphod, señaló en foros: la pantalla de login de Dropbox empezó a ofrecer la opción "Continue with SSO" para su correo aunque nunca había creado un Lenovo ID. Esa aparición de un botón que no debería existir fue la primera señal de que algo estaba mal integrado.

Por qué el MFA habría detenido el ataque

El ataque era un bypass de contraseña: si la víctima hubiera tenido MFA activo, el atacante habría llegado al segundo factor y se habría detenido ahí. Dropbox confirmó a Decrypt que todas las cuentas afectadas "no tenían la autenticación de dos factores de Dropbox activada".

El patrón es consistente con lo que muestra la industria: según Verizon Data Breach Investigations Report recogido por Bleeping Computer, las credenciales robadas están involucradas en el 44,7% de las brechas. El MFA no es garantía absoluta — existen técnicas de phishing AiTM que capturan tokens de sesión en tiempo real — pero convierte este vector específico en inviable.

El patrón de las integraciones SSO heredadas

Este incidente no es un caso aislado. En 2025, según el mismo análisis de Bleeping Computer, la Universidad de Pensilvania sufrió una brecha de su SSO PennKey que terminó exponiendo datos de 1,2 millones de personas y dio acceso a VPN, Salesforce, Qlik, SAP y SharePoint. Era el mismo patrón: una credencial única abriendo múltiples sistemas.

Las integraciones SSO tienen tres propiedades que las hacen especialmente peligrosas cuando se olvidan:

Acumulan en silencio. Se configuran en un proyecto, resuelven un problema concreto y nadie las desactiva cuando ese proyecto termina.
Bypasean la contraseña de la cuenta objetivo. El atacante no necesita conocer ni filtrar credenciales; solo necesita que el proveedor de identidad afirme que el usuario es legítimo.
Hereda supuestos de seguridad del momento de implementación. Verificación de correo en 2018, validación de dominio en 2015, controles que parecían suficientes hace una década.

La palabra "legacy" en los comunicados de ambas compañías no es decorativa. Describe sistemas que siguen corriendo porque apagarlos podría romper algo, aunque nadie en el equipo actual recuerde exactamente para qué.

Qué hizo Dropbox (y qué deberían revisar los usuarios)

La respuesta de Dropbox, según recogieron The Next Web y Bleeping Computer, fue de corte clásico:

Terminó todas las sesiones autenticadas vía Lenovo ID.
Desactivó la integración por completo.
Exige ahora contraseña nativa de Dropbox antes de permitir cualquier acceso, incluso a través de SSO.
Notificó a usuarios el lunes posterior al cierre de la investigación.
Reportó el caso a reguladores de protección de datos, lo que activa el plazo de 72 horas del RGPD para usuarios europeos.

Lenovo, por su parte, confirmó que sus clientes propios no se vieron afectados: la falla estaba en cómo su sistema se conectaba a Dropbox, no en su servicio principal.

¿Qué significa esto para tu startup?

Si tu empresa usa Dropbox, Google Workspace, Notion, Slack o cualquier SaaS con SSO, asume que tienes integraciones que nadie ha revisado en años. El incidente de Dropbox-Lenovo es el ejemplo perfecto del riesgo que asume una startup cuando積aan integraciones sin auditoría periódica.

Acciones concretas que puedes tomar esta semana:

Audita las aplicaciones conectadas de cada cuenta crítica hoy mismo. En Dropbox: Ajustes → Aplicaciones conectadas. Revoca todo lo que no reconozcas o lleve más de seis meses sin uso. Lo mismo en Google Workspace (Seguridad → Apps de terceros con acceso a datos) y Microsoft 365 (Consentimientos de aplicaciones empresariales).
Fuerza MFA en todos los usuarios, sin excepciones y sin "usuarios de bajo riesgo". El bypass de contraseña del caso Dropbox no distingue entre cuentas con archivos importantes y cuentas vacías; usa la MFA resistente a phishing (FIDO2, WebAuthn o passkeys) para administradores y cuentas con datos sensibles.
Inventaría trimestralmente las integraciones SSO activas. Trata cada conexión OAuth o SAML como una superficie de ataque adicional. Automatiza alertas para integraciones sin actividad registrada en más de 90 días y revisa los consentimientos delegados — son el vector que los atacantes usan para mantener persistencia tras el acceso inicial.
Aísla las cuentas de servicio y los IdP admins del SSO principal. Si tu proveedor de identidad se ve comprometido, quieres que existan cuentas separadas con autenticación resistente a phishing capaces de cortar el acceso de emergencia.

El coste de la auditoría es bajo. El coste de enterarte por un incidente — como les ocurrió a las 5.000 víctimas de esta brecha — es siempre más alto.