Outubro negro: o que aconteceu, quais plataformas de saúde digital estão expostas e o que fazer

Em menos de uma semana uma autoridade certificadora quebrou, as linguagens com que boa parte da internet é feita foram corrigidas às pressas e plataformas que guardam as chaves de milhares de desenvolvedores foram invadidas. Nas redes já o chamam de «Outubro negro». Isto é o que de fato aconteceu, o que significa para os sistemas de saúde e o que as organizações deveriam fazer hoje.

O nome se popularizou com uma publicação da conta @AISafetyMemes de 22 de outubro: «Estas são as 48 horas mais sérias da história da cibersegurança. Estão chamando de "Outubro negro"». Veículos como CNBC, Axios e 404 Media adotaram o termo, e vários o associam à velocidade com que as ferramentas de IA estão encontrando falhas. As do PHP, por exemplo, foram encontradas em agosto por pesquisadores da Wiz e da Calif com modelos de IA da OpenAI e do Google, segundo a CNBC. O ex-diretor da CISA Chris Krebs deu a medida: 3% de todas as vulnerabilidades críticas já descobertas apareceram no último mês. E o Relatório Global de Ameaças 2026 da CrowdStrike já registrava um aumento de 89% nos ataques de adversários que usam IA.

Uma ressalva antes de seguir: circularam nas redes versões exageradas de quase todos estes casos. Como observa a SecurityToday, o que se concentrou nestes dias foram sobretudo as divulgações; vários ataques estavam em curso havia semanas ou meses. Aqui contamos cada caso com o que dizem as fontes primárias, e indicamos onde o boato vai além dos fatos.

A confiança na internet: a eMudhra e suas chaves de um byte

A eMudhra é uma autoridade certificadora indiana: uma das empresas cujas assinaturas os navegadores usam para confirmar que um site é quem diz ser. Em 17 de outubro um pesquisador relatou ao Google que oito certificados intermediários da eMudhra tinham chaves privadas absurdamente fracas. Eram chaves de curva elíptica P-384, que deveriam ser números de 384 bits escolhidos ao acaso; em vez disso, eram inteiros menores que 256. Uma delas era, literalmente, o número 4. Os pesquisadores relataram também 56, 66, 115, 155, 156, 230 e 237.

Com uma chave assim, qualquer um podia reconstruí-la em menos de um segundo a partir do certificado público e emitir certificados válidos para qualquer site. A Mozilla recuperou as chaves por conta própria e as bloqueou naquela mesma noite, segundo seu relatório técnico e seu aviso de segurança. Chrome, Apple e Microsoft fizeram o mesmo entre 17 e 20 de outubro, e a confiança na raiz emSign ECC Root CA – G3 foi retirada. A eMudhra atribui o erro a uma etapa defeituosa da sua cerimônia de chaves de abril de 2025.

A ação caiu dois dias seguidos até o limite diário de 20% na bolsa de Bombaim, cerca de 36–38% em uma semana segundo o Business Standard. Em 22 de outubro a empresa anunciou que sai do negócio global de certificados SSL/TLS. Entre suas razões citou o baixo peso do negócio na receita, a concorrência de certificados gratuitos e que «a amplificação nas redes sociais» trouxe um escrutínio desproporcional; não assumiu a falha como causa. Antes, no fio técnico, a eMudhra havia culpado o «intenso escrutínio nas redes sociais» pelos seus atrasos, e o programa raiz do Chrome rejeitou essa explicação.

Por que isso importa além dos navegadores: os pacotes de certificados do Python (certifi), do Node.js e do Go também precisaram ser atualizados. Um servidor ou contêiner que não é reconstruído continua confiando nas chaves comprometidas, mesmo que o navegador do usuário já não confie.

As linguagens e servidores sobre os quais tudo roda

PHP: o caso que acendeu os alarmes

