gestão de segredos
19 artigos com esta tag
Incidente de segurança da Fireworks AI (outubro de 2026): afetados dados de cobrança e, em algumas contas, conjuntos de dados e pesos de modelos incompletos; a empresa diz que houve envolvimento de uma violação em provedor de nuvem. O que os clientes devem fazer
A Fireworks AI, que oferece infraestrutura de inferência de modelos de IA, publicou em 9 de novembro de 2026 uma atualização do incidente de segurança que divulgou pela primeira vez em 9 de outubro. Segundo a empresa, do incidente original, detectado em 6 de outubro, só se sabia que envolvia segredos armazenados na Fireworks (como os usados em tarefas de avaliação); desde então ela encontrou impacto em informações de conta e de cobrança e, em um conjunto limitado de contas, em segredos, conjuntos de dados e pesos de modelos incompletos. No relato dela, um provedor de nuvem terceirizado que hospedava suas máquinas de P&D sofreu um incidente de segurança em 23 de outubro, e em 24 de outubro um terceiro não autorizado o usou para chegar a máquinas de desenvolvimento da Fireworks e executar uma carga de trabalho não autorizada, causando impacto adicional em dados de clientes. A empresa detectou isso no mesmo dia e, até 25 de outubro, não havia detectado novas evidências de acesso não autorizado bem-sucedido à plataforma usada pelos clientes. Diz que as evidências indicam ligação com um grupo cibercriminoso com motivação financeira. A empresa não armazena números de cartão de pagamento e eles não foram afetados. Nenhum impacto foi detectado em Inference, Training SDK nem Nexus, que por padrão não retêm dados. Os uploads e downloads de conjuntos de dados por autoatendimento estão desativados durante a investigação. Nossa opinião: os clientes devem inventariar e trocar o que guardaram na plataforma; os operadores devem manter os ambientes de desenvolvimento separados dos sistemas de cobrança e de dados de clientes.
Violação da NEAR AI por uma falha no mecanismo de inferência (dados de conta de cerca de 100 usuários): o que foi confirmado e o que usuários e operadores de infraestrutura de IA devem fazer
A NEAR AI, que oferece chat e agentes de IA, divulgou em uma publicação oficial de seu blog, datada de 9 de novembro de 2026, um acesso não autorizado a parte de sua infraestrutura. Segundo a empresa, a causa foi uma falha de execução remota de código no SGLang, o mecanismo de inferência de código aberto que roda em seus servidores; o invasor executou código em um servidor de inferência e a partir dele chegou a outra infraestrutura. O que ela confirmou: dados de conta de cerca de 100 usuários (endereços de e-mail, nomes e, em algumas contas, informações de plano e saldo) levados de um sistema interno por trás do Private Chat, já descontinuado; o histórico de chat, as configurações e os logs de 18 agentes legados que não rodavam em seu ambiente de computação confidencial (TEE); e, separadamente, chaves de API do NEAR AI Cloud de dois clientes do Cloud que ficaram expostas em logs (revogadas; o relatório não diz que foram levadas). Em 8 de novembro, o invasor também pôde observar as requisições dos usuários sendo processadas no servidor comprometido, inclusive as do modo confidencial. A empresa não encontrou indício de que as conversas armazenadas do Private Chat ou os arquivos enviados tenham sido acessados. Diz ter substituído as credenciais, corrigido a falha e restabelecido o acesso ao NEAR AI Cloud (o Private Chat continua fora do ar). O relatório oficial não informa número de CVE. Nossa opinião: para operadores de infraestrutura de IA, o essencial é manter os servidores de inferência separados dos sistemas internos, não deixar ambientes legados para trás e manter segredos fora dos logs.
bee-js 13.3.0 da Ethersphere e Swarm Desktop 0.56.2 distribuíram malware (novembro de 2026): versões afetadas e o que os usuários devem fazer
A versão 13.3.0 do pacote npm @ethersphere/bee-js, da Ethersphere, a desenvolvedora da rede de armazenamento descentralizado Swarm, continha código malicioso. Um aviso do GitHub (GHSA-hh7j-5m3j-23pf) publicado em 9 de novembro de 2026 lista a 13.3.0 como a única versão afetada e diz que não há versão corrigida. Diz que qualquer computador que tenha o pacote instalado ou em execução deve ser considerado totalmente comprometido, e que todos os segredos e chaves nele devem ser trocados imediatamente a partir de outro computador. Remover o pacote pode não eliminar todo o software malicioso causado pela instalação. Quanto ao Swarm Desktop, as notas de versão da Ethersphere dizem que a versão 0.56.3, lançada em 9 de novembro, substitui a 0.56.2 comprometida. Segundo a análise de uma empresa de segurança, o bee-js 13.3.0 apareceu no npm por volta das 00:09 UTC de 9 de novembro (09:09 no horário do Japão) e foi removido cerca de 75 minutos depois. O Swarm Desktop 0.56.2 ficou público por cerca de 8,5 horas e também foi entregue por atualização automática no Windows x64 e no Apple Silicon. Relata-se que o bee-js 13.2.0 e anteriores, e o Swarm Desktop 0.56.1, não são afetados. A mesma análise diz que o arquivo de configuração do nó Bee (que guarda uma senha em texto simples) e sua chave de carteira foram alvos, e que credenciais usadas pela automação oficial de publicação foram abusadas. Nossa conclusão: reconstrua qualquer máquina ou ambiente de CI que instalou uma versão afetada, mova a carteira para uma chave nova e os fundos com ela, e troque as credenciais a partir de outra máquina.
Falha no servidor MCP da mittwald explorada, 56 projetos de clientes comprometidos (novembro de 2026): a cronologia publicada e o que usuários e operadores de integrações de IA devem fazer
A empresa alemã de hospedagem web mittwald disse em uma postagem oficial de seu blog que uma falha em seu servidor MCP, que conecta os assistentes de IA dos clientes ao seu painel de controle mStudio, foi explorada e que 56 projetos de clientes foram comprometidos. Segundo a empresa, o atacante testou a falha pela primeira vez em 21 de outubro, passou a agir como um usuário comum com contas de teste a partir de 23 de outubro e explorou a falha às 15:03 de 27 de outubro usando outra conta. A empresa trata como comprometidos todos os dados de 27 de outubro em diante. Em 4 de novembro foi encontrado um comportamento incomum e, no mesmo dia, a empresa identificou o servidor MCP como ponto de entrada e o desligou. Em 6 de novembro examinou forensemente os 56 projetos comprometidos e o servidor MCP, não encontrou mais projetos comprometidos e diz que atualmente não consegue detectar atividade do atacante. Nenhuma senha foi lida; o que foi lido foram os tokens de sessão dos usuários, todos revogados, diz. O centro de clientes e os sites gerenciados nele não foram afetados. O servidor MCP continua fora do ar, e a volta dele será decidida após a investigação. A empresa diz que a velocidade do atacante sugere o uso de ferramentas de IA; é uma suspeita da empresa. Diz que publicará um relato detalhado na semana seguinte. Nossa avaliação: em servidores MCP que conectam assistentes de IA a ambientes de hospedagem ou de produção, o essencial são tokens de escopo estreito e curta duração e um monitoramento capaz de pegar a fase de sondagem.
Incidente de segurança da Trigger.dev (novembro de 2026): chaves de API root e variáveis de ambiente acessadas em 0,66% dos clientes; regenere as chaves e troque os segredos
A Trigger.dev, plataforma para executar tarefas em segundo plano e agentes de IA, divulgou um incidente de segurança em 1º de novembro de 2026 e publicou um relatório de acompanhamento em 6 de novembro. A empresa diz que alertas da infraestrutura sinalizaram atividade anômala em 1º de novembro, que a julgou maliciosa e bloqueou o atacante. O incidente afetou 0,66% de todos os clientes. O atacante obteve chaves de API root de alguns ambientes de clientes; uma chave root dá acesso total às configurações de um ambiente, incluindo suas variáveis de ambiente. Em alguns ambientes o atacante também listou execuções, implantações e agendamentos recentes, o que retornou IDs, nomes de tarefas, chaves de idempotência de execuções, status das execuções, tags, metadados e erros de implantações, IDs externos de agendamentos e metadados de execuções. A empresa diz que não encontrou indício de que outros dados de clientes, outros serviços, seus próprios bancos de dados de produção ou contas do painel de clientes tenham sido acessados. Ela não divulga o vetor de ataque, para proteger a investigação e os clientes. Os clientes afetados foram contatados por e-mail (em 1º e 2 de novembro) e por um banner no painel (sem informar quando), e as chaves de API potencialmente afetadas foram revogadas. Clientes afetados devem regenerar suas chaves de API e trocar as credenciais dos ambientes afetados, como senhas de bancos de dados e chaves de API de terceiros, revogando as antigas no provedor. A empresa diz que clientes que não receberam aviso de impacto não foram afetados, que os segredos de assinatura de webhooks não foram expostos e que as implantações auto-hospedadas não foram afetadas. Avaliação deste site: confira primeiro o e-mail e o banner do painel e, se você foi afetado, regenere as chaves e troque as credenciais como a empresa orienta.
Incidente de segurança da Northflank (outubro de 2026): variáveis de ambiente armazenadas que devem ser tratadas como descriptografadas e uso indevido de chaves de API de IA
Em 30 de outubro de 2026 (UTC), a plataforma de implantação em nuvem Northflank publicou um incidente de segurança em sua página de status. Um alerta de ameaça de um fornecedor de segurança chegou às 11:43 UTC; a empresa implantou correções a partir das 12:02 UTC, orientou os clientes a trocar as variáveis de ambiente às 13:40 UTC e, às 13:58 UTC, a presumir que todas as variáveis de ambiente foram descriptografadas. Às 15:12 UTC sua página de status já registrava que vários usuários relatavam que suas chaves de IA haviam sido usadas e, às 23:38 UTC, dizia que usuários relataram uso não autorizado de chaves de API de IA armazenadas na plataforma. Em 31 de outubro habilitou os registros de auditoria para todos os clientes e foi liberando a rotação de segredos dos complementos, um tipo de cada vez. Em uma atualização de 2 de novembro (11:09 UTC, status Monitoring) disse acreditar ter contido o ataque na hora seguinte ao primeiro alerta, que as cargas de trabalho em execução não foram afetadas e que não viu sinais de que as cargas de trabalho ou seus dados tenham sido acessados, e que o ataque parecia focado em segredos do plano de controle. Auditores forenses independentes estão revisando, ela revogou tokens de acesso, sessões, integrações com sistemas de controle de versão (VCS) e funções IAM entre contas (portanto os usuários precisam entrar de novo e reconectar as integrações), e prometeu uma análise de causa raiz quando os achados forem confirmados. Em uma atualização de 6 de novembro (10:09 UTC) disse que a primeira descriptografia conhecida de segredos ocorreu entre 02:39 e 03:08 UTC de 30 de outubro, antes do primeiro alerta, às 11:43 UTC; que o exploit foi corrigido em até 60 minutos após o aviso e os clientes foram notificados em até duas horas; que não encontrou indício de que cargas de trabalho de clientes ou seus dados tenham sido acessados; e que trabalhou com provedores upstream para revogar credenciais quando possível. A revisão forense continua. O número de clientes afetados, como o atacante entrou e quais provedores de IA estiveram envolvidos não foram divulgados. Avaliação deste site: revogue todos os segredos que você guardou na Northflank no serviço que os emitiu, depois confira o uso e a cobrança de cada provedor de IA e defina limites de gastos.
Violação no OpenCode Console (outubro de 2026, 1,4% dos usuários do Console): chaves de API de provedores de IA possivelmente expostas, e o que fazer
Em 17 de outubro de 2026, a OpenCode, o agente de programação com IA de código aberto, disse em sua conta oficial no X que sofreu na noite anterior uma violação de segurança, relacionada a um ataque de destilação em grande escala, que atingiu 1,4% dos usuários do OpenCode Console. Disse que havia enviado naquela manhã um e-mail a todos os usuários afetados, que quem não recebeu o e-mail não foi afetado e que os afetados eram um subconjunto que tinha provedores externos vinculados. A empresa disse que o incidente continuava em andamento, que não podia dar mais detalhes e que estava trabalhando com os provedores de IA envolvidos. Segundo reportagens sobre o e-mail e sobre declarações da empresa, chaves de API de provedores de IA externos que os usuários haviam armazenado em workspaces do Console podem ter sido expostas por meio de um sistema antigo, e os usuários afetados foram orientados a revogar e substituir essas chaves diretamente em cada provedor. Um cofundador disse que o app de código aberto e a ferramenta de linha de comando não foram afetados. A opinião deste site: se você recebeu o e-mail, ou tinha chaves de provedores de IA vinculadas no OpenCode Console e não tem certeza, revogue-as hoje no painel de cada provedor e verifique uso e cobrança a partir de 17 de outubro.
Incidente de segurança da Zeabur (outubro de 2026, 3,22 milhões de variáveis de ambiente lidas): quais segredos trocar e o que os usuários devem fazer
Em 19 de outubro de 2026, a plataforma de deploy de aplicações Zeabur publicou um relatório preliminar sobre um incidente de segurança ocorrido em 14 e 15 de outubro (UTC). A empresa afirma que um invasor usou credenciais internas vazadas da Zeabur para entrar em seu cluster compartilhado, em alguns Dedicated Servers e em sistemas internos e, por fim, leu o banco de dados da plataforma entre 16:10 e 16:47 UTC de 15 de outubro. Ela confirmou que foram lidos 3.218.965 registros de variáveis de ambiente (nomes e valores) e dados de 321.810 contas (e-mail, nome de usuário, número de telefone e outros), além de 566 chaves de API do zSend, que ela revogou. A empresa diz que a causa raiz é responsabilidade da Zeabur: credenciais administrativas de longa duração eram armazenadas em texto puro e podiam ser usadas a partir da internet. Ela pede a todos os usuários que substituam todas as senhas e chaves armazenadas na Zeabur, mesmo que já as tenham substituído após outro incidente em agosto. A Zeabur havia anunciado em 17 de outubro que encerrará as atividades em 31 de dezembro de 2026 e, em 22 de outubro, fixou 30 de novembro de 2026 como prazo para pedidos de ressarcimento de perdas causadas pelo incidente. A opinião deste site: trate todo segredo que você já colocou em uma variável de ambiente da Zeabur como conhecido por outra pessoa, revogue-o primeiro no serviço que o emitiu e verifique faturas e logs a partir de 14 de outubro.
Variáveis de ambiente da Railway possivelmente expostas (outubro de 2026, até 1,85% dos workspaces): quais segredos rotacionar e o que os usuários devem fazer
Em 21 de outubro de 2026 (UTC), a Railway anunciou que detectou atividade anômala envolvendo sistemas que armazenam variáveis de ambiente de clientes, e que um terceiro não autorizado pode ter acessado variáveis de ambiente criptografadas e, em parte delas, obtido o conteúdo descriptografado. Segundo o relatório preliminar datado de 22 de outubro (disponibilizado às 16:38 UTC de 23 de outubro, conforme a página de status), o ataque ocorreu de 13:58 UTC de 20 de outubro até 03:32 UTC de 22 de outubro. Começou com tentativas de escalonamento de privilégios na infraestrutura de build; em 21 de outubro, credenciais do ambiente de CI foram usadas e um subconjunto de variáveis de ambiente criptografadas foi descriptografado. No máximo 1,85% de todos os workspaces (cerca de 100.000 workspaces, segundo a empresa) tiveram algumas variáveis de ambiente potencialmente comprometidas. A empresa afirma que nenhuma conta de usuário da Railway foi acessada e não descartou o acesso ao código-fonte até o relatório final. O invasor parece ter buscado chaves de API de provedores de IA. A Railway recomenda que todos os usuários rotacionem os segredos armazenados antes de 21 de outubro, removam o acesso público de rede aos bancos de dados e revisem os logs de auditoria do GitHub e de registries (como o Docker Hub). Conclusão deste site: mesmo que você não tenha sido contatado, trate os segredos armazenados na Railway como expostos, reemita-os na origem e faça o redeploy antes de revogar os valores antigos.
LiteLLM 1.107.0 distribuiu um ladrão de credenciais (outubro de 2026): versão afetada no PyPI e imagens Docker, e o que os usuários devem fazer
Em 21 de outubro de 2026 (UTC), a BerriAI, empresa por trás do LiteLLM, anunciou que seu pipeline de lançamento havia sido comprometido e que uma v1.107.0 contendo malware que rouba credenciais e carrega ferramentas de execução remota de código foi publicada. Foram afetados o litellm==1.107.0 no PyPI (das 11:39 às 13:23 UTC) e as tags v1.107.0, latest, main-latest e main-stable no Docker Hub (das 11:46 às 14:20 UTC) e no GHCR (a partir das 11:46 UTC até serem retiradas, no máximo às 13:51 UTC, cerca de duas horas). A tag oficial do código-fonte v1.107.0 no GitHub não contém os arquivos maliciosos; os artefatos foram construídos a partir de um repositório semelhante controlado pelo atacante. Todas as versões anteriores estão fora deste comprometimento, e a empresa pede que os usuários fixem a 1.106.2 ou outra versão anterior explícita. Em 24 de outubro (UTC) a empresa publicou as versões 1.103.8, 1.104.6, 1.105.4 e 1.106.3, e a partir dessas versões as imagens Docker e os Helm charts são assinados com uma nova chave cosign (a chave anterior não os verifica mais). Em 23 de outubro a empresa publicou uma análise de causa raiz e corrigiu sua primeira hipótese de que os tokens teriam sido obtidos dos logs de uma implantação interna do LiteLLM. Segundo a análise, um arquivo de configuração enviado por engano a um repositório público em 27 de maio continha a chave mestra de uma plataforma interna de agentes; o commit foi sobrescrito, mas a chave nunca foi revogada. Em 10 de outubro o atacante usou essa chave para chamar a API da plataforma e obteve o token do GitHub CLI de um proprietário da organização no GitHub configurado ali. Com ele, o atacante exfiltrou segredos de CI para obter os tokens de mais dois mantenedores e, em 21 de outubro, desativou a proteção de branch, alterou o workflow de lançamento e aprovou o lançamento. Conclusão deste site: reconstrua todo ambiente que instalou ou iniciou a 1.107.0 durante a janela e rotacione todas as chaves que ele podia acessar, incluindo chaves de provedores de LLM, a chave mestra do proxy, a senha do banco de dados e as funções de nuvem.
Worms na cadeia de suprimentos do npm: como as credenciais são roubadas na instalação e como se defender
Adicionar uma dependência significa executar o código de outra pessoa com os seus privilégios, então a defesa precisa estar no momento da instalação. A visão deste site: assinaturas e proveniência não detiveram esta campanha, então não podem ser a base da confiança. O que funciona é desativar os scripts de instalação por padrão, esperar alguns dias antes de adotar uma nova versão e manter os tokens com vida curta e escopo restrito. E, se você suspeitar de infecção, a ordem em que revoga as credenciais importa.
Detenha segredos antes do commit com o gitleaks: pegue vazamentos de chave de API antes do push
Segredos não podem ser 'apagados depois que vazam'. Uma vez comitado, um segredo fica no histórico do Git, e uma vez enviado deve ser tratado como vazado — a chave precisa ser revogada/rotacionada. O gitleaks é uma ferramenta gratuita que varre todo o repo e o histórico de commits com regex/entropia para encontrar chaves de API, chaves privadas e tokens. O cerne da defesa são duas verificações: um hook de pre-commit que o detém localmente antes do push e CI/cron que pega o que escapa. O .gitignore só evita novo rastreamento — ele não detecta, então você ainda precisa de um scanner.
Gerenciadores de senhas são seguros? Como funcionam, nuvem vs. local e como escolher
Um gerenciador de senhas ajuda a usar uma senha forte e diferente para cada serviço. A criptografia de conhecimento zero foi projetada para proteger o conteúdo mesmo se dados criptografados vazarem do provedor, mas a segurança também depende da força da senha-mestra, das configurações de criptografia e da segurança do dispositivo. Use MFA para impedir logins não autorizados e escolha nuvem ou local conforme o uso.
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.
A base de segurança para devs independentes e pequenos operadores: os controles padrão em ordem de prioridade
A base não é 'tudo igualmente importante'. A ordem de prioridade deste site: 1) contas de administrador, domínio e e-mail (MFA), 2) segredos e código, 3) o próprio app, 4) corrigir, detectar, recuperar. Com tempo finito, preencha de cima para baixo. A maioria das invasões sérias vem não de ataques inéditos, mas da falta de um destes controles básicos.
Inventário de segurança: 7 verificações que quem roda vários servidores ignora
Para operadores solo/pequenos, incidentes vêm menos de controles ausentes do que de estado não rastreado. A fronteira é o PC que guarda suas chaves. Priorize o 2FA conforme qual conta pode recuperar as outras (o e-mail primeiro), liste qual chave SSH abre qual servidor e apague duplicatas, chaves sem uso e cadastros esquecidos, remova senhas em texto puro da nuvem, remedie de forma reversível uma de cada vez e mantenha segredos fora do registro. Inventarie antes de adicionar ferramentas.
Git auto-hospedado vs. GitHub: qual é de fato mais seguro?
Auto-hospedar o Git não te torna 'mais seguro' — realoca o risco. A classe de exposição pública acidental desaparece, mas aplicar patches no servidor, backups e detecção de segredos pré-commit passam para você. A escolha certa se você continua fazendo esse trabalho; pior que o GitHub se você o negligencia. A visão deste site: a auto-hospedagem só funciona junto com seus controles compensatórios.
Guardar suas senhas no Google Drive é seguro? Como mantê-las do jeito certo
Guardar senhas em um Documento/Planilha Google em texto puro é perigoso: uma conta Google vira o ponto único de falha para toda senha — sequestro de conta, um app conectado malicioso ou phishing vazam todas de uma vez. A opção mais segura é um gerenciador de senhas dedicado (o conteúdo fica criptografado mesmo quando sincronizado). Se você precisar usar o Drive, guarde só um arquivo de cofre criptografado e coloque MFA resistente a phishing na conta.
Vazamento da Codecov (2021) — quando uma ferramenta de CI foi adulterada e segredos vazaram
Uma ferramenta de CI confiável (o Bash Uploader curl|bash) foi alterada na origem. Como o seu próprio código permaneceu intocado, passou despercebido por cerca de 2 meses enquanto segredos de CI vazavam; uma verificação de checksum o pegou. No seu CI: verifique artefatos baixados, segredos de menor privilégio, rotação, monitoramento de egress.