O que aconteceu

A Apify publicou um aviso de segurança informando que uma terceira parte não autorizada acessou partes de seus sistemas internos entre 9 e 10 de novembro de 2026. A empresa detectou a atividade em 11 de novembro, às 12:13 UTC, interrompeu o caminho de acesso e iniciou uma investigação. Em atualização publicada em 13 de novembro, a Apify informou que continua analisando o incidente e que já notificou clientes cujo dado pessoal ou dado armazenado foi acessado.

O comunicado não apresenta, até o momento, uma causa raiz completa nem uma lista pública de todos os registros envolvidos. Por isso, a leitura correta é de um incidente em investigação, com medidas de contenção e comunicação em andamento. Usuários devem conferir mensagens recebidas diretamente da Apify, sem assumir que a ausência de um e-mail elimina todos os riscos futuros.

Como funciona

O caminho descrito pela Apify começou com uma credencial comprometida. Essa credencial foi usada para obter um número de credenciais de contas e acessar contas relacionadas. O aviso não detalha publicamente a identidade da credencial, o método inicial de comprometimento ou a sequência completa de ações. Mesmo assim, o caso ilustra um padrão comum: quando um segredo privilegiado é reutilizado ou aceito por muitos serviços, o invasor pode transformar uma única exposição em acesso lateral.

A plataforma combina API, Actors, integrações externas e storages. Tokens de API podem permitir autenticação automatizada, enquanto integrações OAuth conectam a conta a outros serviços. Storages podem conter dados produzidos por Actors ou arquivos enviados por equipes. A superfície de risco, portanto, não é apenas a senha do usuário. Ela inclui tokens, conexões, permissões, identificadores de storage, repositórios e segredos usados pelos próprios projetos.

Quem foi afetado

A página de status informa que o incidente afeta a API, os Actors e a área geral da Apify. Em uma atualização, a empresa disse que notificou individualmente clientes cujo dado pessoal ou dado armazenado foi acessado. Também informou que, se não houver e-mail, a conta não foi identificada como afetada até aquele momento. Essa frase deve ser tratada como um retrato da investigação, não como uma garantia permanente.

Equipes que criam Actors a partir de repositórios privados do GitHub receberam uma orientação específica para reconectar o GitHub. Usuários de outras integrações podem ser convidados a reconectar por e-mail. Como conexões OAuth foram revogadas por precaução, automações podem falhar mesmo sem evidência de que o OAuth tenha sido o vetor do ataque.

Como identificar

Comece por uma linha do tempo. Registre quando cada token foi criado, usado e revogado; quais Actors executaram durante o período de 9 a 11 de novembro; quais storages foram lidos; e quais integrações perderam a autorização. Compare os logs de auditoria com o calendário de deploys e com os horários normais de execução.

Procure sinais como chamadas de API fora das regiões ou horários habituais, criação de tokens que ninguém reconhece, alterações de permissões, leituras de storage sem uma execução correspondente, reconexões OAuth inesperadas e falhas de autenticação em sequência. Também examine mudanças em repositórios privados e segredos exportados para variáveis de ambiente. Um indicador isolado pode ser legítimo, mas vários sinais alinhados merecem investigação imediata.

Como se proteger

A recomendação mais direta da Apify é restringir o acesso aos storages. Na Console, em Settings, General resource access, selecione Restricted. O aviso informa que, enquanto o acesso está aberto, qualquer pessoa que conheça o identificador de um storage pode lê-lo. Essa configuração reduz exposição acidental e deve ser aplicada antes de uma revisão detalhada do conteúdo.

Revogue tokens que não sejam necessários e crie novos tokens com escopo mínimo. Não coloque tokens em código-fonte, tickets, imagens de terminal ou arquivos compartilhados. Atualize segredos em pipelines e variáveis de ambiente quando um token for revogado. Revise integrações OAuth, reconectando apenas as que forem necessárias e autorizando-as no domínio correto. Para Actors baseados em GitHub privado, siga o fluxo oficial de reconexão indicado pela Apify.

Ative autenticação multifator nas contas administrativas, se disponível, e aplique uma política de acesso individual. Contas compartilhadas tornam a investigação mais difícil e aumentam o impacto de uma credencial comprometida. Por fim, preserve logs antes de iniciar uma limpeza ampla. A resposta precisa manter evidências suficientes para determinar o que ocorreu.