O PHP está por trás de cerca de 7 em cada 10 sites cuja linguagem de servidor é conhecida, segundo a W3Techs. Em 21 de outubro o projeto publicou correções de emergência para a PHP2Shell, duas falhas que permitem execução remota de código sem autenticação, que já analisamos em detalhe a propósito do OpenEMR.

A reação dos governos não tem precedente recente. A França tirou do ar os sites de suas prefeituras à espera da correção, e Países Baixos, Finlândia, Luxemburgo e várias administrações locais da Alemanha e do Reino Unido fizeram o mesmo por precaução. No Japão, a primeira-ministra Sanae Takaichi pediu publicamente às organizações que aplicassem a correção naquela mesma noite, e o Escritório Nacional de Cibersegurança lembrou que suspender temporariamente um site é uma medida válida para reduzir o risco (nippon.com). Nos Estados Unidos, a NSA recomendou desconectar o que não pudesse ser corrigido de imediato (Defense One). A União Europeia, por meio da ENISA e do CERT-EU, pediu que se considerasse isolar as aplicações expostas. Não houve desligamentos forçados nem foram relatadas invasões de sites governamentais: foram decisões preventivas.

A saúde não ficou de fora. Nos Países Baixos, hospitais como o Jeroen Bosch Ziekenhuis, o Amphia, o Elisabeth-TweeSteden e o Bravis tiraram seus sites do ar por precaução. O Jeroen Bosch esclareceu que o atendimento não foi afetado e que os pacientes continuavam consultando seu prontuário e gerenciando suas consultas (Omroep Brabant). Na Costa Rica, o Ministério de Ciência e Tecnologia (MICITT), por meio do CSIRT-CR, alertou em 20 de outubro as instituições públicas para que preparassem as correções, revisassem os registros de seus servidores e mantivessem backups isolados (Delfino). E os atacantes não esperaram: a Cloudflare detectou milhares de tentativas de exploração nas 10 horas anteriores ao anúncio, e milhões depois (The Guardian).

Python, Node.js, Java e Go

• Python. Não houve uma falha crítica de execução remota no interpretador, como se disse nas redes. Houve publicações de segurança aceleradas: o Python 3.14.9 e seus pares atualizaram os certificados por causa da eMudhra, e foi corrigido um path traversal no tarfile (CVE-2026-114583). A falha grave do mês esteve em uma biblioteca muito usada, a Pillow, que processa imagens e permitia executar código com arquivos EPS manipulados; é corrigida na Pillow 13.0.0.
• Node.js. O lançamento de segurança de 21 de outubro corrige 10 vulnerabilidades, quatro de severidade alta. Uma delas, no descompressor Brotli, pode levar a execução remota de código. As versões corrigidas são 26.12.1, 24.22.1 e 22.23.4; o Node 20 já não recebe correções.
• Java. A atualização trimestral da Oracle de 20 de outubro traz 55 correções para o Java SE, e o aviso do OpenJDK soma 47 vulnerabilidades. Nenhuma passa de 7,5 no CVSS: é uma atualização de rotina, mas com muitas falhas exploráveis a distância.
• Go. Duas publicações de segurança em outubro: a do dia 8 corrige 15 falhas, sobretudo de negação de serviço e contrabando de requisições HTTP; a do dia 19 acrescenta ao Go a desconfiança nos intermediários comprometidos da eMudhra.

NGINX e o kernel do Linux

O NGINX, o servidor web e proxy reverso usado por cerca de 30% dos sites cujo servidor é conhecido (W3Techs), publicou em 14 de outubro cinco correções. A F5 classifica três delas como críticas (9,2 no CVSS v4.0); o próprio projeto NGINX as classifica como médias porque só são exploráveis com configurações específicas. As versões corrigidas são 1.31.7 e 1.30.6.

