hospedagem compartilhada
6 artigos com esta tag
Acesso não autorizado a alguns servidores web do ConoHa WING (GMO Internet) (426 contas): dados nas áreas de servidor web dos clientes afetados e o que os donos de sites devem fazer hoje
Em 20 de setembro de 2026, a GMO Internet, Inc. anunciou que, em alguns servidores de hospedagem (servidores web) do seu serviço de hospedagem de aluguel ConoHa WING, um terceiro obteve acesso não autorizado às áreas de servidor web de alguns clientes e instalou um programa malicioso. 426 contas foram afetadas, e os dados envolvidos são os 'dados armazenados nas áreas de servidor web dos clientes'. O acesso e a instalação começaram em 3 de setembro; a empresa detectou o caso em 16 de setembro e, em 18 de setembro, identificou a causa e a abrangência e removeu os programas. Ela diz ter identificado a causa, mas não a divulgou. Dados de membros, contratos e pagamentos são gerenciados em um ambiente separado e não vazaram, segundo a empresa. O comunicado não diz se os dados das áreas de servidor web foram copiados. Os clientes afetados foram contatados individualmente no endereço de e-mail cadastrado, e os clientes que não foram contatados não são afetados. Não houve comunicado de acompanhamento até 15 de outubro. A visão deste site: primeiro verifique se você recebeu um e-mail individual e, se recebeu, siga as instruções dele. Depois, trate as credenciais guardadas na sua área de servidor web (a senha do banco de dados em wp-config.php, chaves de API em .env etc.) como lidas e troque-as, e procure arquivos, administradores e tarefas agendadas adicionados desde 3 de setembro.
Como verificar se o seu site ou servidor foi invadido: verificações passo a passo para hospedagem compartilhada, WordPress e VPS, e o que fazer primeiro se encontrar algo
Verificar se um site foi invadido significa olhar tanto os sinais visíveis de fora quanto os rastros deixados dentro. Sinais: o relatório Problemas de segurança do Search Console, um rótulo 'Este site pode ter sido invadido' na busca, um aviso da hospedagem, administradores desconhecidos, redirecionamentos que acontecem só no celular ou a partir da busca. Rastros: usuários administradores, arquivos do núcleo modificados (wp core verify-checksums), histórico de login, authorized_keys, cron, portas em escuta, arquivos alterados recentemente. A visão deste site: não encontrar nada não prova que está limpo. Se encontrar algo, preserve as evidências antes de limpar, troque todas as credenciais a partir de um aparelho limpo, restaure um backup anterior à invasão ou reconstrua, feche o ponto de entrada e só então peça uma revisão.
Quando o seu provedor de hospedagem é invadido: o que os clientes devem fazer
Um comprometimento do lado do provedor não pode ser bloqueado pelas configurações do cliente, então a defesa passa de prevenir para limitar o quanto você pode perder. Os resultados da investigação de 10 de setembro estabeleceram a parte que mais importa: o acesso não autorizado ao sistema de gestão de vendas ocorreu entre abril de 2023 e março de 2026, as contas de hospedagem afetadas subiram de 583 para 951, e algumas senhas iniciais não tinham hash. A visão deste site: trate tudo o que está em hospedagem compartilhada como legível, leve segredos, credenciais e backups para fora do provedor e troque hoje qualquer senha inicial que você ainda esteja usando.
Você deixou um arquivo de segredo em um diretório público? Audite seu webroot
Qualquer coisa no seu webroot pode ser baixada pela URL por qualquer um. Um JSON de token/credenciais esquecido, um .env ou um backup significam exposição instantânea — e se veio de um template compartilhado, todo site tem o mesmo arquivo. Correção: coloque no diretório público só o que pode ser compartilhado, mantenha segredos fora do webroot com permissão 600 e, ao achar um, audite todos os sites e hosts.
Um caso em que o .env do Laravel ficou legível publicamente: um erro de posicionamento em hospedagem compartilhada e como corrigi-lo
A causa: o app inteiro ficava sob a raiz web; só o public/ deveria estar visível. Corrija em três passos — um bloqueio temporário com .htaccess, rotacione chaves, reestruture — depois previna com processo.
Mantendo o .env fora da web pública em hospedagem compartilhada
A correção principal: corpo do app fora do docroot, só public/ exposto. Bloqueie o acesso com .htaccess primeiro, torne-o permanente reestruturando e então autoverifique. A visão deste site: isto não é o deslize de uma pessoa, mas um layout perigoso que virou padrão em todo o setor — corrija com processo, não com vigilância. bootstrap-redirect vence o symlink.