Comparação com casos anteriores

Este incidente se diferencia de um simples vazamento de senha porque a comunicação descreve acesso a sistemas internos, credenciais de contas, integrações e dados armazenados. Também não é correto tratá-lo como uma falha comprovada do OAuth: a própria Apify informou que revogou algumas conexões como precaução e que a investigação não encontrou evidência de que elas tenham sido o vetor.

A comparação útil é com incidentes de cadeia de acesso. Em vez de procurar apenas o ponto inicial, a equipe deve mapear todos os caminhos que uma credencial permite: API, Actors, storages, GitHub, integrações e serviços internos. O objetivo é reduzir o raio de impacto mesmo antes de a causa raiz ser publicada.

Análise técnica

Os fatos confirmados publicamente são específicos. O acesso não autorizado ocorreu em partes dos sistemas internos em 9 e 10 de novembro. A atividade foi detectada em 11 de novembro às 12:13 UTC. A Apify declarou que fechou o caminho de acesso, não detectou nova atividade do atacante desde 11 de novembro, rotacionou segredos internos críticos por precaução e acrescentou restrições de rede entre serviços internos, além de autenticação mais forte.

A empresa também informou que tokens de API passaram a ser armazenados somente como hashes. Isso reduz o impacto de uma exposição futura do armazenamento de tokens, pois o valor original não precisa permanecer recuperável no banco. A medida não substitui rotação, escopo mínimo, expiração e monitoramento. Hashes fortes e proteção contra tentativas de adivinhação continuam sendo requisitos importantes.

Não há, no aviso consultado, CVE, pontuação CVSS, PoC ou descrição suficiente para atribuir uma vulnerabilidade de produto. Portanto, este artigo não classifica o evento como CVE nem afirma uma técnica de exploração que a fonte ainda não confirmou.

Impacto e consequências

O impacto potencial depende do que cada conta armazenava e de quais permissões os tokens tinham. Um token amplo pode permitir leitura de dados, acionamento de Actors ou alterações operacionais. Uma integração reconectada de forma apressada pode reabrir uma relação que a equipe acabou de revogar. Um storage público pode expor arquivos mesmo sem um token comprometido, se o identificador tiver sido divulgado.

Há também consequências operacionais. A rotação de segredos pode interromper jobs, exigir atualização de pipelines e gerar falhas temporárias nas integrações. Do ponto de vista de privacidade, as equipes devem preservar os avisos recebidos, identificar categorias de dados e encaminhar dúvidas ao suporte da Apify e aos responsáveis internos por segurança e proteção de dados.

Dicas práticas e boas práticas

Use um checklist curto e repetível. Primeiro, restrinja todos os storages que não precisam ser públicos. Segundo, liste tokens e elimine os que não têm dono, finalidade ou prazo. Terceiro, troque segredos em CI/CD, Actors e ambientes locais. Quarto, revise permissões de membros e integrações. Quinto, busque eventos fora do padrão nos logs. Sexto, confirme se alertas de phishing chegaram por e-mail e encaminhe mensagens suspeitas ao canal oficial.

A Apify alerta que nunca pedirá senha, códigos de autenticação em dois fatores ou dados de pagamento. Não clique em links de mensagens inesperadas. Abra a Console digitando o endereço conhecido, confirme o domínio e compare qualquer instrução com a página oficial de status. Se sua equipe recebeu um aviso individual, siga as instruções da mensagem, mas valide a origem antes de fornecer qualquer informação.

Conclusão: o que fazer agora

O incidente da Apify ainda estava em investigação na atualização de 13 de novembro de 2026. A ação mais segura é reduzir exposição sem esperar o post-mortem: restringir storages, revogar e recriar tokens, revisar integrações, conferir logs e treinar a equipe contra phishing. Registre o horário das ações e preserve evidências.

A empresa informou que publicaria uma atualização em até 72 horas e um post-mortem com causa raiz e remediação em até uma semana. Monitore a página oficial de status e o suporte da Apify para ajustar a resposta quando novos fatos forem divulgados. Até lá, trate tokens e storages como ativos de produção, com escopo mínimo, prazo de validade, dono definido e auditoria contínua.