No kernel do Linux, o Phoronix informou em 22 de outubro que a Zero Day Initiative enviou por engano seis relatórios de vulnerabilidades à lista pública do kernel, antes que existissem correções. Dos seis, dois permitem execução remota, ambos no KSMBD, o servidor SMB integrado ao kernel, que é opcional e raramente está ativo. Os outros quatro são escaladas de privilégio locais ou vazamentos de informação.

Plataformas e cadeia de suprimentos

• Railway. Esta plataforma para publicar aplicações confirmou que entre 20 e 22 de outubro um atacante extraiu e decifrou parte das variáveis de ambiente de seus clientes, buscando sobretudo chaves de provedores de IA. Até 1,85% dos espaços de trabalho pode ter sido exposto; nem todos os desenvolvedores foram afetados. Os deploys ficaram pausados por cerca de um dia e a Railway não recomendou encerrar contas. O que ela pede é rotacionar ou revogar as variáveis sensíveis e revisar o uso dos provedores conectados.
• LiteLLM. A ferramenta não rouba credenciais; o que aconteceu foi um ataque à sua cadeia de suprimentos. Em 21 de outubro foi publicada, por cerca de duas horas, uma versão maliciosa, a 1.107.0, no PyPI e no Docker Hub. Essa versão instalava um programa que roubava chaves de provedores e credenciais de nuvem e SSH, e deixava uma porta dos fundos (aviso oficial, Wiz). Quem a instalou deve considerar roubadas todas as credenciais a que aquela máquina tinha acesso. É o segundo comprometimento da LiteLLM em 2026.
• Plex. Atacantes encadearam quatro falhas do Plex Media Server, batizadas de Plex2Shell, para instalar mineradores de criptomoedas (BleepingComputer, Infobae). A correção é a versão 1.43.3 e, segundo o aviso da Plex, em muitos NAS é preciso instalá-la manualmente. Não há uma cifra pública de servidores infectados; há mais de 48 000 expostos.

Dados pessoais em grande escala

• Estudantes da Califórnia. Alguém usou um acesso roubado ao servidor de arquivos da ETS, a organização que aplica as provas estaduais, e copiou entre maio e setembro dados de estudantes dos últimos três anos letivos: nome, data de nascimento, endereço, notas, condição de deficiência e outros (SecurityWeek, Malwarebytes). Só no ano letivo 2025-26 há mais de 5,7 milhões de estudantes matriculados. Não tem relação com as falhas do kernel do Linux, como se afirmou nas redes: o roubo começou meses antes e foi feito com uma credencial válida.
• Faturamento do Medi-Cal. A Paradigm Healthcare Services, que processa o faturamento do Medi-Cal, o programa público de saúde da Califórnia, informou que uma invasão expôs nomes, datas de nascimento e números de afiliado de mais de 970 000 pessoas (SecurityWeek). O acesso ocorreu em outubro de 2025 e as cartas aos afetados saíram em setembro de 2026, quase um ano depois. É o risco dos terceiros que processam dados de saúde em nome de outros.
• Capcom. A empresa japonesa de videogames confirmou que foram expostos 11 774 247 registros de contas CAPCOM ID, principalmente e-mail e dados de login, e que 196 contas tiveram a senha alterada sem autorização. Em 19 delas os atacantes viram dados pessoais e de compras (atualização de 23 de outubro).

Nem as ferramentas de privacidade escaparam

• Signal. A Malwarebytes informou uma falha (CVE-2026-113380) pela qual outro participante de uma chamada podia impedir que ela se encerrasse por completo ao desligar, de modo que o áudio, e possivelmente o vídeo, continuava chegando a ele. Não é um ataque de um desconhecido, não quebra a criptografia e não há evidência de exploração. Está corrigida desde setembro: é preciso manter o Signal atualizado.
• Tor. Um pesquisador detectou 333 relays de saída, cerca de 10% do total, que redirecionavam o tráfego SSH para servidores do atacante. Não eram relays criados pelo atacante, e sim máquinas de voluntários comprometidas. Roubavam senhas de quem ignorava o aviso de mudança de chave do servidor. O Tor Project os retirou da rede entre 4 e 5 de outubro (lista tor-relays).

