Guias de Segurança
Quando o seu provedor de hospedagem é invadido: o que os clientes devem fazer
O relatório final da Sakura Internet: 951 contas de hospedagem, uma invasão de três anos, senhas iniciais sem hash. O que está confirmado, o que não está e o que os clientes devem fazer hoje.
Para quem é: qualquer pessoa que mantém um site ou caixa de e-mail em hospedagem compartilhada. Este guia trata do caso em que você não fez nada de errado e quem foi comprometido foi o seu provedor. Ele se baseia em informações públicas — a divulgação do próprio provedor e as reportagens sobre ela — e não contém técnicas de ataque.
Este artigo usa o caso da Sakura Internet em 2026 para mostrar o que um cliente pode de fato fazer quando o provedor que ele paga é quem foi invadido. Os detalhes do caso vêm depois dos passos. Se você não tem certeza de que foi afetado, faça os passos 1 e 2 de qualquer forma.
Faça isto primeiro (em ordem — pule o que não se aplica)
Se você tem qualquer conta na Sakura Internet, pode estar no escopo — sendo cliente de hospedagem ou não
O que o segundo relatório envolve é o sistema de gestão de vendas que guarda os registros de contratos, e o FAQ da empresa afirma que o escopo não se limita aos clientes de servidores de aluguel. Um cadastro de membro só de domínio, só de VPS ou parado há muito tempo pode estar no escopo. A orientação passou do "vamos contatar você individualmente se for necessária alguma ação" do primeiro relatório para conselhos preventivos concretos. Se esse é o seu caso, faça o passo 1 hoje.
Troque qualquer senha que você reutilizou em outro lugar (prioridade máxima)
A atualização do FAQ de 21 de agosto definiu a prioridade de forma explícita. O painel de membros exige autenticação de dois fatores no login, então "só uma senha não consegue entrar, e não há forte necessidade de trocá-la imediatamente". O que a empresa recomenda com ênfase: se a mesma senha é usada em outros serviços web, troque-a nesses outros serviços. O que precisa ser protegido não é o serviço que vazou, mas os outros serviços em que a mesma senha funciona. É assim que um incidente do lado do provedor costuma virar um incidente seu. Um gerenciador de senhas é o que torna essa revisão viável.
Se ainda usa a senha inicial do cadastro, troque hoje
O relatório de 10 de setembro revelou uma categoria de dados que não tinha sido mencionada antes: algumas senhas iniciais de servidor do serviço de hospedagem compartilhada e algumas senhas iniciais de administrador do produto VPS. A empresa descreve essas senhas como "sem hash".
Essa diferença decide tudo. Com hash, a senha original é difícil de recuperar — e é por isso que as senhas de 30 IDs de membro são tratadas como precaução, não como emergência. Sem hash, uma senha que foi lida pode ser usada para entrar do jeito que está. A empresa está contatando diretamente os clientes afetados e pedindo que troquem qualquer senha inicial ainda em uso.
O teste é simples: se você trocou a senha em qualquer momento depois do cadastro, isto não se aplica a você. Se não lembra de ter trocado, ou ainda usa as credenciais da mensagem de boas-vindas, troque hoje — e verifique com um gerenciador de senhas se essa mesma senha é usada em algum outro lugar. Por que deixar uma senha emitida sem trocar é arriscado em geral está em hábitos com senhas que realmente importam.
Troque as senhas do servidor e do e-mail e verifique o seu segundo fator
Para clientes de hospedagem, a empresa cita a senha do servidor (FTP) e as senhas das contas de e-mail, e recomenda trocá-las por precaução. Aproveite para verificar as configurações de dois fatores e passe de códigos enviados por e-mail para SMS ou um app autenticador — num incidente em que os próprios dados de e-mail podem ter sido lidos, um código enviado para essa caixa é um segundo fator fraco. O FAQ também pede que os clientes confirmem se o e-mail e o telefone cadastrados ainda funcionam, e que limpem as contas que não usam mais. Faça tudo entrando no site oficial por conta própria, nunca por um link num e-mail. A exposição de senhas com hash citada até agora abrange 30 contas, mas os clientes não têm como saber se estão entre elas — e é exatamente por isso que agir de forma preventiva é racional.
Faça o inventário dos segredos naquele servidor e tire-os de lá
Procure arquivos .env, dumps de banco de dados, arquivos de backup, arquivos de configuração com chaves de API, CSVs de clientes — em qualquer lugar dentro ou perto do diretório publicado. O que este incidente lista como possivelmente exposto é justamente "informações armazenadas na área do cliente". Suponha que tudo o que está ali foi lido. Para detalhes de organização, veja como manter o .env fora de alcance em hospedagem compartilhada e o que nunca deve ficar num diretório público.
Separe as credenciais da hospedagem de todo o resto
As senhas do painel de controle, FTP/SSH, e-mail e banco de dados não devem existir em nenhum outro lugar, para que uma exposição não se espalhe para outras contas. Coloque autenticação multifator no painel de controle e prefira passkeys onde houver. Um gerenciador de senhas é o que torna isso sustentável.
Mantenha um backup fora do provedor
Se o provedor é a parte comprometida, backups guardados dentro desse mesmo provedor perdem parte da confiabilidade. Mantenha uma cópia localmente ou num provedor sem relação — e uma da qual você já tenha restaurado de fato pelo menos uma vez. O modelo está em o essencial de backup e recuperação (a regra 3-2-1).
Verifique os três sinais e espere phishing
As verificações que a empresa pediu aos clientes: arquivos ou contas de administrador desconhecidos, mudanças sem explicação no site ou aplicativo, e logins ou envios de e-mail que você não consegue explicar. Espere uma onda de phishing se passando pela empresa de hospedagem — a empresa afirma claramente que nunca pede senhas, credenciais ou dados de cartão por e-mail ou telefone. O FAQ adicionado em 2 de setembro indica support@sakura.ad.jp como remetente dos avisos — trate isso como motivo para rejeitar uma mensagem que não bate, não como prova de que uma que bate é genuína, já que endereços de remetente podem ser falsificados. Não siga links nesses e-mails; entre no site oficial por conta própria.
O que foi divulgado (pelas declarações da própria empresa)
A Sakura Internet Inc. divulgou o acesso não autorizado em 17 de agosto de 2026, publicou um segundo relatório em 19 de agosto e, em 10 de setembro, publicou os resultados da investigação e o plano de correção. O mais importante nesse relatório final não é o número de pessoas — é há quanto tempo isso estava acontecendo. Tudo abaixo vem das declarações da própria empresa e do FAQ dela.
Abril de 2023 – março de 2026
(estabelecido no relatório final) O período em que ocorreu o acesso não autorizado ao sistema de gestão de vendas. A empresa afirma que "confirmou que ocorreu entre abril de 2023 e março de 2026" — cerca de três anos.De julho de 2025 em diante
(estabelecido no relatório final) Foram encontrados no ambiente de hospedagem compartilhada vestígios de atividade suspeita que se acredita serem de julho de 2025 ou depois.9 ago. 2026
Uma anomalia foi detectada num servidor de manutenção do serviço de hospedagem compartilhada, e a investigação começou. Foi aí que a detecção começou — a atividade no sistema de gestão de vendas já tinha terminado cinco meses antes.Durante a investigação
Confirmou-se que um terceiro tinha chegado a alguns ambientes de clientes por meio do ambiente de gerenciamento da empresa, e que malware tinha sido colocado em alguns servidores.Logo após a confirmação
Contenção: credenciais invalidadas, acesso bloqueado, malware removido.17 ago. 2026
Primeiro relatório (583 contas), além de comunicações ao Ministério de Assuntos Internos e Comunicações, à Comissão de Proteção de Informações Pessoais e a outras autoridades.19 ago. 2026
Segundo relatório: possível acesso ao sistema de gestão de vendas, 1.360.563 contas de membros potencialmente no escopo, e uma página de FAQ dedicada.10 set. 2026
Resultados da investigação e plano de correção: o número sobe para 951 contas, o período da invasão é definido, algumas senhas iniciais são reveladas como sem hash, e a empresa conclui que não foram encontrados fundamentos claros ligando os dois eventos.
- 951 contas de hospedagem (eram 583 antes do relatório final)
- Identificadores de usuário e dados armazenados na área do cliente — dados de e-mail, dados do site, dados de log e outros arquivos guardados na área do cliente
- 1.360.563 contas de membros
- Registros de contrato — ID de membro, nome da empresa, departamento, endereço, nome, telefone, e-mail, data de nascimento, gênero, número de fax, serviços contratados, período do contrato, valores cobrados e similares
- 30 dessas contas
- Dados de senha com hash (a empresa define isso como dados a partir dos quais é difícil recuperar a senha original)
- Dados de cartão de pagamento
- A empresa afirma que não armazena dados de cartão, então nenhum foi exposto
- Senhas iniciais sem hash
- Algumas senhas iniciais de servidor do serviço de hospedagem compartilhada e algumas senhas iniciais de administrador do produto VPS. O relatório final afirma que elas "não tinham hash", e a empresa está pedindo que os clientes que ainda usam uma senha inicial emitida a troquem
- Exfiltração
- O relatório final afirma que "não foram identificados fatos claros que confirmem que dados foram levados para fora da empresa", e que não foi observada nenhuma publicação na internet ou na dark web
- Quem está no escopo
- O FAQ afirma claramente que o escopo não se limita aos clientes de servidores de aluguel — qualquer pessoa com cadastro de membro está sendo examinada
Não interprete errado o 1,36 milhão (atualizado com o relatório final)
1.360.563 é o número de registros de membros potencialmente no escopo, não um vazamento confirmado — o FAQ da empresa diz explicitamente que não há constatação de que todos eles vazaram. Também não é motivo de tranquilidade. Quatro pontos orientam o que você realmente faz. (1) O caminho da invasão continua sem divulgação mesmo no relatório final — a empresa afirma que está retendo os detalhes técnicos sobre o caminho da invasão e a configuração dos sistemas para não facilitar ataques imitadores. (2) "Possível acesso" não é "foi exfiltrado". (3) A exposição de senhas com hash abrange 30 contas — espere que esse número seja confundido com o 1,36 milhão nas reportagens de segunda mão. (4) Mas as senhas iniciais sem hash são um item separado, revelado em 10 de setembro, e esse exige ação hoje. Não transforme incertezas em fatos, e não leia "não confirmado" como "está tudo bem".
Por que o reforço do lado do cliente não impede isso
Atacante
↓ caminho de entrada não divulgado
Ambiente de gerenciamento do provedor
↓ chega aos ambientes dos clientes por aqui
O seu ambiente
arquivos / banco de dados / e-mail
O que um cliente pode aplicar
senhas fortes, apps atualizados, restrição de IP — nenhum deles fica nesse caminho
A única variável que você controla é o que está guardado naquela área. Então a meta não é "manter os invasores do lado de fora", mas "fazer com que ser lido não seja um desastre".
Fora do seu controle
- A invasão do ambiente de gerenciamento do provedor
- Atacantes chegando à sua área por esse caminho de gerenciamento
- Ficar sabendo rapidamente — aqui, passaram-se oito dias entre a detecção e a divulgação; levar tempo para investigar antes de divulgar é normal, e nesse meio-tempo os clientes não tinham como saber
Você decide
- O que você guarda ali — segredos, dados pessoais, credenciais
- Se aquela senha também funciona em outro lugar
- Se o seu único backup fica dentro do mesmo provedor
- Se você tem algum meio de perceber que algo está errado
A visão deste site: reduzir o que você perderia vale mais do que trocar de contrato
Todo incidente desse tipo gera o conselho "saia da hospedagem compartilhada, contrate uma VPS". Não recomendamos isso como resposta padrão. Uma VPS isola mais, mas também entrega a você toda a responsabilidade pelas correções do sistema operacional e do middleware; sem capacidade operacional para acompanhar, o resultado é um servidor abandonado que vira a sua própria porta de entrada. Este site roda numa infraestrutura que não é exclusiva dele, e o princípio de operação ali é "tornar suportável se aquele host for lido" — segredos guardados como variáveis de ambiente gerenciadas fora da árvore publicada, credenciais limitadas por finalidade, e a cópia oficial dos backups e do conteúdo publicado mantida em outro lugar. O tipo de contrato não é uma defesa; é um fator que influencia quanto dano uma invasão pode causar.
Como a divulgação evoluiu: do primeiro relatório ao relatório final
Os fatos de um incidente nunca chegam todos de uma vez. Neste caso, os detalhes que mudaram o que os clientes deviam fazer apareceram no FAQ antes de aparecerem num comunicado à imprensa. A seguir, só o que se soube depois, em ordem.
O que a atualização do FAQ de 2 de setembro acrescentou
Em 2 de setembro, a empresa adicionou várias entradas ao FAQ. Nenhum terceiro comunicado à imprensa foi emitido, mas as informações que mudam o que os clientes devem fazer aparecem primeiro no FAQ. Quem acompanha só a página de comunicados à imprensa vai achar que nada está acontecendo.
Cancelar um serviço não é o mesmo que apagar a conta — ex-clientes também estão no escopo
Perguntada por que pessoas que já tinham cancelado estavam recebendo avisos, a empresa explicou que cancelar um serviço (encerrar um contrato ativo) e sair do cadastro de membro (pedir a exclusão do registro de membro) são procedimentos separados, e que os registros de membros são mantidos a menos que você saia do cadastro. O sistema de gestão de vendas que foi acessado guardava exatamente esses registros, então pessoas que não usam mais nenhum serviço da Sakura continuam no escopo.
Isso não é exclusivo de um provedor. Um serviço que você parou de usar não apagou os seus dados só porque você cancelou a assinatura — quando ele é invadido, as contas de que você tinha esquecido são invadidas junto. Uma vez por ano, leve os serviços que você não usa mais além do cancelamento, até a exclusão real da conta. Reduzir o número de contas paradas compensa mais ou menos tanto quanto parar de reutilizar senhas. O mesmo padrão, em que algo que você parou de usar vira uma fraqueza, aparece na tomada de subdomínio.
"Não confirmado" não é o mesmo que "não aconteceu"
As novas entradas delimitam as perguntas que os clientes de fato fazem. Todas são formuladas como "até o momento, esse fato não foi confirmado", e a investigação continua aberta. Leia-as como pendentes, não como negações.
- Corpo dos e-mails e e-mails recebidos
- Nenhum fato confirmado de que o corpo das mensagens ou os e-mails recebidos nas contas de e-mail foram visualizados ou levados — o segundo relatório trata do sistema que guarda os registros de contratos
- Dados do WordPress, dados do site, envios de formulários de contato
- Nenhum fato confirmado de que foram visualizados ou levados por um terceiro
- Configurações de domínio e DNS
- Nenhum fato confirmado de alteração não autorizada; a empresa sugere revisar as suas configurações no painel de membros
- Confirmação por cliente
- A empresa afirma que não tem condições de confirmar, cliente por cliente, se os dados foram visualizados ou levados. Então "não fui contatado" não significa "não fui afetado" — agir de forma preventiva é a única opção disponível
O que o relatório de 10 de setembro estabeleceu: a duração importa mais do que o número
Cerca de três anos. Esse é o fato mais importante do relatório
A empresa afirma que "foi confirmado que o acesso não autorizado ao sistema de gestão de vendas ocorreu entre abril de 2023 e março de 2026". No ambiente de hospedagem, também foram encontrados vestígios que se acredita serem de julho de 2025 ou depois. Mesmo assim, a anomalia que deu início à investigação foi detectada em 9 de agosto de 2026 — e foi detectada num servidor de manutenção do serviço de hospedagem.
Ou seja, a atividade no sistema de gestão de vendas já tinha parado cinco meses antes de alguém perceber. Os números das manchetes (1,36 milhão, 951) circulam mais porque são fáceis de citar, mas o que quem defende deve tirar disso é o tempo que a invasão passou sem ser vista. O fato de a própria lista de correções da empresa incluir "revisar o escopo dos logs de segurança, os prazos de retenção e a capacidade de análise" mostra que eles chegaram à mesma conclusão.
Estabelecido em 10 de setembro
- O acesso não autorizado ao sistema de gestão de vendas durou de abril de 2023 a março de 2026
- Os vestígios no ambiente de hospedagem são de julho de 2025 em diante
- O escopo subiu de 583 para 951 contas (368 acrescentadas pela investigação posterior)
- Algumas senhas iniciais não tinham hash — senhas iniciais de servidor da hospedagem compartilhada, senhas iniciais de administrador do produto VPS
- Não foram encontrados fundamentos claros ligando os dois eventos
Ainda não confirmado, mesmo no relatório final
- Qualquer fato claro que confirme que dados foram levados para fora da empresa
- Publicação na internet ou na dark web
- Uso indevido secundário, uso fraudulento ou prejuízo financeiro
- O caminho da invasão — retido explicitamente para não facilitar ataques imitadores
A visão deste site: para um cliente, o valor deste relatório está numa frase sobre senhas iniciais
O relatório lista sete medidas de correção, e quase todas são coisas que só o provedor pode fazer — auditar privilégios administrativos, ampliar a cobertura de EDR, reconstruir todos os servidores, contratar auditorias externas. Só um trecho diz a um cliente para fazer algo hoje: o que diz que certas senhas iniciais não tinham hash. Diante de um relatório de incidente longo, o instinto é querer entender tudo; o hábito mais útil é o contrário — encontrar primeiro as variáveis que você controla. O resto é material para escolher o próximo provedor, não para hoje à noite.
Mais uma coisa. "Três anos sem ser percebido" não é uma afirmação de que esta empresa é incomum — invasões descobertas só depois de um ano ou mais continuam sendo relatadas, no Japão e em outros lugares. Por isso, a suposição sensata do lado do cliente é que um provedor vai ser invadido algum dia. É também por isso que a conclusão deste artigo não muda: reduza o que você perderia.
Fontes
Os fatos acima vêm dos registros públicos a seguir. Nenhuma inferência sobre o caminho da invasão, e nenhuma afirmação além do que foi publicado.
- Sakura Internet Inc., "Sobre o acesso não autorizado a parte do ambiente do nosso serviço de servidores de aluguel" (primeiro relatório, publicado em 17 de agosto de 2026) — sakura.ad.jp
- Sakura Internet Inc., "Aviso sobre o acesso não autorizado aos nossos sistemas (segundo relatório)" (publicado em 19 de agosto de 2026, atualizado às 18h40 do mesmo dia) — sakura.ad.jp
- Sakura Internet Inc., "Resultados da investigação e medidas de correção sobre o acesso não autorizado aos nossos sistemas (terceiro relatório)" (publicado em 10 de setembro de 2026) — sakura.ad.jp
- Sakura Internet Inc., "Aviso e FAQ" (publicado em 19 de agosto de 2026, atualizado em 21 de agosto e 2 de setembro; verificado de novo para este artigo em 10 de setembro de 2026) — help.sakura.ad.jp
- Reportagens do INTERNET Watch, ITmedia NEWS e Nikkei (17 e 19 de agosto de 2026), todas baseadas nas declarações acima
Histórico de atualizações
2026-09-21: Reestruturado. Os passos agora vêm primeiro para que o leitor possa agir, e a sequência do primeiro ao relatório final está reunida em "Como a divulgação evoluiu", no fim. Nenhum fato foi acrescentado ou alterado (a data de verificação não mudou).
2026-09-10: Incorporados os resultados da investigação e o plano de correção (terceiro relatório). O acesso não autorizado ao sistema de gestão de vendas agora está estabelecido como ocorrido de abril de 2023 a março de 2026, com vestígios no ambiente de hospedagem a partir de julho de 2025. O escopo subiu de 583 para 951 contas. A empresa revelou que algumas senhas iniciais de servidor da hospedagem compartilhada e algumas senhas iniciais de administrador do produto VPS não tinham hash, então um passo foi adicionado (trocar hoje qualquer senha inicial ainda em uso). A empresa concluiu que não há fundamentos claros ligando os dois eventos. A exfiltração continua não confirmada, e o caminho da invasão é retido explicitamente para não facilitar ataques imitadores.
2026-09-05: Incorporada a atualização do FAQ de 2 de setembro. A empresa explicou que cancelar um serviço e sair do cadastro de membro são procedimentos separados, e que os registros de membros são mantidos até a saída do cadastro, e é por isso que ex-clientes estão no escopo. Também delimitou o corpo dos e-mails, os dados do WordPress e do site, os envios de formulários de contato e as configurações de DNS ("nenhum fato confirmado" até aquela data, com a investigação ainda aberta), e afirmou que não consegue confirmar a exposição cliente por cliente. Uma nova seção cobre tudo isso, e foi acrescentado o endereço de remetente usado nos avisos (support@sakura.ad.jp). O caminho da invasão continua sem divulgação; o próximo anúncio está previsto para meados de setembro de 2026.
2026-08-22: Incorporada a atualização do FAQ de 21 de agosto. O painel de membros exige autenticação de dois fatores, então a empresa diz que não há forte necessidade de trocar essa senha imediatamente; o que ela recomenda é trocar qualquer senha reutilizada em outros serviços. Os passos foram reordenados de acordo, e a troca das senhas do servidor e do e-mail e a verificação do segundo fator viraram um passo separado. A confirmação dos dados de contato cadastrados e a limpeza de contas sem uso também foram acrescentadas ao FAQ. Nenhum terceiro comunicado à imprensa tinha sido publicado até a redação.
2026-08-20: Incorporado o segundo relatório (19 de agosto). Possível acesso não autorizado ao sistema de gestão de vendas que guarda os registros de contratos, com 1.360.563 contas de membros potencialmente no escopo (dados de senha com hash de 30 delas). O FAQ da empresa passou a recomendar uma troca de senha preventiva, que virou o primeiro passo, e o escopo deixou de se limitar aos clientes de servidores de aluguel. O caminho da invasão continua sem divulgação.
2026-08-18: Primeira versão, com base na primeira divulgação.
Leia a seguir
- Comparando os principais casos de 2026: o que KDDI, Aflac, a Agência Digital e a Sakura Internet têm em comum
- Quando a VPN é a porta de entrada: equipamentos de VPN são a principal porta de entrada do ransomware: defesa do acesso remoto depois do vazamento da Agência Digital
- Verificando o seu próprio site: como verificar se o seu site ou servidor foi invadido (hospedagem compartilhada, WordPress, VPS)
- Prática: como manter o .env fora de alcance em hospedagem compartilhada / o essencial de backup e recuperação / como escolher a autenticação multifator
- Termos: o que é phishing / o que é malware
- Caso: o ataque à cadeia de suprimentos da Codecov (2021) — o mesmo formato, em que um caminho confiável é comprometido e os clientes não conseguem bloqueá-lo sozinhos
- Um caso na nuvem de um fornecedor: vazamento de endereços de e-mail da JR East, VIEW Card e JR Kyushu (acesso não autorizado à plataforma em nuvem por trás do serviço de envio de e-mails)
- O padrão: os vazamentos de 2026 vieram por credenciais válidas (uma leitura cruzada das divulgações japonesas)
FAQ
QSe o meu provedor de hospedagem foi invadido, a culpa é minha?
Não. Quando os atacantes chegam aos ambientes dos clientes pelo próprio ambiente de gerenciamento do provedor, nenhuma configuração do lado do cliente impede essa invasão — é uma situação diferente de um site tomado por uma senha fraca ou por um aplicativo sem correção. O que você controla é o quanto fica exposto quando isso acontece: mantenha segredos fora da área acessível pela web, nunca reutilize a senha da hospedagem e mantenha backups fora do provedor.
QO que devo verificar agora?
Três coisas: arquivos ou contas de administrador que você não reconhece, mudanças sem explicação no seu site ou aplicativo, e logins ou envios de e-mail que você não consegue explicar. Essas são as verificações que a Sakura Internet pediu aos clientes. Além disso, trate como suspeita qualquer mensagem com tom de urgência que diga vir da sua empresa de hospedagem até verificar, entrando por conta própria.
QDevo trocar as minhas senhas?
Pare de reutilizá-las imediatamente — isso ajuda independentemente de qualquer incidente. Para o serviço afetado em si, os provedores costumam avisar individualmente os clientes afetados; a Sakura Internet declarou que vai contatar diretamente os clientes afetados se uma troca de senha ou outra ação for necessária. Verifique o site oficial em vez de agir por um link dentro de um e-mail.
QEu já cancelei o serviço. Por que recebi um aviso?
Numa entrada do FAQ adicionada em 2 de setembro, a Sakura Internet explicou que cancelar um serviço e sair do cadastro de membro são dois procedimentos diferentes: a menos que você saia do cadastro, o seu registro de membro é mantido. O sistema de gestão de vendas que foi acessado guardava esses registros de membros, então ex-clientes que não usam mais nenhum serviço também estão no escopo. A empresa diz que os avisos dela vêm de support@sakura.ad.jp e que ela nunca pede senhas ou credenciais por e-mail ou telefone. Se uma mensagem parecer duvidosa, não use os links dela — abra a página oficial por conta própria.
QAinda uso a senha inicial emitida quando me cadastrei. O que faço?
Troque hoje. Nos resultados da investigação de 10 de setembro de 2026, a Sakura Internet revelou que algumas senhas iniciais de servidor do serviço de hospedagem e algumas senhas iniciais de administrador do produto VPS, nas palavras da própria empresa, 'não tinham hash', e está contatando os clientes afetados para pedir que troquem qualquer senha inicial ainda em uso. O hash torna difícil recuperar a senha original; sem ele, uma senha que foi lida pode ser usada para entrar do jeito que está. Se você trocou a senha em qualquer momento depois do cadastro, este item não se aplica a você.
QPor que o número subiu de 583 para 951 contas?
Por causa de investigação adicional. A empresa afirma que 583 contas foram informadas como possivelmente visualizadas ou levadas em 17 de agosto, e que o trabalho posterior identificou mais 368 contas com a mesma possibilidade, chegando a 951 no total. Ela também observa que não foi estabelecida uma ligação clara entre essas 368 contas adicionais e o evento original. Números que sobem durante uma investigação são normais na resposta a incidentes — não trate um número do primeiro relatório como definitivo.
QDevo trocar a hospedagem compartilhada por uma VPS?
Não automaticamente. Uma VPS dá um isolamento mais forte, mas passa para você a aplicação de correções do sistema operacional e do middleware. Sem capacidade operacional para acompanhar, você só cria um servidor abandonado com um novo conjunto de portas de entrada. O que importa mais do que o tipo de contrato é se perder aquele servidor custaria muito para você.