cadeia de suprimentos
25 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.
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.
Ciberataque ao Crédit Mutuel Arkéa (França): transferências fraudulentas da própria conta via plataforma de um prestador de serviços, ativos dos clientes não afetados
Em 4 de novembro de 2026, o grupo financeiro francês Crédit Mutuel Arkéa disse que sofreu um ataque que permitiu operações fraudulentas. Segundo o grupo, os atacantes chegaram a ele pela plataforma de um prestador de serviços e enviaram dinheiro da conta própria do Arkéa a outros agentes bancários, o que pode ter permitido convertê-lo em criptoativos por plataformas especializadas. Contas de clientes de suas federações e subsidiárias não foram usadas, os ativos dos clientes não foram afetados, apenas algumas transferências foram executadas com atraso e a maior parte das operações voltou na manhã de 4 de novembro. O grupo negou erro humano e negou que a intrusão tenha vindo pela subsidiária de banco online. Os valores ainda estão sendo avaliados: sobre os 118 milhões de euros (133 milhões de dólares) levantados como pergunta em seu comunicado complementar, disse que a ordem de grandeza é válida e que ainda não está em condições de publicar um valor definitivo. Parte dos fundos foi bloqueada e a recuperação está em andamento. Alerta para phishing. Conclusão deste site: clientes não devem abrir links de mensagens que digam ser do grupo e devem conferir por canais oficiais que abram por conta própria; empresas devem revisar as conexões e os privilégios que prestadores de serviços têm em seus sistemas de pagamento.
Ciberataques e vazamentos de dados de outubro de 2026: 36 vulnerabilidades exploradas e vazamentos em larga escala
Em outubro de 2026, a CISA adicionou 36 vulnerabilidades ao seu catálogo de Vulnerabilidades Exploradas Conhecidas (KEV), sete a menos que as 43 de setembro. Onze eram produtos de borda e de acesso remoto, como appliances VPN e firewalls; cinco eram falhas antigas publicadas entre 2015 e 2023 (todas adicionadas em 8 de outubro); dez eram de Plex, PHP, Ahsay e Zammad, e dez de outros produtos. Este site publicou 115 primeiros relatos sobre incidentes e vulnerabilidades em outubro (65 incidentes no Japão, 28 no exterior, 4 globais e 18 vulnerabilidades); é uma contagem de artigos deste site, não estatística nacional. No Japão, continuaram os vazamentos de bancos de dados de membros e de aplicativos. Os maiores números anunciados foram ShopServe (cerca de 23,356 milhões de pessoas), o app da MUJI (até cerca de 27,26 milhões de registros, possível), Club Tourism (cerca de 4,32 milhões de registros, possível) e Hana Cupid (até 4.238.242 registros). Também continuaram os vazamentos em provedores de serviços e SaaS, os roubos em corretoras de criptomoedas e os incidentes em plataformas para desenvolvedores de IA. Nossa conclusão para novembro: atualize primeiro os dispositivos de borda que chegaram ao KEV, faça o inventário dos serviços externos que guardam suas listas de clientes e prepare-se para o phishing que se passa por uma empresa afetada.
Servidor de atualizações do AOMEI Backupper adulterado (de abril a julho de 2026): quem pode ter sido afetado, as datas e como verificar seu PC
A AOMEI, fabricante do software de backup para Windows AOMEI Backupper, publicou em 19 de outubro de 2026 (última atualização em 30 de outubro) um comunicado sobre um comprometimento da cadeia de suprimentos de software em seu servidor de atualizações. Citando a investigação de uma empresa de segurança, ela diz que entre abril e julho de 2026 arquivos de configuração do servidor de atualizações do AOMEI Backupper foram alterados repetidamente por cerca de cinco a dez minutos e depois restaurados. Durante essas janelas, a configuração alterada podia fazer o software baixar arquivos maliciosos. Até agora foram identificadas três janelas: 28 de maio (05:40–05:50 UTC), 16 de julho (08:33–08:39 UTC) e 20 de julho (10:35–10:40 UTC). A empresa reforçou os servidores até 29 de julho, transferiu o serviço de atualizações para um novo servidor em 5 de agosto e lançou o AOMEI Backupper 8.5.1 em 19 de outubro. Ela pede a todos os usuários do AOMEI Backupper, afetados ou não, que executem o AOMEI Security Scanner, atualizem para a 8.5.1, façam uma varredura com o software de segurança e troquem a senha da conta do Windows ou de domínio. O número de usuários afetados e as versões afetadas não foram divulgados. A opinião deste site: se o AOMEI Backupper estava instalado em um PC que ficou ligado durante essas janelas, faça os quatro passos e, se puder, troque a senha do Windows a partir de outro dispositivo limpo.
Extensão “Claude Code” adulterada no marketplace do Cursor (29 de out., cerca de 11 horas): como verificar se há um backdoor SSH
A Cursor publicou um aviso de segurança em 29 de outubro de 2026 (atualizado em 30 de outubro) dizendo que as versões adulteradas 2.1.312 e 2.1.313 de uma extensão publicada com o nome da Anthropic (Anthropic.claude-code) foram distribuídas no marketplace de extensões do Cursor para Windows e macOS entre aproximadamente 2:27 e 13:35 (horário do Pacífico) de 29 de outubro. A Cursor afirma que as versões não foram desenvolvidas pela Anthropic. Segundo a Cursor, o código era executado quando a extensão carregava, coletava informações do host e do usuário, adicionava uma chave SSH controlada pelo atacante (com o rótulo svc-telemetry), tentava habilitar o SSH e abrir um túnel reverso, instalava persistência por um LaunchAgent no macOS ou por uma tarefa agendada ou entrada de Inicialização no Windows e enviava detalhes do host ao atacante. A Cursor diz que habilitar o SSH falha na maioria dos hosts, então o atacante não poderia ter entrado pelo túnel ali. A Cursor removeu a extensão, pausou o marketplace, auditou outras extensões, trocou chaves e diz que o servidor do atacante não funciona mais. A Cursor diz não ter evidências de que outras versões ou a distribuição oficial estejam afetadas. O BleepingComputer relata que até cerca de 5.000 desenvolvedores podem ter sido expostos. Nossa conclusão: se você instalou ou atualizou essa extensão no Cursor em 29 de outubro, verifique a chave e as entradas de persistência e troque os segredos acessíveis a partir dessa máquina.
Polymarket suspende as negociações após o comprometimento de um script de terceiros: o que usuários e operadores de sites devem fazer
Em 29 de outubro de 2026, a página de status da Polymarket informou que sua plataforma internacional (Polymarket.com) entrou em modo somente cancelamento às 14h05 ET, que um provedor externo havia sido comprometido, que o caso foi encaminhado às autoridades e que todos os afetados serão ressarcidos; as negociações foram suspensas temporariamente às 14h37 ET por precaução e a retomada era esperada por volta das 15h00 ET. Reportagens da imprensa, citando uma empresa de pesquisa em segurança, dizem que o provedor era um serviço de monitoramento de desempenho de sites cujo script rodava nas páginas da Polymarket e foi usado para vender ou mover as posições de usuários logados, e estimam o valor rastreado em cerca de US$ 2,2 a 2,7 milhões, conforme o veículo. Em uma análise pós-incidente em sua página de status, datada de 30 de outubro, a Polymarket disse que devolve US$ 3,9 milhões (cerca de US$ 2,7 milhões em reembolsos por carteiras esvaziadas e posições assumidas durante o ataque, e US$ 1,2 milhão por perdas ligadas à pausa das negociações), que não é preciso fazer reivindicação nem abrir chamado porque identificou as carteiras elegíveis a partir de dados on-chain e de negociação, e que removeu o script do fornecedor, pausou as negociações e redefiniu todas as sessões de login ativas. Segundo a imprensa, a conclusão inicial do fornecedor é que ele foi comprometido por meio de seu registrador de domínios. A análise pós-incidente não informa o número de usuários afetados. A opinião deste site: como a Polymarket diz que não é preciso reivindicar, os usuários devem tratar qualquer mensagem que peça para reivindicar ou receber um reembolso como possível golpe e usar apenas o site oficial, e os operadores de sites devem inventariar todos os scripts de terceiros nas páginas em que os usuários estão logados.
Gerenciar scripts de terceiros com segurança: inventário, SRI, CSP e destinos de formulários
Um script de terceiros pode ler a página em que roda, incluindo o que o usuário digita. Se o fornecedor for comprometido ou o arquivo mudar, seus usuários são afetados mesmo que o seu servidor esteja intacto. A ordem de defesa: listar tudo o que roda, remover o desnecessário, adicionar SRI a arquivos fixos ou servir uma cópia revisada do seu próprio site, restringir origens e destinos com CSP e verificar mudanças periodicamente. O CSP form-action não herda default-src, então defina-o explicitamente.
Trezor relata possível implante de hardware em um Safe 5 de um ex-revendedor (não confirmado): o que os proprietários devem fazer
Em 30 de outubro de 2026, a Trezor publicou um comunicado dizendo que sua equipe de segurança recebeu, em 28 de outubro, um relato de divulgação responsável sobre um implante de hardware em um Trezor Safe 5. O dispositivo foi comprado em agosto de 2026, por um marketplace online, de uma empresa que foi revendedora oficial da Trezor no Sudeste Asiático até outubro de 2026. O relato descreve uma placa de circuito extra com módulo celular e antena entre a placa principal e a tela, que supostamente lê o que a tela mostra, incluindo o backup da carteira (frase de recuperação), e o envia por uma rede móvel. A Trezor não recebeu o dispositivo, então isso não foi verificado, e diz que não há fundos roubados conhecidos. Para dispositivos comprados dessa revendedora desde março de 2026, a Trezor diz: não configure um novo e, se já usa um, crie uma nova carteira com uma nova frase de recuperação em um dispositivo novo e mova seus fundos. Nossa conclusão: é um relato, não uma constatação confirmada, mas os passos são baratos perto do risco, então siga a orientação do fabricante se seu dispositivo veio dessa revendedora.
Incidente do ConnectWise Cloud Backup (antes SkyKick): tentativas de login conduzidas por IA contra mais de 2.250 tenants do Microsoft 365 e o que os administradores devem verificar
Em 16 de outubro de 2026, a ConnectWise publicou um aviso dizendo que houve acesso não autorizado a credenciais de aplicativos associadas ao Cloud Backup (antes SkyKick), seu serviço de backup do Microsoft 365 para provedores de serviços gerenciados (MSPs). Em 17 de outubro, desativou sete identidades de aplicativo, suspendeu o Cloud Backup, o SaaS Security e o Cloud Management, e em 19 de outubro redefiniu todas as contas e credenciais do ambiente afetado. Em 21 de outubro a Microsoft publicou uma pesquisa avaliando que um grupo alinhado a um Estado estava por trás da invasão e depois usou uma estrutura multiagente de testes de intrusão com IA, de código aberto, para tentar logins em mais de 2.250 tenants. A Microsoft diz que a maior parte das tentativas não teve sucesso, mas que houve acesso privilegiado à nuvem em muitas organizações, em alguns casos em menos de três horas. Uma empresa de segurança confirmou separadamente logins não autorizados em 162 tenants em 16 de outubro. A ConnectWise diz que os arquivos de backup existentes não mostram indício de comprometimento, mas que isso não estabelece se tenants individuais do Microsoft 365 foram afetados. A avaliação deste site: se você ou seu MSP já instalou esses aplicativos, verifique as credenciais, as funções de diretório e os consentimentos de aplicativos no seu próprio tenant, e mantenha os aplicativos desativados até que a ConnectWise diga o contrário.
Vazamento de dados da Frontline Education (fornecedora de software escolar): 3,09 milhões de pessoas segundo a lista do Procurador-Geral de Indiana; números de Seguro Social, de Medicaid e de estudante afetados, e o que funcionários e famílias devem fazer
A Frontline Education, fornecedora americana de software de administração para distritos escolares K-12, publicou um Aviso de Vazamento de Dados datado de 26 de outubro de 2026. Diz que sua equipe de segurança encontrou em 14 de agosto de 2026 uma vulnerabilidade em um produto de software de terceiros que utiliza, que essa vulnerabilidade permitiu acesso não autorizado a parte de seu ambiente a partir desse dia, e que o último dia de atividade não autorizada foi 15 de agosto. Os dados afetados se relacionam a dois produtos, Frontline Central e School Health Management. A empresa diz que os seguintes dados foram afetados, e quais se aplicam varia conforme a pessoa: número de Seguro Social, data de nascimento, número da carteira de motorista, número de passaporte, outro documento de identidade oficial, identificador do Medicaid e identificador de estudante. A Frontline diz que não tem conhecimento de nenhum uso indevido dos dados e oferece a adultos nos EUA dois anos de monitoramento de crédito da TransUnion e a menores monitoramento cibernético (sua página do incidente fala em monitoramento da dark web onde disponível). A lista de vazamentos de dados do Procurador-Geral de Indiana (edição de novembro de 2026) mostra 3.085.266 pessoas no total (66.157 moradores de Indiana; data de notificação 26 de outubro, data do vazamento 14 de agosto), enquanto as notificações em outros cinco estados (MA, NH, SC, TX, VT) somavam cerca de 1,3 milhão (1.298.917), segundo a SecurityWeek. O número de distritos não foi divulgado. Nossa avaliação: se você trabalha em um distrito escolar dos EUA que usa a Frontline, ou tem um filho em um, presuma que o aviso se aplica a você, faça um congelamento de crédito gratuito e trate como não comprovada qualquer ligação ou e-mail que cite seu identificador do Medicaid ou de estudante.
Acesso não autorizado ao fornecedor do sistema de reservas da JAL, JTA, ANA, Korean Air e Asiana (cerca de 92.000 clientes da JAL/JTA e 37.800 da ANA): números de reserva, nomes e mais dados, e o que os viajantes devem fazer
A Japan Airlines (JAL) e a Japan Transocean Air (JTA) anunciaram em 28 de outubro de 2026 que, em 23 de outubro, o fornecedor do seu sistema de atendimento a passageiros, uma empresa estrangeira, as informou de que um acesso não autorizado aos sistemas do fornecedor deixou indícios de que parte das informações de reservas foi visualizada de fora. O período vai de 10 de agosto de 2023 a 23 de setembro de 2026. Em cerca de 90.000 pessoas estão envolvidos número de reserva, nome, data de embarque, rota e classe de cabine; de cerca de 2.000 pessoas também foram visualizados e-mail, telefone, número de passaporte, nacionalidade, número de milhas, número do bilhete, número do assento e mais. O total é de cerca de 92.000 pessoas. Em 30 de outubro, a JAL e a JTA atualizaram o comunicado para dizer que entraram em contato com esses clientes pelo e-mail informado na reserva. A All Nippon Airways (ANA) anunciou em 30 de outubro que há indícios de que parte das informações de reservas de cerca de 37.800 pessoas que reservaram no mesmo período foi visualizada (cerca de 1.700 delas incluindo passaporte, número de milhas e mais). Na Coreia do Sul, a Korean Air e a Asiana Airlines anunciaram em 23 de outubro que há sinais de que os números de reserva de alguns clientes vazaram do sistema de reservas da mesma empresa; dizem que a causa foi um acesso não autorizado com credenciais de login e que se estima que tenha ocorrido entre agosto de 2023 e setembro de 2026 (nenhuma divulgou um número). JAL, JTA e ANA dizem que dados de cartão de crédito e senhas não foram incluídos. Conclusão deste site: mesmo que uma mensagem que diga ser de uma companhia aérea acerte seu número de reserva, seu nome e seu voo, não use os links nem os números dela; verifique no app ou no site oficial. Se seu passaporte ou número de milhas pode estar envolvido, troque a senha da sua conta de milhas e revise o histórico de resgates.
Vazamento de endereços de e-mail da newsletter do Piccoma (1.002.404 registros): apenas endereços de e-mail expostos e o que os usuários devem fazer
Em 24 de outubro de 2026, a Kakao piccoma Corp., responsável pelo aplicativo de mangás japonês Piccoma, anunciou que a blastmail, o sistema de entrega de e-mails da RAKUS Lite Cloud Corporation que utilizava para enviar sua newsletter, foi acessada sem autorização por um terceiro, e que 1.002.404 endereços de e-mail de clientes, destinatários de um envio da newsletter, vazaram. A Piccoma soube do caso por meio de comunicado do serviço de entrega em 24 de outubro. Apenas os endereços de e-mail cadastrados para receber a newsletter vazaram; a empresa afirma ter confirmado que não foram incluídos os números de gerenciamento de clientes nem as datas da última compra. As senhas nunca foram fornecidas à blastmail e não podem ter vazado, e a Piccoma não possui nomes nem dados de cartão de crédito. O aplicativo Piccoma, o site e os sistemas próprios da empresa não foram acessados, e contas, senhas e dados de compra não foram afetados. Até o momento, não foi confirmado nenhum vazamento relacionado à newsletter do Piccoma Novels. A empresa suspendeu a newsletter, alterou configurações para que e-mails enviados pela blastmail não sejam tratados como e-mails genuínos da Piccoma e comunicou o caso à Comissão de Proteção de Informações Pessoais do Japão. Ela afirma que entrará em contato individualmente com os clientes afetados. Conclusão deste site: quem recebeu a newsletter do Piccoma não deve abrir links em e-mails ou mensagens de texto que se apresentem como da Piccoma ou de editoras, deve verificar pelo aplicativo e nunca deve digitar senhas ou números de cartão a partir de um e-mail.
Vazamento na plataforma de cartão pré-pago Value Card (1,42 milhão de registros, 1,13 milhão de registros do MOS Card): números de cartão, PINs e saldos vazados, e o que os portadores devem fazer
Em 23 de outubro de 2026, a PayCloud Holdings, empresa listada no mercado Growth da Bolsa de Valores de Tóquio, anunciou que os servidores do Value Card, um serviço de emissão de moeda eletrônica (cartão pré-pago de loja) próprio que sua subsidiária Value Design Inc. fornece a emissores de cartões, foram acessados sem autorização por um terceiro, e que 1.424.748 registros de números de identificação, PINs e informações de saldo vazaram (569.224 IDs emitidos e 855.524 IDs não emitidos, isto é, IDs ainda não adquiridos por um usuário). O acesso foi confirmado em 19 de outubro, e a causa foi um terceiro explorar uma vulnerabilidade de servidor web em parte do ambiente de sistemas da subsidiária. Não houve envolvimento de informações pessoais; o risco de uso indevido de IDs emitidos foi tratado, e não houve nenhum dano real decorrente de uso indevido. No mesmo dia, a MOS Food Services, Inc., que opera a rede de hamburguerias MOS Burger e seu cartão pré-pago MOS Card, anunciou que o acesso não autorizado ao sistema da Value Design, empresa contratada para operar e manter os servidores do MOS Card, vazou 1.133.070 registros do MOS Card (número de cartão de 16 dígitos, PIN de 6 dígitos e saldo; cerca de 570.000 cartões em circulação e cerca de 560.000 ainda não em circulação), e que redefiniu à força os PINs vinculados aos números de cartão vazados. Nomes, endereços, números de telefone e dados de cartão de crédito não foram incluídos. Quais cartões de outros emissores foram afetados não foi divulgado. Conclusão deste site: os portadores do MOS Card devem verificar seu histórico de uso em busca de cobranças que não reconhecem, entrar em contato com a central de atendimento dedicada se as consultas de saldo online e funções semelhantes deixarem de funcionar e nunca fornecer seu PIN ou número de cartão a quem pedir.
Chaves de CA intermediária da eMudhra (emSign) comprometidas: o que usuários de Python precisam fazer com pip, certifi e uv
Em 17 de outubro de 2026, um relatório mostrou que as chaves privadas de oito certificados intermediários da autoridade certificadora indiana eMudhra (seis para TLS) haviam sido geradas de forma tão inadequada que qualquer pessoa poderia recuperá-las. A eMudhra revogou todos os oito em 18 de outubro, e Chrome e Firefox os bloquearam em 17 de outubro por meio de seus mecanismos de envio. Em 20 de outubro a Mozilla decidiu uma remoção emergencial de confiança na raiz superior, emSign ECC Root CA - G3, e o Chrome a removerá em 27 de outubro (horário do Pacífico). Os navegadores estão protegidos, mas clientes TLS fora do navegador podem confiar em certificados forjados até que sua própria cópia da lista de CAs seja atualizada. No Python, o pip sempre carrega seu certifi incorporado, portanto um pip antigo continua exposto mesmo após a correção do repositório do sistema operacional. Os projetos Python publicaram um aviso em 20 de outubro (atualizado até 22 de outubro) pedindo que os usuários atualizem para pelo menos certifi 2026.10.19, pip 26.2.2, uv 0.13.4, sigstore 4.5.1, conda 26.9.4 e pixi 0.82.1 e que reconstruam imagens de contêiner sem o cache de camadas. Em 21 de outubro lançaram Python 3.15.1, 3.14.9 e 3.13.17 com pip 26.2.2. Não haverá versão 3.11 ou 3.12 com um pip mais novo. Isto não é um bug de execução de código no CPython: um invasor na rota da rede poderia redirecionar conexões ao PyPI, python.org e outros sites para um servidor falso. Nenhuma exploração havia sido anunciada até 24 de outubro. Em 22 de outubro a eMudhra disse que vai deixar o negócio global de certificados SSL/TLS. A visão deste site: atualize o pip para 26.2.2 ou posterior e o certifi para 2026.10.19 ou posterior em todos os ambientes, reconstrua imagens Docker sem o cache e eleve quaisquer fixações de certifi em lockfiles.
Vazamento de dados na terceirizada da Iwai Cosmo Securities (4.975 clientes): o que vazou, as ordens não intencionais e o que os clientes devem fazer
Em 16 de outubro de 2026, a Iwai Cosmo Securities Co., Ltd., corretora japonesa, anunciou por meio de uma divulgação oportuna de sua controladora Iwai Cosmo Holdings que o sistema de uma terceirizada usada para operar e manter seu sistema de negociação online havia sido acessado por terceiros, e que nomes, endereços de e-mail e outros dados (氏名、メールアドレス他) de 4.611 clientes de negociação online haviam vazado. A empresa detectou o acesso em 14 de outubro. Em seu segundo comunicado, em 20 de outubro, afirmou que uma revisão dos registros de acesso e de comunicação identificou mais 364 pessoas, elevando o total para 4.975; disse que isso não foi causado por nenhum acesso posterior. Os dados vazados não incluem senhas de negociação, e a empresa afirma que eles não podem ser usados para entrar em contas ou negociar. O segundo comunicado também revelou que, em 14 de outubro, o sistema de gestão de negociações também foi atacado, e ordens que os clientes não pretendiam foram lançadas em 7 contas (5 delas foram executadas). As negociações foram revertidas e os clientes não arcam com nenhum custo. A empresa diz que os dados pessoais vazados não foram usados nessas negociações. Diz também que o ponto que permitiu o acesso foi identificado e corrigido, e que a terceirizada adicionou medidas como restrições de acesso às funções de gestão. O método específico não foi divulgado. Nota deste site: não use links nem números de telefone em mensagens que se digam da Iwai Cosmo; confira seu histórico de ordens e execuções em uma página de login que você abriu por conta própria e entre em contato com a linha oficial (0120-405-546) em caso de dúvidas.
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.
Rank Math PRO 3.0.123 distribuído com malware (outubro de 2026): quem foi afetado e o que os donos de sites WordPress devem fazer
Em 16 de outubro de 2026 (UTC), o Rank Math anunciou que o Rank Math PRO v3.0.123, versão paga do seu plugin para WordPress, continha malware para um número limitado de usuários que o baixaram entre 20:02 UTC de 15 de outubro e 07:12 UTC de 16 de outubro. O malware poderia comprometer um site se o plugin fosse ativado e poderia recriar sua backdoor oculta sempre que o site fosse visitado. A empresa removeu os arquivos afetados e lançou a v3.0.124 limpa. A versão gratuita distribuída no WordPress.org não é afetada. Não foram divulgados nem o número de usuários afetados nem como o malware chegou aos arquivos. Até 20 de outubro, a última alteração do aviso foi em 19 de outubro, quando foi incluída uma nota de que a versão gratuita não é afetada. Conclusão deste site: trate qualquer site que tenha ativado uma cópia da 3.0.123 obtida durante o período afetado como comprometido e, ou restaure um backup feito antes do período, ou apague toda a pasta do plugin e faça a limpeza na ordem indicada pela empresa. Em qualquer caso, troque todas as credenciais que o site poderia acessar.
Possível vazamento de e-mails da JR East, VIEW Card e JR Kyushu (2026): o que fazer
Em 9 de outubro de 2026, a East Japan Railway Company (JR East), a VIEW Card Co., Ltd. e a Kyushu Railway Company (JR Kyushu) anunciaram cada uma que o serviço externo que usam para enviar e-mails a seus membros foi afetado por acesso não autorizado em um provedor de serviços em nuvem, e que não podem descartar que endereços de e-mail e outros dados dos membros tenham sido visualizados ou obtidos. Os números são, no máximo, cerca de 1,67 milhão de membros do eki-net e cerca de 390 mil membros do Otona no Kyujitsu Club (JR East); cerca de 4,03 milhões de endereços de e-mail de usuários do VIEW's NET (VIEW Card); e, no máximo, cerca de 1,3 milhão de membros do JR Kyushu Web (JR Kyushu). Para eki-net, VIEW's NET e membros do JR Kyushu Web, apenas endereços de e-mail estão envolvidos; para membros do Otona no Kyujitsu Club, também estão envolvidos o número de membro, a data de validade do cartão de crédito e a data de nascimento. Nomes, endereços, telefones e números de cartão estão excluídos. O provedor de serviços em nuvem afirmou que a interrupção iniciada no começo de 7 de outubro foi causada por um ataque de ransomware de terceiros. Em seu quinto relatório, em 14 de outubro, o provedor disse não ter encontrado nenhum rastro de dados nos servidores virtuais da área afetada sendo visualizados ou retirados, e concluiu que não houve vazamento externo de dados. Em 15 de outubro, após receber essas conclusões, a JR Kyushu anunciou que não foi confirmado nenhum vazamento de endereços de e-mail dos membros do JR Kyushu Web. O site do eki-net da JR East também informa que, em 15 de outubro, a empresa de serviço de envio de e-mails comunicou ter concluído que nenhum dado pessoal dos membros do eki-net vazou (verificado em 19 de outubro). Para membros do Otona no Kyujitsu Club e para a VIEW Card, este site não encontrou novidades até 19 de outubro (verificado no site de cada empresa). Em seu sétimo relatório, em 27 de outubro, o provedor de serviços em nuvem disse que sua investigação foi concluída e apontou como causa uma vulnerabilidade em um software de código aberto usado no sistema de autenticação de seu portal de gestão de clientes. Sua conclusão de que nenhum dado dos servidores virtuais vazou para o exterior não mudou. A visão deste site: a JR Kyushu disse que nenhum vazamento foi confirmado, e o eki-net afirma ter sido informado de que nenhum dado pessoal de seus membros vazou. Mesmo assim, e-mails falsos que usam este incidente como pretexto ainda podem chegar. Não faça login a partir de links em e-mails; verifique pelo aplicativo oficial ou por um favorito salvo por você mesmo.
Vazamento de dados da Daiwa Securities via fornecedor (cerca de 110.000 clientes, 220.000 registros): o que pode ter vazado e o que os clientes devem fazer
Em 5 de outubro de 2026, a Daiwa Securities Co. Ltd., uma das maiores corretoras do Japão, anunciou que o servidor de um fornecedor cujo serviço ela usa para gerenciar consultas online de clientes foi acessado sem autorização. Nomes, endereços de e-mail, números de conta e outras informações de 110.000 clientes, contidos em registros de consultas, podem ter vazado; incluindo consultas que não identificam ninguém, cerca de 220.000 registros estão envolvidos. O acesso ocorreu entre cerca de 20h33 de 2 de outubro e 8h01 de 3 de outubro, e não foi encontrado acesso não autorizado aos sistemas próprios da Daiwa. A empresa afirma que esses dados não podem ser usados para acessar contas ou negociar, inclusive por meio de negociação online, e que, até 5 de outubro, não foram encontradas negociações fraudulentas nem publicação ou disseminação dos dados. Em 6 de outubro, o lado do fornecedor publicou um aviso próprio: dados de consultas armazenados nos ambientes de até cinco empresas clientes no mesmo servidor, com até 713.126 registros contados por consulta, podem ter sido copiados. Citando o mesmo fornecedor, a Citizen Watch (cerca de 100.000 pessoas), a Sompo Japan (cerca de 60.000 registros contados por consulta) e a ORIX Life Insurance (cerca de 26.500 registros) também anunciaram que os dados de seus clientes podem ter vazado. A visão deste site: espere mensagens falsas que conheçam o número da sua conta e suas consultas anteriores. Nunca faça login a partir de links em e-mails ou mensagens de texto; acesse por um favorito ou pelo aplicativo oficial e verifique ali sua caixa de mensagens e seu histórico de operações.
Vazamento em massa do MOVEit (2023) — como um zero-day de SQL injection alcançou mais de 2.700 organizações, e como se defender
A entrada foi um zero-day de SQL injection (CVE-2023-34362) no MOVEit Transfer, exposto à internet. Um web shell (LEMURLOOT) foi plantado e dados foram roubados em massa do banco de dados de retaguarda, atingindo mais de 2.700 organizações e cerca de 93,3M de pessoas. A maioria das vítimas foi arrastada indiretamente porque um fornecedor usava o MOVEit. No seu ambiente: patch rápido de KEV, minimizar a exposição, menor privilégio e segmentação entre web↔DB, inventário de fornecedores e minimização de dados.
Instalando e usando o osv-scanner: encontre CVEs nas suas dependências automaticamente
O osv-scanner escaneia lockfiles e containers para revelar CVEs nas suas dependências, de graça. Este guia percorre a instalação, a execução e a integração ao CI, além de quando usá-lo vs. npm/pnpm audit vs. Dependabot. A visão deste site: qual ferramenta serve depende da sua configuração. Use o osv-scanner em projetos multi-ecossistema ou sem GitHub, e o pnpm audit embutido para uma única árvore npm.
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.
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.
O backdoor do XZ Utils (CVE-2024-3094) — um ataque à cadeia de suprimentos feito por um co-mantenedor confiável
Um mantenedor confiável plantou um backdoor no xz, num ataque à cadeia de suprimentos. Um engenheiro notou que os logins estavam lentos e o encontrou pouco antes das versões estáveis. O alvo não era o código; eram as pessoas e a confiança. Minimize dependências, fixe versões, faça builds reprodutíveis, persiga anomalias e apoie os mantenedores.