A IA entra nas contas bancárias

A jornalista Madison Mills revelou na Axios que grandes bancos dos Estados Unidos estão encontrando agentes de IA de terceiros operando dentro de contas de clientes, quase sempre com usuário e senha que o próprio cliente entregou. Um executivo admitiu que é difícil distinguir se um agente foi autorizado pelo usuário ou age por conta própria. Não é um ataque aos fundos, como a própria jornalista esclareceu à CBS, mas algo mais profundo: os sistemas não sabem quem está agindo em nome de quem. JPMorgan, Bank of America, Citi e Morgan Stanley já restringem ou bloqueiam esses agentes.

E a imprensa?

O PHP chegou ao noticiário geral. Na cobertura ao vivo da BBC, resumiu-se que seu correspondente de cibersegurança, Joe Tidy, não sabia que o PHP existia até o dia anterior, e que é «uma dessas coisas que damos como certas» (HackerNoon reproduz a captura). Além da zombaria nas redes, a frase retrata algo verdadeiro: a infraestrutura mais crítica é a que ninguém vê. Se a imprensa especializada tem dificuldade em acompanhá-la, a diretoria de um hospital tem mais ainda, e por isso essa conversa não pode ficar só nas mãos da equipe de TI.

Quais plataformas de saúde digital estão expostas?

Até agora não foi relatado nenhum hospital ou sistema de saúde comprometido por estes casos em particular. Mas quase todo o software que sustenta a saúde digital é construído sobre estas peças, o que o torna diretamente exposto. Este é um guia rápido:

O Java merece uma nota à parte. Boa parte da infraestrutura de interoperabilidade em saúde é escrita nessa linguagem, incluindo vários bens públicos digitais nos quais se apoiam ministérios e organismos de cooperação. As falhas de outubro no JDK não são as mais graves do mês, mas essas plataformas acumulam também suas próprias vulnerabilidades: em 2026 o DHIS2 corrigiu uma execução remota crítica e o Mirth Connect, falhas XXE exploráveis sem login. E a CVE-2023-43208, uma execução remota no Mirth, continua no catálogo de vulnerabilidades exploradas da CISA. Um motor de integração que recebe mensagens HL7 de toda a rede é, por definição, algo que convém manter em dia.

Plano de ação

Jason Clinton, vice-diretor de segurança da informação da Anthropic, disse assim aos responsáveis de segurança: vão agora às suas diretorias e peçam ajuda, «não para IA, para o básico» (CNBC). Sem entrar em detalhe técnico, estes são os passos que toda organização de saúde deveria ter em andamento:

1. Saber o que se tem. Um inventário de sistemas, versões e componentes (o chamado SBOM). Sem ele não há como responder à pergunta «isto nos afeta?».
2. Corrigir por prioridade. Primeiro o que está exposto à internet: portais, APIs FHIR, motores de integração. O que não puder ser corrigido hoje, isola-se. Para definir a ordem, o catálogo de vulnerabilidades exploradas da CISA pesa mais que a pontuação CVSS: entre a divulgação de uma falha grave e sua exploração já passam em média três dias, segundo a Rapid7 (SecurityToday).
3. Rotacionar os segredos. Se usou a Railway, a LiteLLM 1.107.0 ou mantém chaves em variáveis de ambiente de serviços afetados, troque-as, revise seu uso e defina uma data de validade.
4. Cuidar da cadeia de suprimentos. Fixar versões das dependências, reconstruir os contêineres em vez de corrigi-los à mão, e não atualizar às cegas para a versão «latest».
5. Revisar a confiança. Atualizar os repositórios de certificados de servidores e contêineres, e saber qual autoridade assina os certificados com que seus sistemas se comunicam entre si.
6. Governar a identidade dos agentes de IA. Nenhum agente deveria entrar com a senha de uma pessoa; precisa ter identidade própria, permissões limitadas e registro do que faz.
7. Estar pronto para responder e notificar. Um responsável definido, um plano de resposta testado e clareza sobre a obrigação de notificar a autoridade de proteção de dados (no Brasil, a ANPD) e os titulares afetados.

