Dropbox teve 5 mil contas invadidas via integração legada com Lenovo ID

O Dropbox confirmou que cerca de 5.000 contas foram comprometidas em agosto, com invasores visualizando e baixando conteúdo armazenado na plataforma de cloud storage. O anúncio veio na terça-feira (02/09/2026), depois que a Bloomberg noticiou o ataque mais cedo no mesmo dia, segundo reportagem da Reuters publicada pelo ET Tech.

Segundo a empresa, o acesso não autorizado aconteceu entre 4 e 21 de agosto. Alguns usuários receberam e-mail de notificação na segunda-feira informando que suas contas foram acessadas nesse período. Em menos de um terço das contas comprometidas os invasores chegaram a acessar arquivos, informou o Dropbox. As ações da companhia caíram cerca de 2,4% no after-hours de terça.

O vetor: uma integração legada com o Lenovo ID

O ponto que mais interessa a quem constrói software é como isso aconteceu. O Dropbox disse à Reuters que identificou acesso não autorizado afetando contas vinculadas a um Lenovo ID que não tinha a autenticação de dois fatores (2FA) habilitada. A Lenovo, por sua vez, identificou uma "integração legada" (legacy integration) entre o Lenovo ID e o Dropbox que "poderia ser usada para autenticar indevidamente certas contas Dropbox".

Em outras palavras: um mecanismo antigo de login federado (entrar no Dropbox usando as credenciais de um Lenovo ID) permitia autenticar contas sem passar pela camada de segurança adicional que o segundo fator exige. Onde não havia 2FA no elo Lenovo, o portão ficou aberto.

A Lenovo afirmou que seus próprios clientes não foram afetados e que a investigação segue em andamento.

A resposta do Dropbox, ponto a ponto

As ações tomadas pela empresa dão pistas de onde estava o problema:

• Encerrou todas as sessões autenticadas via Lenovo ID.
• Removeu qualquer vínculo entre Lenovo IDs e contas Dropbox.
• Alterou o sistema para exigir que o usuário digite a senha do Dropbox antes de acessar a conta pelo caminho Lenovo, quebrando o single sign-on automático que permitia o abuso.
• Reportou o incidente aos reguladores de proteção de dados.

A sequência mostra que a mitigação foi cirúrgica no fluxo de autenticação federada, não uma falha genérica de senha de todos os usuários. Mas isso não muda o recado para o resto da base.

O que isso muda para o dev que usa Dropbox

Aqui vale separar o que é fato da fonte do que é leitura de segurança aplicada. O fato: contas sem 2FA no elo Lenovo foram exploradas. A leitura óbvia para quem desenvolve: o segundo fator não é opcional, ainda mais quando a conta guarda coisas que não deveriam vazar.

E é aí que mora o risco real para nosso público. Dropbox é frequentemente usado, na prática, como repositório informal de artefatos que não deveriam estar lá:

• arquivos .env e configs com credenciais;
• chaves privadas SSH/GPG, .pem, id_rsa;
• dumps de banco e backups de produção;
• código-fonte de projetos privados que não foram para o Git;
• tokens de API em planilhas, PDFs e prints.

Se qualquer um desses esteve numa conta comprometida (e lembre: os invasores baixaram conteúdo em parte das contas), o vazamento de arquivo é só o começo, o problema vira credencial válida circulando por aí.

Checklist prático de resposta

Independente de ter recebido o e-mail do Dropbox, o caminho que faz sentido seguir agora:

1. Confirme se recebeu a notificação oficial do Dropbox (cheque também a caixa de spam) e verifique o histórico de sessões e dispositivos conectados na conta.
2. Ative o 2FA se ainda não estiver ligado, de preferência com app autenticador (TOTP) ou chave física, não SMS.
3. Troque a senha do Dropbox e não a reaproveite em outro serviço.
4. Rotacione toda credencial que possa ter passado pela conta: chaves de API, tokens, secrets de .env, chaves SSH. Se você não tem certeza do que estava lá, trate como comprometido.
5. Tire segredo de storage de arquivo. Secrets vão para um cofre (Vault, AWS↳AWS20 conteúdosE-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envioDevSecOps · out 2025Codex na AWS: chegada do agente da OpenAI à nuvem da AmazonDevSecOps · abr 2026Salesforce e AWS ampliam colaboração em IA, CRM e marketplaceDevSecOps · nov 2023Ver tudo em DevSecOps → Secrets Manager, GCP Secret Manager, 1Password, doppler), não para pasta sincronizada.
6. Revise integrações e SSO legados de outras contas: o vetor aqui foi exatamente uma federação antiga esquecida. Vale auditar apps de terceiros conectados às suas contas críticas.

O que ainda está em aberto

A fonte não detalha quem foram os responsáveis, se os arquivos baixados já circulam ou qual o volume exato de dados exfiltrados, além da informação de que arquivos foram acessados em menos de um terço das 5.000 contas. A investigação da Lenovo continua, e não há, até a publicação, menção específica a impacto no Brasil.

O episódio reforça um padrão que já vimos em outros vazamentos: a superfície de ataque raramente é o sistema principal, e sim uma integração antiga, um SSO federado que ninguém revisava, um elo que sobreviveu a migrações. Para quem mantém identidade federada entre serviços, o Lenovo ID aqui é um lembrete de que cada ponte de autenticação é também uma porta, e portas legadas envelhecem mal.

Fonte: ET Tech (Índia)