O que isto diz sobre padrões, interoperabilidade e arquitetura

O Outubro negro não é só uma lista de correções. Ele põe à prova a forma como desenhamos o intercâmbio de informação em saúde, e deixa cinco lições.

A interoperabilidade multiplica o alcance de uma falha. Um prontuário que expõe uma API FHIR, ou um motor de integração que recebe mensagens de dez hospitais, já não é um sistema isolado: é uma porta para toda a rede. Por isso a segurança tem de fazer parte da arquitetura desde o início. Um exemplo é uma camada FHIR que se interpõe entre o sistema legado e a internet, em vez de expô-lo diretamente. O Jeroen Bosch Ziekenhuis mostrou isso: desligou seu site institucional e seu portal do paciente continuou funcionando. Separar o público do clínico é uma decisão de arquitetura.

O padrão não é a implementação. Falar FHIR não torna um sistema seguro. A pesquisadora Alissa Knight mostrou isso em 2021 em Playing with FHIR: Hacking and Securing FHIR API Implementations, um estudo patrocinado pela Approov. Ela analisou APIs FHIR em produção que atendiam um ecossistema de 48 aplicações e APIs, com dados agregados de 25 000 prestadores e operadoras, e com uma única conta de paciente chegou a 4 milhões de registros de pacientes e clínicos (resumo da Approov). Cinco anos antes, seus achados já antecipavam o que este mês repetiu:

• Todas as APIs FHIR testadas deixavam ver dados de outros pacientes com as credenciais de um só. É a falha de autorização por objeto (BOLA) que encabeça o OWASP API Security Top 10, e o mesmo problema de fundo dos bancos: o sistema não verifica quem age em nome de quem.
• 53% dos apps móveis tinham chaves e tokens embutidos no código: o mesmo tipo de segredo roubado na Railway e na LiteLLM.
• Nenhum app impedia ataques de intermediário. É a confiança em certificados que a eMudhra quebrou.
• Metade dos agregadores não separava os bancos de dados de seus clientes, o contrário de guardar menos e separar o que é sensível.

Uma ressalva importante: não foram violados nem o padrão nem os repositórios FHIR dos fabricantes de prontuários. A HL7 International esclareceu que o estudo não encontrou falhas no FHIR nem nas APIs dos EHR testados; as brechas estavam nos aplicativos e nos agregadores intermediários, e por isso a autora mudou o título original. A segurança de um ecossistema FHIR é definida pelo seu elo mais fraco, e esse elo quase nunca é o padrão.

A confiança repousa em certificados, e os certificados também falham. O caso eMudhra atinge em cheio a saúde. O intercâmbio entre instituições usa TLS mútuo, o perfil IHE ATNA exige nós autenticados com certificados, a assinatura digital de documentos clínicos depende de uma cadeia de confiança e as redes nacionais como o X-Road, que a Costa Rica adota com seu Decreto de Interoperabilidade, repousam sobre serviços de confiança. Escolher bem a autoridade certificadora, controlar os repositórios de confiança e poder revogar rápido são decisões de arquitetura. É o que resolvemos com o Kivú eSignature.

Os padrões já resolvem o problema dos bancos. Um agente entrar com a senha do usuário é justamente o que o perfil IHE Internet User Authorization (IUA) evita. O IUA se apoia no OAuth 2.1: cada aplicação ou sistema obtém seu próprio token de acesso, de duração limitada e revogável. Esse token diz quem é o usuário, a que organização pertence, com que papel e com que finalidade age (atendimento, emergência, pesquisa) e sob qual consentimento do paciente. O servidor que guarda os dados decide com essa informação, não com uma senha compartilhada. A isso se soma a rastreabilidade: o IHE ATNA e o IHE BALP definem como registrar cada acesso em recursos AuditEvent do FHIR e, junto com o Provenance, deixam registro de quem fez o quê, em nome de quem e com qual autorização. Quando os agentes de IA chegarem aos portais de pacientes, e vão chegar, cada agente deveria ter seu próprio token e sua própria identidade, não a do paciente. A diferença entre um sistema preparado e um exposto estará em ter implementado esses perfis, não em bloquear às cegas.

Guardar menos é expor menos. A invasão na Califórnia expôs dados de deficiência e notas de milhões de menores que ficaram em um servidor de arquivos. Em saúde, a minimização de dados, a pseudonimização e uma modelagem de dados que separe o identificável do clínico reduzem o dano quando algo falha. E algo sempre falha.

Como podemos ajudar

Na Meddyg acompanhamos instituições de saúde na revisão de sua arquitetura com esses riscos em mente:

• Avaliação de interoperabilidade: que sistemas tem, o que expõem, sobre quais tecnologias rodam e quão preparada está sua organização.
• Definição de arquiteturas: intercâmbio seguro com HL7 FHIR, perfis IHE como IUA e ATNA, e X-Road, com identidade, auditoria e confiança desenhadas desde o início.
• Camada FHIR e Kivú FHIR: expor os dados por meio de padrões sem abrir os sistemas legados à internet.
• Kivú eSignature: assinatura digital e gestão de certificados verificáveis.

Se quiser saber quanto da sua operação depende das peças que quebraram neste mês, vamos conversar.

Fontes

• @AISafetyMemes: publicação sobre o «Outubro negro», 22 de outubro de 2026
• CNBC: o «Outubro negro» da IA
• The Guardian: especialistas alertam para uma nova era de ataques com IA
• CrowdStrike: Relatório Global de Ameaças 2026
• Omroep Brabant: sites de hospitais holandeses fora do ar
• Delfino: o MICITT alerta as instituições públicas sobre a PHP2Shell
• SecurityWeek: a invasão da Paradigm Healthcare
• SecurityToday: muitos ataques estavam em curso havia meses
• Mozilla Bugzilla 2083449: chaves fracas dos intermediários da eMudhra
• Mozilla: proteção do Firefox após o comprometimento da eMudhra
• eMudhra: saída do negócio de certificados SSL/TLS
• W3Techs: uso do PHP e uso do NGINX
• nippon.com: o pedido da primeira-ministra Takaichi
• Defense One: alerta da NSA sobre o PHP
• ENISA: declaração conjunta da UE sobre o PHP
• Python: anúncios de segurança
• Node.js: lançamentos de segurança de outubro de 2026
• Oracle: Critical Patch Update de outubro de 2026 e aviso do OpenJDK
• Go: histórico de versões
• NGINX: avisos de segurança
• Phoronix: vulnerabilidades do kernel publicadas por engano
• Railway: relatório preliminar do incidente
• LiteLLM: incidente de segurança de 21 de outubro
• Plex: atualização de segurança para a versão 1.43.2 e anteriores
• SecurityWeek: dados de estudantes da Califórnia
• Capcom: aviso de 22 de outubro e atualização de 23 de outubro
• Malwarebytes: a falha do Signal
• kaba.cx: relays de saída do Tor sequestrados
• Axios: agentes de IA não verificados em contas bancárias
• Approov e Alissa Knight: Playing with FHIR: Hacking and Securing FHIR API Implementations, outubro de 2021
• HL7 International: declaração sobre o estudo Playing with FHIR, 27 de outubro de 2021
• CISA: aviso médico ICSMA-26-253-01 (Mirth Connect)
• DHIS2: avisos de segurança